BRPI0817530B1 - método e sistema para processamento de registros de dados em múltiplos idiomas e mídia de armazenamento legível por computador - Google Patents

Abstract

método e sistema para associação de registro de dados em várias línguas concretizações descritas aqui fornecem um sistema e método para associar registros de dados em várias línguas dentro de uma plataforma. à medida que um registro vem de uma fonte de informação acoplada à plataforma, ele é associado com uma língua particular em uma camada de núcleo. a plataforma mapeia cada língua uma a uma para um tipo de membro. para cada registro de dado de um tipo de membro particular, código de derivação único é utilizado para realizar padronização e bucketing na camada derivada. um peso pode ser usado para balancear a riqueza de línguas de modo que os registros em diferentes línguas podem ter os mesmos significados estatísticos. uma vez que os atributos são padronizados com relação a uma língua de um registro de dados, línguas apropriadas ou scripts podem ser passados junto com o registro de dados. a plataforma pode então corresponder os registros de dados aos algoritmos ideais para processamento de entidade em uma camada de entidade.

Description

MÉTODO E SISTEMA PARA PROCESSAMENTO DE REGISTROS DE DADOS EM MÚLTIPLOS IDIOMAS E MÍDIA DE ARMAZENAMENTO LEGÍVEL POR COMPUTADOR

REFERÊNCIA CRUZADA A PEDIDOS RELACIONADOS [0001] Este pedido reivindica prioridade do pedido de patente Provisório n° 60/997,025, depositado em 28 de setembro de 2007, intitulado MÉTODO E SISTEMA PARA ASSOCIAR REGISTROS DE DADOS EM DIVERSOS IDIOMAS, que é totalmente aqui incorporado por referência. Este pedido também se refere ao pedido de patente US No. 12/056,720, apresentado em 27 de março de 2008, intitulado MÉTODO E SISTEMA PARA GERENCIAMENTO DE ENTIDADES”, US 11/967,588, depositado em 31 de dezembro de 2007, intitulada MODO E SISTEMA PARA ANÁLISE DE IDIOMAS”, US 11/904,750, depositado em 28 de setembro de 2007, intitulado MÉTODO E SISTEMA PARA INDEXAÇÃO, RELATIVO E GESTÃO DE INFORMAÇÕES SOBRE ENTIDADES”, US 11/901,040, apresentado em 14 de setembro de 2007, intitulado HIERARQUIA DO SISTEMA GLOBAL DE GESTÃO DE USUÁRIO E INTERFACE”, US 11/809,792, apresentado em 1 de junho de 2007, intitulado SISTEMA E MÉTODO PARA GERAÇÃO AUTOMÁTICA de PESO PARA CORRESPONDÊNCIA PROBABILÍSTICA”, US 11/702,410, apresentado em 5 de fevereiro de 2007, intitulada MÉTODO E SISTEMA PARA UMA INTERFACE GRÁFICA DO USUÁRIO PARA CONFIGURAÇÃO DE UM ALGORITMO PARA A COMPARAÇÃO DE REGISTROS DE DADOS”, US 11/165,611, apresentado em 22 de janeiro de 2007, intitulado MÉTODO E SISTEMA PARA INFORMAÇÕES DE INDEXAÇÃO SOBRE ENTIDADES COM RESPEITO ÀS HIERARQUIAS”, US 11/522,223, apresentado em 15 setembro de 2006, intitulado: “MÉTODO E SISTEMA PARA COMPARAR OS ATRIBUTOS, COMO NOMES PESSOAIS”, e US 11/521,928, apresentado em 15 de setembro de

Petição 870190083248, de 26/08/2019, pág. 10/98

2/74

2006, intitulado: “MÉTODO E SISTEMA PARA COMPARAR ATRIBUTOS, COMO NOMES DE NEGÓCIO”. Todos os pedidos citados neste parágrafo estão totalmente incorporados aqui para todos os efeitos.

CAMPO TÉCNICO [0002] Esta divulgação refere-se geralmente a associar registros de dados e, mais particularmente, à identificação de registros de dados que podem conter informações sobre a mesma entidade de tal forma que os registros Estes dados podem ser associado. Ainda mais particularmente, modalidades aqui reveladas podem estar relacionadas com a associação de registros de dados em vários idiomas.

ANTECEDENTES [0003] Nos dias e na era atual, a grande maioria das empresas mantém grandes quantidades de dados sobre vários aspectos de suas operações, como estoques, clientes, produtos, etc. Dados sobre entidades, tais como pessoas, produtos, peças ou qualquer coisa mais podem ser armazenados em formato digital num armazenamento de dados, tais como uma base de dados de computador. Esses bancos de dados de computador permitem que os dados sobre uma entidade para serem acessados rapidamente e permitir que os dados sejam cruzados com outras peças relevantes de dados sobre a mesma entidade. Os bancos de dados também permitem que uma pessoa para consultar o banco de dados para encontrar registros de dados relativos a uma entidade particular, de tal forma que os registros de dados de vários armazenamentos de dados pertencentes à mesma entidade podem ser associados a uma outra.

Petição 870190083248, de 26/08/2019, pág. 11/98

3/74 [0004] Um armazenamento de dados, no entanto, tem várias limitações que possam limitar a capacidade de encontrar os dados corretos sobre uma entidade do armazenamento de dados. Os dados reais dentro do armazenamento de dados só são tão precisos quanto à pessoa que introduziu os dados, ou uma fonte de dados original. Assim, um erro na entrada dos dados para o armazenamento de dados pode causar uma busca de dados sobre uma entidade no banco de dados de perder dados relevantes sobre a entidade, porque, por exemplo, um último nome de uma pessoa foi digitado incorretamente ou a segurança social número foi digitado incorretamente, etc. Uma série de esses tipos de problemas pode ser imaginado: dois registro separado para uma entidade que já tem um registro no banco de dados pode ser criado de tal forma que vários registros de dados poderão conter informações sobre a mesma entidade, mas, por exemplo, os nomes ou números de identificação contidos nos dois registros de dados podem ser diferentes, de modo que ele pode ser difícil de associar os registros de dados referentes a uma mesma pessoa com outra.

[0005] Para uma empresa que opera um ou mais dados lojas que contêm um grande número de registros de dados, a capacidade de localizar informações relevantes sobre uma determinada entidade dentro e entre as respectivas bases de dados é muito importante, mas não é facilmente obtida. Mais uma vez, qualquer erro na entrada de dados (incluindo, sem limitação, a criação de mais de um registro de dados para a mesma entidade) em qualquer fonte de informação pode causar dados relevantes para ser desperdiçada quando os dados para uma entidade particular são procurados no banco de dados. Além disso, em casos que envolvam múltiplas fontes de

Petição 870190083248, de 26/08/2019, pág. 12/98

4/74 informação, cada uma das fontes de informação pode ter sintaxe de dados ligeiramente diferentes ou formatos que pode complicar ainda mais o processo de encontrar dados entre os bancos de dados. Um exemplo da necessidade de identificar corretamente uma entidade referida em um registro de dados e para localizar todos os registros de dados relativos a uma entidade no campo da saúde é aquele em que um número de diferentes hospitais associados a uma determinada organização de cuidados de saúde pode ter um ou mais fontes de informação que contenham informações sobre o seu paciente, e uma organização de saúde recolhe as informações de cada um dos hospitais em um banco de dados mestre. É necessário vincular os registros de dados de todas as fontes de informação que pertencem ao mesmo paciente para permitir a busca de informações para um determinado paciente em todos os registros hospitalares.

[0006] Há vários problemas que limitam a capacidade de encontrar os dados relevantes sobre uma entidade de tal banco de dados. Podem existir múltiplos registros de dados para uma entidade particular como resultado de registros de dados separados recebidos de uma ou mais fontes de informação, o que leva a um problema que pode ser chamado de fragmentação de dados. No caso de fragmentação de dados, uma consulta do banco de dados mestre não pode recuperar todas as informações relevantes sobre uma determinada entidade. Além disso, tal como descrito acima, a consulta pode perder alguma informação relevante sobre uma entidade devido a um erro de digitação feita durante a entrada de dados, o que leva ao problema de inacessibilidade de dados. Além disso, um grande banco de dados pode conter registros de dados que parecem ser idênticas, como uma pluralidade de registros

Petição 870190083248, de 26/08/2019, pág. 13/98

5/74 para as pessoas com o sobrenome Smith e o primeiro nome de Jim. Uma consulta do banco de dados irá recuperar todos esses registros de dados e uma pessoa que fez a consulta à base de dados pode, muitas vezes escolher, ao acaso, um dos registros de dados recuperados que podem ser o registro de dados errado. A pessoa não pode muitas vezes tipicamente tentativa para determinar qual dos registros é apropriado. Isso pode levar a os registros de dados para a entidade errada sendo recuperados, mesmo quando os registros de dados corretos estão disponíveis. Estes problemas limitam a capacidade de localizar a informação para uma entidade específica dentro do banco de dados.

[0007] Para reduzir a quantidade de dados que devem ser revistos, e impedir que o usuário escolher o registro de dados errado, é também desejável para identificar e associar Dados de registros das várias fontes de informação que podem conter informações sobre a mesma entidade. Existem sistemas convencionais que colocam os registros de dados numa base de dados duplicadas e excluir esses registros de dados duplicadas, mas estes sistemas só podem localizar os registros de dados que são substancialmente idênticos uns aos outros. Assim, estes sistemas convencionais não conseguem determinar se dois registros de dados, com, por exemplo, sobrenomes ligeiramente diferentes, no entanto, conter informações sobre a mesma entidade. Além disso, estes sistemas convencionais não tentam registros de dados de índice a partir de uma pluralidade de diferentes fontes de informação, localizar registros de dados dentro de uma ou mais fontes de informação que contenham informações sobre a mesma entidade, e vincular os registros de dados em conjunto. Consequentemente, seria desejável ser capaz de associar os

Petição 870190083248, de 26/08/2019, pág. 14/98

6/7 4 registros de dados a partir de uma pluralidade de fontes de informação, que dizem respeito a uma mesma pessoa, apesar de discrepâncias entre os atributos destes registros de dados e ser capaz de - informações montar e presente a partir destes vários registros de dados em - uma forma coesa. Na prática, no entanto, pode ser extremamente difícil para fornecer uma visão precisa, codificada da informação a partir de uma pluralidade de fontes de informação. Onde os registros de dados estão em vários idiomas, o desafio pode ser ainda mais assustador.

SUMÁRIO DA DESCRIÇÃO [0008] À medida que os registros de dados a partir de várias fontes podem ser diferentes em ambos e no formato de dados que eles contêm, a configuração de sistemas de processamento de dados pode apresentar um trabalho de Hércules. Essas dificuldades são em parte causados porque a configuração do processo podem ser uma tarefa manualmente intensivo que exige uma grande quantidade de especializado conhecimento da arquitetura e capacidades do sistema a ser utilizado para a associação de registros de dados e, além disso, um elevado grau de análise e minutos atenção aos detalhes para assegurar que a configuração resultante do algoritmo (s) usado para associar os registros de dados irá produzir os resultados desejados.

[0009] Estas dificuldades podem ser ainda mais exacerbadas pelo fato de, em muitos casos, os registros de dados de várias fontes de dados podem ser em idiomas diferentes. Em alguns casos, os atributos de registros de dados podem estar em um idioma que não usa o alfabeto latino em tudo. Alguns idiomas não necessariamente obedecem às regras, paradigmas ou convenção de idiomas escritos no

Petição 870190083248, de 26/08/2019, pág. 15/98

7/7 4 alfabeto latino, tornando atributos em idiomas difíceis de analisar. Os vários algoritmos ou comparações realizadas ou utilizadas podem, portanto, tem que ser adaptado para comparar registros de dados em diferentes idiomas. Pode ser difícil, contudo, para determinar que algoritmos, comparações, etc., devem ser utilizados em conjunção com os quais os registros de dados. Assim, existe uma necessidade de sistemas e métodos para a obtenção e associando os registros de dados de uma variedade de fontes de informação, onde estes dados registros podem estar numa variedade de diferentes idiomas.

[0010] As concretizações aqui descritas fornecem uma solução fundamental para facilitar a pesquisa e associando registros de dados em vários idiomas dentro de um único centro de tal forma que, em resposta a uma consulta, o centro pode pesquisar registros de dados em vários idiomas, determinam como esses registros de dados deve ser associado de uma forma específica do idioma, e preparar uma resposta em conformidade, de uma forma oportuna e precisa.

[0011] Mais especificamente, à medida que cada registro chega, que está associado com um idioma particular numa camada de núcleo do núcleo. Muitas vezes, o idioma de um registro é conhecido ou pode ser facilmente determinado. Se não, um idioma padrão pode ser atribuído. No núcleo, cada idioma é mapeado um a um para um tipo de membro. Em algumas modalidades, os registros de dados em vários idiomas podem compartilhar tipos de atributos dentro de uma definição de idioma no núcleo.

[0012] Para cada registro de dados de um tipo de membro particular, código de derivação única é utilizada para realizar a normalização e a bucketing (seleção do

Petição 870190083248, de 26/08/2019, pág. 16/98

8/74 candidato) em uma camada derivada do centro. O código de derivação única é único no sentido de que é única para um idioma específico mapeado para um tipo de membro particular. O código de derivação pode utilizar uma ou mais técnicas de normalização, como a padronização da linguagem, padronização transliteração, etc. Enquanto a normalização pode ser específica do idioma, bucketing pode ser independente de idioma. Como um exemplo, normalização japonesa específica é aqui descrita com referência às figuras 9-13. Nomes japoneses processadas que com tokens normalizados são então executados através de um processo de bucketing independente de idioma, tal como aqui descrito com referência às figuras 14-19.

[0013] O processo de seleção bucketing ou candidato pode compreender uma comparação de um ou mais atributos de um conjunto de registros de dados para determinar se eles são suficientemente semelhantes para implicar a comparação adicional. Se assim for, então uma nova determinação é feita sobre como devem ser ligados ou associados. Como será descrito abaixo com referência às figuras 4-8, a comparação mais detalhada pode implicar a comparação de cada um dos conjuntos de atributos de um registro (por exemplo, um registro existente) para o atributo correspondente no outro registro (por exemplo, um novo registro) para gerar um peso para o atributo. Os pesos de cada um dos conjuntos de atributos podem então ser somados para gerar um peso total que pode então ser comparada com um limiar, para determinar se e como os dois registros deve ser ligado.

[0014] No contexto de um cubo multilíngue, o peso pode ser usado para equilibrar automaticamente a riqueza de idiomas, de modo que os registros de dois dados em diferentes idiomas podem ter o mesmo significado estatístico. Desta

Petição 870190083248, de 26/08/2019, pág. 17/98

9/74 forma, os registros de dados associados com diferentes idiomas podem ser ligados a uma única entidade ou entidades de idioma do mesmo na camada de entidade do cubo. Em alguns casos, as relações entre os registros de dados a partir de diferentes idiomas podem precisar ser identificadas de tal modo que registros de dados associados com diferentes idiomas na camada de núcleo do cubo pode ser ligada a várias entidades na camada de entidade. Desde todos os atributos de um registro de dados sejam devidamente padronizados com relação ao idioma dominante de que o registro de dados, o centro pode automaticamente e inteligentemente a coincidir com o algoritmo óptimo (s) para processar entidades em idiomas individuais na camada entidade. Em outras palavras, uma vez que os idiomas ou roteiro apropriados podem ser passados junto com o registro, o registro pode ser encaminhado para o caminho de algoritmo apropriado para processamento entidade no cubo.

