ES2895999T3

ES2895999T3 - Sistema y método informático para selección rápida de nombres en una base de datos de datos de personas

Info

Publication number: ES2895999T3
Application number: ES18248295T
Authority: ES
Inventors: Mateusz Pietrzyk
Original assignee: CRIF Sp Zoo
Current assignee: CRIF Sp Zoo
Priority date: 2017-12-29
Filing date: 2018-12-28
Publication date: 2022-02-23
Anticipated expiration: 2038-12-28
Also published as: EP3506123A1; PL424112A1; PT3506123T; PL3506123T3; EP3506123B1

Abstract

Un sistema informático (1), que comprende un equipo informático diseñado para conectarse a una base de datos (4) de datos de personas que almacena una pluralidad de registros, incluyendo cada registro al menos datos de nombres de persona respectivos y datos de localización de dirección respectivos, estando el equipo informático configurado para recuperar de la base de datos (4) registros de salida que coinciden con una solicitud de entrada, que incluye al menos un nombre y una dirección que se va a buscar, donde los datos de localización de dirección respectivos y la dirección que se va a buscar incluyen datos de referencia de dirección que definen una ciudad, un identificador de calle y un número de casa; y el equipo informático está configurado para: implementar la indexación de los registros de la base de datos en función de atributos de coordenadas geográficas derivados de los datos de localización de dirección respectivos; determinar los atributos de coordenadas geográficas correspondientes asociados con la dirección que se va a buscar; evaluar la proximidad geográfica entre los datos de localización de dirección respectivos y la dirección que se va a buscar, como una función de dichos atributos de coordenadas geográficas; evaluar la similitud de nombre entre los datos de nombres de personas respectivos y el nombre que se va a buscar en función de la distancia de Levenshtein implementando un autómata universal de Levenshtein ampliado configurado para tener en cuenta la semántica específica del idioma; y recuperar los registros de salida que coinciden con la solicitud de entrada, en función de una evaluación combinada de la similitud de nombre y la proximidad geográfica, donde la base de datos (4) se refiere a un territorio geográfico, y el equipo informático está configurado para dividir dicho territorio geográfico en una pluralidad de áreas de geolocalización en diferentes niveles jerárquicos de área geográfica (L); estando dichos atributos de coordenadas geográficas basados en los registros de la base de datos, o en la dirección que se va a buscar, que pertenecen a un área de geolocalización respectiva en un nivel jerárquico de área geográfica respectivo.

Description

DESCRIPCIÓN

Sistema y método informático para selección rápida de nombres en una base de datos de datos de personas REFERENCIA CRUZADA A SOLICITUDES

Esta solicitud de patente reivindica la prioridad de la solicitud de patente polaca N.° P. 424112 presentada el 29 de diciembre de 2017.

CAMPO TÉCNICO

La presente solución se refiere a un sistema y método informático para selección rápida de nombres en una base de datos de datos de personas.

ANTECEDENTES DE LA TÉCNICA

El problema de la selección rápida de nombres de personas / empresas (a continuación, solo se hará referencia a nombres de personas, en aras de la claridad, sin que esto implique una pérdida de generalidad) en grandes bases de datos de datos de personas es un tema común en los sistemas de información modernos. Uno de los elementos centrales de un sistema de información de cualquier empresa que proporciona bienes o servicios es, de hecho, una base de datos de nombres de personas junto con sus direcciones, números de teléfono y varios atributos adicionales. Una base de datos típica de datos de personas almacena una pluralidad de registros que contienen el nombre de la persona (nombre de pila y apellido) y la dirección (incluidas las coordenadas geográficas) que cubren la población de un área o país determinado. Las operaciones de selección en la base de datos prevén encontrar (identificar) registros o entradas en la base de datos que correspondan a una persona deseada en función de datos de entrada proporcionados.

Con una tecnología hipotéticamente perfecta, independientemente de la calidad de los datos proporcionados por el usuario (como criterios de búsqueda) y de la calidad del contenido de la base de datos, si la persona solicitada aparece en la base de datos, siempre debería ser encontrada. No obstante, en situaciones reales, los nombres de personas en la base de datos pueden contener errores (errores tipográficos, información faltante y/o información irrelevante); asimismo, la solicitud de búsqueda de entrada puede presentar los mismos problemas.

Estos errores pueden deberse a fallos humanos al introducir los datos, afectando la integridad / corrección de los datos o incluyendo información innecesaria; o incluso pueden ser el resultado de actos de mala fe y de comportamientos fraudulentos, en el caso de personas que deliberadamente desean presentarse como no identificadas y que, por lo tanto, combinan, a conciencia, todos los problemas mencionados, por ejemplo, tratando de "codificar" sus propios datos personales para "engañar" al sistema de identificación. Los errores descritos anteriormente también pueden deberse a problemas técnicos, por ejemplo, que resultan de la interoperación de diversos sistemas de procesamiento de información, tales como problemas de codificación, errores de OCR (reconocimiento óptico de caracteres) o similares.

Por lo tanto, un problema común en los sistemas de bases de datos conocidos se puede formular de la siguiente manera: dada una solicitud de entrada (que incluye al menos un nombre y una dirección), encontrar de forma eficaz nombres similares en los registros de la base de datos, con un nivel de precisión elevado y un tiempo de búsqueda breve.

HESHAM H ABDEL GHAFOUR ET AL, "AEDA: Arab edit distance algorithm Towards a new approach for Arabic name ^{matching", Computer Engineering&Systems (ICCES), 2011 International Conference On,}IeEE, ^{(20111129), páginas}307 - 311, describe un nuevo algoritmo para la coincidencia de cadenas en árabe que tiene en cuenta las características singulares del idioma árabe y los diferentes niveles de similitud de las letras árabes, como la similitud fonética y la similitud de forma de los caracteres, además de la distancia en el teclado. En particular, el documento describe una modificación del algoritmo original de Levenshtein para abordar la cuestión del peso / coste variable de varias operaciones de edición. Kevin Sahr ET AL, "Geodesic Discrete Global Grid Systems", Cartography and Geographic Information Science, páginas 121 -134, describe una serie de estructuras de datos para conjuntos de datos georreferenciados globales basados en particiones de poliedros regulares y de resolución múltiple. En particular, el documento describe un estudio de los sistemas más prometedores de este tipo, denominados sistemas de mallas globales y discretas geodésicos (DGGS geodésicos). CLODOVEU A. DAVIS et AL, "Assessing the Certainty of Locations Produced by an Address Geocoding System", GEOINFORMATICA, Boston, (2007-01-13), vol. 11, N.° 1, páginas 103 a 129, describe un esquema conceptual para direccionar bases de datos. El esquema es lo suficientemente flexible como para dar cabida a una variedad de sistemas de direccionamiento, en diversos niveles de detalle, y en diferentes países, apartándose de la estrategia habitual de geocodificación empleada en productos de SIG comerciales, que generalmente se limita al formato de dirección estándar estadounidense o británico. El esquema también amplía la noción de dirección postal, incluyendo nombres conocidos de lugares, nombres de edificios, lugares de referencia y otros conceptos.

DESCRIPCIÓN DE LA INVENCIÓN

El objetivo de la presente solución es resolver, al menos parcialmente, los problemas anteriormente destacados y, en general, proporcionar soluciones automatizadas mejoradas para la selección rápida de nombres en una gran base de datos de datos de personas.

De acuerdo con la presente solución, se proporcionan un sistema informático y un método informático, como se define en las reivindicaciones adjuntas.

BREVE DESCRIPCIÓN DE LOS DIBUJOS

Para una mejor comprensión de la presente invención, a continuación se describen realizaciones preferidas de la misma, meramente como ejemplos no taxativos, con referencia a los dibujos adjuntos, donde:

- La Figura 1 es un diagrama de bloques esquemático de un sistema informático según la presente solución;

- las Figuras 2A-2B, 3A-3B, 4A-4E, 5A-5B muestran áreas geográficas jerárquicas ejemplares que se utilizan para indexar datos en una base de datos de personas, de acuerdo con aspectos de la presente solución; y

- las Figuras 6-9 son diagramas de flujo relacionados con operaciones realizadas en el sistema informático, de acuerdo con aspectos adicionales de la presente solución.

MEJOR MODO DE LLEVAR A CABO LA INVENCIÓN

En general, la presente solución se refiere al campo del establecimiento de coincidencias por similitud entre registros de bases de datos.

El campo del establecimiento de coincidencias por similitud ofrece una amplia base de investigación; entre los desarrollos recientes se incluyen las siguientes fuentes:

Klaus U. Schulz, Stoyan Mihov, "Fast String Correction with Levenshtein-Automata", International Journal on Document Analysis and Recognition, noviembre 2002, Volumen 5, Número 1, páginas 67-85; y Petar N. Mitankin, "Universal Levenshtein Automata. Building and Properties (Thesis)", Sofía, 2005, Universidad St. Kliment Ohridski.

Estos documentos describen el concepto de autómata universal de Levenshtein (ULA), que es una máquina de estados finitos creada para una distancia de Levenshtein dada (por ejemplo, 1 o 2), que es capaz de encontrar rápidamente para una base de datos de cadenas determinada y una cadena de entrada todas las cadenas de la base de datos con la distancia de Levenshtein asumida de la cadena de entrada; la distancia de Levenshtein mide la diferencia entre dos cadenas de caracteres como un número mínimo de cambios atómicos que se requieren para convertir la primera cadena de caracteres en la segunda cadena de caracteres (los cambios atómicos son, por ejemplo, la inserción, la eliminación y el reemplazo de una letra individual).