[0015] Assim, as concretizações aqui divulgadas possível vinculam os registros de dados em uma variedade de idiomas dentro de um único centro. Outras características, vantagens e objetivos da divulgação será melhor apreciado e compreendido, quando considerada em conjunto com a seguinte descrição e os desenhos que a acompanham.

BREVE DESCRIÇÃO DOS DESENHOS [0016] Os desenhos em anexo e que formam parte da presente especificação estão incluídos para ilustrar determinados aspectos da divulgação. Uma impressão mais clara da descrição, e dos componentes e funcionamento dos sistemas fornecidos com a divulgação, vai tornar-se mais facilmente evidente fazendo referência ao exemplar e, por conseguinte, não limitativo, concretizações ilustradas nos

Petição 870190083248, de 26/08/2019, pág. 18/98

10/74

desenhos.	Sempre	que possível,	os mesmos números	de
referência	serão	utilizados por	todos os	desenhos	para
referir as	mesmas	características	ou como	(elementos)	. Os

desenhos não são necessariamente desenhados à escala.

[0017] A Figura 1 descreve uma infraestrutura de exemplo de uma concretização de uma entidade do sistema de processamento.

[0018] As figuras 2A e 2B mostram uma representação de duas concretizações de registros de dados.

[0019] A Figura 3 ilustra um diagrama de fluxo de uma concretização comparando os registros de dados.

[0020] A Figura 4 representa um diagrama de fluxo de uma concretização de um método para a comparação de atributos de um registro de dados.

[0021] As Figuras 5A e 5B representam um diagrama de fluxo de uma concretização de um método para a determinação de um peso para dois atributos.

[0022] A Figura 6 representa um diagrama de fluxo de uma concretização de um método para determinação de valores usados no cálculo de um peso.

[0023] A Figura 7 representa um exemplo de uma tabela para utilização na descrição um exemplo da aplicação de uma concretização da presente invenção.

[0024] As Figuras 8A e 8B ilustram exemplos de mesas para utilização na descrição de um exemplo de aplicação de uma concretização da presente invenção.

[0025] A Figura 9 representa um diagrama de fluxo para uma realização da análise em um idioma asiático.

[0026] A Figura 10 ilustra um exemplo de alguns caracteres tradicionais e seus equivalentes simplificados.

Petição 870190083248, de 26/08/2019, pág. 19/98

11/74 [0027] A Figura 11 mostra um exemplo de modificadores de agrupamento ou outros caracteres não agrupados.

[0028] A Figura 12 representa um histograma traçando as estatísticas do número de tokens que uma concretização da análise aqui divulgados podem ser criados para cada nome de um conjunto de amostras.

[0029] A Figura 13 representa um histograma representar graficamente a distribuição dos comprimentos de caracteres de os tokens analisados da figura 12.

[0030] A Figura 14 representa uma distribuição de uma série de caracteres após a análise e tradução.

[0031] A Figura 15 lista caracteres japoneses e as suas frequências a partir da amostra da Figura 14.

[0032] A Figura 16 mostra a distribuição dos tokens originais da amostra da Figura 14 e uma distribuição dos tokens codificados.

[0033] A Figura 17 ilustra um exemplo de nomes processadas que são originais e itens de bucket correspondentes.

[0034] As Figuras 18A e 18B mostram exemplos de um método de idioma independente do nome bucketing.

[0035] A Figura 19 é um diagrama de plotagem que ilustra o número de membros que realizam bucket juntos qualitativamente.

[0036] A Figura 20 ilustra uma concretização de um exemplo de implementação de um centro de identidade multilíngue.

[0037] A Figura 21 ilustra a exemplo de implementação da Figura 20 em mais detalhes.

DESCRIÇÃO DETALHADA

Petição 870190083248, de 26/08/2019, pág. 20/98

12/74 [0038] Concretizações preferidas e as várias características e detalhes vantajosos do mesmo são explicadas mais detalhadamente com referência aos exemplos ilustrados nos desenhos anexos. Descrições de hardware de computador bem conhecidos e software, incluindo as técnicas de programação e processamento de dados, são omitidos de modo a não obscurecer desnecessariamente a descrição em pormenor. Os especialistas na técnica devem compreender, no entanto, que a descrição detalhada e os exemplos específicos, embora a divulgação de concretizações preferidas da divulgação, são fornecidos a título de ilustração apenas e não como forma de limitação. Várias substituições, modificações, adições ou rearranjos dentro do escopo do conceito inventivo subjacente (s) serão evidentes para aqueles peritos na técnica após leitura desta descrição.

[0039] Algumas concretizações aqui divulgadas podem utilizar uma concretização de um sistema e método para a indexação de informações sobre entidades partir de diferentes tipos de informação, como descrito na Patente dos Estados Unidos N ° 5,991, 758, concedida em 23 de novembro de 1999, que é aqui incorporado por referência. Algumas concretizações aqui divulgadas podem aproveitar uma concretização de um sistema de processamento de entidade e o método para a indexação de informações sobre entidades com respeito às hierarquias, como divulgado no acima referenciado Pedido de Patente US N ° 11/165,611, depositado em 22 de janeiro de 2007, intitulada MÉTODO E SISTEMA PARA INFORMAÇÕES DE INDEXAÇÃO SOBRE ENTIDADES COM RESPEITO A HIERARQUIAS, que também é aqui incorporada por referência.

[0040] A Figura 1 é um diagrama de blocos que ilustra uma infraestrutura exemplo de uma concretização de sistema

Petição 870190083248, de 26/08/2019, pág. 21/98

13/74 de processamento de entidade 30. O sistema de processamento de entidade 30 pode incluir centro de identidade 32 que processa, atualiza ou armazena dados referentes a registros de dados sobre uma ou mais entidades de uma ou mais fontes de informação 34, 36, 38 e responde a comandos ou consultas a partir de uma pluralidade de operadores 40, 42, 44, onde os operadores podem ser usuários humanos e/ ou sistemas de informação. O centro de identidade 32 pode operar com registros de dados a partir de uma única fonte de informação ou, como mostrado, registros de dados de várias fontes de informação. As entidades rastreadas usando concretizações do centro de identidade 32 podem incluir, por exemplo, pacientes em um hospital, participantes de um sistema de cuidados de saúde, as peças em um armazém, ou quaisquer outras entidades que podem ter registros de dados e informações contidas em registros de dados que lhe estão associados. O centro de identidade 32 pode ser um ou mais sistemas de computadores com pelo menos uma unidade central de processamento (CPU) 45 executam instruções legíveis por computador (por exemplo, uma aplicação de software) armazenado em um ou mais legíveis por computador meios de armazenamento para executar as funções do centro de identidade 32. O centro de identidade 32 pode também ser implementado utilizando circuitos de hardware ou uma combinação de software e hardware, como seria compreendido pelos versados na técnica.

[0041] No exemplo da Figura 1, o centro de identidade 32 pode receber os registros de dados a partir de fontes de informação 34, 36, 38, bem como gravação corrigido dados de volta para fontes de informação 34, 36, 38. Os dados corrigidos comunicados às fontes de informação 34, 36, 38 podem incluir informações de que estava correto, mas mudou,

Petição 870190083248, de 26/08/2019, pág. 22/98

14/74 informações sobre como corrigir informações em um registro de dados, e / ou informações sobre as ligações entre dados de registros.

[0042] Além disso, um dos operadores de 40, 42, 44 pode transmitir uma consulta para centro de identidade 32 e receber uma resposta para a consulta de volta do centro de identidade 32. Fontes de informação 34, 36, 38 pode ser, por exemplo, diferentes bases de dados que podem ter registros de dados sobre as mesmas entidades. Por exemplo, no campo da saúde, cada fonte de informação 34, 36, 38 podem estar associados a um hospital particular, em uma organização de cuidados de saúde e a organização dos cuidados de saúde podem utilizar o centro de identidade 32 para relacionar os registros de dados associados com a pluralidade de hospitais de modo que um registro de dados para um paciente em Los Angeles pode ser localizado quando o mesmo paciente está de férias e entra num hospital em New York. O centro de identidade 32 pode estar localizado numa localização central e as fontes de informação 34, 36, 38 e os usuários 40, 42, 44 podem ser localizados remotamente a partir do centro de identidade 32 e podem ser conectados ao centro de identidade 32 através de, por exemplo, uma ligação de comunicações, tal como a Internet ou qualquer outra rede de comunicações do tipo, tal como uma rede de área ampla, intranet, rede sem

fio, rede locada, etc.	concretizações, o	centro	de
[0043]	Em algumas
identidade	32 pode ter a	sua própria base de dados	que
armazena os registros de	dados completos no	centro	de
identidade	32. Em algumas concretizações,	centro	de
identidade	32 pode também	conter apenas dados	suficientes
para identificar um regis	tro de dados (por	exemplo,	um

Petição 870190083248, de 26/08/2019, pág. 23/98

15/74 endereço de uma fonte particular de dados 34, 36, 38) ou de qualquer parte dos campos de dados que compreendem um registro de dados completo de modo que o centro de identidade 32 pode recuperar todo o registro de dados de informação a partir da fonte 34, 36, 38 quando necessário. O centro de identidade 32 pode vincular os registros de dados em conjunto com informação sobre a mesma entidade utilizando um identificador entidade ou um banco de dados associativa separado de registros de dados reais. Assim, centro de identidade 32 pode manter ligações entre os registros de dados em uma ou mais fontes de informação 34, 36, 38, mas não necessariamente manter um único registro de dados uniforme para uma entidade.

[0044] Em algumas modalidades, centro de identidade 32 pode vincular dados registros em fontes de informação 34, 36, 38, comparando um registro de dados (recebido de um operador, ou a partir de uma fonte de dados 34, 36, 38) com outros registros de dados em fontes de informação 34, 36, 38 para identificar os registros de dados que devem ser ligados entre si. Este processo de identificação pode implicar a comparação de um ou mais dos atributos dos registros de dados com atributos de como os outros registros de dados. Por exemplo, um atributo de nome associado a um registro pode ser comparado com o nome de outros registros de dados, número de segurança social pode ser comparado com o número de um outro registro, etc. Desta maneira a segurança social, os registros de dados que devem ser vinculados podem ser identificados.

[0045] Será evidente para os versados na técnica, fontes que informações 34, 36, 38 e os operadores 40, 42, 44 podem estar ligados com organizações semelhantes ou

Petição 870190083248, de 26/08/2019, pág. 24/98

16/74 diferentes e/ ou proprietários e pode ser fisicamente separado e/ ou distantes uns dos outros. Por exemplo, fonte de informação 34 pode ser filiado a um hospital em Los Angeles gerido por uma rede de cuidados de saúde, enquanto fonte de informação 36 pode ser filiado a um hospital em Nova York dirigido por outra rede de cuidados de saúde, talvez, de propriedade de uma empresa francesa. Assim, os registros de dados a partir de fontes de informação 34, 36, 38 podem ser de diferentes formatos, idiomas diferentes, etc.

[0046] Isto pode ser ilustrado de forma mais clara em relação às figuras 2A e 2B, que descrevem duas concretizações de registros de dados de exemplo. Cada um destes dados dos registros 200, 202 tem um conjunto de campos de 210 correspondendo a um conjunto de atributos de cada um dos registros de dados. Por exemplo, um dos atributos de cada um dos registros 200 pode ser um nome, um outro atributo pode ser um número de contribuinte, etc. Torna-se evidente que um atributo pode compreender vários campos 210 registros de dados de 200, 202. Por exemplo, um atributo endereço do registro de dados 202 pode compreender campos 210c, 210d e 210e, a rua, a cidade e campos estaduais, respectivamente.

[0047] No entanto, cada um dos dados registra 200, 202 pode ter um formato diferente. Por exemplo, registro de dados 202 pode ter um campo 210 para o atributo de seguradora, enquanto registro de dados 200 pode não ter nenhum tal campo. Além disso, os atributos semelhantes podem ter diferentes formatos bem. Por exemplo, campo de nome no registro de 210b 202 pode aceitar a entrada de um nome completo, enquanto 210a campo nome no registro 200 pode ser concebido para permitir a entrada de um nome de um

Petição 870190083248, de 26/08/2019, pág. 25/98

17/7 4 comprimento limitado. Tais discrepâncias pode ser problemático quando se comparam dois ou mais registros de dados (por exemplo, atributos de registros de dados) para identificar registros de dados que devem ser vinculados. Por exemplo, o nome Bobs Flower Shop é semelhante, mas não exatamente o mesmo que Bobs Very Pretty Flower Shoppe. Além disso, um erro de digitação ou erro na inserção de dados para um registro de dados também pode afetar a comparação de registros de dados e, assim como dos seus resultados (por exemplo, comparando o nome Bobs Pretty Flower Shop com Bobs Pretty Glower Shop, onde Glower resultou a partir de um erro de digitação, inserindo a palavra Flower).