El concepto de ULA es genérico: no tiene en cuenta la semántica del idioma. En otras palabras, para un nombre de entrada "ROS", se devolverían tanto "ROZ" como "ROB" como cadenas igualmente similares, teniendo ambas una distancia de Levenshtein de 1 contra el nombre de entrada. Sin embargo, en aplicaciones de la vida real, teniendo en cuenta el contexto del idioma, el par «ROS / ROZ» tiene una similitud mucho mayor que el par «ROS / ROB»; de hecho, el segundo ejemplo podría ni siquiera ser tratado como similar, ya que son nombres de pila diferentes.

Por otra parte, la aplicación del ULA en el campo de las grandes bases de datos de datos de personas generalmente no permite obtener una respuesta de identificación rápida.

Por lo tanto, como se detallará a continuación, entre los aspectos de la presente solución se prevé lo siguiente: - indexación de nombres en la base de datos con atributos de coordenadas geográficas, lo que permite una búsqueda rápida de nombres similares con proximidad geográfica respecto de una dirección de entrada dada, donde la similitud de nombre y la proximidad geográfica se evalúan conjuntamente para formar una medida ponderada (por ejemplo, se puede considerar que los nombres más similares que están lejos geográficamente de la entrada difieren más que los nombres menos similares cercanos geográficamente a la entrada); y

- ampliación del concepto de ULA (en lo sucesivo denominado EULA, ULA ampliado), de modo que admita la búsqueda de nombres (de pila, apellido) por similitud en cuanto a idioma, teniendo en cuenta la semántica específica del idioma. Como se muestra esquemáticamente en la Figura 1, la presente solución se implementa generalmente como un sistema informático 1, que puede incluir una cantidad de equipos informáticos 2, por ejemplo, un ordenador personal, un ordenador portátil o cualquier tipo de unidad de procesamiento que incluya un procesador de datos y que proporcione una interfaz de usuario de entrada, conectados (por ejemplo, en una relación de cliente a servidor) a una base de datos de personas 4 (PDB), que almacena datos personales como registros (o entradas).

Cada equipo informático 2 está conectado a la base de datos de personas 4 a través de un enlace de comunicación 5 y de cualquier tipo de interfaz de comunicación, por ejemplo, a través de una interfaz de red o una interfaz gráfica de usuario; la base de datos de personas 4 está dispuesta generalmente de forma remota con respecto a los equipos informáticos 2, asociada con un servidor dedicado 4' que tiene una unidad de procesamiento respectiva.

El equipo informático 2 y el servidor 4' cooperan para ejecutar un método automatizado de selección rápida de nombres en los registros de datos personales almacenados en la base de datos de personas 4, en función de una solicitud de entrada proporcionada a través de la interfaz de usuario de entrada; de acuerdo con una realización, la unidad de procesamiento del servidor 4' está diseñada para ejecutar instrucciones de programa informático para permitir la selección rápida de nombres en la base de datos de personas 4 en respuesta a la solicitud de entrada.

A continuación, se describirá en detalle el método automatizado implementado por el sistema informático 1; no obstante, aunque no siempre se haga referencia al sistema informático 1, se entiende que el método automatizado se ejecuta en el mismo sistema informático 1.

De acuerdo con una realización, la base de datos de personas 4 se trata conceptualmente como un conjunto de registros que tiene la siguiente forma:

[recordID; firstName; lastName; SID; houseNumber; coordenadas geográficas].

donde SID (identificador de calle) es un identificador único asignado a una calle en función de la referencia de dirección postal; de hecho, se asume que cada registro de la base de datos de personas 4, además de los tokens de nombre de pila y apellido de la persona asociada y las coordenadas geográficas de la dirección, contiene el SID de la dirección y el número de casa asociado con la dirección.

Primero se describe una jerarquía de áreas de geolocalización utilizadas para la indexación de nombres de base de datos; partiendo del área de geolocalización más pequeña hasta llegar al área de geolocalización más grande, estas áreas de geolocalización son las siguientes:

- GID: un área cuadrada, por ejemplo, de aproximadamente 500 m x 500 m;

- SGS: los alrededores de una calle;

- GACID: un área que abarca un grupo de ciudades / pueblos «administrativos»; y

- GLOBAL: todo el territorio o país.

Más detalladamente, se asume que cada dirección en la base de datos de personas 4 (en particular, una casa correspondiente) tiene atributos de geolocalización (en términos de latitud y longitud).

Los atributos de geolocalización sin procesar no son adecuados para indexación de bases de datos, ya que una única búsqueda en índice solo devolvería un único punto geográfico (es decir, una sola casa). Por lo tanto, se introduce el concepto de Geo-ID (abreviado GID), que proporciona lo siguiente: granularidad más gruesa que las coordenadas geográficas sin procesar y facilidad de búsqueda en índice de puntos geográficos vecinos.

Los GID se crean de la siguiente manera: toda el área geográfica (por ejemplo, Europa) está cubierta por una cuadrícula de cuadrados, de aproximadamente 500 m x 500 m; cada cuadrado se identifica mediante coordenadas x e y que, combinadas en un valor entero, definen un GID. La combinación de dos coordenadas (x, y) en un solo valor entero se realiza, por ejemplo, de la siguiente manera:

(x << 16) | y

donde "<<" es el operador binario de DESPLAZAMIENTO a la IZQUIERDA, y "|" es el operador binario O.

Las Figuras 2A-2B muestran un GID ejemplar, en una porción de un área geográfica; también se muestran en la Figura 2B otros GID circundantes, adyacentes al GID ejemplar, identificado en la figura con el número 6.

Las operaciones básicas en los GID incluyen el análisis de coordenadas geográficas reales (latitud, longitud) desde un GID y viceversa, por ejemplo, de acuerdo con las siguientes expresiones:

x(longitud) = (longitud - -10,00000) / 0,00675;

y(latitud) = (latitud - 30,00000) / 0,00450;

getGid(x, y) = (x « 16) | y

getX(gid) = gid >>> 16

getY(gid) = gid & OxFFFF

La longitud mínima (en el ejemplo, -10,00000) y la latitud mínima (en el ejemplo, 30,00000) se eligen para que la infraestructura del GID pueda cubrir toda Europa. Las etapas de longitud y latitud (en el ejemplo, 0,00675 y 0,00450) se eligen de modo que formen aproximadamente un cuadrado de 500 m x 500 m en el centro de Europa (esta aproximación es suficiente para realizar la indexación; no es necesario considerar la curvatura de la Tierra); esta configuración permite que el GID sea un valor entero de 4 bytes. El concepto es fácilmente ampliable para cubrir el mundo entero, usando un entero más largo para el GID (por ejemplo, un valor de 8 bytes), o territorios incluso más pequeños.

Además, las operaciones básicas en los GID incluyen:

- la transformación del GID en coordenadas geográficas reales aproximadas (en el centro del cuadrado del GID) es una simple inversión de la transformación anterior con un desplazamiento hacia el centro del cuadrado del GID; - para cierto GID, se pueden determinar GID circundantes, que se desplazan hacia el norte / sur / este / oeste, con las siguientes expresiones:

directionNorth getGid(getX(gid), getY(gid)+1);

directionSouth getGid(getX(gid), getY(gid)-1);

directionEast getGid(getX(gid)+1, getY(gid));

directionWest getGid(getX(gid)-1, getY(gid)).

Usando las transformaciones anteriores, se puede calcular fácilmente el conjunto de GID cercanos a un GID dado. Las Figuras 3A y 3B muestran la representación real de los GID para dos países ejemplares, Alemania y Polonia, donde cada píxel (en la imagen original, no redimensionada) es un GID, y la población del GID está representada según la intensidad del color.

El concepto de GID descrito anteriormente es un bloque de construcción básico y el objeto «más pequeño» en el que se realizará la indexación de nombres de base de datos; el siguiente objeto en la jerarquía se denomina «entorno geográfico de la calle» (SGS), donde se supone que «calle» abarca la combinación de calle y código postal (por lo tanto, una calle real que se extiende en múltiples códigos postales se tratará como múltiples «calles»).

El entorno geográfico de la calle SGS de una localización es un SID de asignación -> {SID1, SID2, ..., SIDn}, donde la lista asignada de los SID representa todas las calles que rodean geográficamente a un SID dado; se asume que la lista de calles circundantes incluye la calle en sí.

Con referencia a las Figuras 4A-4D, las calles circundantes de un SID 7 dado se encuentran con el siguiente algoritmo de búsqueda de SGS:

- encontrar todos los GID (y sus correspondientes coordenadas (x,y)) para el SID dado, como se muestra en la Figura 4A; esto se puede lograr iterando por todas las casas (a partir de la referencia de la dirección postal) para el SID 7 dado;

- a partir de los GID mencionados, encontrar valores mínimos / máximos de las coordenadas x e y, como se muestra en la Figura 4B;

- obtener todos los GID determinados por los valores mínimos / máximos de x e y mencionados, como se muestra en la Figura 4C;

- obtener todos los SID que cruzan todos los GID encontrados en la operación anterior, como se muestra en la Figura 4D.

De acuerdo con un aspecto de la solución, el SGS determinado de esta manera se puede «recortar» en función de la población contenida en el mismo.

De hecho, como se ha comentado anteriormente, el SGS solo depende de los datos de referencia de la dirección postal; es independiente de la base de datos de personas 4. Dado que el SGS es, sin embargo, sólo un instrumento de indexación para obtener los registros reales (es decir, nombres de personas similares) en el entorno geográfico de una calle determinada, puede surgir un problema en relación con el número impredecible de registros reales en el SGS (es decir, los registros en calles pertenecientes al SGS); este número puede dispararse a millones para zonas congestionadas de grandes ciudades.