[0048] Os nomes de negócios em registros de dados podem apresentar uma série de problemas bastante específicos, como resultado de sua natureza. Alguns nomes de negócios podem ser muito curtos (por exemplo, Quick-EMart), enquanto outros podem ser muito longos (por exemplo, San Francisco's Best Coffee Shop). Além disso, nomes de empresas podem frequentemente usam palavras similares (por exemplo, Shop, Inc., Co.), que, ao comparar registros de dados no mesmo idioma, não deve pesar em qualquer heurística para comparar esses nomes. Além disso, os acrônimos são frequentemente usados em nomes de negócio, por exemplo, uma empresa com o nome Ney York City Bagel podem frequentemente ser inseridos em um registro de dados como NYC Bagel.

[0049] Como será descrito em detalhes abaixo, concretizações do centro de identidade 32 aqui divulgadas utilizam algoritmos que podem levar em conta essas específicas peculiaridades quando comparar nomes de negócios. Especificamente, alguns algoritmos empregados por

Petição 870190083248, de 26/08/2019, pág. 26/98

18/74 centro de identidade 32 siglas de apoio, ter em conta a frequência de certas palavras em nomes de negócio, e considerar a ordenação de tokens dentro de um nome comercial (por exemplo, o nome Clínica de Austin pode ter sido considerado praticamente idênticos para Austin Clinic). Alguns algoritmos utilizam uma variedade de técnicas de comparação nome para gerar um peso com base na comparação (por exemplo, a semelhança) de nomes nos registros diferentes, onde este peso pode, então, ser utilizados para determinar se os dois registros devem ser ligados, incluindo vários métodos de comparação fonéticos, ponderação com base na frequência de tokens nome, correspondências iniciais, correspondências de apelido, etc. Em algumas concretizações, os sinais do atributo nome de cada registro seriam comparados uns contra os outros, utilizando metodologias para coincidir com os tokens (por exemplo, se os tokens corresponder exatamente, foneticamente, etc.). Estas correspondências poderiam, então, ser fornecidas com um peso, com base na correspondência determinada (por exemplo, uma correspondência exata é dada um primeiro peso, enquanto que um determinado tipo de correspondência inicial é dada um segundo peso, etc.). Estes pesos poderiam, então, ser agregados para determinar um peso total para o grau de correspondência entre o atributo nome de dois registros de dados. Exemplos de concretizações de um método de geração de peso adequado encontram-se descritos no acima referenciado Pedido de Patente dos EUA No. 11/809.792, depositado em 1 de junho de 2007, intitulada SISTEMA E MÉTODO PARA GERAÇÃO DE PESO AUTOMÁTICO DE CORRESPONDÊNCIA PROBABILÍSTICA, o qual é aqui incorporado por referência. Concretizações exemplares de técnicas de comparação nome adequados são

Petição 870190083248, de 26/08/2019, pág. 27/98

19/74 descritos nos pedidos de patente dos EUA acima referenciado No. 11/522.223, depositado em 15 de setembro de 2006, intitulado MÉTODO E SISTEMA PARA COMPARAR ATRIBUTOS, COMO NOMES PESSOAIS e No. 11/521, 928, apresentado em 15 de setembro de 2006, intitulado MÉTODO E SISTEMA PARA COMPARAR OS ATRIBUTOS, COMO NOMES DE NEGÓCIO, ambos os quais são aqui incorporados por referência.

[0050] A Figura 3 mostra um exemplo de uma metodologia para identificar os registros relativos a uma mesma entidade. No passo 310, um conjunto de registros de dados pode ser empurrado ou puxado pelo centro de identidade 32 para avaliação. Esses registros de dados podem incluir, por exemplo, um ou mais novos registros de dados para comparar a um conjunto de registros de dados existentes (que pode já existir em, por exemplo, fontes de informação 34, 36, 38 ou que possam ser fornecidos ao centro de identidade 32). No passo 320, os registros de dados para comparação podem ser padronizados se já não estiverem normalizados. Esta padronização pode compreender a padronização dos atributos de um registro de dados de tal forma que o registro de dados é transformado de seu formato original para um formato padrão. Desta forma, as comparações posteriores entre atributos como de diferentes registros de dados podem ser realizadas de acordo com o formato padrão de ambos os atributos e registro de dados. Será evidente para um perito na técnica que cada um dos atributos dos registros de dados a serem comparadas, ou pode ser normalizada por token de acordo com um formato diferente, um conjunto diferente de semântica, léxico, etc., e a normalização de cada atributo em sua forma padrão correspondente pode ser realizada por uma função distinta. Assim, cada um dos registros de dados

Petição 870190083248, de 26/08/2019, pág. 28/98

20/74 pode ser normalizado em um formato padrão, através da padronização dos vários atributos dos registros de dados, cada atributo padronizado por uma função correspondente (estas funções atributo de normalização podem, naturalmente, ser operável para padronizar vários tipos de atributos).

[0051] Por exemplo, o campo 210a do atributo nome de registro de dados 200 pode ser avaliado para produzir um conjunto de tokens para o atributo nome (por exemplo, Bobs, bonito, flor e Shop) e estes tokens podem ser concatenados em conformidade com uma certa forma de produzir um atributo padronizada (por exemplo, BOBS: BONITA: FLOR: LOJA) de tal forma que o atributo padronizado pode posteriormente ser analisado para gerar os tokens que compreendem o atributo nome. Como outro exemplo, quando os nomes são padronizados, tokens individuais consecutivos podem ser combinados em tokens (por exemplo, IBM torna-se IBM) e substituições podem ser realizadas (por exemplo, Co. é substituído por Empresa, Inc. é substituída por Incorporated, etc.). Compreendendo uma tabela de equivalência das abreviaturas e suas substituições equivalentes podem ser armazenados numa base de dados associado com o código de centro de identidade 32. Pseudo para uma concretização de padronizar nomes comerciais são as seguintes:

BusinessNameParse (inputString, equivalenceTable):

STRING OutputString para C em inputString:

se c é uma letra ou um dígito: cópia c para OutputString else if c é um dos seguintes caracteres (E comercial, aspas simples, de volta citação)

Petição 870190083248, de 26/08/2019, pág. 29/98

21/74 pular c (não substituir por um espaço) else // non-ALPHA-DIGIT [&,', '] caractere se o último caractere na sequência de saída não é um espaço, copiar um espaço para sequência de saída.

// Agora extrair os tokens.

TokenList = []

Para token no OutputString // OutputString é uma lista de tokens separados por espaços

Se (token é um único caractere e é seguido por um ou mais caracteres simples)

Combine as singletokens em um único token

Se (equivalenceTable mapeia token)

Substituir token com a sua equivalência.

Anexar token ao token List.

Voltar tokenList [0052] Não importa as técnicas utilizadas, uma vez que os atributos dos registros de dados a serem comparados, e os próprios registros de dados, foram padronizados em um formulário padrão no passo 320, um conjunto de candidatos pode ser selecionado a partir dos registros de dados existentes para comparar com o novo ou registro de dados de entrada(s) no passo 330. Este processo de seleção de candidato (também aqui referidos como bucketing) pode compreender a comparação de um ou mais atributos dos novos registros de entrada de dados ou aos registros de dados existentes para determinar qual do novo existente registros de dados são semelhantes o suficiente para os novos registros de dados de implicar posterior comparação. Cada conjunto de candidatos (grupo bucket) pode basear-se numa comparação de cada um de um conjunto de atributos entre registros de dados

Petição 870190083248, de 26/08/2019, pág. 30/98

22/74 (por exemplo, entre um registro de dados de entrada e um registro de dados existente) usando uma função de seleção de candidatos (função bucketing) correspondente ao atributo. Por exemplo, um conjunto de candidatos podem ser selecionados com base numa comparação entre os atributos de nome e endereço usando uma função de seleção de candidatos desenhado para comparar nomes e outra para comparar endereços.

[0053] No passo 340, os registros de dados que compõem este conjunto(s) de candidatos podem, então, submeter-se a uma comparação mais detalhada com os registros novos ou de entrada sempre que um conjunto de atributos são comparados entre os registros para determinar se um registro de dados existente deve ser vinculado ou associado com o novo registro de dados. Esta comparação mais detalhada pode implicar comparando um ou mais do conjunto de atributos de um registro (por exemplo, um registro existente) para o atributo correspondente no outro registro (por exemplo, a nova entrada ou registro) para gerar um peso para esse atributo. Os pesos para o conjunto de atributos podem então adicionadas para gerar um peso total que pode então ser comparada com um limiar, para determinar se os dois registros devem ser ligados. Por exemplo, se o peso total é inferior a um primeiro limite (referido como o limiar softlink ou revisão), os registros podem não ser ligados, se o peso total é maior do que um segundo limiar (referido como o limiar autolink) os registros podem estar ligados, enquanto que se o peso total cai entre os dois limiares, os registros podem ser ligados e marcados para revisão do usuário.

[0054] Referindo-se brevemente a figura 1, centro de identidade 32 tem vários componentes que podem armazenar, retornar e visualizar scripts e idiomas internacionais na

Petição 870190083248, de 26/08/2019, pág. 31/98

23/74 implementação da metodologia descrita acima. No entanto, esta solução simples pode se tornar mais complexo quando essas vários idiomas são derivadas de diferentes sistemas de fonte de informação, quando o idioma de um registro de dados é desconhecido, quando os registros de diferentes idiomas devem estar dentro da mesma entidade, ou quando as relações entre registros devem ser identificadas a partir de diferentes linguagens (como uma relação hierárquica). Por exemplo, a ligação dos registros de dados pode ser ainda mais complicada pelo fato de os registros de dados de fontes de informação 34, 36, 38 podem estar em diferentes idiomas e, em alguns casos, diferentes registros de dados dentro da mesma fonte de informação podem estar em diferentes idiomas. Suponha que um dos operadores 40, 42, 44 pode transmitir uma consulta em um primeiro idioma para centro de identidade 32 e fontes de informação 34, 36, 38 manter registros de dados sobre as mesmas entidades em vários idiomas, centro de identidade 32 precisaria procurar os registros de dados em idiomas diferentes, determinar se e como devem ser ligados, preparar uma resposta à consulta em conformidade, e enviar a resposta para a consulta de volta ao operador 40, 42, ou 44 no primeiro idioma de uma forma atempada e rigorosa.

[0055] Uma maneira de lidar com registros de dados em vários idiomas é para processá-los por meio de cubos separados, cada um centro configurado em um determinado idioma. A busca de idioma específico pode ser realizada dentro de cada cubo e um usuário ou grupo de usuários pode, em seguida, tentar colocar os resultados da pesquisa em conjunto. O problema dessa abordagem é que não há nenhuma maneira de fazer pesquisas de cross-language e colocando os resultados da pesquisa de cubos separados em conjunto, de

Petição 870190083248, de 26/08/2019, pág. 32/98

24/74 forma manual ou usando um computador, pode ser um tedioso, demorado, de trabalho intenso, caro e de erros processo de bruços. A outra abordagem é tentar escrever um super algoritmo que iria trabalhar em todos os idiomas, mas um super algoritmo tal não é extensível ao(s) novo(s) idioma(s).

[0056] As concretizações aqui divulgadas são baseadas em uma abordagem mais fundamental. Como aqui descrito, concretizações do centro de identidade 32 pode fornecer uma variedade de funções diferentes, incluindo a normalização, bucketing, comparação detalhada, geração de peso, ligando, processamento entidade, etc., e aplicar estas funções com base no idioma de um registro de dados particular ou par de registros de dados. Ou seja, para associar registros de dados em vários idiomas dentro de um único núcleo, centro de identidade 32 pode ser configurado com algoritmos específicos e pode determinar qual algoritmo (s) deve ser utilizado em conjunto com a qual os registros de dados com base no idioma do registro de dados (s) a ser padronizado, em comparação, etc.

[0057] Com referência à Figura 20, que mostra uma concretização do exemplo de execução 300 centro de identidade multilíngue 32, e Figura 21, que ilustra um exemplo de execução 300 com mais detalhes. Como descrito acima, os registros de dados a partir de fontes de informação 34, 36, 38 podem ser os mesmos ou em diferentes idiomas. Assim, na Camada de Núcleo 302, registros de dados são armazenados em vários idiomas. O idioma que cada registro de dados está pode não ser conhecido.

[0058] À medida que cada registro chega, ele é marcado, caracterizado, cedido ou de outro modo associado com um idioma particular. Este processo é automático e

Petição 870190083248, de 26/08/2019, pág. 33/98

25/74 determinístico. Muitas vezes, o idioma de um registro pode ser facilmente determinado. Por exemplo, um código de país pode ser atribuído por um aplicativo do navegador, um idioma padrão pode ser definido por um administrador, um algoritmo pode ser utilizado para determinar o idioma correto com base no conteúdo do registro em conjunto com o código de país associado ao registro, etc. Em algumas concretizações, o pior idioma é selecionado para posterior processamento. Aqui, o idioma é considerado pior do que outro idioma, se é geralmente aceito ou pode ser determinado que pode demorar mais recursos computacionais para processo. Por exemplo, se um registro de dados tem dados em Inglês e Japonês, o idioma japonês é selecionado como o idioma para que o registro de dados em particular, uma vez que pode demorar mais esforço para analisar um registro em japonês, independentemente de saber se esse registro também pode conter Inglês. Em algumas modalidades, o centro de identidade 32 armazena registros de dados em vários idiomas, incluindo Inglês, francês, alemão, chinês, japonês e coreano.

[0059] No exemplo da Figura 21, como registros de dados de R₁, R₂, R₃,..., R_n entrar, eles são atribuídos ou determinada a estar em idiomas L₁, L₂, ..., L_n e R₁ e R₂ são no mesmo idioma L 1. No centro de identidade 32, cada idioma é mapeado um a um para um tipo de membro. Assim, L₁ é mapeado para MemType₁, L₂ é mapeado para MemType₂, etc. Em algumas concretizações, os registros de dados em múltiplos idiomas podem compartilhar tipos de atributos dentro de uma definição de linguagem no centro de identidade 32.

[0060] Para cada registro de dados de um nomeadamente tipo de membro, Camada na Derivado 304, código de derivação única para que tipo de membro particular (e, portanto,

Petição 870190083248, de 26/08/2019, pág. 34/98

26/74 exclusivo para a linguagem mapeada para esse tipo de membro particular) é utilizada para realizar a normalização e bucketing (seleção de candidatos) em atributos. O código de derivação pode utilizar uma ou mais técnicas de normalização. Por exemplo, a linguagem de normalização, normalização transliteração, etc. No caso de transliteração, algumas concretizações podem manter os atributos originais, bem como os transliterados e algumas concretizações só pode manter os (normalizado) os transliterados. Um perito na técnica pode apreciar que outras técnicas de normalização são também possíveis.

[0061] Deve-se notar que este código de derivação original pode processar atributos que contêm caracteres (s) no idioma (s) que não seja a linguagem de marcação para o registro de dados. Por exemplo, suponha que o registro de dados Ri contém atributos nome em Inglês e Japonês. Tal como descrito acima, Ri seria identificado por derivação utilizando código único para japonês, mesmo que R₁ contém atributos nome em Inglês. Em normalização-japonês específico, caracteres que têm pouco ou nenhum significado em japonês pode ser eliminado ou removido de consideração. Exemplos de concretizações de normalização-japonesa específica são descritos abaixo com referência às FIGS. 913. Em algumas concretizações, o processo de seleção de candidatos (bucketing) pode ser independente de linguagem. Exemplos de concretizações bucketing independente da linguagem são descritos abaixo com referência às figuras 14-

19.

[0062] As concretizações aqui divulgadas possível vinculam os registros de dados, mesmo se eles compreendem atributos em uma variedade de outros idiomas além do Inglês.

Petição 870190083248, de 26/08/2019, pág. 35/98

27/74

Específico do idioma normalização pode ser bastante útil na análise de registros de dados em vários idiomas. Por exemplo, der em alemão significa aquilo. Assim, para um registro de dados que está marcado para o alemão e mapeado para um tipo de membro correspondente ao alemão, der em um atributo de nome de registro de dados que pode ser recebido na normalização específica em alemão. No entanto, der em Inglês pode ser um código da estação de Dearborn, Michigan, Estados Unidos. Assim, para um registro de dados que está marcado para Inglês e mapeado para um tipo de membro correspondente para Inglês, um atributo de nome contendo der pode ser padronizado em padronização específica em inglês.

[0063] Em alguns casos, os atributos de registros de dados podem estar num idioma que não usa o alfabeto latino completamente. À medida que esses idiomas não necessariamente obedecem às regras, paradigmas ou convenção de idiomas escritos no alfabeto latino, atributos em idiomas podem ser difíceis de analisar em tokens. Estas questões são particularmente pertinentes quando se trata de idiomas asiáticos, como japonês, coreano, chinês, etc., que utilizam muitos conjuntos de códigos diferentes ou em alfabetos para além caracteres latinos, caracteres ideográficos, etc. Para complicar ainda mais a análise destes tipos de idiomas estão os espaços em branco que não podem ser usados para porções separadas de nomes, tornando a análise de tais nomes em tokens extremamente difícil sem a aplicação de uma grande base de conhecimento para o idioma.

[0064] Como será descrito abaixo com referência às Figuras 9-13, concretizações aqui reveladas podem analisar atributos, como nomes, em vários idiomas, incluindo os

Petição 870190083248, de 26/08/2019, pág. 36/98

28/74 idiomas asiáticos, em tokens. Algumas configurações podem separar atributos nos idiomas da Ásia em tokens. Como exemplo, nomes japoneses (por exemplo, um nome que compreende pelo menos um caractere em um alfabeto ou conjunto de caracteres japoneses, mas que também pode compreender caracteres em qualquer outro alfabeto) são analisados em um ou mais tokens. Em alguns casos, um espaço em branco é introduzido um nome japonês atributo de modo a que o nome japonesa pode ser analisado em uma ou mais tokens com base no espaço em branco.

[0065] Com referência contínua às Figuras 20 e 21, uma vez que os atributos de registros de dados são normalizados em relação ao seu idioma identificado e analisado em tokens na camada derivada 304, que pode ser utilizado no processo de seleção de candidatos (bucketing). Este processo de seleção de candidatos, que pode ser independente de linguagem, pode compreender uma comparação de um ou mais atributos de um conjunto de registros de dados para determinar se eles são suficientemente semelhantes para implicar a comparação adicional. Se assim for, então uma nova determinação é feita sobre como devem ser ligados ou associados. Como será descrito abaixo com referência às Figuras 4-8, a comparação mais pormenorizada pode implicar a comparação de cada um dos conjuntos de atributos de um registro (por exemplo, um registro existente) para o atributo correspondente no outro registro (por exemplo, um novo registro) para gerar um peso para o atributo. Os pesos de cada um dos conjuntos de atributos podem então ser somados para gerar um peso total que pode então ser comparada com um limiar para determinar se os dois registros deve ser

Petição 870190083248, de 26/08/2019, pág. 37/98

29/74 softlinked, autolinked, ou ligado com um sinalizador para avaliação do usuário.

[0066] No contexto de centro de identidade multilíngue 32, os pesos podem ser usados para equilibrar automaticamente a riqueza de idiomas, de modo que dois registros de dados em diferentes idiomas podem ter o mesmo significado estatístico. Em alguns casos, os pesos podem fornecer uma maneira de substituir um nível de associação de dados previamente determinados registros. Geração de peso é ainda descrito abaixo e ensinamentos adicionais sobre a geração de peso pode ser encontrado no Pedido de Patente dos EUA acima referenciado No. 11/809.792, depositado em 1 de junho de 2007, intitulada SISTEMA E MÉTODO PARA GERAÇÃO DE PESO AUTOMÁTICO CORRESPONDÊNCIA PROBABILÍSTICA, o qual é aqui incorporado por referência.

[0067] Assim, os registros de dados marcados para diferentes idiomas podem ser ligados a uma única entidade ou entidades de linguagem do mesmo na entidade da camada 306 no centro de identidade multilíngue 32. Dependendo do modelo de busca utilizado, uma pode querer procurar uma entidade, digamos, Initiate Systems, em idiomas diferentes (por exemplo, Quais são os nomes chineses e alemães para Iniciado Sistemas?) ou procurar a mesma entidade, independentemente de qual idioma os registros estão. Na sequência do exposto exemplo de cuidados de saúde organização com locais em Los Angeles e Nova York, suponha que a organização de saúde também tem uma localização em Paris, França, a organização de cuidados de saúde podem usar centro de identidade 32 para relacionar os registros de dados associados com a pluralidade de hospitais em esses locais para que, quando o paciente está em um hospital em Paris, França, uma consulta para

Petição 870190083248, de 26/08/2019, pág. 38/98

30/74 procurar registros relativos a esse paciente retornará um registro de dados de Inglês em Los Angeles e um registro de dados francesa em Paris.

[0068] Em alguns casos, relações entre os registros de dados de diferentes idiomas podem ter de ser identificado. Ou seja, registros de dados marcadas para diferentes idiomas da camada principal 302 pode ser ligado a várias entidades a entidade da camada 306 em centro de identidade Multilíngue 32. Exemplos de tais entidades podem incluir, mas não estão limitados a indivíduos, famílias, contêineres, organizações, etc. suponha que o mesmo paciente descrito acima é um membro de duas famílias, um nos Estados Unidos e um em França, os registros de dados que pertencem a esse mesmo paciente pode ser ligado a duas entidades de uso doméstico, que identificam a mesma pessoa, mas pode ter dois diferentes atributos endereço e pode estar em dois idiomas diferentes.

[0069] Uma vez que todos os atributos de cada registro de dados e, portanto, o próprio registro de dados é adequadamente padronizado com relação ao idioma dominante de que o registro de dados, centro de identidade Multilíngue 32 pode automaticamente e inteligentemente a coincidir com a algoritmo óptimo (s) para processar essas entidades em idiomas individuais na camada entidade 306. Em outras palavras, uma vez que os idiomas ou roteiro apropriados podem ser passados junto com o registro, o registro pode ser encaminhado para o caminho algoritmo apropriado para a entidade de processamento a entidade da camada 306. Os leitores são direcionados para Pedido de Patente dos EUA No. 11/702.410, apresentado em 5 de fevereiro de 2007, intitulado método e sistema para uma interface gráfica do usuário para configuração de um algoritmo para a comparação de registros

Petição 870190083248, de 26/08/2019, pág. 39/98

31/74 de dados para ensinamentos sobre configuração de um algoritmo para a correspondência de registros de dados. Algumas concretizações aqui divulgadas podem utilizar concretizações de um sistema de processamento de entidade e método para indexação, relativa, e gestão de informações sobre entidades, como divulgado no acima referenciado Pedido de Patente dos EUA N° 11/165,611, depositado em 22 de janeiro de 2007 MÉTODO E SISTEMA PARA INDEXAÇÃO DE INFORMAÇÕES SOBRE ENTIDADES COM RESPEITO A HIERARQUIAS, intitulada No. 11/904.750, depositado em 28 de setembro de 2007, intitulada método e sistema para indexação, RELATIVO E GESTÃO DE INFORMAÇÕES SOBRE ENTIDADES, No. 11/901,040, apresentado em 14 de setembro de 2007, intitulado HIERARQUIA DO SISTEMA DE GESTÃO GLOBAL USUÁRIO E INTERFACE, e No. 12/056.720, apresentado em 27 de março de 2008, intitulado MÉTODO E SISTEMA PARA ENTIDADES GESTORAS, que são incorporados aqui por referência.

[0070] Algumas concretizações aqui reveladas podem alavancar concretizações do atributo análise e comparação de técnicas como descrito no pedido de patente US 11/967,588, depositado em 31 de dezembro de 2007, intitulado MÉTODO E SISTEMA PARA ANÁLISE DE IDIOMAS, No. 11/522,223, apresentado em 15 de setembro de 2006, intitulado MÉTODO E SISTEMA PARA COMPARAR ATRIBUTOS, COMO NOMES PESSOAIS, e No. 11/521,928, apresentado em 15 de setembro de 2006, intitulado MÉTODO E SISTEMA PARA COMPARAR OS ATRIBUTOS, COMO NOMES DE NEGÓCIO, que são aqui incorporados por referência.

[0071] As concretizações de técnicas de normalização e bucketing-japonesas específica será agora descrita com referência às figuras 9-19.

Petição 870190083248, de 26/08/2019, pág. 40/98

32/74 [0072] Voltando agora à Figura 9, um diagrama de fluxo de uma concretização de um método para a análise de uma sequência de caracteres, tais como um nome em japonês (por exemplo, possuindo pelo menos um caractere japonês) é retratado. No passo 910, um nome japonês é recebido. Todos os caracteres Katakana de meia largura, que representam caracteres latinos, em nome recebidos são convertidos em seus equivalentes latino - no passo 920. Numa concretização, cada um dos caracteres nome do nome pode ser representado por um código, por exemplo de acordo com o código promulgada pelo consórcio Unicode (por exemplo, Unicode Transformation Format (UTF) ou conjunto de caracteres Universal (UCS)) ou semelhante, por exemplo, cada caractere pode ser representado por um ponto de código no UCS-4, UTF-32, UTF16, UCS-2, UTF-EBDIC, UTF-8, UTF-7, etc. Assim, cada um dos pontos de código para cada um dos caracteres do nome pode ser comparado a uma gama de pontos de código correspondentes a caracteres de meia largura Katakana que são equivalentes aos caracteres latinos para ver se o caractere é um caractere de meia largura Katakana. Se o caractere é um caractere de meia largura Katakana o que equivale a um caractere Latina, este poderá ser substituído (por exemplo, o ponto de código correspondente ao caráter substituído por outro ponto de código) com um caráter Latim equivalente. Equivalentes latinos na meia largura na faixa de código Katakana devem ser traduzidos para o intervalo Latina. Especificamente, numa concretização, um caractere cujo código porção cai dentro do intervalo de 65281 a 65370 é traduzido para o respectivo ponto de código na gama de pontos de código a partir de 33 a 122 (por exemplo, se um ponto de 65281 código é encontrado, ele é substituído por o ponto de código 33, se

Petição 870190083248, de 26/08/2019, pág. 41/98

33/74 um ponto de código 65300 é encontrado, ele é substituído pelo ponto de código 52, etc.).

[0073] Para facilitar ainda mais a comparação dos atributos de nome, em seguida, todo os caracteres minúsculos latinos no nome podem então ser traduzidos para os seus equivalentes em maiúsculas (por exemplo, um é traduzido como A) no passo 930. Mais uma vez, numa concretização, este pode compreender uma substituição de quaisquer pontos de código que representam os caracteres latinos minúsculas no nome com o respectivo ponto de código representando uma versão em maiúsculas do mesmo caráter Latina.

[0074] No passo 940, qualquer tipo de delimitadores dentro o nome pode ser traduzido para o espaço em branco. A definição de quais caracteres são delimitadores pode ser tanto uma lista padrão de delimitadores correspondentes ao conjunto de pontos de código utilizados ou pode ser uma lista proprietária de delimitadores (por exemplo, o que pode incluir uma lista padrão de delimitadores mais específicas delimitadores para o idioma do nome, tal como delimitadores específicos japonesas ou similares ou quaisquer outros delimitadores desejado). Por exemplo, uma lista de pontos de código correspondentes aos delimitadores pode ser armazenada numa base de dados de tal modo que no passo 930 a cada um dos pontos de código de caracteres do nome pode ser comparada com a lista de delimitadores e se o ponto de um caractere de código o nome corresponder a um ponto de código na lista de delimitadores ao ponto de o caráter do nome de código podem ser substituídos com o ponto de código correspondente ao espaço em branco.

[0075] Em seguida, no passo 950 caracteres tradicionais no nome podem ser traduzidos para um equivalente

Petição 870190083248, de 26/08/2019, pág. 42/98

34/74 simplificado. Mais uma vez, numa concretização, um mapeamento tradicional de código de pontos correspondentes aos caracteres tradicionais para codificar pontos correspondentes ao seu equivalente simplificado pode ser usado para traduzir um caractere tradicional para o seu equivalente simplificado, substituindo o ponto de código correspondentes aos caracteres tradicional, com o ponto de código correspondente ao caráter simplificado equivalente. Numa outra concretização, no entanto, o mapeamento entre os caracteres tradicionais e caracteres simplificados pode ser um mapeamento proprietária e uma base de dados pode armazenar uma lista de pontos de código de caracteres tradicionais, onde cada um destes pontos de código está associado com um ponto de código para o caractere simplificado equivalente. Usando esta lista, em seguida, os caracteres tradicionais do nome podem ser identificados por meio da comparação dos pontos de código do nome para a lista e os caracteres tradicionais identificadas traduzido para caracteres simplificados, substituindo o seu ponto de código com o código de associado para o caractere simplificado equivalente.

[0076] Depois de caracteres tradicionais são traduzidos para seu equivalente simplificado, no passo 950, o espaço em branco pode ser inserido entre caracteres de diferentes tipos no passo 960. Por exemplo, um nome japonês pode englobar caracteres de muitos tipos diferentes: Latina, hiragana, katakana, fonética Katakana, meia-largura Katakana, entre muitos outros. Assim, se dois caracteres que são de diferentes tipos (por exemplo, diferentes conjuntos de caracteres) de espaço em branco pode ser inserida entre os dois caracteres no nome. Numa concretização, as gamas de

Petição 870190083248, de 26/08/2019, pág. 43/98

35/74 pontos de código podem designar conjuntos de caracteres (por exemplo, caractere Latina pode compreender a gama de pontos de código de 1 a 255, Hiragana pode compreender o caractere da gama de pontos de código de 12352 para 12447, etc.). Gamas de ponto de código. Portanto, utilizar especificadas ou de outra forma definidos, caracteres adjacentes dentro de várias categorias de ponto de código podem ser identificados e os espaços em branco inserido no nome entre esses dois caracteres.

[0077] Após a inserção de espaços em branco entre caracteres de diferentes tipos na etapa 960, caracteres ideográficos podem ser identificados em nome e estes caracteres ideográficas ajustados fora por espaços em branco (por exemplo, um espaço em branco inserido, antes ou depois do caractere) no passo 970. Numa concretização, uma lista pode ser mantida compreendendo um conjunto de pontos de código que corresponde a caracteres IDEOGRAPHIC. Se um caractere é identificado no nome que é um ideográfico (por exemplo, através da comparação do ponto de código correspondentes aos caracteres para os pontos de código que compreendem uma lista de caracteres ideográficas), espaços em branco podem ser inseridos no nome antes do caractere Ideográfico e depois do caractere ideográfico (por exemplo, se o caractere ideográfico não é o último caractere do nome).

[0078] O nome pode então ser analisado em um conjunto de token no passo 980. Numa concretização, esta análise pode ser feita com base no espaço em branco no nome. Assim, o espaço em branco pode designar o final de um sinal do nome ou do início de outro token do nome. Desta forma, em seguida, um conjunto de tokens pode ser obtido a partir de um nome japonês. Além disso, através da aplicação de outras

Petição 870190083248, de 26/08/2019, pág. 44/98

36/74 concretizações da divulgação (que podem, por exemplo, utilizar diferentes pontos de código ou intervalos de ponto de código) Nomes em outros idiomas asiáticos, como coreano ou chinês pode também ser separados em um conjunto de tokens. Uma concretização para comparar nomes ou atributos japoneses compreende analisar os nomes em tokens, utilizando uma técnica de tradução baseada em tabelas. Numa concretização, a técnica de tradução induzido por tabela pode ser realizada através de mapeamento Unicode ou capacidade de tipo Umap para mapeamento / filtragem de entre diferentes conjuntos de caracteres e de codificação. Podem também ser utilizadas outras técnicas de tradução.

[0079] Assim, numa concretização, um nome japonês pode ser analisado em tokens como segue:

- Traduzir meia largura Katakana para o latim.

- Traduzir equivalentes latinos na faixa de código de meia largura Katakana em decimal (65281, 65370) para a gama Latina em decimal (33, 122).

- Traduzir minúsculas Latinas para maiúsculas.

- Traduzir delimitadores de espaço em branco.

- Adicionar delimitadores específicas-japonesa à lista padrão quando aplicável. Embora não seja uma lista exaustiva exemplos extraídos de dados de exemplo incluem:

Petição 870190083248, de 26/08/2019, pág. 45/98

37/74

Decimal code	Character
34
38	&
39
40	(
41	)
42	*
43	4-
44	,
45
46
47	/
58
59
95
65381
12539	•
12283

[0080] Traduzir caracteres chineses tradicionais para caracteres simplificados. Numa concretização, há uma tabela de 222 destas traduções. Um exemplo é mostrado na FIGURA 10, onde o caractere tradicional é na segunda coluna e o equivalente é simplificado na primeira coluna.

[0081] Uma segunda técnica pode ser aplicada quando conjuntos de código de alteração. Um exemplo de que é ddddddd onde os três primeiros caracteres são Katakana e os quatro últimos são Kanji. Aqui, dois tokens seria formado. Isso também irá ajudar quando não está embutida Latina como NTTDDDDDDD ou DDDDDD. A diferença entre o primeiro e o segundo é que o primeiro utiliza reais pontos de código latino, onde o segundo usa seus equivalentes de meia largura.

[0082] Os seguintes intervalos de pontos de código são exemplares e não esgotam a gama completa ou intervalos disponíveis:

Petição 870190083248, de 26/08/2019, pág. 46/98

38/74

Character-set name	Decimal range
Latin	1	255
Hiragana	12352	12447
Katakana	12448	12543
Katakana phonetic	12784	12799

Half - kat	65280	65519
CJK - unified	19968	40895
CJK - a ext	13312	19903
CJK - b ext	131072	173791
CJK compatible	63744	64255
CJK - b comp	194560	195103
CJK - radicals	11904	12031
CJK - strokes	12736	12783

Aqui, a primeira coluna é o nome do conjunto de caracteres e o segundo e o terceiro são os intervalos decimais. CJK - unificada é o que é chamado de Kanji, quando aplicados a dados japoneses.

[0083] A distribuição segue são a partir de estatísticas sobre caracteres de um conjunto de amostras de dados de nome da empresa japonesa:

Petição 870190083248, de 26/08/2019, pág. 47/98

39/74

Character-set name	Occurrence
Latin	51288
Hiragana	5159
Katakana	154766
Katakana phonetic	0
Half - kat	20543
CJK - unified	226443
CJK-a ext	0
CJK - b ext	0
CJK compatible	5
CJK - b comp	0
CJK-radicals	0
CJK - strokes	0

Neste caso, a maioria são Kanji (CJK - unificado) e katakana .

[0084] Neste exemplo, determinados caracteres nos dados não cair em nenhum destes grupos. Eles eram em sua maioria modificadores e esses caracteres foram agrupados caracteres com os caracteres que precedê-la (a mais comum delas foi o caractere iterador D (ou seja, DD significa DD). Quase qualquer método de modificadores de agrupamento ou outros caracteres não agrupados pode ser aplicada.

[0085] Os supracitados duas técnicas podem ser combinadas. Por exemplo, eles podem ser aplicados a um conjunto de exemplos de nomes de modo que DDDDDDDDDD analisa {D, DDDDDDD}, e torna-se ddddddddddd {dddd, DD, DDDD}, etc. Uma amostra da análise é mostrada na Figura 11. A Figura 12 é um histograma representando as estatísticas do número de tokens a análise criada para cada nome do conjunto de amostra de dados. Como pode ser visto na Figura 12, cerca de 16.608 dos nomes foram deixadas como tokens individuais de 44,681

Petição 870190083248, de 26/08/2019, pág. 48/98

40/74 nomes de amostra. Deste modo, cerca de 63% dos nomes foram analisados em pelo menos dois tokens. A maioria é de dois nomes simbólicos e a média é de 1,94 tokens analisados por nome. A Figura 13 é um histograma que representa a distribuição dos comprimentos dos caracteres do tokens analisados, com uma média de 5,1 caracteres por token. Isso se compara a um comprimento médio de 10,3 caracteres nos dados originais. Para resumir, nesta concretização, os passos para a análise do nome compreendem:

1. traduzir os caracteres de meia largura para seus equivalentes latino - aqueles que os têm.

2. traduzir minúsculas Latina a maiúsculas Latina.

3. traduzir caracteres especiais para espaços em branco (delimitadores).

4. inserir espaços em branco sempre que caracteres mudar de um conjunto de códigos para outro - os intervalos também devem ser orientados por tabelas - a menos que a mudança é um modificador.

5. inserir espaços em branco antes e depois (se necessário) quaisquer caracteres ideográficos; e

6. analisar os tokens no espaço em branco.

[0086] Deve-se notar que qualquer linguagem limitando designa porções de ou artigos dentro de concretizações descritas acima irá ser entendido aplicar-se apenas na vista de, ou em relação a, as concretizações particulares, e não deverá ser entendido para uma aplicação geral para os sistemas e métodos da presente invenção.

[0087] Em algumas concretizações, um método de bucketing para nomes em inglês compreende três passos principais:

1) a análise de um nome em tokens;

Petição 870190083248, de 26/08/2019, pág. 49/98

41/74

2) a criação de um código fonético para os tokens e quaisquer tokens equivalentes (por exemplo, apelidos); e

3) aplicação de bucketing baseado na frequência para tokens foneticamente codificados.

[0088] A seguir descreve como, uma versão deste método independente de idioma genérico pode ser criada e aplicada a nomes em idiomas arbitrários. Este método bucketing independente de linguagem pode fornecer uma capacidade de correspondência básica e pode ser utilizado com o método de análise descrito acima, em que a entrada é analisada com base em um conjunto de delimitadores e mudanças no script. Atualmente, centro de identidade 32 pode executar processamento de nome equivalente independente de idioma e bucketing baseado em frequência independente de idioma. Assim, para criar um método de bucketing independente de idioma, a única coisa que resta a fazer é criar uma rotina de codificação genérica que pode ser aplicada a idiomas/ script arbitrários.

[0089] Na criação de um idioma/ script sistema de codificação independente, é preciso considerar as estatísticas de caráter. Como um exemplo, a Figura 14 representa um único caractere de distribuição a partir de uma amostra nome japonesa após análise e da tradução. Em alfabetos mais restritos, um provavelmente precisará olhar para caracteres emparelhados ou gráficos bi. Suponha-se que após a análise e da tradução, há 2168 caracteres com a distribuição mostrada na Figura 14. A Figura 15 lista os primeiros 20 japoneses caracteres e as suas frequências a partir da amostra da figura 14.