Por lo tanto, se puede introducir una versión "recortada" del entorno geográfico de la calle SGS que tenga en cuenta el contenido de la base de datos de personas 4.

En primer lugar, para cada SID, el número de registros de base de datos únicos, en términos de pares (firstName, lastName), se determina como la "población de nombres del SID". En lugar de agregar todos los SID que atraviesan todos los GID encontrados (como se especificó anteriormente), el algoritmo de búsqueda de SGS descrito anteriormente para el «entorno recortado» puede prever lo siguiente:

- ordenar todos los GID encontrados, por la distancia geográfica al centro del área que se muestra en la Figura 4B; y - comenzar con el SID 7 de «origen» y seguir añadiendo los GID mencionados (es decir, los SID que los cruzan) hasta que la población total de nombres de todos los SID añadidos hasta entonces sea superior a un umbral máximo de población, por ejemplo, 50.000 (esto garantiza que la población circundante se mantenga dentro de ciertos límites, es decir, que no supere el umbral máximo establecido).

La Figura 4E muestra la versión recortada del SGS, teniendo en cuenta el ejemplo mostrado en la Figura 4D anterior. El siguiente objeto en la jerarquía de áreas geográficas es la «ciudad administrativa agrupadora», GACID, que está diseñada para representar un gran área que abarca ciudades enteras, o regiones en un país, que están conectadas por el nombre de la ciudad y/o la parte más significativa del código postal. El GACID se puede construir usando el siguiente algoritmo:

- establecer una asignación entre el prefijo del código postal, por ejemplo, formado por los tres primeros dígitos del mismo, y el conjunto de ciudades que tengan dicho prefijo;

- para cada uno de los conjuntos de ciudades determinadas anteriormente, se elige la ciudad más grande del conjunto y se establece una asignación entre esta ciudad más grande y todas las demás ciudades del conjunto.

De esta manera, se establece una asignación con la forma {city} -> {parentCity}, donde cada «ciudad madre» define el centro de un GACID; un único GACID es, de hecho, una ciudad X con todas sus ciudades circundantes (es decir, ciudades que tienen X como su «ciudad madre» en la asignación del GACID).

Las Figuras 5A y 5B muestran la representación real de GACID para dos países ejemplares, de nuevo, Alemania y Polonia.

El último elemento de la jerarquía de áreas geográficas es todo el territorio o país, GLOBAL: en términos de la base de datos de personas 4, simplemente significa toda la base de datos.

A continuación y también con referencia a la Figura 6, se explica con mayor detalle la indexación de los datos contenidos en la base de datos de personas 4, en función de la jerarquía de áreas geográficas.

En particular, para cada uno de los niveles de área geográfica, en la presente designados con la letra L, en la jerarquía mencionada que incluye (GID, SGS, GACID, GLOBAL):

- en la etapa 10, la base de datos de personas 4 se divide en una lista de objetos de base de datos PDB_L_1, ..., PDB_L_nL, donde cada uno de los objetos de base de datos PDB_L_i contiene datos de un área geográfica respectiva L_i, donde nLes el número total de áreas geográficas en el nivel de área respectiva L (por ejemplo, tomando la base de datos de personas 4 de Alemania, hay: ~500k de objetos de base de datos GID PDB_GID_i; 1m de objetos de base de datos SGS PDB_SGS_i; 600 objetos de base de datos GACID PDB_GACID_i; y una única base de datos/índice GLOBAL PDB_GLOBAL);

- en la etapa 12, se crean dos autómatas de diccionario (un "autómata" es una máquina de estados finitos que reconoce cadenas que pertenecen a un diccionario dado, como se detallará a continuación) para cada objeto de base de datos PDB_L_i, uno para tokens de nombre de pila y el otro para tokens de apellido contenidos en los mismos

- en la etapa 14, se crean dos listas indexadas para cada objeto de base de datos PDB_L_i: una lista indexada de nombres de pila, que incluye una lista de identificadores ordenados (recordID) de registros en la base de datos de personas 4 que contienen determinados tokens de nombre de pila; y una lista indexada de apellidos, que incluye una lista de identificadores ordenados de registros que contienen determinados tokens de apellido (teniendo en cuenta que se crea una lista para cada uno de los tokens de nombre de pila / apellido, al final hay tantas listas como tokens). En la descripción anterior, se subraya que el término «objeto de base de datos PDB_L_i» se utiliza conceptualmente: no significa necesariamente un elemento de un sistema de gestión de bases de datos, DBMS; también podría ser un fichero, una estructura de datos en memoria o similar.

Todas las bases de datos / listas indexadas mencionadas forman el denominado Índice de personas de la base de datos de personas 4, donde cada uno de los objetos de base de datos PDB_L_i tiene exactamente la misma estructura, por ejemplo:

{

FNDict: {FRANK, MICHAEL, PETER, JOHN, ...}

LNDict: {MEIER, SMITH, PETERS, ...}

FN Index:

FRANK {id, id, id, ... }

JOHN { id, id, id, ... }

MICHAEL{id, id, id, ... }

PETER {id, id, id, ... }

LN Index:

MEIER {id, id, id, ... }

PETERS {id, id, id, ... }

SMITH {id, id, id, ... }

}

En particular, cada objeto de base de datos PDB_L_i contiene: un diccionario de nombres de pila, que incluye los tokens de nombre de pila que se encuentran en el área geográfica respectiva; un diccionario de apellidos, que incluye los tokens de apellido que se encuentran en el área geográfica respectiva; y, para cada token de nombre de pila y apellido dado, listas indexadas FN / LN de los identificadores (recordID) de los registros de la base de datos de personas 4 que contienen los tokens de nombre de pila y apellido dados (antes designados, en general, con la abreviatura "id") .

El Índice de personas generado de la base de datos de personas 4 permite identificar y seleccionar rápidamente registros similares en la base de datos de personas 4, en respuesta a una consulta de entrada, la llamada operación de «búsqueda en índice»; esta operación combina ventajosamente el concepto de ULA ampliado (que se discutirá con más detalle a continuación) con el concepto mencionado de la jerarquía de áreas geográficas.

En particular, se implementan dos ULA ampliados estáticos, EULA(1) y EULA(2) (que se describirán en detalle a continuación) para encontrar nombres de pila / apellidos similares en los autómatas de diccionario de los objetos de base de datos PDB_L_i (con similitud con distancias de Levenshtein 1 y 2, respectivamente). Para encontrar nombres de pila / apellidos exactos (es decir, resultados con distancia de Levenshtein 0), basta con realizar una búsqueda directa en las listas indexadas FN / LN, sin implementar el EULA.

En detalle, y con referencia también a la Figura 7, en la etapa 20, el módulo informático 2 recibe una solicitud de entrada, que incluye la persona / dirección que se va a buscar, incluyéndose el nombre de pila, apellido y dirección de la persona que se va a buscar en la base de datos de personas 4.

En la etapa 21, teniendo en cuenta la dirección de la solicitud de entrada, en función de los datos de referencia postal, se encuentran la ciudad, el SID y el houseNumber de la dirección; eso, a su vez, permite determinar el GID, GSG y GACID reales asociados con esa dirección, es decir, las áreas geográficas jerárquicas asociadas con la dirección de entrada.

Habiendo determinado el GID, GSG y GACID de la dirección de entrada, se realiza una búsqueda en cada uno de los niveles de área geográfica L en la etapa 22, para recuperar el PDB_L_i respectivo en el Índice de personas (aquí, «i» se refiere a los GID, GSG y GACID reales asociados a la solicitud de entrada) . Por ejemplo, si la solicitud de entrada da GID=5, GSG=10, GACID =20, entonces en el Índice de personas se consideran p Db_GID_5, PDB_GSG_10 y PDB_GACID_20; obviamente, en el ejemplo considerado, PDB_GLOBAL_1 no necesita ninguna búsqueda ya que solo hay un PDB GLOBAL, que corresponde a toda la base de datos de personas 4.

A continuación, en la etapa 23, teniendo en cuenta el firstName (FN) de la solicitud de entrada y los objetos de base de datos PDB_L_i recuperados para cada uno de los niveles de área geográfica L, se realiza una búsqueda del nombre de pila FN para recuperar las respectivas coincidencias de token de nombre de pila, de la siguiente manera:

- primero se recuperan los nombres de pila con distancia de Levenshtein 0 contra el firstName FN de entrada, realizando una búsqueda directa en las listas indexadas FN de los objetos de base de datos PDB_L_i;

- se recuperan los nombres de pila con distancia de Levenshtein 1 implementando el EULA(1) en los diccionarios de nombres de pila de los objetos de base de datos PDB_L_i, de acuerdo con la siguiente expresión:

EULA(1) (FN, PDB_L_i_FNDict) = { fnc_L_1_1, ..., fnc_L_1_n };

- se recuperan los nombres de pila con distancia de Levenshtein 2 utilizando el EULA(2), de acuerdo con la siguiente expresión:

EULA(2) (FN, PDB_L_i_FNDict) = { fnc_L_2_1, ..., fnc_L_2_m }.

Cada fnc_L_0_j, fnc_L_1_j, fnc_L_2_j representa una coincidencia de token de nombre respectiva en el nivel jerárquico respectivo L, con distancia de Levenshtein 0, 1 o 2.

De manera acorde, teniendo en cuenta el lastName (LN) de la solicitud de entrada, se realiza una búsqueda del apellido LN para recuperar coincidencias de token de apellido, de la siguiente manera:

- primero se recuperan los apellidos con distancia 0 contra el lastName LN de entrada realizando una búsqueda directa en las listas indexadas LN del PDB_L_i;

- se recuperan los apellidos con distancia 1 utilizando el EULA(1), de acuerdo con la siguiente expresión:

EULA(1) (LN, PDB_L_i_LNDict) = { lnc_L_1_1, ..., lnc_L_1_p };

- se recuperan los apellidos con distancia 2 utilizando el EULA(2), de acuerdo con la siguiente expresión:

EULA(2) (LN, PDB_L_i_LNDict) = { lnc_L_2_1, ..., lnc_L_2_q }.

De nuevo, cada lnc_L_0_j, lnc_L_1_j, lnc_L_2_j representa una coincidencia de token de apellido respectiva en el nivel jerárquico respectivo L, con distancia de Levenshtein 0, 1 o 2.

Luego, en la etapa 24, usando las listas indexadas FN / LN en cada uno de los PDB_L_i, se pueden generar listas de identificadores de registro (RID) de base de datos ordenados para cada una de las coincidencias de token de nombre de pila / apellido encontradas en la etapa anterior 23. En particular, una lista indexada respectiva de registros está asociada con cada uno de fnc_L_0_j, fnc_L_1_j, fnc_L_2_j y lnc_L_0_j, lnc_L_1_j, lnc_L_2_j (cada lista indexada se encuentra en un nivel jerárquico respectivo L y para una distancia de Levenshtein respectiva 0, 1 o 2).

Por lo tanto, los resultados del procedimiento de búsqueda se pueden resumir de la siguiente manera:

Coincidencias de GID

nombres de pila con dist 0:

FN -> { RID, ... }

apellidos con dist 0:

LN -> { RID, ... }

nombres de pila con dist 1:

fnc_GID_1_1 -> { RID, .. }

fnc_GID_1_n -> { RID, .. }

apellidos con dist 1

lnc_GID_1_1 -> { RID, . }

lnc_GID_1_p -> { RID, . }

nombres de pila con dist 2

fnc_GID_2_1 -> { RID, .. }

fnc_GID_2_m -> { RID, . }

apellidos con dist 2

lnc_GID_2_1 -> { RID ,. }

lnc_GID_2_q -> { RID, .. }

Coincidencias de SGS

nombres de pila con dist 0

FN -> { RID, .. }

apellidos con dist 0

LN -> { RID, .. }

nombres de pila con dist 1

fnc_SGS_1_1 -> { RID, . }

fnc_SGS_1_n -> { RID, . }

apellidos con dist 1

lnc_SGS_1_1 -> { RID, . }

lnc_SGS_1_p -> { RID, . }

nombres de pila con dist 2

fnc_SGS_2_1 -> { RID, . }

fnc_SGS_2_m -> { RID, .. }

apellidos con dist 2

lnc_SGS_2_1 -> { RID, . }

lnc_SGS_2_q -> { RID, .. }

Coincidencias de GACID

nombres de pila con dist 0

FN -> { RID, .. }

apellidos con dist 0

LN -> { RID, .. }

nombres de pila con dist 1

fnc_GACID_1_1 -> { RID, .. }

fnc_GACID_1_n -> { RID, .. }

apellidos con dist 1

1nc_GACID_1_1 -> { RID, . }

lnc GACID 1p -> { RID, . }

nombres depila con dist 2

fnc GACID 21 -> { RID, . }

fnc GACID 2m -> { RID, . }

apellidos con dist 2

lnc GACID 21 -> { RID, . }

lnc GACID 2q -> { RID, . }

Coincidencias de GLOBAL

nombres depila con dist 0

FN -> { RID, .. }

apellidos con dist 0

LN -> { RID, .. }

nombres depila con dist 1

fnc_GLOBAL_1_1 -> {RID, .. }

fnc_GLOBAL_1_n -> {RID, .. }

apellidos con dist 1

lnc_GLOBAL_1_1

lnc_GLOBAL_1_p -> {RID, ... }

nombres depila con dist 2

fnc_GLOBAL_2_1 -> {RID, ... }

fnc_GLOBAL_2_m-> {RID, ... }

apellidos con dist 2

lnc_GLOBAL_2_1 -> {RID, ... }

lnc_GLOBAL_2_q -> {RID, ... }

En el paso 25, todas las listas de coincidencias mencionadas se pueden reorganizar en dos conjuntos, uno para los nombres de pila y otro para los apellidos. Cada elemento de los conjuntos es una lista de coincidencias para una coincidencia de token de nombre de pila / apellido respectiva, designada, en lo sucesivo, «token_GDIST_LDIST», a la que se asocian dos atributos:

- la distancia geográfica contra la dirección de entrada: GDIST (GID, SGS, GACID o GLOBAL); y

- la distancia de Levenshtein contra el nombre de entrada: LDIST (0, 1 o 2) .

Los dos conjuntos de listas de coincidencias (incluidas las respectivas listas indexadas de identificadores de registros de base de datos RID) son los siguientes:

Coincidencias de NOMBRE DE PILA

{

fnc_GDIST_LDIST_1 -> {RID, ... }

fnc_GDIST_LDIST_N -> {RID, ... }

}

Coincidencias de APELLIDO

{

lnc_GDIST_LDIST_1 -> { RID, ... }

lnc_GDIST_LDIST_M -> {RID, ... }

}

En la etapa 26, se determinan los resultados del algoritmo de búsqueda, calculando las intersecciones de los identificadores de registro RID obtenidos, seleccionando una lista indexada de las coincidencias de nombre de pila y una lista de las coincidencias de apellido.

Puede haber tantos como NxM de tales resultados (dependiendo de la elección de las listas de coincidencias de NOMBRE DE PILA y APELLIDO), siendo N el número total de coincidencias de nombre de pila y M el número total de coincidencias de apellido. De acuerdo con una posible realización, solo se pueden seleccionar listas indexadas con la misma distancia geográfica para calcular las intersecciones mencionadas, por lo que la cantidad útil de combinaciones puede ser menor.

En cualquier caso, el resultado final del algoritmo de selección (es decir, el resultado de las intersecciones mencionadas) es una cantidad de registros de salida que tienen asociados tres parámetros de salida:

- Distancia de Levenshtein LDIST del nombre de pila: (0, 1 o 2);

- Distancia de Levenshtein LDIST del apellido: (0, 1 o 2); y

- distancia geográfica GDIST: (GID, SGS, GACID o GLOBAL).

Estos parámetros de salida permiten calcular una medida ponderada de similitud para cada registro de salida recuperado (equilibrando la distancia de Levenshtein del token de nombre de pila / apellido con la distancia geográfica de la solicitud de entrada), en el paso 27.

Los pesos reales que se aplicarán a cada parámetro dependen de la aplicación real y de las características reales de los datos en la base de datos personales. Por ejemplo, si hay muchos errores en los nombres de pila y apellidos de los registros, puede ser conveniente aplicar pesos de menor valor a la distancia de Levenshtein LDIST, con respecto a la distancia geográfica GDIST, en la medida ponderada de similitud.

A continuación se describirá con mayor detalle el concepto de ULA ampliado (EULA), utilizado en el algoritmo de búsqueda para la búsqueda de similitud de nombres en la base de datos de personas 4.

La entrada al ULA contiene dos elementos:

- una cadena de entrada (en el ejemplo descrito anteriormente, el nombre de pila / apellido de entrada que se va a buscar);

- una base de datos de cadenas que se van a buscar en forma de «autómata de diccionario», es decir, una máquina de estados finitos que reconoce cadenas que pertenecen a un diccionario dado (en el ejemplo descrito anteriormente, los diccionarios de nombres de pila o apellidos en los objetos de base de datos PDB_L_i).

Con la entrada mencionada, el ULA está configurado para «recorrer» el autómata de diccionario (es decir, moverlo de un estado a otro), donde cada estado es «de aceptación» o de «no aceptación» (es decir, la cadena vista hasta entonces pertenece al diccionario, o no); este recorrido es dirigido por la cadena de entrada.

La salida (después del recorrido) es el subconjunto de la base de datos en la que se buscaron las cadenas, con determinada distancia de Levenshtein con respecto a la cadena de entrada.

En particular, como se indicó anteriormente, se consideran dos ULA: ULA(1), que reconoce cadenas con distancia de Levenshtein 1 contra una cadena de entrada determinada, y ULA(2) que reconoce cadenas con distancia de Levenshtein 2 contra la cadena de entrada determinada.

El concepto genérico de ULA no tiene en cuenta la semántica específica del idioma. Por ejemplo, teniendo en cuenta las lenguas europeas, una sustitución de una consonante por una consonante diferente (por ejemplo, G -> P) generalmente tiene un peso mucho mayor que una sustitución de dos vocales (por ejemplo, A -> E). Por lo tanto, un ULA genérico generaría muchas coincidencias irrelevantes que, de hecho, tienen la distancia de Levenshtein solicitada, pero que tienen una «similitud natural de idioma» muy baja. Además, al escanear diccionarios de gran volumen, la búsqueda de todas las coincidencias requeridas con la distancia de Levenshtein solicitada disminuiría significativamente el rendimiento en tiempo de ejecución.

Como ejemplo adicional, dada la siguiente base de datos de cadenas (modelada en el concepto ULA como un autómata de diccionario que reconoce un diccionario dado):

ZWIN, ZSIN, ZRIN, KAKIN, KAJN, KAJIN, GAN, GAZIN, GAWN, JATK, JATL, JATR, UJAN, OJIN, OJAN, JUAN, JOAN, JIUN, JIEN, JIAN, JEAN, JAI, JAINAD, IJIN, IJAN, EJIN, AJIN, AJAN y la cadena de entrada "JAIN", entonces todas las cadenas mencionadas tienen distancia de Levenshtein 2 contra la cadena de entrada, por lo que todas serían devueltas por ULA(2) como cadenas similares.