[0090] Uma vez que a distribuição cai rapidamente, isto sugere que quase todos os tokens analisados irá conter

Petição 870190083248, de 26/08/2019, pág. 50/98

42/74 alguns caracteres não frequentes. Assim, um esquema de codificação pode ser construído com base selecionando o n caracteres mais raros de cada token. Neste caso, o algoritmo pode compreender:

1. Ordene os caracteres que compõem o token pela sua frequência global. Menos frequentes primeiro caractere.

2. Escolha do primeiro n destes (até o comprimento do token original).

[0091] Ao escolher n, a frequência de token é o de não ser demasiado inflada. Isto é, a distribuição dos sinais codificados deve estar dentro de uma ordem de grandeza da distribuição dos sinais originais. Esta é uma das razões que metaphone é preferência sobre Soundex. Suponha que nós olhamos n = 2 e n = 3 e estabeleceu-se no último. A distribuição é mostrada na Figura 16.

[0092] Aqui, a curva 160 representa a distribuição dos tokens originais e a curva 162 representa a distribuição dos tokens codificados. Exceto os primeiros dois valores codificados, os quais podem ser manuseados com bucketing baseado na frequência, a distribuição parece razoável.

[0093] Em seguida, estes tokens codificados são usados para bucketing. Para ilustrar como um exemplo, vamos usar um corte de 1/1000 e bucket em tokens individuais, se a sua frequência é inferior a 1/1000 e de outra forma utilizar combinações de pares, enquanto a frequência par é menor que 1/1000.

[0094] A Figura 17 ilustra um exemplo de nomes processados originais (coluna esquerda) e itens de bucket correspondentes (coluna da direita). Note-se que na 5^a linha, os três únicos tokens de caracteres não são frequentes o suficiente para bucket sozinho, enquanto na 6a linha, nós

Petição 870190083248, de 26/08/2019, pág. 51/98

43/74 terminamos com dois buckets, em dois sentidos. Observe também que esses dados também contêm palavras em Inglês. Estes não são tratados de forma diferente.

[0095] A aplicação do regime acima descrito, Figura 18A mostra que bucketing em nome analisado 170 cria um conjunto de nomes no bucket 175 e 18B mostra que bucketing em nome analisado 180 cria um conjunto de nomes no bucket 185. Ambos estes exemplos ilustram um método independente de linguagem de bucketing de nome.

[0096] A figura 19 é um diagrama que ilustra o enredo número de membros que juntos realizam bucket qualitativamente. A média desta distribuição é de 17 (ou seja, em média, um membro realizaria bucket com 17 outros membros em nome sozinho). A partir da Figura 19, cada 100 consultas, nós realizaríamos bucket com mais de 170 membros. Este é um exemplo de execução. Outras implementações podem bater uma ordem de magnitude vezes a média de 1: 1000 (-3 no eixo dos Y) em vez de 1: 100 [0097] Na arquitetura atual, o método bucketing acima descrito pode ser facilmente implementado com razoável desempenho. Por exemplo, uma rotina de codificação pode consumir uma tabela de frequência caráter, classificar os caracteres no token de acordo com que frequência, e selecione os três principais caracteres. Para usar essa rotina em outros que não o japonês roteiros, o número de caracteres selecionados pode ser um parâmetro configurável. O bucketing à base de frequência atual pode então ser utilizado. Uma vez que as distribuições dos sinais originais e os tokens codificados são semelhantes, as frequências podem ser executadas, quer pelos sinais originais ou sobre os sinais codificados. Os tokens podem ser encomendados utilizando as

Petição 870190083248, de 26/08/2019, pág. 52/98

44/74 técnicas descritas no pedido de patente No. 11/522.223, apresentado em 15 de setembro de 2006, intitulado MÉTODO E SISTEMA PARA COMPARAR ATRIBUTOS, COMO NOMES PESSOAIS, e No. 11/521,928, depositado em 15 de setembro de 2006, intitulado MÉTODO E SISTEMA PARA COMPARAR OS ATRIBUTOS, COMO NOMES DE NEGÓCIO, que são aqui incorporados por referência.

[0098] Referindo-se novamente às Figuras 20 e 21, não importa as técnicas utilizadas, uma vez que os atributos dos dados registros a serem comparados foram padronizados e um conjunto de candidatos selecionados para comparação, comparação mais detalhada entre os registros de dados pode ser realizada no nível de atributo. Um peso pode ser gerado para cada comparação.

[0099] Voltando agora à figura 4, um diagrama de fluxo de uma concretização de um método para gerar uma contagem a partir da comparação de atributos é descrito. Embora a concretização do método descrito pode ser utilizada para comparar quaisquer dois atributos (por exemplo, nomes de pessoas, nomes, endereços de empresa, etc.), que pode ser especialmente útil para a comparação nomes comerciais, e será descrito como tal.

[0100] Em passo 410, dois nomes são dados ou fornecidos (por exemplo, a entrada de um aplicativo de software) de tal forma que estes nomes podem ser comparados. Os nomes podem ser cada um em um formulário padronizado que compreende um conjunto de tokens, como discutido acima. Uma pontuação de informação pode ser calculada para cada um dos nomes na etapa 420. Esta pontuação informação para o atributo pode ser a soma dos valores exatos das correspondências (também referido como a pontuação de informação para o sinal) de cada um dos tokens do nome. A pontuação de informação dos

Petição 870190083248, de 26/08/2019, pág. 53/98

45/74 dois atributos pode então ser calculada a média no passo 430.

[0101] O uso de um valor médio para a pontuação de informação dos dois atributos (em vez de, por exemplo, uma informação de pontuação máxima entre os dois mínimos ou atributos) pode permitir concretizações do algoritmo de comparação de nome para permitir que o peso gerado entre dois atributos para ter em conta em falta tokens entre os dois atributos, e, em algumas concretizações, pode permitir que a penalidade aplicada por falta de tokens para ser metade da penalidade aplicada por isso de uma incompatibilidade entre dois tokens. A pontuação de informação de cada um dos tokens pode, por sua vez, ser baseada na frequência da ocorrência de um token numa amostra de dados. Através da utilização de frequência relativa de tokens para determinar uma pontuação de informações para o token, a uniformização de certos sinais (por exemplo, Inc.) podem ser tidos em conta ao marcar esses tokens inferior.

[0102] Uma pontuação entre os dois nomes pode, então, ser gerada no passo 440 por comparação dos dois nomes. Esta pontuação pode então ser normalizada no passo 450 para gerar uma pontuação final para os dois nomes. Numa concretização, este processo de normalização pode aplicar um fator de escala para a razão entre o marcador gerado para a pontuação de informação média para gerar um valor de índice normalizado. Este valor de índice normalizado pode então ser utilizado para indexar uma tabela de valores para gerar uma pontuação final probabilidade.

[0103] Ela pode ser útil aqui para mergulhar com mais detalhes nas várias etapas da concretização de um algoritmo para comparação de nomes ilustrado na figura 4. Como tal, o

Petição 870190083248, de 26/08/2019, pág. 54/98

46/74 primeiro a ser abordado será o cálculo de uma pontuação de informação média, como representado no passo 430. Como discutido acima, o marcador de informações para um atributo pode ser a soma dos pesos correspondentes exatos para cada um dos tokens do atributo. Pode ser útil para descrever as concretizações da forma como estes pesos correspondentes exatos são calculados. Em uma realização, uma tabela de peso correspondente exato pode ter valores de peso para uma correspondência exata para um token ou um valor padrão a ser usado para uma correspondência exata para um token. Em outras palavras, a tabela de correspondência exata de peso pode compreender uma lista de tokens com um valor do peso correspondente. Este valor do peso pode corresponder a uma peso de correspondência exata. Colocado de uma maneira diferente, se ambos os sinais a serem comparados são os mesmos, o testemunho pode ser localizado na tabela de peso correspondente exato e o peso correspondente é usado como o peso correspondente para os dois tokens. Se dois tokens estão determinados a ser uma correspondência exata e o token não está na tabela de peso correspondente exato, um valor de peso padrão pode ser utilizado para o peso correspondente.

[0104] Numa concretização, os pesos associados com os tokens na tabela de peso correspondente exato podem ser calculados a partir de um conjunto de amostras de registro de dados, como um conjunto de registros de dados associados a uma ou mais das fontes de informação 34, 36, 38 ou um conjunto de registros de dados fornecidos. Usando o exemplo de conjunto de registros de dados de pesos de correspondência exata pode ser calculada usando dados de frequência e os dados de conjunto correspondente. O número de strings de nome (por exemplo, atributos de nome) NomeTot no exemplo de

Petição 870190083248, de 26/08/2019, pág. 55/98

47/74 conjunto de registros de dados pode ser computada, e para cada nome do token T correspondente a essas sequências de nome uma contagem: T_count e uma frequência T_freq = T_Count / Nome_Tot.

[0105] Os tokens são, então, ordenados por tokens com frequências mais altas primeiro e uma frequência cumulativa para cada token que é a soma das frequências para o token e todos aqueles que vieram antes de ser calculado como descrito na Tabela 1 que se segue:

Token	Freq	Cumulative Freq
To	T freq-0	T freq-0
Ti	T freq-1	Tfreq-o+ Tfreq-1
T 2	T freq-2	T freq-O+ T freq-1 + T freq-2
......	......	......
TN	T freq-N	Tfreq-o+ ......+ Tfreq-N

[0106] Em algumas configurações, todos os tokens até e incluindo o primeiro sinal cuja frequência acumulada excede 0,80 são, então, determinados e para cada um destes tokens o peso exato correspondente pode ser calculado utilizando a fórmula: Exat_Ti = - In (T_freq-i) . Se T_M é o primeiro sinal cuja frequência cumulativa superior a 0,80 e T_N é a última ou a menor frequência de token de exato o peso correspondente padrão pode ser calculado pela média de -In (T_freq. _M + i) t · · ·, -In (T_freq. _N) . Uma concretização do algoritmo de comparação aqui descrito para comparar nomes pode então ser aplicada a um conjunto de pares aleatórios de nomes nos dados estabelecidos para gerar: Ran_NameComp = O número total de pares de nome de corda em comparação e para i = 0 a MAX_SIM, Ran Sim-I = o número total de pares nome de cordas cuja semelhança é normalizado I. Para cada I, RanFreq _Si_m-i= Ran_slm

Petição 870190083248, de 26/08/2019, pág. 56/98

48/74 __Σ / Ran_NameComp pode então ser calculado. Match Freq Sim-I = MatchSim -I / Match_NameComp também pode ser calculado para um sinal utilizando o processo de geração de peso tal como descrito no Pedido de Patente dos EUA No. 11/521,928, com o titulo MÉTODO E SISTEMA PARA COMPARAR ATRIBUTOS, COMO NOMES DE NEGÓCIO por Norm Adams et al. , apresentado em 15 de setembro de 2006, ou Pedido de Patente dos EUA 11/522,223, intitulado Método e sistema para comparar atributos, como nomes pessoais por Norm Adams et al., depositado em 15 de setembro de 2006, ambos os quais são aqui totalmente incorporados por referência. Pesos finais para um token podem então ser calculados como: Peso-Norm-Simx = loglO (MatchFreq sim-i/ RanEreqsim-z) .

[0107] Uma vez que os pesos correspondência exata para um conjunto de tokens são calculados podem ser armazenados em uma tabela em um banco de dados associado centro de identidade 32. Por exemplo, o seguinte pseudocódigo descreve uma concretização para o cálculo de uma pontuação de informações para um atributo utilizando duas tabelas uma tabela initialcontent que compreende pesos de correspondência exata para as iniciais, e exactContent compreendendo pesos correspondência exata para outros tokens:

tokenListlnfo(tList) total Info = 0.0 for token in tList:

if token is an initial:

totalinfo += initialContent(token) else totalinfo += exactContent(token) return total Info

Petição 870190083248, de 26/08/2019, pág. 57/98

49/74 [0108] Referindo ainda à figura 4, uma vez que pontuações de informação são calculadas e estes pesos em média, no passo 430, pesos podem ser gerados para os dois nomes no passo 440. Voltando agora à Figura 5A, um diagrama de fluxo de uma concretização de um método para gerar um peso entre dois atributos está representado. Mais particularmente, cada token de um atributo pode ser comparada no passo 515 para cada token de outro atributo. Esta comparação pode ser efetuada de acordo com a ordem do conjunto de tokens que compõem cada atributos. Em outras palavras, o primeiro sinal de um atributo pode ser comparado com cada um dos tokens de outro atributo, após o que o segundo token de atributo pode ser comparado a cada um dos tokens do outro atributo, etc.

[0109] Para cada um desses pares de tokens pode ser determinado se existe uma correspondência entre os dois tokens no passo 525. Se não existir nenhuma correspondência entre os dois tokens no passo 525 o peso correspondente atual pode ser definido como zero no passo 537. Se existir uma correspondência entre os dois tokens, no entanto, o peso atual correspondente para os dois tokens pode ser calculado no passo 535.

[0110] Uma vez que tenha sido determinado se existe uma correspondência entre os dois tokens no passo 525 e o peso correspondente calculado no passo 535 para o peso correspondente atual se tal correspondência existe, pode ser determinado se uma penalidade de distância deve ser imposta no passo 547. Numa concretização, pode ser determinado se uma penalidade de distância deve ser imposta, e a penalidade de distância computada, com base em onde a última correspondência entre um par de tokens dos atributos ocorreu.

Petição 870190083248, de 26/08/2019, pág. 58/98

50/74

Para este fim, a última posição de correspondência pode ser determinada no passo 545 que indica onde a última correspondência entre dois tokens dos atributos ocorreu. Se a diferença de posição (por exemplo, em relação aos atributos) entre os dois tokens atuais a serem comparados e a última posição correspondente é maior do que um certo limiar, uma penalidade de distância pode ser calculada no passo 555 e o peso correspondente atual corrigido no passo 557 pela subtração da penalidade de distância do peso correspondente atual. Será evidente que estas penalidades de diferença podem diferir com base na diferença entre a última posição correspondente e a posição dos tokens atuais.

[0111] Os pesos correspondentes para os tokens anteriores dos atributos podem também ser determinados nos passos 565, 567 e 575. Mais particularmente, na etapa 565, um primeiro peso correspondente anterior é determinado para o token de um atributo a ser comparado e o token anterior (por exemplo, que precede o token atual a ser comparado em ordem) do segundo atributo atualmente a ser comparado, se ele existe. Da mesma forma, no passo 567 um segundo peso correspondente anterior é determinado para o token de segundo atributo a ser comparado e o token anterior do primeiro atributo a ser comparado, se ele existir. No passo 575, um terceiro peso correspondente anterior é determinado utilizando os tokens anteriores de cada um dos atributos atuais, se existir qualquer token. O peso correspondente atual para o par de tokens a ser comparado pode depois ser ajustada pelo passo 577, adicionando o terceiro peso correspondente anterior ao peso correspondente atual.

[0112] O peso correspondência atual pode então ser comparado com o primeiro e segundo anterior combinar peso,

Petição 870190083248, de 26/08/2019, pág. 59/98

51/74 no passo 585, e se o peso correspondente atual é maior ou igual a qualquer um dos pesos correspondentes anteriores, o peso pode ser ajustado para o peso correspondente atual no passo 587. Se, no entanto, o primeiro ou o segundo peso correspondente anterior é maior do que o peso correspondente atual irá ser definido como o maior dos primeiros ou segundos pesos correspondentes anteriores no passo 595. Deste modo, depois de cada um dos sinais dos dois atributos foi comparado um peso vai ser produzido.

[0113] Torna-se evidente que muitos tipos de elementos de dados ou estruturas de dados podem ser úteis na execução de certas concretizações aqui reveladas. Por exemplo, a Figura 5B representa um diagrama de fluxo para uma concretização de um método para gerar um peso entre dois atributos, utilizando uma tabela. No passo 510 uma tabela pode ser construída para auxiliar na comparação entre os dois nomes. Esta tabela pode compreender uma linha para cada uma dos tokens em um dos nomes além de uma linha adicional, e uma coluna para cada um dos tokens no outro nome além de uma coluna adicional. Deste modo, a primeira fileira e da primeira coluna da tabela pode corresponder às condições iniciais, ao passo que cada uma das outras células da tabela pode corresponder a um único par de sinais, um sinal a partir de cada um dos nomes a ser comparadas. Cada célula da tabela pode ter a capacidade de armazenar uma posição (por exemplo, celular) e um indicador de peso. Enquanto uma tabela é utilizada na concretização ilustrada, será evidente que uma tabela é apenas um exemplo de estrutura, e qualquer estrutura de dados, armazenamento de estrutura pode ser utilizada (por exemplo, uma matriz de qualquer dimensão, uma lista ligada, uma árvore, etc.).

Petição 870190083248, de 26/08/2019, pág. 60/98

52/74 [0114] Depois da tabela é construído no passo 510, pode ser inicializado no passo 520 de modo a que certas células iniciais dentro da tabela têm valores iniciais. Mais particularmente, numa concretização cada uma das primeira linha e primeira coluna pode ser inicializado de modo a que a posição do indicador pode receber um valor nulo ou o valor zero e o peso associado com cada uma destas células pode ser inicializado para um valor de zero.

[0115] Cada uma das outras células (por exemplo, para além das células iniciais) da tabela pode então ser iterado para determinar uma posição e um valor a ser associado com a célula. Para cada uma das células é determinado, se a célula já foi acompanhada por meio de uma sigla de correspondência no passo 530, e se assim a célula pode ser omitida. Se a célula não foi previamente combinada, no entanto, no passo 540, pode ser determinado se existe uma correspondência entre os dois marcadores de célula correspondentes, se não existir nenhuma correspondência pode, então, ser determinado se qualquer uma dos tokens correspondentes à célula é um acrônimo para um conjunto dos tokens no outro nome no passo 532, por, numa concretização, comparando os caracteres de um token para os primeiros caracteres de um conjunto de tokens de outro nome. Se um dos tokens é um acrônimo de um conjunto de tokens no outro nome, um último indicador de posição e de peso celular (como descrito em mais detalhes a seguir) é calculado no passo 534 para o conjunto de células, cujos tokens correspondentes são o acrônimo e o conjunto de tokens de outro nome que corresponde à sigla. Pseudocódigo para determinar se um marcador é um acrônimo de um conjunto de tokens de outro nome é o seguinte:

Petição 870190083248, de 26/08/2019, pág. 61/98

53/74

MAX INIT MATCH is the maximum acronym length, which, in this embodiment, is 3.