Sin embargo, en el contexto del idioma, solo un subconjunto del diccionario mencionado (marcado en cursiva) contiene nombres realmente similares a la cadena de entrada; las cadenas restantes solo contaminan los resultados, disminuyendo su calidad y, al mismo tiempo, disminuyendo el rendimiento en tiempo de ejecución.

De acuerdo con un aspecto de la presente solución, la ampliación del concepto de ULA (que proporciona el denominado EULA), por lo tanto, prevé al menos uno (preferentemente ambos) de:

- omitir el recorrido del autómata de diccionario, si una cadena construida hasta entonces heurísticamente no promete una coincidencia lo suficientemente cercana (esto permite mejorar la calidad de los resultados y también mejorar significativamente el rendimiento en diccionarios de gran volumen); y

- si se ha encontrado una coincidencia (es decir, durante el recorrido, tanto el ULA como el autómata de diccionario están en estados de aceptación), realizar otra heurística que permita descartar resultados que no son lo suficientemente cercanos en un contexto natural de idioma (esto permite mejorar aún más la calidad de los resultados). A continuación se describirá con mayor detalle la omisión del recorrido del autómata de diccionario.

La decisión de si se debe continuar con el recorrido del diccionario depende de la cadena de entrada (aquí designada con la letra R) y de la cadena construida hasta entonces (es decir, el prefijo de la coincidencia potencial que se va a alcanzar en el recorrido, aquí designado con la letra P).

En cualquier momento, el ULA realiza un seguimiento de P y de los posibles siguientes caracteres que se pueden añadir a P (esta información se mantiene en el autómata de diccionario): dado un posible carácter «ch», la cadena C, definida como C=P+ch, es el nuevo prefijo potencial que se considerará más adelante en el recorrido (a partir de un primer carácter, se agregan caracteres adicionales cada vez durante el recorrido, hasta que se encuentra una coincidencia potencial).

En este punto del algoritmo, se introducen una serie de heurísticas que permiten descartar o «recortar» toda la «rama» C del autómata de diccionario, en caso de que la similitud entre la cadena de entrada R y la cadena C construida hasta entonces no sea prometedora para una coincidencia potencial; esto mejora en gran medida el rendimiento en tiempo de ejecución y descarta las coincidencias irrelevantes.

La modificación del algoritmo del ULA se muestra conceptualmente en el diagrama de flujo de la Figura 8.