acroynmCheck(acToken, //a token which we will check as a possible acronym tokenList, //the other list of tokens currentPosition //start at this position to check for an acronym match )

if (length(acToken) < 2 or >MAX_INIT_MATCH) return NO_MATCH if (currentPosition + length(acToken) -1 > length(tokenList)) return NO_MATCH listPosition = currentPosition tokenPosition = 0 total Info = 0 while(tokenPosition != end of word) if firstChar of tokenList[listPosition] != acToken[tokenPosition] return NO_MATCH total Info = totalinfo + initialContent(firstChar) - INIT_PENALTY tokenPosition++ listPosition++ return MATCH, totalinfo, listPosition [0116] Se for determinado que nenhum dos tokens é um acrônimo no passo 532, o peso páreo para a célula atual pode ser definido como zero no passo 542. Voltando ao passo 540, se existir uma correspondência entre os dois tokens correspondentes à célula atual, o peso correspondente para os dois tokens pode ser calculado no passo 542. Apesar de virtualmente qualquer tipo de comparação pode ser utilizada

Petição 870190083248, de 26/08/2019, pág. 62/98

54/74 para comparar os dois sinais correspondentes e gerar um peso correspondente associado de acordo com os passos 540 e 542, numa concretização, pode ser determinado se um correspondência exata, uma correspondência inicial, uma correspondência fonética, uma correspondência ou um jogo apelido apelido-fonética ocorre e um peso correspondente calculado conforme descrito no já mencionado Pedido de Patente dos EUA No. 11/522.223, intitulado MÉTODO E SISTEMA PARA COMPARAR OS ATRIBUTOS TAIS COMO NOMES DE PESSOAL por Norm Adams et ai., apresentado em 15 de setembro de 2006, que é totalmente aqui incorporada por referência. Pseudocódigo para comparar dois tokens e gerar um peso correspondente associado é a seguinte:

tokenCompare(11, t2) //t1 and t2 are tokens.

If one or both is an intial:

If first chars agree:

Return min(exactContent1, exactContent2) - Initial_Penalty

Else

Return 0.0, NO_MATCH

Petição 870190083248, de 26/08/2019, pág. 63/98

55/74

Dist = normalizedEditDistance(t1, t2)

If Dist == 0

Return exactContent(tl), EX ACT_ MATCH

If tokens match phonetically

Return min(exactContent1, exactContent2) - phonetic_Penalty,

PARTIAL-MATCH

If tokens match via a nickname

Return Return min(exactContent1, exactContent2) Nickname_Penalty, PARTIAL-MATCH if there is a nickname-phonetic match

Return Return min(exactContent1, exactContent2) Nickphone_Penalty, PARTIAL-MATCH

If Dist <= 0.2 * maximum token length

Return min(exactContent1, exactContent2) - Nickname_Penalty,

PARTIALMATCH

Else:

Return 0.0, NO MATCH [0117] Olhando ainda para a Figura 5B, uma vez que tenha sido determinado se existe uma correspondência entre os dois tokens correspondentes à célula no passo 540 e o peso fósforo calculado no passo 542, se uma tal correspondência existe, pode ser determinado se uma penalidade de distância deve ser imposta no passo 550 e a pena distância calculada no passo 552. Numa concretização, pode ser determinado se uma penalidade de distância deve ser aplicada, e a penalidade de distância calculada, com base numa diferença entre a posição de uma célula que corresponde a uma última posição correspondente e a célula atual. Uma diferença na posição da linha e posição da coluna pode ser calculada, e se a diferença for maior do que um (indicando que uma penalidade de distância deve ser imposta) , a maior

Petição 870190083248, de 26/08/2019, pág. 64/98

56/74 destas diferenças pode usado para determinar uma penalidade de distância para impor. Por exemplo, se a diferença entre as células de corrente de linha e a linha da célula com a última correspondência é dois e a diferença entre a coluna de células de corrente e da coluna da célula com a última correspondência é três, uma penalidade de distância associada com a distância de três que podem ser utilizados. Será evidente que grandes penalidades diferença pode associado e impôs baseada em uma maior distância entre a última célula correspondente e a célula atual que está sendo avaliada. Se, de fato, é determinado que uma distância grande penalidade deve ser imposta e da pena de distância calculada no passo 550, o peso correspondente pode depois ser ajustado pelo passo 560, subtraindo a pena de distância do peso correspondente.

[0118] Usando o peso correspondente para a célula, em seguida, um peso de células e última posição correspondente para a célula pode ser calculado no passo 570. Um diagrama de fluxo de uma concretização de um método para calcular uma posição correspondente e um último peso de célula para uma célula está representada na FIGURA 6. Geralmente, o peso da pilha e última posição correspondente pode ser calculada com base na última posição correspondente e o peso das células das células circundantes. Em especial, uma célula de peso a partir de uma célula adjacente da célula corrente (por exemplo, o número da linha da corrente de uma célula de menos e o mesmo número da coluna) pode ser determinado no passo 610 e o peso das células a partir de outra célula adjacente a célula corrente (por exemplo, o número de coluna da corrente menos uma célula e o mesmo número de linha) pode ser determinado no passo 620. No passo

Petição 870190083248, de 26/08/2019, pág. 65/98

57/74

630, um peso de células temporária pode ser determinada pela adição do peso celular da célula adjacente numa diagonal (por exemplo, a número da linha da corrente de uma célula de menos e o número de células atual coluna menos um) para o peso de fósforo calculado para a célula corrente (passo 570).

[0119] Os pesos de células a partir de duas células adjacentes e o peso das células temporária pode ser comparado no passo 640. Se o peso das células temporária é maior do que qualquer um dos pesos celulares das células adjacentes, a última posição correspondente da célula de corrente é ajustada para a posição da célula atual no passo 642 e o peso das células de a célula corrente é ajustado para o peso das células temporário, no passo 644. Se, no entanto, um dos pesos de células excede o peso de células temporárias, o maior dos dois pesos celulares será atribuído como o peso celular da célula corrente e o valor do indicador de última posição correspondente dessa célula (por exemplo, células com maior peso das células adjacentes) será designado como o último indicador de posição da célula atual no passo 652 ou passo 654.

[0120] Voltando agora à Figura 5B, depois de todas as células a mesa foi iterado do modo descrito acima, no passo 580 o peso para os dois nomes sendo comparada podem

ser o peso	de	células da	última célula	da	tabela	(por
exemplo, última	linha,	última coluna). Uma	vez	que o peso é
determinado	no	passo	580,	então, este	peso	pode,	numa

concretização, ser normalizada, tal como representado no passo 450 da Figura 4, através do cálculo de uma razão entre o peso para os dois nomes para o valor médio de informação dos dois nomes e multiplicando essa relação por um valor de índice máximo para se obter um valor de índice normalizado.

Petição 870190083248, de 26/08/2019, pág. 66/98

58/74

Este valor de índice normalizado pode então ser utilizado para determinar um peso final por, numa concretização, a indexação de uma tabela de pesos armazenados numa base de dados do centro de identidade 32, utilizando o valor do índice.

[0121] Antes de entrar exemplos da aplicação de concretizações dos métodos acima descritos, pode ser útil para discutir como várias penalidades de competição e distribuição são determinados. Numa concretização, para calcular estas penas uma concretização de um algoritmo de comparação, como descrito acima em relação à FIGURA 4 é aplicado a um conjunto de pares aleatórios de nomes obtidos a partir de um conjunto de amostras de registros de dados. Tipicamente pode ser utilizado cerca de 10 milhões de pares de nomes. Ao aplicar a comparar o algoritmo seguinte pode ser rastreado:

•RanComp	O número total de	tokens de	nomes que	são
comparados.
•RanExact =	O número total	de tokens	de nomes	que
concordam exatamente
•Ranmitial	= O número total	de tokens	de nome	que
concordam através de uma correspondência	inicial.	Uma
correspondência	inicial é aquel	a em que	os primeiros
caracteres de	acordo, um token	possui um	comprimento e
comprimento do	outro é maior do que 1.
•RanPhonetic	= O número total	de tokens	de nome	que

concordam foneticamente, não exatamente.

• Ran_Nickname = O número total de tokens de nome que têm um apelido comum, e não correspondem exatamente.

Petição 870190083248, de 26/08/2019, pág. 67/98

59/74 • Ran_NickPhone = O número total de tokens de nome que têm apelidos que correspondem foneticamente e não correspondem exatamente ou através de um apelido sozinho • Ran_Edit = O número total de tokens de nome que correspondem através de uma distância de edição comparar e não correspondem exatamente.

• RanD_ist-0 = (CXNM apenas) O número total de nomes de tokens que corresponder exatamente e onde os sinais anteriores em cada string name também correspondida.

Exemplo 1: em BOBS loja de flores em comparação com BOBS Florista, as correspondências exatas para FLOR seriam contadas, já que o havia uma BOBS correspondência exata nos tokens anteriores. Da mesma forma SHOP também são contados.

Exemplo 2: Em BOBS FLOWER SHOP comparado com BOBS PRETTY FLOWER SHOP. FLOWER não seria contada, uma vez que os sinais anteriores são BOBS e consideravelmente e que é uma correspondência. SHOP seria contada.

• RanDist-i, Ran_Dist-2, Ran_Dist-3 = (CXNM apenas) O número total de tokens de nomes que correspondem exatamente e onde o número máximo de tokens extras entre a correspondência atual um a anterior é 1, 2 ou 3.

No exemplo 2 acima, para a correspondência FLOWER, a correspondência anterior é BOBS. Não há tokens extras na primeira string e 1 na segunda, isso seria um exemplo de Ran_Dist-1.

Se as strings, BOBS PRETTY FLOWERS e BOBS GOOD FLOWERS são comparadas, a distância para a correspondência exata FLOWERS, ainda seria 1, uma vez que existe um token extra em cada string.

Petição 870190083248, de 26/08/2019, pág. 68/98

60/74

Se as strings, BOSB PRETTY NICE FLOWERS e BOBS GOOD FLOWERS são comparadas, a distância para a correspondência exata FLOWERS, seria 2, uma vez que existem 2 tokens extras na primeira string.

Se o número de tokens extras é maior do que ou igual a 3, é contado em Ran_Dist-3.

[0122] As seguintes frequências podem, ser calculadas:

em seguida,

RanPrObExact ⁼ R^^Exac/ ^^^Gomp

Ran P fob initial ⁼ R^ninitial/ R^ncomp RanProbphonetic ⁼ RãHphonetic/ RanComp RanPrObNickname ⁼ R^mNickname/ R^Ucomp RanProbNickPhone= R^flNickPhone/ ^^Ποοηηρ RanProb_Edit = Ran_Edi1/ Ran_Comp RanProb_Dist-o

RanProb_Dist-i RanProb_Dist.₂ RanProb_Dist3 = Ran_Dist-o/ Rsricomp = Ran_Dist-i/ Rs^comp ⁼ RailDist-s/ R^flComp = Ran Dist-3/ R^i^comp [0123] Usando o processo descrito acima em conjunto com a geração de correspondência exata pesos, um conjunto de pares de nomes correspondentes podem ser derivadas, e as seguintes frequências derivada:

• MatchProb_Exact = Match_Exact/ Match_Comp

Petição 870190083248, de 26/08/2019, pág. 69/98

61/74 • MatchProbinitiai = Matchi_ni1ia,/ Match_Com_P • Match Probphonetic = Match _PhOnetic/ Match_Comp • MatchProb_Ni_Ck_name= Match Nickname/ Matchcomp • MatchProbNickPhone⁼ MatctiNickPhone/ Matchc_omp • MatchProb_Edi1 = Match_Edi1/ Match_Com_P • MatchPrcboist-o = Match_Dist-o/ Match_Com_P • MatchProboist-i = Match_Dist-i/ Match_Com_P • MatchProb_Dist-2 = Match_Dist.₂/ Match_Com_P • MatchProb_Dist-3 = Match_Dist-₃/ Match_Com_P [0124] Usando estas frequências os seguintes pesos marginais podem ser calculados:

• MarginalExact = logi₀(MatchProb_Ex_act/ RanProb_Exact) • Marginali_nitiai - logi₀(MatchProbi_niti_ai/ RanProbmit_iai) • Marginalp_honeti_C = log₁₀(MatchProbp_hOn_eti_C/ RanProbp_hOn_etic) • Marginal_Nickname = log₁₀(MatchProb_Ni_Cknam_e/ RanProb_Nickrame) • Marginal_Ni_Ckphone⁼ logio(MatchProbNickPhone/ RanProbNic_kphone) • Marginal_Edit = logi₀(MatchProb_Edit/ RanProb_Edit) • Marginaloist-o = logi₀(MatchProb_Dist-o/ RanProb_Dj_St-o) • Marginal_Dist.i = log₁₀(MatchProb_Di_St-i/ RanProb_Dist-i) • Marginal_Dist-2 = log₁₀(MatchProb_Di_St.2/ RanProb_Dist.₂) • Marginal_Dist 3 = log₁₀(MatchProb_Di_St-3/ RanProb_Di_{St 3}) e as respectivas penalidades calculadas da seguinte forma:

Petição 870190083248, de 26/08/2019, pág. 70/98

62/74 • Initial Penalty = Marginal_Exac1- Marginal|_nitiai • Initial Penalty = Marginal_Ex_ac1- Marginal^ai • Phonetic Penalty = Marginal.* - Marginalph_Onetic • Nickname Penalty = Marginal_Ex_act- Marginal_Nickrame • NickPhone Penalty = Marginal_Exact- Marginal_Nickp_hane • Edit Distance Penalty = Marginal_Exact- Marginal_Edit • DistPenalty-ι = Marginal_Dist._o- Marg Inal _Dist-i • DistPenalty₂ = Marginal_Dist-o- Marginal_Dist.2 • DistPenalty₃ = Marginal_Dist0- Marginal_Dis13 [0125] Referindo-se a tabela de exemplo da figura 7, suponha que se deseja obter um peso entre dois nomes: Bobs Flower Shop e Bobs muito bonito Flower Shoppe e que os seguintes parâmetros devem ser utilizados para a comparação, os pesos correspondência exata para cada um dos tokens é:

BOBS - 200

VERY- 150

PRETTY - 300

FLOWER - 400

SHOPPE - 600

SHOP - 150

Enquanto a pena de distância para a uma distância de 3 100 e é uma penalidade fonética é 100.

[0126] Numa concretização, uma pontuação média de informação pode ser calculada para os dois nomes serem comparadas (passo 430) . Numa concretização, isto é feito usando os pesos correspondentes exatos para cada um dos sinais em cada um dos nomes. De acordo com este método, a pontuação de informações para Bobs Flower Shop é 750 (por

Petição 870190083248, de 26/08/2019, pág. 71/98

63/74 exemplo, 200 + 400 + 150) e a pontuação de informações para o nome Bobs Muito bonito da flor Shoppe é 1,650 (200 + 150 + 300 + 400 + 600), fazendo a média das duas notas de informação 1200.

[0127] Uma vez uma pontuação média de informações para os dois nomes é calculada (passo 430) um peso para os dois nomes pode ser gerado (passo 440). Numa concretização, a tabela 700 é construído (passo 510). Quando cada célula 702 tem a capacidade de manter um indicador de posição (por exemplo, linha, coluna) e um peso de células. Células 702a da mesa podem, em seguida, ser inicializado (passo 520).

[0128] Uma vez que as células 702a da mesa ter sido inicializado, o restante das células 702 da tabela 700 pode ser iterado. Começando com 702b celular (por exemplo, a linha 1, coluna 1), determina-se que ocorre uma correspondência entre os dois tokens correspondentes à 702b célula (passo 540). O peso correspondente para estes dois marcadores pode então ser calculado (passo 542), que neste caso é de 200. Os valores de peso de células para as células adjacentes podem então ser determinado (Passos 610, 620), e a partir disto, pode ser determinado que o peso de células (0) a partir do 702a1 célula diagonal mais 200 (por exemplo, peso de célula temporário para a célula) é maior do que o peso de células de qualquer 702a2 célula adjacente, 702a3 (passo 640). Assim, o último indicador de posição correspondente de célula 702b é definido como a célula 702b atual (1, 1) e o peso celular da célula atual é definida como o peso correspondente calculado (200) (passos 642, 644).

[0129] O último indicador de posição correspondente e de peso de célula para a célula seguinte 702c pode então ser calculado. É determinado que nenhuma correspondência

Petição 870190083248, de 26/08/2019, pág. 72/98

64/74 ocorre entre os dois tokens correspondentes a célula 702c (passo 540). Como nenhum acrônimo correspondente ocorre (passo 532) o peso páreo para essa célula é, então, definido como zero (passo 542). Um peso de células temporária - pode então ser calculado (passo 630) e comparados com os pesos da pilha de células adjacentes 702b, 702a4 (passos 640, 650) e a partir desta pode-se determinar que o peso de células (100) a partir da célula adjacente 702b é maior do que o peso da célula de célula adjacente 702a4 ou o peso de células de células 702a3 diagonal mais o peso correspondente para a célula atual (0) (por exemplo, peso de célula temporária). Assim, o último indicador de posição correspondente de célula atual 702c está definido para o último indicador de posição correspondente de célula 702b adjacente (1, 1) e o peso das células da célula atual 702c está definido para o peso das células da célula adjacente 702b com o maior peso de célula (passo 652).

[0130] Do mesmo modo, as células 702d, 702e, 702f, 702g, 702h, 702i, 702j e 702k pode ser iterado com resultados semelhantes como os descritos acima em relação à célula 702c. Ao atingir a célula 702I, no entanto, pode ser determinado que ocorre uma correspondência entre os dois tokens correspondentes à célula 702I (passo 540). O peso correspondente para os tokens correspondentes a célula 702I (por exemplo, Flor e Flor) pode então ser calculado (passo 542), que neste caso pode ser 400. Pode, então, ser determinado se uma penalidade de distância deve ser aplicada por comparação da posição da última posição correspondente da célula 702h diagonal com a posição da célula corrente 702I (passo 550). Esta comparação pode ser realizada subtraindo os índices de linha a partir de um outro (por

Petição 870190083248, de 26/08/2019, pág. 73/98

65/74 exemplo, 4-1) e a coluna índices uns dos outros (por exemplo, 2-1) e tendo o máximo de estes valores (por exemplo, 3) e comparando esta distância valor a um nível de limite para determinar se uma penalidade de distância deve ser imposta. Neste caso, o valor de limiar para uma pena de distância pode ser uma distância igual a um, como três é maior do que um, pode ser determinado que uma penalidade de distância deve ser aplicada. A penalidade de distância correspondente ao valor da distância (por exemplo, 3) podem então ser subtraído do peso fósforo calculado para a célula corrente (passos 552, 560). Neste caso, a penalidade de distância é de 100, o que pode ser subtraído a partir do peso correspondente 400 para ajustar o peso correspondente para 702I célula 300. Os valores de peso de células para as células adjacentes podem então ser determinada, e a partir desta pode ser determinada que o peso de células (200) a partir da 702h célula diagonal mais o peso correspondente para a célula atual 702I (por exemplo, 300) é maior do que o peso de células de qualquer 702k célula adjacente, 702i (por exemplo, 200 e 200, respectivamente) (passo 640). Assim, o último indicador de posição correspondente de célula 702I está definido para a célula atual 702I (4,2) e do peso celular da célula atual 702I é definido como o peso correspondente calculado mais o peso da célula a partir da 702h célula diagonal (por exemplo, 300 + 200 = 500) (passos 642, 644).

[0131] O último indicador de posição correspondente e pesos de células para células de 702m, 702n e 702o pode ser calculado da mesma forma para os cálculos descritos acima. Ao atingir a célula 702p, no entanto, pode ser determinado que ocorre uma correspondência entre os dois

Petição 870190083248, de 26/08/2019, pág. 74/98

66/74 tokens correspondentes a célula 702p (passo 540). O peso correspondente para os tokens correspondentes a célula 702p (por exemplo, Shoppe e Shop) pode então ser calculados (passo 542), que neste caso pode ser de 50 (como o encontro entre Shoppe e Shop pode ser uma correspondência fonética seu peso pode ser o mínimo dos pesos de correspondência exata para Shoppe and Shop menos o peso pena fonética). Pode então ser determinado se uma penalidade de distância deve ser aplicada através da comparação da posição da última correspondência de posição da célula diagonal 7021 com a posição da célula 702p atual (etapa 550). Esta comparação pode ser realizada subtraindo os índices de linha a partir de um outro (por exemplo, 5-4) e a coluna índices de uma outra (3-2) e tendo o máximo de estes valores (por exemplo, 1) e comparando este valor de distância um nível de limiar para determinar se uma penalidade de distância deve ser imposta. Neste caso, o valor limite para uma penalidade de distância pode ser uma distância de um e, como tal pena distância não deve ser imposta. Assim, o peso correspondente 702p célula atual é 50. Os valores de peso de células para as células adjacentes 702o, 702m pode então ser determinado (Passos 610, 620), e a partir disto, pode ser determinado que o peso de célula da célula diagonal 702I (500) mais o peso correspondente para a 702p célula corrente (50) é maior do que o peso de qualquer célula 702k célula adjacente, 702i (por exemplo, 500 e 500, respectivamente) (passo 640). Assim, o último indicador de posição correspondente de célula 702p está definido para a célula 702p atual (5,3) e o peso de células da célula atual 702p está definido para o peso correspondente calculado mais o peso de célula da célula

Petição 870190083248, de 26/08/2019, pág. 75/98

67/7 4 diagonal 702I (por exemplo, 500 + 50 = 550) (passos 642, 644).

[0132] Lendo a última célula 702p da tabela 700, pode ser determinado que o peso para os dois nomes sendo comparados é 550. Este peso pode então ser normalizado de acordo com um índice de semelhança máxima e uma razão entre o peso de uma pontuação média para as duas informações nomes (passo 450). Por exemplo, se o índice de semelhança máxima é 10, o peso pode ser normalizado para um valor de índice normalizado de 4 arredondando os resultados da equação 10 * 550/1200. Este valor de índice normalizada pode ser usado como índice para uma tabela de peso normalizada, para gerar o peso final para os dois tokens (passo 450). Por exemplo, o peso normalizado, de 4 pode indexar para um peso final de 441 para os dois nomes.

[0133] A figura 8 representa um exemplo onde um acrônimo está presente. Assume-se que isso é desejado para se obter um peso entre dois nomes: prumos VP florista e prumos flor muito consideravelmente loja e que os parâmetros seguintes são para ser utilizado para a comparação, os pesos correspondência exata para cada um dos tokens seja:

BOBS - 200

IVERY- 150

PRETTY - 300 FLOWER - 400 SHOP - 150

Enquanto a pena de distância para uma distância de 3 é 100.

Petição 870190083248, de 26/08/2019, pág. 76/98

68/74 [0134] Em uma modalidade, uma pontuação média informações podem ser calculados para os dois nomes estão sendo comparados (passo 430). Numa concretização, isto é feito usando os pesos correspondentes exatos para cada um dos sinais em cada um dos nomes. De acordo com este método, a pontuação de informações para Bobs VP Flower Shop é de 1050 (por exemplo, 200 + 300.400 + 150) e a pontuação de informações para o nome Bobs Very Pretty Flower Shop é de 1200 (200 + 150 + 300 + 400 + 150), fazendo a média dos dois resultados de informação 1125.

[0135] Uma vez que uma pontuação média para as duas informações nomes é calculado (passo 430) um peso para os dois nomes pode ser gerado (passo 440). Numa concretização, a tabela 800 é construída (passo 510). Quando cada célula 802 tem a capacidade de manter um indicador de posição (por exemplo, linha, coluna) e um peso de células. Células 802a da mesa podem, em seguida, ser inicializado (passo 520).

[0136] Uma vez que as células 802a da mesa ter sido inicializado, o restante das células 802 da tabela 800 pode ser iterado. Começando com 802b celular (por exemplo, a linha 1, coluna 1), determina-se que ocorre uma correspondência entre os dois tokens correspondentes à 802b célula (passo 540). O peso correspondente para estes dois marcadores pode então ser calculado (passo 542), que neste caso é de 200. Os valores de peso de células para as células adjacentes podem então ser determinado (Passos 610, 620), e a partir disto, pode ser determinado que o peso de células (0) a partir do 802a1 célula diagonal mais 200 (por exemplo, peso de célula temporário para a célula) é maior do que o peso de células de qualquer 802a2 célula adjacente, 802a3 (passo 640) . Assim, o último indicador de posição correspondente de célula 802b

Petição 870190083248, de 26/08/2019, pág. 77/98

69/74 é definido como a célula 802b atual (1, 1) e o peso das células da célula atual 802b é ajustado para o peso correspondente calculado (200) (passos 642, 644).

[0137] As células 802c-802F podem similarmente ser iteradas, como discutido acima. Ao atingir 802g de células pode ser determinado que não existe correspondência entre os dois tokens correspondentes a 802g célula (passo 540), no entanto, pode ser determinado que a VP é acrônimo (passo 532). Esta determinação pode ser realizada através da comparação do primeiro caractere de um primeiro token VP que corresponde a 802g de células (por exemplo, V) para o primeiro caractere do outro token que corresponde a 802g de células (por exemplo, muito). Como o caractere - -V corresponde ao primeiro caractere do token Muito, o próximo caractere do token VP (por exemplo, P) é comparado com o seguinte token no outro nome (por exemplo, Pretty) como esses caracteres correspondentes, e não há mais caracteres do primeiro sinal (por exemplo, VP), pode-se determinar que o sinal de VP é um acrônimo e valores pode ser calculada para o conjunto de células 802g, 802k correspondente à sigla token (por exemplo, cada célula o que corresponde a um caractere de a sigla token e um sinal de outro nome) de forma semelhante ao cálculo discutido acima (no exemplo descrito em relação à Figura 8A, tanto as correspondências entre os caracteres da sigla (por exemplo, V e P) e seus respectivos tokens correspondentes (por exemplo, Muito e Pretty) gerar uma correspondência inicial com um peso de 50). Após valores são computador para as células 802g e 802k a tabela pode assemelhar-se ilustrada na figura 8A.

[0138] O resto das células 802 da tabela 800 pode, então, ser iterado início com células 802D para calcular

Petição 870190083248, de 26/08/2019, pág. 78/98

70/74 correspondências última posição e pesos celulares para estas células, como descrito acima. Células 802g e 802k podem ser ignorados durante este processo iterative como essas células já foram combinados via uma sigla (passo 530) . Após a iteração através do restante das células 802 do quadro 800, a tabela 800 pode assemelhar-se a tabela ilustrada na Figura

8b.	;0139] A leitura da última célula 802U de mesa 800

pode ser determinado que o peso para os dois nomes sendo comparado é 850. Este peso pode ser, em seguida, normalizado de acordo com um índice máximo de similaridade e uma razão entre o peso de uma pontuação média para as duas informações nomes (passo 450) . Por exemplo, se o índice de semelhança máxima é 10, o peso pode ser normalizado para um valor de índice normalizado de 8 arredondando os resultados da equação 10 * 850/1 125. Este valor de índice normalizada pode ser usado como índice para um peso normalizado mesa para gerar o peso final para os dois tokens (passo 450). Por exemplo, o peso normalizado de 8 pode ser indexado para um peso final de 520 para os dois nomes.

de um

;0140] Pseudocódigo que descreve uma concretização método para a comparação de nomes é o seguinte: Compare(tList1, tl_ist2) // tListl and tlist2 are lists of tokens L1 = len(tListl) L2 = len(tList2) compareTable = a 2 dim-array indexed 0...L1 and 0...L2 containing real numbers. Set all entries in row 0 to 0.0 and None

Petição 870190083248, de 26/08/2019, pág. 79/98

Ί1/Ί4

Set all entries in column 0 to 0.0 and None

For r in range(1 ...L1)

For c in range(1 ..L2) tokeninfo, compareResult = compare(tList1[r], tl_ist2[c]) if the compareResult was a match (exact or partial):

get l_MATCH and J_MATCH from compareTable[r-1][c-1] maxDiff = max(r - I MATCH, c - J MATCH) if maxDiff > 1:

//need to apply the distance penalty.

penalty = posPenalty[maxDiff] else penalty = 0.0 diagonalcontent = compareTable[r-1 ][c-1 ] .infoScore+token Info penalty compareTable[r][c]. infoScore = max(compareTable[r1 ][c]. infoScore, compareTable[r][c-1 ]. infoScore, compareTable[r][c]. infoScore) + token Info) if new infoScore is result of new match: compareTable[r][c].l_MATCH = r compareTable[r][c].J_MATCH = c elsif new info score comes from [r, c-1 ] or [r-1, c] compare l_MATCH, J_MATCH from that cell else if acronymCheck(tList1[r], tList2, c) or acronymCheck(tl_ist2[c], tListl, c)

L = length of acronym for i in range(0, L-1) compareTable[r+i, c+i].l_Match = r+L compareTable[r+i,c+i].J_Match = c+L compareT able[r+i,c+i].infoScore = max(compareTable[r-1][c].infoScore,

Petição 870190083248, de 26/08/2019, pág. 80/98

72/74 compareTable[r][c-1]. infoScore, compareTable[r][c], infoScore) + acronymScore else: //compare results was not a match compareTable[r][c]. infoScore = max( compareTable[r-1][c-1] ].infoScore, compareTable[r][c-1] ].infoScore, compareTable[r][c] ].infoScore) update compareTable[r][c].l_MATCH and J_MATCH using contents of appropriate cell: either [r-1, c-1], [r, c-1] or [r-1, c].

maxinfo = max(tokenListlnfo(tList1), tokenListlnfo(tLis12)) normalizedlnfo = 10 * round(compareTable[L1][L2]/maxlnto) return normalizedlnfo [0141] 0 valor de índice normalizada que pode ser retornado por uma concretização do pseudocódigo acima pode ser utilizado para indexar uma tabela de valores para se obter um peso final, tal como descrito acima. Essa tabela pode assemelhar-se o seguinte, onde o valor do índice máximo pode ser 16:

Petição 870190083248, de 26/08/2019, pág. 81/98

73/74

NORM_ADJWGT_0|-185| N0RM_ADJWGT_11-1011 NORM_ADJWGT_2|-53| NORM_ADJWGT_3|-12| NORM_ADJWGT_4|37| NORM_ADJWGT_5|69| NORM_ADJWGT_6|142| NORM_ADJWGT_7|207| NORM_ADJWGT_8|2611 NORM_ADJWGT_9|280| NORM_ADJ WGT_10|277| NORM_ADJWGT_111309| NORM_ADJWGT_12|360| NORM_ADJWGT_13|452| NORM_ADJWGT_1414771 NORM_ADJWGT_1515641 NORM_ADJWGT_1615981 [0142] Na descrição anterior, a divulgação tem sido descrita com referência a concretizações específicas. No entanto, deve ser entendido que a descrição é por meio de apenas exemplo e não deve ser interpretada num sentido limitativo. Deve ser ainda compreendido, portanto, que numerosas alterações nos detalhes das concretizações do presente relatório descritivo e concretizações adicionais do

Petição 870190083248, de 26/08/2019, pág. 82/98

4/7 4 presente relatório descritivo serão evidentes para, e podem ser feitos por pessoas com conhecimentos normais na técnica tendo em referência esta descrição. É contemplado que todas essas alterações e concretizações adicionais estão dentro do escopo da divulgação, conforme detalhado nas seguintes reivindicações.

Claims (6)

1. REIVINDICAÇÕES

   1. Método para processamento de registros de dados (200, 202) em múltiplos idiomas dentro de um cent ro de identidade (32) único para identificar registros de dados (200, 202) em diferentes idiomas com uma entidade comum

   caracterizado pelo fato de que compreende:

   para cada registro de dados (200, 202) recebido no referido centro de identidade (32) único, associar o referido registro de dados (200, 202) com um idioma;

   aplicar código de derivação específico único para o referido idioma, sobre os atributos do referido registro de dados (200, 202), em que o dito código de derivação única compreende padronização específica do idioma e bucketing específico do idioma e, em que a referida padronização específica do idioma padroniza os referidos atributos do referido registro de dados (200, 202), com relação ao referido idioma e, em que dito bucketing produz um conjunto de registros de dados (200, 202) candidatos para comparar com o dito registro de dados (200, 202) passar informações sobre o idioma e os referidos atributos padronizados do referido registro de dados (200, 202), juntamente com o referido registro de dados (200, 202) para uma camada de entidade (306) do referido centro de identidade (32) único; e selecionar e aplicar um ou vários algoritmos para processar entidades em diversos idiomas na referida camada de entidade (306) do referido centro de identidade (32) único, que utiliza as referidas informações sobre o idioma e os referidos atributos padronizados do referido registro de dados (200, 202), onde ao menos dois registros de diferentes idiomas são associados a uma entidade comum;

   Petição 870190083248, de 26/08/2019, pág. 84/98
2. 2/6 comparar um ou mais atributos padronizados do referido registo de dados com um ou mais atributos padronizados dos referidos registos de dados candidatos; e vincular o referido registo de dados a um ou mais registos de dados candidatos com base na dita comparação para associar dito registro de dados (200, 202) com uma ou mais entidades associadas aos ditos registros de dados (200, 202) candidatos vinculados.

   2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que compreende ainda o mapeamento do referido idioma para um tipo de membro em particular no referido centro de identidade (32) único. 3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que cada um dos referidos vários idiomas são mapeados um a um para um tipo de membro em

   particular no referido centro de identidade (32) único.

   4. Método, de acordo com a reivindicação 3, caracterizado pelo fato de que o referido código de derivação único é seletivamente aplicado com base no referido tipo de membro particular.

   5. Método, de acordo com a reivindicação 3, caracterizado pelo fato de que os registros de dados (200, 202) em vários idiomas compartilham tipos de atributos dentro de uma definição de idioma no referido centro de identidade (32) único.

   6. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que os referidos atributos do referido registro de dados (200, 202) estão em dois ou mais idiomas e em que o referido idioma é selecionado a partir dos referidos dois ou mais idiomas.

   Petição 870190083248, de 26/08/2019, pág. 85/98
3. 3/6

   7. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que os referidos registros de dados (200, 202) são de uma pluralidade de fontes de informação (34, 36, 38) acessíveis pelo referido centro de identidade (32) único, em que a referida pluralidade de fontes de informação (34, 36, 38) está em um ou mais idiomas.

   8. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a associação do referido registro de dados (200, 202) com o referido idioma inclui ainda:

   avaliar o referido registro de dados (200, 202) para

   obter um código de determinar o país; e referido idioma utilizando o código do referido país. 9. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o idioma é um idioma padrão. 10. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que ainda compreende:

   gerar um primeiro peso para um primeiro atributo de um primeiro registro de dados (200, 202) em um primeiro idioma;

   gerar um segundo peso para um primeiro atributo de um segundo registro de dados (200, 202) em um segundo idioma; e comparar o referido primeiro atributo do dito primeiro registro de dados (200, 202) no referido primeiro idioma e o referido segundo atributo do referido segundo registro de dados (200, 202) no segundo idioma utilizando os referidos primeiro e segundo pesos.

   Petição 870190083248, de 26/08/2019, pág. 86/98
4. 4/6

   11. Mídia de armazenamento legível por computador, caracterizada pelo fato de que compreende o método, como definido pela reivindicação 1, que realiza as etapas de:

   para cada registro de dados (200, 202) recebido no referido centro de identidade (32) único, associar o referido registro de dados (200, 202) com um idioma;

   aplicar código de derivação único específico para o referido idioma, sobre os atributos do referido registro de dados (200, 202), em que o dito código de derivação único compreende padronização específica do idioma e bucketing específico do idioma e, em que a referida padronização específica do idioma padroniza os referidos atributos do referido registro de dados (200, 202), com relação ao referido idioma e, em que dito bucketing produz um conjunto de registros de dados (200, 202) candidatos para comparar com o dito registro de dados (200, 202).

   selecionar e aplicar um ou vários algoritmos para processar entidades em diversos idiomas na referida camada de entidade (306) do referido centro de identidade (32) único, que utiliza as referidas informações sobre o idioma e os referidos atributos padronizados do referido registro de dados (200, 202), onde ao menos dois registros de diferentes idiomas são associados a uma entidade comum;

   comparar um ou mais atributos padronizados do referido registo de dados com um ou mais atributos padronizados dos referidos registos de dados candidatos; e vincular o referido registo de dados a um ou mais registos de dados candidatos com base na dita comparação para associar dito registro de dados (200, 202) com uma ou mais entidades associadas aos ditos registros de dados (200, 202) candidatos vinculados.

   Petição 870190083248, de 26/08/2019, pág. 87/98
5. 5/6

   12. Mídia de armazenamento legível por computador, de acordo com a reivindicação 11, caracterizada pelo fato de que faz, adicionalmente, com que o referido computador mapeie o referido idioma para um tipo de membro determinado.

   13. Mídia de armazenamento legível por computador, de acordo com a reivindicação 11, caracterizada pelo fato de que faz o referido computador:

   avaliar o referido registro de dados (200, 202) para obter um código de país, e determinar o referido idioma utilizando o referido código do país.

   14. Mídia de armazenamento legível por computador, de acordo com a reivindicação 11, caracterizada pelo fato de que faz o referido computador:

   gerar um primeiro peso de um primeiro atributo de um primeiro registro de dados (200, 202) em um primeiro idioma;

   gerar um segundo peso para um primeiro atributo de um segundo registro de dados (200, 202) em um segundo idioma; e comparar o referido primeiro atributo do dito primeiro registro de dados (200, 202) no referido primeiro idioma e o referido segundo atributo do referido segundo registro de dados (200, 202) no segundo idioma utilizando os referidos primeiro e segundo pesos.

   15. Sistema de processamento de registros de dados (200, 202) em vários idiomas para identificar registros de dados (200, 202) em diferentes idiomas com uma entidade comum, caracterizado pelo fato de que inclui:

   pelo menos um processador; e

   Petição 870190083248, de 26/08/2019, pág. 88/98
6. 6/6 pelo menos uma mídia de armazenamento legível por computador acessível por pelo menos um processador fazendo o sistema:

   para cada registro de dados (200, 202) recebido no referido centro de identidade (32) único, associar o referido registro de dados (200, 202) com um idioma;

   aplicar código de derivação único específico para a referido idioma, sobre os atributos do referido registro de dados (200, 202), em que o dito código de derivação único compreende padronização específica do idioma e bucketing específico do idioma e, em que a referida padronização específica do idioma padroniza os referidos atributos do referido registro de dados (200, 202), com relação ao referido idioma e, em que dito bucketing produz um conjunto de registros de dados (200, 202) candidatos para comparar com o dito registro de dados (200, 202);

   selecionar e aplicar um ou vários algoritmos para processar entidades em diversos idiomas na referida camada de entidade (306) do referido centro de identidade (32) único, que utiliza as referidas informações sobre o idioma e os referidos atributos padronizados do referido registro de dados (200, 202), onde ao menos dois registros de diferentes idiomas são associados a uma entidade comum;

   comparar um ou mais atributos padronizados do referido registo de dados com um ou mais atributos padronizados dos referidos registos de dados candidatos; e vincular o referido registo de dados a um ou mais registos de dados candidatos com base na dita comparação para associar dito registro de dados (200, 202) com uma ou mais entidades associadas aos ditos registros de dados (200, 202) candidatos vinculados.