En el bloque 30, se ejecuta el algoritmo original del ULA, en función de la cadena de entrada R y el autómata de diccionario (que define el «trie» de posibilidades de ramificación; un «trie» es una estructura especializada de tipo árbol para sujetar cadenas de caracteres en un árbol, véase, por ejemplo: https://en.wikipedia.org/wiki/Trie).

Las heurísticas realizadas por el EULA propuesto están encapsuladas en el bloque 31 (recibiendo la cadena de entrada y el estado de autómata de diccionario, es decir, el prefijo P alcanzado hasta entonces en el trie), en la decisión de «continuar recorrido»: una decisión afirmativa mantiene la funcionalidad del algoritmo original del ULA para la rama C del diccionario; una decisión negativa omite toda la rama C y procede directamente al siguiente carácter ch del autómata de diccionario que se anexará a P, con una decisión posterior de continuar o no el recorrido.

Las heurísticas descritas anteriormente se basan en las propiedades semánticas del idioma utilizado; en general, estas heurísticas se basan en uno o más de los siguientes datos: la longitud de la cadena de entrada R; la longitud de la cadena C alcanzada hasta entonces en el recorrido; el número total de caracteres similares en las cadenas R y C, posiblemente teniendo en cuenta también la posición de los caracteres en las cadenas; el número de vocales o consonantes similares en las cadenas R y C. Las heurísticas también pueden considerar estructuras de referencia estáticas relacionadas con la semántica del idioma específico, por ejemplo, con similitudes entre consonantes y/o vocales; combinación de caracteres comúnmente utilizada; y así sucesivamente.

A continuación se describe con mayor detalle una posible realización de un algoritmo que se puede implementar en el bloque 31 para la decisión de «continuar el recorrido», también con referencia a la Figura 9.

En lo sucesivo, Xi designará el i-ésimo carácter de una cadena X, comenzando desde 0; type(ch) designará la función que devuelve «vocal» o «consonante» para un carácter ch.

En primer lugar, en el bloque 40, se calculan las no coincidencias de prefijo de 3 letras (divididas en no coincidencias de vocales y de consonantes), comparando las letras correspondientes de la cadena de entrada R con la cadena C alcanzada hasta entonces en el recorrido.

En particular:

- R0!=C0 y R0!=C1 -> aumentan el recuento de no coincidencias type(RO);

- R1!=C0 y R1!=C1 y R1!=C2 -> aumentan el recuento de no coincidencias type(R1);

- R2!=C1 y R2!=C2 -> aumentan el recuento de no coincidencias type(R2).

En otras palabras, para cada una de las tres primeras posiciones de las cadenas, el número de no coincidencias se cuenta de acuerdo con las expresiones anteriores, distinguiéndose el número de no coincidencias de consonantes y de vocales.

La decisión de «continuar el recorrido» (SÍ o NO) se toma mediante el siguiente algoritmo (las subrutinas adicionales denominadas «sub_*» se definirán a continuación, según una posible implementación):

- en el bloque 41, si la expresión (length(C)=l OR length(C) > 5 OR length(R)=l) es verdadera, entonces el recorrido continúa (la decisión es SÍ);

- de lo contrario, en el bloque 42, si la expresión (length(C)=2) es verdadera, entonces se implementa la subrutina «sub_continueTraversalLength2» para tomar la decisión;

- de lo contrario, en el bloque 43, si la expresión (length(R)<=2) es verdadera, entonces el recorrido continúa (la decisión es SÍ);

- de lo contrario, en el bloque 44, si el número de no coincidencias de consonantes es mayor que uno (mismatchConsonants >1) o la expresión (R0!=C0 AND mismatchTotal=2) es verdadera (donde mismatchTotal designa el número total de no coincidencias de vocales y consonantes), entonces se omite el siguiente recorrido (la decisión es NO);

- de lo contrario, en el bloque 45, si la expresión (length(C)=3) es verdadera, entonces se implementa la subrutina «sub_continueTraversalLength3» para tomar la decisión;

- de lo contrario, en el bloque 46, si la expresión (length(R)<=3) es verdadera, entonces el recorrido continúa (la decisión es SÍ);

- de lo contrario, en el bloque 47, si la expresión (length(C)=4) es verdadera, entonces se implementa la subrutina «sub_continueTraversalLength4» para tomar la decisión;

- de lo contrario, en el bloque 48, si la expresión (length(R)<=4) es verdadera, entonces el recorrido continúa (la decisión es SÍ);

- de lo contrario, en el bloque 49, se implementa la subrutina «sub_continueTraversalLength5» para tomar la decisión. El código para una posible implementación de las subrutinas se presenta a continuación en lenguaje Java; sin embargo, no se utilizan construcciones / detalles específicos de Java, por lo que el código se puede tratar como un pseudo-código que ilustra el concepto que se puede implementar en cualquier lenguaje informático.

Solo se observa que aquí se usa una implementación simple de objeto de cadena (llamado ByteString): en esta implementación, se asume que todos los caracteres son bytes (letras mayúsculas ASCII); las subrutinas obvias (como «consonante») se omiten; en el pseudo-código que aparece más abajo, la cadena de entrada (R) se designa con «req», mientras que el nuevo prefijo potencial alcanzado hasta entonces (C) se designa con «soFar»; el objeto «LetterMatches» contiene los recuentos de no coincidencias calculados como se describió anteriormente.

Los listados que aparecen a continuación también contienen estructuras de referencia estáticas (tabla «sims» y tabla «len4combinations») que incluyen similitudes entre letras y parámetros de comparación, según una semántica de idioma específica.

continueTraversalLen2

// esta subrutina realiza una heurística simple para predecir si la

// cadena soFar (longitud 2) tiene potencial para ser una coincidencia correcta; al menos

// una letra debería ser igual a una de las dos primeras letras de „req"

// ejemplos de casos en los que la decisión es NO:

// „req" „soFar"

// ALKIN ZG

// ANETRAD ZI

boolean continueTraversalLen2(ByteString req, ByteString soFar)

{

byte req0, reql, soFarO, soFarl;

return

//

(reqO = req.byteAt(O)) == (soFarO = soFar.byteAt(O)) || //

reqO == (soFarl = soFar.byteAt(l)) || //

(reql = req.byteAt(l)) == soFarO || //

reql == soFarl;

}

continueTraversalLen3

// esta subrutina realiza heurísticas para predecir si la cadena

// soFar (longitud 3) tiene potencial para ser una coincidencia correcta; las heurísticas

// se basan en la igualdad de letras, asignando más peso a las coincidencias de // consonantes; ejemplos de casos para los que la decisión es NO:

// „req" „soFar"

// ARIN1HEV ZAI

// BACIK ARC

boolean continueTraversalLen3(ByteString req, ByteString soFar)

{

byte reqO, reql, soFarO, soFarl;

return

//

req.byteAt(2) != soFar.byteAt(2) || //

!match(false, reqO = req.byteAt(O), soFarO = soFar.byteAt(O)) || // !match(false, reql = req.byteAt(l), soFarl = soFar.byteAt(l)) || // (reqO == soFarl && consonant(reqO)) || //

(reql == soFarO && consonant(reql)) || //

(reqO == soFarl && reql == soFarO);

}

match

// esta subrutina es un método de ayuda utilizado en las subrutinas principales boolean match(boolean m, byte bl, byte b2)

{

return m ? (bl == b2) : (bl != b2 && (consonant(bl) || consonant(b2)));

}

continueTraversalLen4

// esta subrutina realiza heurísticas para predecir si la cadena

// soFar (longitud 4) tiene potencial para ser una coincidencia correcta; las heurísticas

// se basan en la igualdad de letras en varias configuraciones basadas en

// nombres de pila y apellidos de personas en idiomas europeos

// ejemplos de casos en los que la decisión es NO:

// „req" „soFar"

// ANETRAD ZNEC // ARINGER ZRIA

boolean continueTraversalLen4(ByteString req, ByteString soFar)

{

if (//

((req.charAt(0) == 'S' && soFar.charAt(0) == 'S') || //

(req.charAt(0) == 'Z' && soFar.charAt(0) == 'Z')) //

&& //

req.charAt(1) == 'H' && soFar.charAt(1) == 'H')

{

return goodMatch(req.byteAt(2), req.byteAt(3), soFar.byteAt(2), soFar.byteAt(3));

}

return

(isLongSim1(req, soFar) || !match(req, soFar, len4combinations[0])) &&

!match(req, soFar, len4combinations[1]) &&

!match(req, soFar, len4combinations[2]) && (isCross12(req, soFar) || !match(req, soFar, len4combinations[3]));

}

goodMatch

// esta subrutina es un método de ayuda utilizado en las subrutinas principales boolean goodMatch(byte a1, byte a2, byte b1, byte b2)

{

return //

goodMatch0(a1, b1, a2, b2) && //

(goodMatchQ(a1, b2, a2, b1) || a2 == b1) && // (goodMatchQ(a2, b1, a1, b2) || a1 == b2) && //

(goodMatchQ(a2, b2, a1, b1) || a1 == b1);

}

goodMatchQ

// esta subrutina es un método de ayuda utilizado en las subrutinas principales boolean goodMatch0(byte cons1, byte cons2, byte rest1, byte rest2)

{

if (consonant(cons1) && consonant(cons2) && cons1 != cons2

&& !(Math.min(cons1, cons2) == 'M'

&& Math.max(cons1, cons2) == 'N'))

{

return

cons

(consonant(rest1) && consonant(rest2) && rest1 == rest2);

}

return true;

}

isLongSim1

// esta subrutina es un método de ayuda utilizado en las subrutinas principales boolean isLongSim1(ByteString req, ByteString soFar)

{

return req.length() >= 9 && isSim(req.byteAt(Q), soFar.byteAt(Q), sim1)

}

isSim

// esta subrutina es un método de ayuda utilizado en las subrutinas principales boolean isSim(byte b1, byte b2, byte sim)

{

return b1 == b2 || sims[b1][b2] == sim;

}

Match

// esta subrutina es un método de ayuda utilizado en las subrutinas principales boolean match(ByteString s1, ByteString s2, boolean[] m)

{

for (int i = 0; i < m.length; i++)

{

if (!match(m[i], s1.byteAt (i),s2.byteAt (i))

{

return false;

}

return true;

}

isCross12

// esta subrutina es un método de ayuda usado en las subrutinas principales boolean isCross12(ByteString req, ByteString soFar)

{

return req.byteAt(1) == soFar.byteAt(2) && req.byteAt(2) ==

soFar.byteAt(1);

}

continueTraversalLen5

// esta subrutina realiza una serie de heurísticas para predecir si

// la cadena soFar (longitud 5) tiene potencial para ser una coincidencia correcta; las

// heurísticas se basan en la igualdad de letras (en posiciones similares en // la cadena); consonantes similares, y varias otras medidas basadas en

// nombres de pila y apellidos de personas en lenguas europeas

// ejemplos de casos en los que la decisión es NO:

// „req" „soFar"

// BARTENS BUXTE

// ARINGER AZONG

// los prefijos de 5 caracteres todavía tienen una oportunidad de ser completados // hasta la distancia de Levenshtein requerida, pero la coincidencia completa // probablemente estará lejos de la cadena de entrada, dado el contexto del idioma boolean continueTraversalLen5(ByteString req, ByteString soFar,

LetterMatches lm)

{

byte //

req1 = req.byteAt(1), req2 = req.byteAt(2),//

req3 = req.byteAt(3), req4 = req.byteAt(4), //

soFar1 = soFar.byteAt(1), soFar2 = soFar.byteAt(2), //

soFar3 = soFar.byteAt(3), soFar4 = soFar.byteAt(4);

return

(req3 == soFar4 | |

req4 ==soFar3 | |

req2 ==soFar4 | |

req4 ==soFar2 | |

!match(false, req2, soFar3) ||

!match(false, req3, soFar2) ||

!match(req, soFar, len4combinations[4]))

&&

(lm.sum() < 2 ||

(reql == soFar3 && req2 == soFar4) ||

(lm.sum() == 2 && (similarConsonants(req1, soFarl) || similarConsonants(req2, soFar2))));

}

similarConsonants

// esta subrutina es un método de ayuda utilizado en las subrutinas principales boolean similarConsonants(byte cons1, byte cons2)

{

Ret

}

La tabla de referencia estática "sims" se construye de la siguiente manera:

byte[ ][ ] sims =new byte ['Z' 1]['Z' 1];

byte siml = 1, sim2 = 2;

static

{

addSim('B', 'P' , siml)

addSim('C', 'K' , sim2)

addSim('I', 'J' , sim2)

addSim('I', 'Y' , sim2)

addSim('J', 'Y' , sim2)

addSim('M', 'N' sim2);

addSim('S', 'Z' , sim2)

void addSim(char chl, char ch2, byte sim

{

sims[ch1][ch2] = sim;

sims[ch2][ch1] = sim;

}

La tabla de referencia estática «len4combinations» se construye de la siguiente manera:

boolean[][] len4combinations = //

{

//

{ false, true, true, false }, //

{ false, true, false, true }, //

{ true, false, true, false }, //

}

Como se explicó anteriormente, un aspecto adicional del EULA propuesto prevé implementar más heurísticas para evaluar las coincidencias encontradas durante el recorrido.

En particular, cuando el EULA alcanza un estado de aceptación durante el recorrido del autómata de diccionario (es decir, tanto el EULA como los autómatas de diccionario están en estados de aceptación), se ha encontrado la coincidencia deseada (es decir, la cadena del autómata de diccionario tiene la distancia de Levenshtein solicitada contra la cadena de entrada). En este punto, se introduce un «recorte» que descarta las coincidencias que están demasiado alejadas teniendo en cuenta el contexto de las lenguas europeas y el dominio del problema (es decir, el hecho de que los nombres de pila y apellidos de las personas tengan que ser recuperados con la búsqueda).

El recorte se basa en una variedad de heurísticas en la cadena de entrada R (designada con tokenReq en el pseudocódigo que se incluye a continuación) y/o el candidato de coincidencia encontrado C (designado con tokenCand en el pseudo-código que se incluye a continuación), en función de uno o más de: el parámetro de distancia de Levenshtein del EULA; las coincidencias de letra calculadas en las etapas anteriores (como se explicó anteriormente, teniendo en cuenta coincidencias de consonantes, coincidencias de vocales y coincidencias totales); las posiciones de las coincidencias o las no coincidencias de letras en las cadenas R y C; la longitud de las mismas cadenas R y C (por ejemplo, si su longitud es igual o diferente y, en ese caso, se contabiliza la diferencia); y así sucesivamente.

La decisión de descartar u omitir una coincidencia está encapsulada en la siguiente rutina designada "isWrongMatch": la decisión afirmativa significa que la coincidencia será descartada.

isWrongMatch

// la rutina principal que decide si la coincidencia es incorrecta (se va a // descartar) o correcta (se va a mantener en el resultado)

// se realiza una serie de heurísticas basadas en la distancia de Levenshtein // requerida las longitudes de las cadenas, si las cadenas tienen

// longitudes iguales

boolean isWrongMatch(ByteString tokenReq, ByteString tokenCand, LetterMatches lm) {

if (!haveCommonLetter(tokenReq, tokenCand, lm))

{

return true;

}

if (la.getEditDistance() == 1 && //

(isShortTypo1(tokenReq, tokenCand) || isShortTypo2(tokenReq, tokenCand))) {

return true;

}

if (la.getEditDistance() == 2 && //

(tokenCand.length() < 3 || //

isProbWrongLM1(tokenReq, tokenCand) || isProbWrongLM2(tokenReq, tokenCand)))

{

return true;

}

if (la.getEditDistance() == 2 && //

tokenReq.length() < 7 && tokenCand.lengthQ < 7 && //

!equalsConsonants (tokenReq, tokenCand))

{

if (tokenReq.length() == tokenCand.length())

{

if (isWrongMatchEqualLen(tokenReq, tokenCand))

{

return true;

}

else if (isWrongMatchDiffLen(tokenReq, tokenCand))

{

return true;

}

return false;

}

A continuación se incluyen las subrutinas del algoritmo principal; el pseudo-código de estas subrutinas también utiliza algunas de las subrutinas descritas anteriormente.

haveCommonLetter

// esta subrutina realiza la medida inicial de la heurística - el objetivo es // detectar casos en los que las dos cadenas no tienen ninguna letra

// similar („común"); la „gravedad" de la no coincidencia depende de la posición // de las diferentes letras

boolean haveCommonLetter(ByteString s1, ByteString s2, LetterMatches lm)

{

if (lm.mismatchTotal < 2)

{

return true;

}

int s1l = s1.length(), s2l = s2.length();

if (s1l < 5 || s2l < 5 || lm.mismatchConsonants > 1 || s1.byteAt(0) != s2.byteAt(0))

{

return false;

}

ByteString longer, shorter;

if (s1l < s2l)

{

shorter = s1;

longer = s2;

}

else

{

shorter = s2;

longer = s1;

}

byte lo3 = longer.byteAt(3), lo4 = longer.byteAt(4), sh2 = shorter.byteAt(2); return //

(lo3 == shorter.byteAt(1) && lo4 == sh2) || //

(lo3 == sh2 && lo4 == shorter.byteAt(3)) ||

lm.mismatchTotal == 2

&& (similarConsonants(longer.byteAt(1), shorter.byteAt(1))

|| similarConsonants(longer.byteAt(2), sh2));

}

isShortTypo2

// esta subrutina detecta una coincidencia incorrecta para la distancia de Levenshtein 2 private static boolean isShortTypo2(ByteString tokenReq, ByteString tokenCand)

{

return tokenCand.length() < 3 && // tokenReq.length() > 4 && // !(vowel(tokenCand.byteAt(0)) && //

tokenReq.contains(tokenCand));

}

isShortTypo!

// esta subrutina detecta una coincidencia incorrecta para la distancia de Levenshtein 1 private static boolean isShortTypo1(ByteString tokenReq, ByteString tokenCand)

{

return tokenCand.length() < 4 && //

tokenReq.length() < 4;

}

isProbWrongLM1

// esta subrutina detecta una coincidencia incorrecta para la distancia de Levenshtein 2 y

// tokens cortos

private static boolean isProbWrongLM1(ByteString tokenReq, ByteString tokenCand) {

if (tokenReq.length() == 1)

{

return tokenCand.length() > 2;

}

if (tokenCand.length() == 1)

{

return tokenReq.length() > 2;

}

return tokenReq.length() <= 6 && //

tokenReq.byteAt(O) != tokenCand.byteAt(O) && //

tokenReq.byteAt(l) == tokenCand.byteAt(l);

}

isProbWrongLM2

// tokens cortos

private static boolean isProbWrongLM2(ByteString tokenReq, ByteString tokenCand) {

return tokenReq.length() <= 5 && //

tokenReq.byteAt(0) != tokenCand.byteAt(0) && //

tokenReq.length() > tokenCand.length() && //

tokenReq.indexOf(tokenCand, 1) == -1;

}

equalsConsonants

// esta subrutina es un método de ayuda utilizado en las subrutinas principales private static boolean equalsConsonants(ByteString s1, ByteString s2)

{

// esta rutina devuelve verdadero si ambas cadenas son iguales después de

// eliminar todas las vocales; para abreviar, se omite el pseudo-código real }

isWrongMatchDiffLen

// tokens largos de diferentes longitudes

private static boolean isWrongMatchDiffLen(ByteString tokenReq,

ByteString tokenCand)

{

ByteString shorter, longer;

if (tokenReq.length() < tokenCand.length())

{

shorter = tokenReq;

longer = tokenCand;

}

else

{

shorter = tokenCand;

longer = tokenReq;

}

if (shorter.length() < 4 && longer.length() > 4 && consonant(longer.byteAt(3)) && consonant(longer.byteAt(4)) && longer.byteAt(3) != shorter.byteAt(2))

{

return true;

}

return !longer.startsWith(shorter) && //

(shorter.length() < 4 || !areAllSim(tokenReq, tokenCand, 4, 1));

}

isWrongMatchEqualLen

// tokens largos de longitudes iguales

private static boolean isWrongMatchEqualLen(ByteString tokenReq,

ByteString tokenCand)

{

return tokenReq.length() <= 4 || !areAllSim(tokenReq, tokenCand, 5, 2)

}

areAllSim

// esta subrutina es un método de ayudautilizado en las subrutinas principales private static boolean areAllSim(ByteString s1, ByteString s2, int limit int increment)

{

for (int i = 0; i < limit; i = increment)

{

if (!isSim(s1.byteAt(i), s2.byteAt(i), sim2))

{

return false;

}

return true;

}

Las ventajas que la solución descrita permite lograr se esclarecen con la descripción anterior.

En particular, se subraya nuevamente que la presente solución permite realizar selecciones de nombres rápidas y eficientes en grandes bases de datos de datos de personas; y se observa una enorme mejora en la calidad de los resultados recuperados y, al mismo tiempo, en el rendimiento en diccionarios de gran volumen con respecto a soluciones conocidas. Los resultados obtenidos son particularmente sólidos de cara a cualquier posible error en los registros de la base de datos, como los producidos por fallos humanos o problemas técnicos.

En particular, la solución prevé la explotación de los detalles de datos de nombres de personas / empresas, con su base de conocimientos semánticos y estadísticos; al centrarse en datos de personas / empresas, los resultados pueden ser significativamente mejores que los obtenidos mediante un enfoque genérico, no ajustado para datos de personas / empresas. Se aprovechan aún más los aspectos geográficos de los datos de personas / empresas, logrando así resultados de mayor calidad.

La solución ofrece velocidad en tiempo real, con un rendimiento de, por ejemplo, un máximo de 100 ms por solicitud individual, con una media muy por debajo de 100 ms.

La solución descrita puede ser implementada, con posibles modificaciones a la heurística de semántica y atributos de geolocalización aplicados, a cualquier base de datos, independientemente del país o del idioma. Gracias a esta «escalabilidad funcional», la solución puede adaptarse fácilmente para su uso en diferentes países, en toda Europa y a nivel mundial. Los «módulos» específicos pueden encapsular la base de conocimientos específicos de una ubicación geográfica (geolocalizaciones para un país específico, sus datos estadísticos de población, reglas semánticas específicas, etc.).

Además, la solución no requiere sistemas informáticos complejos y difíciles de mantener, y ofrece funcionamiento y mantenimiento simples.

La solución también ofrece una escalabilidad técnica completa en cuanto a velocidad, rendimiento y volumen de datos: en caso de aumento del tráfico y/o volumen de datos, el único requisito para mantener el mismo nivel de servicio es aumentar los recursos de hardware (sin cambios en el sistema).

Finalmente, es evidente que se pueden aplicar modificaciones y variaciones a la solución descrita y mostrada, sin apartarse del alcance de las reivindicaciones adjuntas.

En particular, con el fin de eliminar diferencias muy pequeñas entre los tokens de nombre que en la vida real se ignoran y se tratan en su mayoría como «errores tipográficos comunes» (tales como René/Rene, Mustermann/Musterman), y para eliminar los caracteres diacríticos del idioma, un aspecto de la presente solución puede prever la realización de la llamada «codificación de correspondencias» en los tokens de nombre originales. De esta manera, los tokens de nombre se dejan como caracteres ASCII, y el concepto de EULA solo tiene que realizar un trabajo «significativo», es decir, detectar errores de escritura «verdaderos»; por tanto, el algoritmo de búsqueda puede funcionar en la versión con codificación de correspondencias de los tokens de datos originales. Se puede implementar cualquier técnica de codificación de correspondencias conocida (de una manera que no se describe en detalle en la presente).

Además, se subraya que se pueden implementar algoritmos y heurísticas adicionales y/o diferentes para la decisión de «continuar el recorrido» en el algoritmo, por ejemplo, de acuerdo con la semántica específica del idioma o las propiedades del país.

Claims

REIVINDICACIONES

1. Un sistema informático (1), que comprende un equipo informático diseñado para conectarse a una base de datos (4) de datos de personas que almacena una pluralidad de registros, incluyendo cada registro al menos datos 5 de nombres de persona respectivos y datos de localización de dirección respectivos, estando el equipo informático configurado para recuperar de la base de datos (4) registros de salida que coinciden con una solicitud de entrada, que incluye al menos un nombre y una dirección que se va a buscar,

donde los datos de localización de dirección respectivos y la dirección que se va a buscar incluyen datos de referencia de dirección que definen una ciudad, un identificador de calle y un número de casa; y el equipo informático está 10 configurado para:

implementar la indexación de los registros de la base de datos en función de atributos de coordenadas geográficas derivados de los datos de localización de dirección respectivos;

determinar los atributos de coordenadas geográficas correspondientes asociados con la dirección que se va a buscar; evaluar la proximidad geográfica entre los datos de localización de dirección respectivos y la dirección que se va a 15 buscar, como una función de dichos atributos de coordenadas geográficas;

evaluar la similitud de nombre entre los datos de nombres de personas respectivos y el nombre que se va a buscar en función de la distancia de Levenshtein implementando un autómata universal de Levenshtein ampliado configurado para tener en cuenta la semántica específica del idioma; y

recuperar los registros de salida que coinciden con la solicitud de entrada, en función de una evaluación combinada 20 de la similitud de nombre y la proximidad geográfica,

donde la base de datos (4) se refiere a un territorio geográfico, y el equipo informático está configurado para dividir dicho territorio geográfico en una pluralidad de áreas de geolocalización en diferentes niveles jerárquicos de área geográfica (L);

estando dichos atributos de coordenadas geográficas basados en los registros de la base de datos, o en la dirección 25 que se va a buscar, que pertenecen a un área de geolocalización respectiva en un nivel jerárquico de área geográfica respectivo.

2. El sistema según la reivindicación 1, donde la pluralidad de áreas de geolocalización en los diferentes niveles jerárquicos de área geográfica (L) incluyen:

30

- Geo ID, un área geográfica que corresponde a un elemento dado de una cuadrícula en la que se puede dividir el territorio geográfico;

- Entorno geográfico de la calle, un área que rodea una calle determinada, que incluye calles geográficamente circundantes;

35 - ID de ciudad administrativa agrupadora, es decir, un área que abarca un grupo de ciudades que rodean una ciudad determinada; y

- Global, es decir, un área correspondiente a todo el territorio.

3. El sistema según la reivindicación 2, configurado para implementar la indexación de los registros de la 40 base de datos mediante las siguientes acciones:

para cada uno de los niveles jerárquicos de área geográfica (L) , dividir la base de datos (4) en un conjunto de objetos de base de datos (PDB_L_i), donde cada objeto de base de datos contiene datos de registros de un área geográfica respectiva en el nivel jerárquico de área geográfica respectivo;

para cada objeto de base de datos (PDB_L_i), crear: dos autómatas de diccionario (FNDict, LNDict), uno para los 45 tokens de nombre de pila y otro para los tokens de apellido en función de los datos de nombres de personas de los registros respectivos; y dos listas indexadas, una lista indexada de nombres de pila, que incluye una lista de identificadores ordenados de registros en la base de datos (4) que contienen los tokens de nombre de pila respectivos; y una lista indexada de apellidos, que incluye identificadores ordenados de registros en la base de datos (4) que contienen los tokens de apellido respectivos.

50

4. El sistema según la reivindicación 3, configurado para recuperar los registros de salida, mediante la ejecución de un procedimiento de búsqueda en índice en las listas indexadas de los objetos de base de datos (pDB_L_i), en función del nombre y la dirección de la solicitud de entrada; donde el procedimiento de búsqueda en índice incluye:

55 en función de la dirección de la solicitud de entrada, determinar las áreas de geolocalización correspondientes en cada uno de dichos niveles jerárquicos de área geográfica respectivos (L);

determinar los objetos de base de datos (PDB_L_i) relacionados con las áreas de geolocalización correspondientes; para cada objeto de base de datos (PDB_L_i), recuperar, en función de un nombre de pila (FN) y un apellido (LN) de la solicitud de entrada, las respectivas coincidencias de token de nombre de pila y apellido en los diccionarios de 60 nombres de pila y apellidos (FNDict, LNDict), en función de la similitud de los nombres implementando el autómata universal de Levenshtein ampliado con varias distancias de Levenshtein;

para cada una de las coincidencias de token de nombre de pila y apellido, recuperar las listas asociadas de identificadores ordenados de registros en la base de datos, donde dos atributos están asociados con cada lista: la distancia geográfica contra la dirección de entrada; y la distancia de Levenshtein contra el nombre de entrada.

5. El sistema según la reivindicación 4, configurado para recuperar registros de salida, mediante las siguientes acciones adicionales:

calcular las intersecciones de los identificadores obtenidos seleccionando una lista de coincidencias de token de nombre de pila y una lista de coincidencias de token de apellido; y

calcular una medida de similitud para cada registro identificado por la intersección, en función de una combinación ponderada de la distancia de Levenshtein del token de nombre de pila / apellido con la distancia geográfica de la solicitud de entrada.

6. El sistema según la reivindicación 4 o 5, donde el equipo informático está configurado para implementar el autómata universal de Levenshtein ampliado para recorrer los diccionarios de nombres de pila y apellidos (FNDict, LNDict) e identificar las coincidencias de token de nombre de pila y apellido con respecto a una cadena de entrada (R) asociada con el nombre de pila y apellido que se van a buscar;

donde el equipo informático está configurado además para:

omitir el recorrido de los diccionarios de nombres de pila y apellidos (FNDict, LNDict), si una cadena (C) construida hasta entonces no promete encontrar coincidencias según heurísticas basadas en la semántica específica del idioma; y

si se ha encontrado una coincidencia durante el recorrido, realizar heurísticas adicionales que permitan descartar resultados en función de la semántica específica del idioma.

7. El sistema según la reivindicación 6, donde las heurísticas se basan en uno o más de los siguientes datos: la longitud de la cadena de entrada (R); la longitud de la cadena (C) alcanzada hasta entonces en el recorrido; el número total de caracteres similares en las cadenas; las posiciones de similares y diferentes en las cadenas; el número de vocales y/o consonantes similares en las cadenas.

8. El sistema según la reivindicación 7, donde las heurísticas también están diseñadas para tener en cuenta estructuras de referencia estáticas relacionadas con la semántica específica del idioma, que contienen, como mínimo, similitudes entre consonantes y/o vocales y combinaciones de caracteres comúnmente utilizadas.

9. Un método informático, para recuperar registros de salida que coinciden con una solicitud de entrada de una base de datos (4) de datos de personas que almacena una pluralidad de registros, incluyendo cada registro al menos datos de nombres de personas respectivos y datos de localización de dirección respectivos, donde la solicitud de entrada incluye al menos un nombre y una dirección que se van a buscar,

donde los datos de localización de dirección respectivos y la dirección que se va a buscar incluyen datos de referencia de dirección que definen una ciudad, un identificador de calle y un número de casa; y el método comprende además: implementar la indexación de los registros de base de datos en función de atributos de coordenadas geográficas derivados de los datos de localización de dirección respectivos;

determinar atributos de coordenadas geográficas correspondientes asociados con la dirección que se va a buscar; evaluar la proximidad geográfica entre los datos de localización de dirección respectivos y la dirección que se va a buscar, como una función de dichos atributos de coordenadas geográficas;

evaluar la similitud de nombre entre los datos de nombres de personas respectivos y el nombre que se va a buscar en función de la distancia de Levenshtein implementando un autómata universal de Levenshtein ampliado, configurado para tener en cuenta la semántica específica del idioma; y

recuperar los registros de salida que coinciden con la solicitud de entrada, en función de una evaluación combinada de la similitud de nombre y la proximidad geográfica,

donde la base de datos (4) se refiere a un territorio geográfico; y comprende además dividir dicho territorio geográfico en una pluralidad de áreas de geolocalización en diferentes niveles jerárquicos de área geográfica (L);

estando dichos atributos de coordenadas geográficas basados en los registros de la base de datos, o en la dirección que se va a buscar, que pertenecen a un área de geolocalización respectiva en un nivel jerárquico de área geográfica respectivo.

10. El método según la reivindicación 9, donde la pluralidad de áreas de geolocalización en diferentes niveles jerárquicos de área geográfica (L) incluyen:

- Entorno geográfico de la calle, un área que rodea

una calle determinada, que incluye calles geográficamente circundantes;

- ID de ciudad administrativa agrupadora, es decir, un área que abarca un grupo de ciudades que rodean una ciudad determinada; y

5 - Global, es decir, un área correspondiente a todo el territorio.

11. El método según la reivindicación 10, donde la implementación de la indexación de los registros de la base de datos comprende:

para cada uno de los niveles jerárquicos de área geográfica (L) , dividir la base de datos (4) en un conjunto de objetos 0 de base de datos (PDB_L_i), donde cada objeto de base de datos contiene datos de registros de un área geográfica respectiva en el nivel jerárquico de área geográfica respectivo;

para cada objeto de base de datos (PDB_L_i), crear: dos autómatas de diccionario (FNDict, LNDict), uno para tokens de nombre de pila y otro para tokens de apellido en función de los datos de nombres de personas de los registros respectivos; y dos listas indexadas, una lista indexada de nombres de pila, que incluye una lista de identificadores 5 ordenados de registros en la base de datos (4) que contienen los tokens de nombre de pila respectivos; y una lista indexada de apellidos, que incluye identificadores ordenados de registros en la base de datos que contienen los tokens de apellido respectivos.

12. El método según la reivindicación 11, donde recuperar los registros de salida comprende ejecutar un 0 procedimiento de búsqueda en índice en las listas indexadas de los objetos de base de datos (PDB_L_i), en función del nombre y la dirección de la solicitud de entrada; donde ejecutar el procedimiento de búsqueda en índice comprende:

en función de la dirección de la solicitud de entrada, determinar

áreas de geolocalización correspondientes en cada uno de dichos niveles jerárquicos de área geográfica respectivos 5 (L);

determinar los objetos de base de datos (PDB_L_i) relacionados con las áreas de geolocalización correspondientes; para cada objeto de base de datos (PDB_L_i), recuperar, en función de un nombre de pila (FN) y un apellido (LN) de la solicitud de entrada, las respectivas coincidencias de token de nombre de pila y apellido en los diccionarios de nombres de pila y apellidos (FNDict, LNDict), en función de la similitud de los nombres implementando el autómata 0 universal de Levenshtein ampliado con varias distancias de Levenshtein;

5 13. El método según la reivindicación 12, donde la recuperación de los registros de salida comprende además:

calcular una medida de similitud para cada registro identificado por la intersección, en función de una combinación 0 ponderada de la distancia de Levenshtein del token de nombre de pila / apellido con la distancia geográfica de la solicitud de entrada.

14. El método según la reivindicación 12 o 13, que comprende además implementar el autómata universal de Levenshtein ampliado para recorrer los diccionarios de nombres de pila y apellidos (FNDict, LNDict), e identificar 5 las coincidencias de token de nombre de pila y apellido con respecto a una cadena de entrada (R) asociada con el nombre de pila y apellido que se van a buscar;

que comprende además:

omitir el recorrido de los diccionarios de nombres de pila y apellidos (FNDict, LNDict), si una cadena (C) construida hasta entonces no promete encontrar coincidencias según heurísticas basadas en la semántica específica del idioma; 0 y

15. Un programa informático, que comprende instrucciones que, cuando el programa es ejecutado por un 5 módulo informático, hacen que el módulo informático ejecute el método según cualquiera de las reivindicaciones 9-14.