PT1080415T - Sistema e método para autenticação de utilizadores da rede - Google Patents

Description

Descrição

Sistema e método para autenticação de utilizadores da rede A invenção refere-se a comunicações eletrónicas, e mais particularmente à autenticação da identidade de utilizadores de rede.

Uma grande variedade de redes é hoje usada. As redes de computadores incluem redes de área local (LANs), redes de área metropolitana (MANs), redes de área ampla (WANs), intranets, internet e outros tipos de redes. As redes de comunicação incluem aquelas para o serviço telefónico convencional, redes celulares de variedades diferentes, serviços de paginação e outros. As redes são usadas para muitos propósitos, inclusive para comunicar, a cessar dados e executar transações. Por muitas razões, incluindo a segurança, muitas vezes é necessário confirmar ou autenticar a identidade de um usuário antes de permitir o acesso a dados ou uma transação ocorrer na rede.

Uma abordagem conhecida para a autenticação da rede de computadores é a utilização de palavras-passe especificas do utilizador. As senhas oferecem algum nivel de proteção, mas não são seguras contra falhas. Uma das senhas da razão é vulnerável porque os usuários muitas vezes compartilham-nas. Mesmo se elas são mantidas em privado, alguém que quer obter uma senha muitas vezes pode, usando geradores aleatórios, monitores de teclado ou outras técnicas. Além disso, ao lidar com usuários desconhecidos, como pessoas que querem realizar uma transação eletrónica pela Internet, senhas ad hoc não são práticos. Vários esquemas de não-senha existem que executam algum nível de autenticação antes de autorizar transações ou permitir acesso a dados. Esses sistemas geralmente exigem que o usuário forneça uma amostra de informações básicas de identificação, como nome, data de nascimento, número de segurança social, endereço, número de telefone e informações de licença de motorista. Esse tipo de informação, às vezes conhecida como informações de tipo carteira, é comparada a dados conhecidos, como um arquivo de crédito, para determinar o quão bem a entrada do usuário corresponde a essa fonte.

Por várias razões, os esquemas de autenticação de um nível não são totalmente fiáveis. Em alguns casos, um usuário que fornece informações de identificação precisas pode não ser autenticado. Isso pode ocorrer, por exemplo, porque o usuário insere um pseudónimo ou uma contração ao invés de um nome próprio e o processo de autenticação não verifica se há um pseudónimo ou outra variação. Como resultado, um usuário que deve ter direito a cessar informações ou executar uma transação não pode. Outras inconsistências podem desencadear um falso negativo, e muitas vezes o falso negativo terminará a transação sem mais processamento ou consulta corretiva.

Em outras instâncias, um utilizador que fornece informações fraudulentas pode ser autenticado. Isso pode ocorrer quando perdido ou roubadas informações tipo carteira é inserido por um usuário não autorizado. Outras situações também podem levar a um resultado positivo falso.

Tanto falsos positivos como falsos negativos são indesejáveis.

Existem outras razões para a rejeição sumária não justificadas, e outras desvantagens. 0 documento US 5 712 914 revela um método e um aparelho de comunicação de informação compreendendo o fornecimento de um dado que inclui um certificado digital contendo dados. 0 documento US 5 436 972 revela uma autenticação de múltiplos de fatores fazendo perguntas conhecidas do utilizador.

Um objetivo de uma forma de realização da invenção é superar estes e outros inconvenientes dos sistemas e métodos de autenticação existentes.

Outro objetivo de uma forma de realização da invenção consiste em proporcionar um sistema e um método de autenticação que executem um primeiro nivel de autenticação com base num primeiro tipo de informação e, com base nos resultados do primeiro nivel de autenticação, determinem se realizam pelo menos um segundo nivel de autenticação usando outro tipo de informação.

Outro objetivo de uma forma de realização da invenção é proporcionar um sistema e método de autenticação que determinam a realização de pelo menos um segundo nível de autenticação dependendo da informação disponível e do nível de certeza desejado.

Outro objetivo de uma forma de realização da invenção é proporcionar um sistema e método de autenticação incluindo uma característica de consulta interativa automática.

Outro objetivo de uma forma de realização da invenção é proporcionar um sistema e método de autenticação que pré processam informações fornecidas pelo utilizador para verificar, por exemplo, a normalização, o formato, a validade e a consistência dessas informações antes de compará-las com dados conhecidos.

Outro objetivo de uma forma de realização da invenção é proporcionar um sistema e método de autenticação que sejam personalizáveis.

Outro objetivo de uma forma de realização da invenção é proporcionar um sistema e método de autenticação que acedam a informação a partir de uma variedade de fontes de dados.

Outro objetivo de uma forma de realização da invenção é proporcionar um sistema e método de autenticação que permitam a seleção das fontes de dados utilizadas para comparação e as circunstâncias sob as quais essas comparações são feitas.

Outro objetivo de uma forma de realização da invenção é proporcionar um sistema e método de autenticação que gere uma pontuação que indique o nivel de confiança ou de certeza da autenticação.

Outro objetivo de uma forma de realização da invenção é proporcionar um sistema e método de autenticação no qual uma pontuação ou exigência minima pode ser definida para campos ou fontes de dados particulares. A invenção é definida nas reivindicações.

Numa concretização ilustrativa da invenção, um utilizador que pretenda candidatar-se a uma transação em linha acede a uma rede cliente/servidor através de um terminal cliente. 0 lado do servidor da rede inclui um servidor de aplicativos que se comunica com um servidor de autenticação. Quando o utilizador deseja iniciar a transação noutras horas, o servidor de autenticação determina se a identidade do utilizador pode ser confirmada e o nivel de autenticação que pode ser concedido à identidade do utilizador com base em regras especificas para o fornecedor que aceita a transação. A transação que o utilizador está a solicitar, tal como uma transação de corretagem eletrónica, é executada ou não é realizada ou outra ação é tomada dependendo dos resultados da autenticação. A extensão do processamento de autenticação executada depende da natureza da transação e dos requisitos específicos do fornecedor. Uma vez que o processo de autenticação tenha sido satisfeito, a invenção pode gerar um certificado digital registando níveis de autenticação e outras informações relacionadas com o utilizador. 0 certificado digital pode então ser apresentado em transações futuras para evitar a necessidade de rá autenticar o usuário para cada novo evento de transação.

Por exemplo, no contexto do comércio eletrónico, transações de menor risco, tais como compras relativamente pequenas pode não exigir um processo extenso de autenticação. Por outro lado, as transações de risco mais sensíveis ou maiores, como grandes compras ou acesso a dados confidenciais, podem exigir um processo de autenticação mais completo e um nível de certeza maior. Um maior nível de segurança poderia ser concebido através da realização automática de um processo de autenticação completa para cada transação. No entanto, esta abordagem incorre em custos ou recursos desnecessários nos casos em que apenas um menor nível de certeza é necessária. A invenção evita este inconveniente permitindo que diferentes níveis de autenticação sejam realizados com base no nível de segurança desejado, reduzindo custos e utilização desnecessária de recursos do sistema.

De um modo geral na invenção, o utilizador é autenticado de acordo com a sua capacidade de responder a consultas sucessivas de informação pessoal e ao nível de correspondência conseguido a partir da comparação das informações que proporcionam com fontes de dados fidedignas. 0 utilizador é inicialmente solicitado a fornecer um primeiro tipo de informação de identificação. 0 primeiro tipo de informação é, preferencialmente, informações de tipo carteira, isto é, informação tal como nome, endereço, carteira de motorista ou outra informação que possa ser comummente transportada na pessoa. Estas informações são transmitidas ao servidor de autenticação de um processo de autenticação de primeiro nível nessas informações.

Esse processo de autenticação de primeiro nível compara o grau de correspondência entre o primeiro tipo de informação fornecido pelo utilizador e os dados conhecidos sobre o utilizador a partir de outras fontes. Ao concluir este processo de autenticação de primeiro nível, o servidor de autenticação pode permitir o acesso solicitado, permitir o acesso solicitado com restrição, recusar o acesso ou prosseguir para outro nível de autenticação.

Preferencialmente, o segundo e quaisquer níveis adicionais de autenticação solicitam um segundo tipo de informação não-carteira do utilizador. 0 segundo tipo de informação é de preferência baseado em informações comparativamente privadas que apenas o utilizador saberia. Por exemplo, o segundo tipo de informação pode incluir empréstimo hipotecário ou outras informações obtidas de um relatório de crédito ou outra fonte. Essas informações normalmente não são realizadas com uma pessoa e, portanto, as chances de fraude por alguém que obtém informações perdidas ou roubadas e tentativas de executar uma transação são reduzidas.

Os dados financeiros privados ou outros dados obtidos no processo de autenticação de segundo nivel podem ser solicitados utilizando uma consulta interativa. A consulta interativa pode incluir perguntas de múltipla escolha que são geradas automaticamente com base nas informações disponíveis nas fontes de dados conhecidos. Por exemplo, o servidor de autenticação pode ter acesso a um arquivo de crédito para identificar os empréstimos do usuário que ainda estão em estado de retorno. Um ou mais empréstimos podem ser selecionados e o nome do credor e o montante de pagamento mensal correspondente recuperados do arquivo de crédito. A consulta interativa pode pedir ao utilizador o nome do credor ou o montante do pagamento no empréstimo identificado e oferecer um número de escolhas para cada um do nome do credor e o montante de pagamento correto, apenas um dos quais está correto.

Dependendo das respostas, a identidade do utilizador pode ser autenticada completamente, ou num grau maior ou menor de certeza comparado com aquele baseado unicamente no processo de autenticação de primeiro nível. A invenção pode incluir uma fase de pré-processamento executada antes da autenticação de primeiro ou segundo nível. 0 estágio de pré-processamento filtra ou corrige erros relativamente menores na formatação e consistência nas respostas do usuário, preservando a transação para posterior processamento e evitando o encerramento desnecessário antes que os estágios superiores sejam atingidos.

De acordo com a invenção, é proporcionado um método e sistema como definido nas reivindicações. A invenção será agora descrita a título de exemplo não limitativo com referência aos desenhos anexos, nos quais: FIG. 1 é um fluxograma de um processo global para autenticar utilizadores de acordo com a invenção. FIG. 2 é um fluxograma de um fluxo de processamento global para autenticar utilizadores de acordo com a invenção num outro aspeto. FIG. 3 é um fluxograma de certos aspetos da autenticação de segundo nível de acordo com a invenção. FIG. 4 é um fluxograma de um processo de pré-processamento de acordo com a invenção. FIG. 5 é um fluxograma que representa um processo de verificação de formato de acordo com a invenção. FIG. 6 é um fluxograma que representa um processo de normalização de acordo com a invenção. FIG. 7 é um fluxograma que representa um processo de verificação de validade de acordo com a invenção. FIG. 8 é um fluxograma que representa um processo de verificação de consistência de acordo com a invenção. FIG. 9 ilustra um exemplo de uma matriz de verificação utilizada na invenção. FIG. 10 ilustra um exemplo de códigos de erro que podem ser gerados de acordo com a invenção. FIG. 11 ilustra um exemplo de uma matriz de pré- processamento utilizada na invenção. FIG. 12 ilustra um diagrama de blocos de um sistema global de acordo com a invenção.

As Figs. 13 a 16 ilustram um registo de transação gerado de acordo com a invenção.

As Figs. 17 e 18 ilustram os critérios de reconhecimento de padrões utilizados pela invenção para detetar irregularidades. FIG. 19 ilustra ação potencial tomada pela invenção após a deteção de critérios de reconhecimento de padrões. FIG. 20 ilustra uma matriz de pontuação para diferentes tipos de contas na autenticação de segundo nivel de acordo com a invenção. FIG. 21 ilustra uma ponderação relativa de diferentes tipos de consultas utilizadas na autenticação de segundo nível de acordo com a invenção. FIG. 22 ilustra um cansaço das pontuações de certeza num conjunto de categorias de acordo com a invenção.

As Figs. 23-28 ilustram uma atribuição de pontuações de certeza global de resultados de autenticação de primeiro e segundo níveis gerados de acordo com a invenção, do mais elevado ao mais baixo. FIG. 29 ilustra um anel de ligação de resultados de autenticação para diferentes tipos de contas de origem de acordo com a invenção. FIG. 30 ilustra limiares de ação para um conjunto de ações diferentes de acordo com a invenção.

As Figs.31-33 ilustram as consultas de pré-processamento e de autenticação de primeiro nível numa sessão de autenticação de exemplo de acordo com a invenção.

As Figs. 34-36 ilustram consultas de autenticação de segundo nível em uma sessão de autenticação de exemplo de acordo com a invenção.

As Figs. 37-40 ilustram as consultas utilizadas para emitir um certificado digital de acordo com a invenção. FIG. 41 ilustra um certificado digital gerado de acordo com a invenção. FIG. 42 ilustra um sistema de autenticação remoto de acordo com a invenção em que a autenticação é realizada de uma forma offline. A Fig.43 ilustra a forma de realização de autenticação remota offline da invenção que funciona quando é fornecido um campo de dados de número de segurança social. FIG. 44 ilustra a forma de realização de autenticação remota offline da invenção que funciona quando não é fornecido um campo de segurança social. FIG. A figura 45 ilustra um diagrama de blocos de um sistema global de acordo com a invenção, num outro aspeto. 0 invento opera, em geral, num ambiente de rede e proporciona um sistema e um método para autenticar a identidade de um utilizador de rede utilizando uma hierarquia de consultas de informação. A invenção pode basear-se em informação de uma ou mais fontes de dados para executar a hierarquia de fases de autenticação, dependendo da sensibilidade da transação ou dos dados. A invenção pode ajustar dinamicamente a extensão de autenticação necessária, com base em limiares predefinidos ou em testes de validade de entrada à medida que o utilizador fornece essas informações.

Uma fase de pré-processamento da frente pode servir para filtrar ou corrigir informações erróneas tais como códigos postais equivocados, dígitos em falta ou outras questões de forma para que a transação possa ser preservada sem terminação desnecessária antes da autenticação de primeiro ou segundo nível. Na conclusão do processo de autenticação, a invenção pode emitir um certificado digital para a máquina do utilizador para registar informações de autenticação, para apresentar para transações posteriores ou para atualização. Uma ilustração da arquitetura global do invento está na Fig. 45 e fluxogramas do fluxo de processamento global são mostrados nas Figs. 1 e 2.

Em termos do ambiente de rede da invenção, numa concretização ilustrada na Fig. 12, o cliente 110 comunica com o servidor de aplicação 130 através de uma ligação de transmissão fisica ou sem fios 150. A ligação de transmissão 150 pode ser uma ligação direta à Internet ou incluir a Internet como um segmento intermédio. A ligação de transmissão 150 pode incluir uma ligação de acesso telefónico à Internet, acesso ao servidor de acesso telefónico, uma ligação de intranet, uma linha digital TI ou T3, uma linha digital ISDN, ligação LAN, uma rede de área alargada, Ethernet, ligação DSL ou outro cabo ou conexão sem fio.

Num contexto de Internet, o servidor de aplicações 130 preferencialmente contém software de servidor de Internet (tal como o pacote Apache publicamente disponível ou outros) que comunica com um aplicativo de navegador residente no cliente 110, que pode ser um computador pessoal ou estação de trabalho que executa o Microsoft Windows ™ 95 ou 98, um dispositivo de acesso à Internet, como uma unidade WebTV™, ou outro hardware ou software. O sistema inclui um servidor de autenticação 120 no qual o processo de autenticação 10 da invenção é residente e executa. O processo de autenticação 10 pode, por exemplo, ser implementado em instruções de máquina programadas, tais como C, C ++, Java ou outras linguagens de programação compiladas, interpretadas ou outras. Numa concretização alternativa, o processo de autenticação 10 pode ser co residente no servidor de aplicação 130. Obviando a necessidade do servidor de autenticação 120. O servidor de autenticação 120 e o servidor de aplicação 130 podem ser cada um estação de trabalho ou computador pessoal, por exemplo executando o Unix, Linux ou Sistemas operacionais Microsoft Windows ™ NT ™ ou outro hardware e software e cada um pode comunicar-se com vários bancos de dados para obter informações de identificação do usuário para autenticação de primeiro e segundo nivel.

Conforme ilustrado na Fig. 12, tais bases de dados podem incluir uma base de dados de crédito 160, uma base de dados de correio 170, uma base de dados de telefone 180 e uma ou mais bases de dados 190 que podem ser direta ou indiretamente acessíveis por ou residentes no servidor de autenticação 120 ou servidor de aplicações 130. Além disso, está associado e comunica com o servidor de autenticação 120. O processo de autenticação 10 preferencialmente recebe e armazena dados para e da base de dados de autorização 152, incluindo o registo de transação 112 (ilustrado nas Figuras 13-16) que regista a entrada do utilizador, as consultas e outras informações como uma ou registo permanente. A fig. 12 mostra também um ou mais recursos 140 que são acessíveis ao servidor de aplicação 130. Estes podem incluir, por exemplo, bases de dados, outros computadores, memória eletrónica, CD ROMs, armazenamento RAID, fita ou outro armazenamento de arquivo, rateadores, terminais e outros periféricos e recursos.

De acordo com a invenção, um utilizador que deseja aceder a informação ou processar uma transação através de uma rede é solicitado a submeter informações ao processo de autenticação 10 através do cliente 110. O processo de autenticação 10 invoca o passo de pré-processamento 26, no qual o utilizador é solicitado para fornecer um primeiro tipo de informação de identificação de utilizador. O primeiro tipo de informação de identificação de utilizador preferencialmente compreende informações de tipo carteira tais como nome, endereço, número de telefone, número de segurança social, número de carta de condução e outras informações pessoais comuns.

Estas informações são fornecidas ao processo de autenticação 10 através do servidor de aplicação 130, num formato de aplicação padrão, pelo cliente 110. Num aspeto da invenção, o servidor de aplicação 130 pode ser operado por um fornecedor em linha, tal como uma empresa de corretagem, regista mercadoria ou outro (ver e.g. Fig. 45) e serve como uma conduta entre o cliente 110 e o servidor de autenticação 120 uma vez que o processo de autenticação 10 é invocado. No entanto, é possível que o cliente 110 e o servidor de autenticação 120 comuniquem os dados solicitados diretamente sem passar pelo servidor de aplicações 130. O utilizador introduz o primeiro tipo de informação solicitada no cliente 110. Os dados podem ser consultados pelo utilizador através de questões textuais, interfaces gráficas de utilizador (GUIs), formulários de hipertexto (HTML) ou quaisquer outros mecanismos adequados, quer num ambiente interativo em tempo real ou através de um envio em lote. A seleção do modo de entrada pode depender de vários fatores, como carregamento e disponibilidade de recursos, modelo de negócios, tráfego do usuário e do sistema e criticidade da transação.

Na sequência da inicialização do registo de transações 112, a verificação da associação 24 pode ser executada. Antes de entrar no passo de pré-processamento 26, o processo de autenticação pode invocar a verificação de associação 24 para avaliar se o pedido em consideração está associado a outras solicitações ou tentativas, recentes, concorrentes ou não. 0 objetivo das verificações de associação é filtrar solicitações suspeitas de serem fraudulentas ou parte de um ataque de algum tipo. 0 reconhecimento de padrões (ilustrado nas Figuras 17 e 18) pode ser utilizado para identificar solicitações que devem ser identificadas como tendo um defeito fatal ou potencial de fraude, exigindo a rejeição imediata do pedido.

Numa realização preferida, o processo de autenticação 10 armazena informações recebidas através de todas as requisições na base de dados de autorização 152, que armazena o registo de transações 112 registando todas as entradas recebidas do utilizador. Usando esta informação, as verificações de associação com base nos dados disponíveis são facilitadas. Por exemplo, se uma tentativa de acesso incluir um nome e um número de segurança social associado, uma solicitação concorrente ou posterior com o mesmo nome, mas um número de segurança social diferente, pode ser negada ou sinalizada para autenticação adicional. Inversamente, se o pedido posterior incluir um nome diferente mas o número de segurança social anteriormente submetido, o pedido também pode ser negado ou sinalizado para autenticação adicional. As verificações de associação podem examinar quaisquer dados fornecidos pelo utilizador antes ou durante o passo de pré-processamento 26.

Depois da verificação de associação 24, o passo de pré-processamento 26 pode ocorrer em um ou mais clientes de autenticação 110, o servidor de autenticação 120 e servidor de aplicações 130. O passo de pré-processamento 26 no cliente 110 pode ser efetuado através da utilização, por exemplo, De applets Java para o cliente 110 ou através de outro software residente ou executando no cliente 110. Assim, embora o processo de autenticação 10 seja mostrado na Fig. 12 para ser residente no servidor de autenticação 120, partes ou todo o processo de autenticação 10 podem ser distribuídas noutro local.

Uma vantagem do passo de pré-processamento 2 6 é que ele processa tanto os dados pedidos quanto possível antes de obter dados de fontes de dados armazenadas separadamente, tais como ficheiros de crédito, que podem ser caros em termos de recursos de processamento, tempo e custo. Esses ficheiros de dados separados podem ser acessíveis através da Internet ou de outras redes, podem ser propriedade de entidades separadas e podem envolver uma cobrança por acesso. O passo de pré-processamento 26 envolve, num certo aspeto, assegurar que a formatação de dados é consistente entre as informações fornecidas pelo utilizador e o que é esperado nas bases de dados. O passo 26 de pré-processamento ajuda assim a assegurar que os dados fornecidos são tão precisos quanto possível para aumentar a probabilidade de gerar uma correspondência quando a identidade do utilizador é genuína. Isso reduz os falsos negativos devido a inconsistências como os apelidos fornecidos em vez de um primeiro nome completo, contrações, títulos ausentes ou formatação desajustada de números de segurança social aplicados contra fontes de dados conhecidos.

Se os dados fornecidos pelo utilizador forem determinados como não viáveis, incorretos ou claramente deficientes antes de solicitarem dados a partir de fontes de dados separadas, é ainda possível prosseguir para essas outras fontes de dados depois de a entrada do utilizador ter sido revista para satisfazer os requisitos mínimos sem interromper a transação global.

Se o utilizador não responder a uma solicitação de um item obrigatório de informação (por exemplo, nome) é preferível reprometer o utilizador para esse campo antes de incorrer em quaisquer encargos de base de dados ou gastar recursos de processamento adicionais. Outro exemplo em que a interceção desta maneira é benéfica é quando um usuário fornece um número de segurança social de seis dígitos. Nesse caso, fica claro que a resposta é deficiente e não há correspondência possível nas bases de dados do número de segurança social, portanto, essas bases de dados não devem ser desnecessariamente a cessadas.

Numa realização preferida, o passo de pré-processamento 26 pode executar uma ou mais das seguintes verificações de validação. 1) Verificações do Campo Padrão. Para verificar se todos os campos de informação requeridos estão presentes e no formato apropriado e se não, reprometer para eles ou reformatá-los como necessário à forma apropriada. 2) Verificação de Segurança Social. 0 número de segurança social de entrada é comparado com uma ou mais tabelas de números de segurança social publicadas ou processadas usando um ou mais algoritmos para determinar a sua validade. Esses quadros podem incluir informações como números relatados como falecidos ou fraudulentos. 3) Verificações de endereço e telefone. 0 endereço e o número de telefone fornecidos são verificados quanto à consistência (isto é, cidade, estado e código postal concordam, o código de área concorda com o estado) e o endereço do usuário é padronizado. A normalização permite uma correspondência mais exata com outras bases de dados em fases posteriores do processo de autenticação 10. Durante o passo de pré-processamento 26, a rejeição ou sinalização para autenticação adicional pode ocorrer como resultado de descasamentos. 4) Verificação de Validação da Licença de Motorista. O número de licença do driver de entrada é processado para verificar se o número é válido para o estado de emissão. Estes algoritmos podem ser obtidos através de departamentos de veículos a motor ou de outra forma.

As informações seguintes são preferencialmente solicitadas para (sendo R exigido, sendo O opcional) pelo processo de autenticação 10 durante o passo de pré-processamento 26 e fornecido pelo utilizador:

Outras informações não-carteira, que são utilizadas para níveis subsequentes de autenticação, podem ser recolhidas durante o passo de pré-processamento 26 ou diferidas até uma fase posterior do processo de autenticação 10. Um utilizador que não fornece estas informações durante o passo de pré-processamento 2 6 pode ser reprometido para ele, e o processamento pode ou não pode continuar no evento o usuário nunca fornece a informação designada como exigido. Esta informação inclui de preferência:

Tabela 1

DESCRIÇÃO REQ/OPT

Sobrenome R

Primeiro nome R

Inicial do Meio 0

Sufixo 0

Nome de solteira, se aplicável 0

Endereço atual (CA) R

Em CA <2 Anos Indicador (S/N) R

Antigo Endereço R somente se At CA <2 Anos 0 indicador é Y, caso contrário

Opcional

Número de telefone residencial R

Indicador de Alteração de Código de Área (S/N) R

Telefone residencial publicado Indicador (S/N) R Número de telefone do trabalho 0

Sexo R

Data de Nascimento R

Número de Segurança Social R

Indicador de Licença de Motorista (S/N) R

Número de Licença de Motorista (DL) R somente se o Indicador DL estiver definido como Y, caso contrário, Opcional

Licença de condução Estado de emissão R somente se o indicador DL estiver definido como Y, caso contrário, Opcional

Nome de solteira da mãe 0

Ano, escola, graduação, 0 Número de irmãos 0 ,inclui meio e irmãos etapa

Endereço de e-mail 0

Outras informações não-carteira, que são usadas para níveis subsequentes de autenticação, podem ser pré-processamento 26 ou diferidas até uma fase posterior do processo de autenticação 10. Um utilizador que não forneça esta informação durante o passo de pré-processamento 26 pode ser repontada para ele, e o processamento pode ou não continuar no caso de o usuário nunca fornecer informações designadas conforme necessário. Esta informação inclui de preferência:

Tabela 2

DESCRIÇÃO REQ/OPT

Nome do credor R, somente se a

Autenticação de segundo nível usada Número da Conta do Empréstimo 0

Indicador de Tipo de Empréstimo R, somente se a

Autenticação de

Segundo Nível

Montante de pagamento mensal R, somente se a

Autenticação de segundo nível usada O passo de pré-processamento 26 pode assim incluir um conjunto de verificações de validação incluindo verificações do campo padrão, validação do número de segurança social, validação de endereços, validação do código da área e validação da licença de condutor e outra verificação preliminar de dados. É preferível que o pré-processamento ocorra na ordem apresentada, em parte devido a dependência de dados de verificações posteriores sobre as anteriores. No entanto, deve entender-se que a ordem pode ser rearranjada e podem ser empregues diferentes verificações de pré-processamento. As verificações de validação enumeradas são discutidas em mais detalhes na ordem abaixo.

Em primeiro lugar, as verificações do campo padrão ocorrem de preferência no cliente 110, onde e quando os dados solicitados são recolhidos, para assegurar que todos os dados necessários estão presentes e todos os dados fornecidos estão no formato apropriado e cumprem os requisitos minimos. A conclusão deste processamento no cliente 110 minimiza o número de pedidos que têm de ser encerrados neste primeiro momento no processo de autenticação devido a dados formalmente incorretos. Isso é particularmente importante quando o usuário não está presente no momento da autenticação, como quando as solicitações são enviadas em forma de lote, em vez de interactivamente. Em geral, as verificações de campo padrão garantem que um intervalo esperado ou formato de caracteres são inseridos pelo usuário, apropriado para consultas individuais e tipos de dados. O seguinte é de preferência realizado durante verificações de campo padrão: 1) Todos os campos obrigatórios devem estar presentes. 2) Todos os campos devem estar no formato apropriado. • O primeiro nome deve ter pelo menos uma letra fornecida. • Os números de telefone devem ter 10 dígitos. • 0 número de segurança social deve ter 9 dígitos. • 0 número de Segurança Social não deve ter todos os 9 dígitos iguais. • Os primeiros 3 dígitos do número de segurança social não devem ser iguais a 000. • Os números 4 e 5 do número de segurança social não devem ser iguais a 00. • Os últimos 4 dígitos do número de segurança social não devem ser iguais a 0000. 3) Os campos especificados devem atender a requisitos adicionais. • A idade, derivada da data de nascimento, deve ter 18 anos ou mais. (No entanto, um número de telefone e drivers Licença ainda pode ser verificada, mesmo se um arquivo de crédito não está disponível) • O endereço de e-mail deve conter um sinal @ e um ".com" ou outro domínio.

De preferência, o utilizador proporciona até duas tentativas adicionais para corrigir quaisquer campos que não cumpram os requisitos de verificação de campo padrão. Se qualquer campo não puder ser corrigido após um total de três tentativas, o processo de autenticação 10 é de preferência abortado. Se a solicitação foi concluída com êxito como determinado pela parte de verificação de campo padrão da etapa de pré-processamento 26, a solicitação pode continuar para a próxima verificação de pré-processamento.

Na próxima fase de verificações de campo normalizadas, o número de segurança social pode ser verificado para alguns ou todos os seguintes: • 0 número de segurança social contém 9 dígitos • Número da Segurança Social Φ 000000000, 11111111, . .., 999999999. • Número de segurança social primeiro 3 dígitos Φ 000 • Número de segurança social 4o e 5°dígitos Φ 00 • Número de segurança social últimos 4 dígitos Φ 0000 • O número de segurança social não corresponde a nenhum número de segurança social encontrado na tabela de fraude e número de Segurança Social. • O número de segurança social está na faixa emitida, conforme determinado por uma pesquisa na tabela de intervalo de número de segurança social. • A data de nascimento concorda com as datas de emissão do número do seguro social. • Verifique se a cidade, o estado e o CEP concordam. Se apenas uma cidade e estado são fornecidos, o pacote pode ser capaz de adicionar o código postal. Se apenas um código postal for fornecido, o pacote geralmente pode adicionar a cidade e o estado. • Padronizar a linha de endereço. 0 pacote pode corrigir nomes de ruas com erros ortográficos, preencher as informações em falta e retirar marcas e espaços de pontuação desnecessários. • Identificar endereços não entregues (isto é, lotes vagos, edifícios condenados, etc.). • Criar um código de status que informa como um endereço de entrada teve que ser corrigido. • Crie um código de erro que indique por que um endereço de entrada não pode ser correspondido ou atribuído. A verificação em relação à tabela de fraudes de número de segurança social publicada é utilizada para assegurar que a tabela social fornecida não é fraudulenta.Tal tabela pode ser obtida a partir de qualquer uma de várias fontes, incluindo, por exemplo, empresas de relatório de crédito ou agências de aplicação da lei. A tabela de intervalo de número de segurança social é usada para garantir que o número de segurança social fornecido não seja um número inválido. Uma tal tabela pode ser obtida a partir de qualquer uma de várias fontes incluindo, por exemplo, agências governamentais.

Uma vez determinado que o número de segurança social foi emitido e uma série de datas de emissão é conhecida, a data de nascimento fornecida no pedido pode ser comparada com o intervalo de datas para a consistência. Assim, é possível realizar outra verificação para garantir que o número de segurança social é válido com base na data de nascimento informação.

De preferência, o utilizador recebe apenas uma tentativa adicional de corrigir informação de número de segurança social que foi rejeitada pela verificação de validação de número de segurança social. Se o número de segurança social não puder ser aceite após um total de duas tentativas, o processo de autenticação 10 é de preferência abortado. Em seguida, confirma-se a validade das informações de endereços, de preferência utilizando um pacote de correcção e normalização de endereços (tal como o pacote PostalSoft disponível da First Logic Corp.). Para o endereço atual, e endereço anterior, se fornecido, o pacote pode:

As respostas ou ações para cada um dos possíveis códigos de estado ou códigos de erro relacionados com o endereço na matriz de código de erro 156 (ilustrada nas Figuras 9-11) são fornecidas como saída durante o passo de pré-processamento 26. O utilizador é de preferência dado Apenas uma tentativa adicional para corrigir cada endereço que foi rejeitado por validação de endereços. Se o endereço não puder ser corrigido após um total de duas tentativas, a solicitação prossegue como designado na matriz de resposta 154 ilustrada nas Figs. 9-11. A matriz de resposta 154 pode estar localizada no servidor de autenticação 120, na base de dados de autorização 152 ou noutro local e servir para associar mensagens com resultados de teste e registos de transacção durante a parte de endereço do passo de pré-processamento 2 6, em simultâneo com o processamento de aplicação global.

Por outras palavras, a matriz de resposta 154 envia mensagens ao cliente 110 com base em testes de verificação específicos ou com base no estado actual do registo de transacções 112. Por exemplo, a mensagem pode solicitar ao utilizador que verifique se os dados que foram introduzidos são Correta ou uma mensagem para direcionar o usuário para chamar o serviço ao cliente para a intervenção manual. A matriz de resposta 154 é preferencialmente accionada por parâmetros, de modo que mensagens apropriadas podem ser associadas a eventos particulares. 0 código de área para o número de telefone residencial é preferencialmente verificado para determinar se é válido para o estado fornecido no endereço corrente, no passo de pré-processamento 26. O código de área e estado fornecidos em ligação com o pedido são comparados com uma entrada Para o código de área em uma tabela de código de área, disponível a partir de banco de dados e outras fontes. A tabela de código de área contém informações de código de área para cada uma das localizações de código de área na área geográfica que está sendo atendida. A base de dados para o código de área e as informações associadas podem ser preferencialmente implementadas, por exemplo, utilizando o pacote MetroNet comercialmente disponível. A informarão da base de dados de ni^ero de telefone pode ser armazenada na base de dados de telefone 180 ligada ao servidor de autenticai^o 120, ou de outro modo. A coerência do código de área com o estado de residência pode, por exemplo, ser verificada.

Preferencialmente, o utilizador recebe apenas uma tentativa adicional de corrigir as informações do número de telefone doméstico que foi rejeitado pela verificação de validação de código de área. Após o número de telefone residencial ter sido aceito ou após um total de duas tentativas, o processo indica o resultado, válido ou não válido, no registro de transação 112 e prossegue. Seguidamente, o número de licença de condução é verificado para assegurar que o formato do número é consistente com o formato para o estado de emissão. Um algoritmo pode procurar o estado de emissão e comparar o número de licença do motorista fornecido no pedido com o formato aceito para o estado. De preferência, o utilizador recebe apenas uma tentativa adicional de corrigir as informações do número da licença do condutor que foram rejeitadas pela verificação da licença do condutor (ou podem ser resolvidas imediatamente, de acordo com a preferência do fornecedor). Após o número de licença do condutor ter sido aceite ou após um total de duas tentativas, o processo de autenticação 10 indica o resultado, válido ou não válido, no registo de transacção 112 e prossegue.

No caso de o utilizador pagar um produto ou serviço com um cartão de crédito, o processo de autenticação 10 pode invocar a verificação do cartão de crédito neste momento. Neste caso, os cheques podem ser executados contra um banco de dados de cartão de crédito. Essas verificações podem incluir garantir que a linha de crédito disponível é suficiente para fazer a compra, garantindo que o endereço de faturamento do cartão de crédito no banco de dados corresponda ao endereço enviado e assegurando que o cartão de crédito não é roubado. As bases de dados que apresentam este tipo de informação estão comercialmente disponíveis. O passo 26 de pré-processamento pode assim incluir correcções internas, bem como comparações de dados fornecidos pelo utilizador a

Dados conhecidos que podem ser obtidos a partir de fontes separadas. Essas fontes podem ser bancos de dados de terceiros, como bancos de dados comerciais ou governamentais ou bancos de dados internos. De preferência, no entanto, o passo de pré-processamento 26 está limitado à verificação de dados fornecidos pelo utilizador contra dados do tipo carteira que são acessados de forma relativamente conveniente e local. 0 passo de pré-processamento 26 proporciona, consequentemente, uma maior certeza de autenticação utilizando bases de dados adicionais e exigindo consistência interna como um predicado para autenticação de primeiro e segundo nivel.

Em conjunto com as verificações efectuadas pelo passo de pré-processamento 2 6, a base de dados de crédito 160 pode ser qualquer banco de dados de crédito de consumo adequado disponível a partir de várias fontes incluindo empresas de crédito tais como Equifax ™. A base de dados de correio 170 e a base de dados de telefone 180 podem ser quaisquer bases de dados adequadas que proporcionam informações de endereço e telefone para a área geográfica relevante (por exemplo, MetroMail, que é um compêndio de informação regional fornecida pela empresa Bell). Outras bases de dados 190 podem incluir, por exemplo, um banco de dados de licenças de controladores de serviços de checagem que fornece informações sobre a validade de verificação. Qualquer base de dados comercialmente disponível ou interna ou outros podem ser empregues no processamento das sub-etapas de verificação do passo de pré-processamento 26.

Adicionalmente, as verificações do passo 26 de pré-processamento podem incluir a utilização de um modelo de fraude de aplicação de cartão de crédito ou algum outro modelo que analisa estatisticamente os dados de resposta.

Por exemplo, os dados fornecidos pelo utilizador podem ser modelados e classificados para o nível de confiança com base em modelos empíricos fornecidos por fornecedores terceirizados ou disponíveis internamente. Uma ilustração dos critérios de reconhecimento de padrões que podem ser empregues a este respeito pela invenção é ilustrada nas Figs. 17 e 18. Conforme ilustrado nestas figuras, em geral a invenção monitoriza a entrada de utilizador registada no registo de transacções 112 ou de outra forma para tentativas repetitivas de autenticação, o que pode representar tentativa de fraude ou algum tipo de ataque de rede.

Em tais casos, e como ilustrado na matriz de critérios de reconhecimento de padrões 904 mostrada na Fig. 17, a entrada pode incluir porções válidas de informação, tal como um número de segurança social, mas várias tentativas malsucedidas de encontrar entradas válidas para outros campos. A qualquer momento durante o processo de autenticação 10, a invenção pode impedir o evento de autenticação e terminar a sessão quando o reconhecimento de padrões detecta uma probabilidade significativa de irregularidade. As respostas diferentes a diferentes tipos de transacções fraudulentas detectadas potenciais são mostradas na matriz de acção de correspondência de reconhecimento de padrões 912 da Fig. 19. Conforme ilustrado na figura, diferentes tipos de inconsistências podem resultar em ações diferentes, incluindo o bloqueio de entradas suspeitas fraudulentas para padrões como o mesmo nome em vários endereços de e-mail. Outras inconsistências podem resultar no início do processo de autenticação 10 novamente (entradas QILT) a pedido do utilizador.

Numa concretização preferida da invenção, os dados fornecidos pelo utilizador devem corresponder a um registo de pelo menos duas fontes de dados para se graduarem a partir do passo de pré-processamento 26. Isto aumenta o nível de certeza de que a identidade do utilizador é genuína antes de se graduar a partir de Essa fase. As rotinas de correspondência, implementadas para cada fonte de dados e tipo de verificação, comparam os dados da consulta com dados de origem conhecidos e preferencialmente atribuem um valor a cada instância de correspondência. Este valor pode ser denominado uma pontuação de certeza de autenticidade. Uma pontuação de certeza de autenticidade pode ser acumulada com base nos valores colectivos atribuídos para cada instância de coincidência da etapa de pré-processamento 26. A pontuação de certeza de autenticidade pode ser utilizada e comparada com limiares predeterminados para determinar a próxima acção para a solicitação (ie, aprovar, , Negar, ir para o primeiro ou outro pré-processamento de nível).

Se os dados fornecidos pelo utilizador não satisfizerem os requisitos de algumas ou todas as verificações da etapa de pré-processamento 26, uma mensagem pode ser devolvida ao utilizador através da ligação 150 solicitando que os dados em questão sejam corrigidos e reenviados. Após a reapresentação, os dados de entrada serão novamente analisados. Alternativamente, o processo de autenticação 10 pode ser pré-configurado para rejeitar imediatamente um pedido com base numa falha para satisfazer um nível mínimo durante o passo de pré-processamento 26.

Se a solicitação for identificada como resultado da verificação de associação 24 ou outra análise como possivelmente fraudulenta usando a verificação de associação ou de outra forma, uma mensagem pode ser devolvida ao cliente 110 indicando que a solicitação não pode ser processada automaticamente e que o processamento manual tal Como chamar serviço ao cliente é necessário.

Os dados biométricos podem ser empregues sozinhos ou em combinação com o pré-processamento acima, bem como os niveis de autenticação subsequentes para assegurar a identidade de um utilizador. Os dados biométricos podem incluir, por exemplo, informações de impressões digitais do utilizador, capturadas em forma analógica ou digital, por exemplo, através de um periférico de impressão ligado ao cliente 110. Os dados biométricos podem também incluir imagens de infravermelhos ou de retina ou de iris, Geometria da mão. Do mesmo modo, os dados biométricos utilizados pela invenção podem também incluir o reconhecimento de escrita manual, o reconhecimento de voz utilizando amostragem digitalizada ou outros meios ou a entrada de reconhecimento facial a partir de vídeo ou outros dispositivos.

Os dados biométricos podem também incluir a correspondência de bases de dados de ADN. Em geral, qualquer tecnologia biométrica existente

Ou desenvolvidos no futuro podem ser incorporados na invenção. Os dados biométricos podem ser utilizados como campos de entrada ou registos no pré-processamento, primeiro ou segundo estádios de nivel de autenticação. Alternativamente, os dados biométricos podem ser utilizados como uma chave para desbloquear e libertar um certificado digital 902 emitido para o utilizador, para ser armazenado no cliente 110 ou de outro modo. A fig. 1 é um fluxograma que ilustra o processo de autenticação global de acordo com a invenção. O processo de autenticação 10 começa no passo 12. O processo de autenticação 10 solicita ao utilizador uma informação de primeiro nivel no passo 14. Novamente, o primeiro tipo de informação é de preferência informação do tipo carteira, isto é, informações tais como nome, endereço, carteira de motorista ou Outras informações normalmente transmitidas à pessoa. O utilizador introduz essas informações de primeiro nivel através de um teclado, rato, digitalizador de voz ou outro mecanismo de entrada adequado no passo 16. O passo 18 identifica que o utilizador completou primeiro Nivel entrada de informação. Passo 20 transmite a entrada. O registo de transacção 112 é inicializado no passo 22. 0 Passo 24 executa uma verificação de associação na entrada de informação pelo utilizador. O processo de autenticação 10 pode então invocar o passo de pré-processamento 26 discutido acima. Se o passo de pré-processamento 26 estiver incluido, o passo 28 também pode ser proporcionado, o qual determina se o passo de pré-processamento 26 está completo. Se o passo de pré-processamento 26 não estiver completo, o processo de autenticação 10 pode retornar ao passo 14 para solicitar ao utilizador informações omitidas, corrigidas ou adicionais, voltar ao passo 16 para permitir ao utilizador introduzir informação ou processo de autenticação final no passo 30. Se o pré- O passo 26 está completo, o processo de autenticação 10 prossegue para o passo 32 da autenticação de primeiro nivel. O processo de autenticação 10 corresponde, no passo 32, ao primeiro tipo de informação introduzida pelo utilizador com informação recebida de uma ou mais fontes de dados separadas. Com base nessa comparação, o processo de autenticação 10 determina se a autenticação de primeiro nivel está completa no passo 34. Se a autenticação de primeiro nivel não estiver completa, o processo de autenticação 10 pode retornar ao passo 14 para solicitar ao utilizador informações omitidas, corrigidas ou adicionais, Para o passo 16 para permitir que o utilizador introduza informação, ou termine o processo de autenticação no passo 36.

Se a autenticação de primeiro nivel estiver completa, o processo de autenticação 10 determina no passo 38 se o utilizador deve ser autenticado. Se o utilizador não foi rejeitado completamente mas ainda não foi autenticado, o processo de autenticação 10 prossegue para a etapa 40, autenticação de segundo nivel. O passo 40 solicita e testa a entrada do utilizador de um segundo tipo de informação, que é de preferência informação de tipo não-carteira. O processo de autenticação 10 determina se uma solicitação de informação foi repetida mais do que um número predeterminado de vezes no passo 42. Se a tentativa exceder o limite predeterminado, o processo de autenticação 10 termina no passo 44. Se a tentativa não exceder o predeterminado Limite, o processo de autenticação 10 determina se o passo 40 está completo no passo 46. Se o passo 40 está completo, o processo de autenticação 10 processa uma decisão de autenticação no passo 48 e depois termina no passo 50. Se o passo 40 não estiver completo, o processo de autenticação pode voltar ao Passo 38 ou termina no passo 47. A fig. 2 é um fluxograma que ilustra o processo do passo de autenticação de primeiro nivel 32 com mais pormenor. O processo de autenticação de primeiro nivel 32 inicia-se no primeiro nivel comparando o passo 52. O primeiro nivel que compara o passo 52 compara a informação introduzida pelo utilizador com informação sobre o utilizador obtido de uma ou mais fontes de dados conhecidas. O utilizador pode ser consultado na etapa de autenticação de primeiro nível 32 para informação semelhante à que foi aceite durante o passo de pré-processamento 26, ou para informações refinadas ou adicionais. Durante o processamento de qualquer informação de número de telefone de entrada de utilizador no passo de autenticação de primeiro nível 32 após o passo de pré-processamento 26 (mas preferencialmente não no próprio passo de pré-processamento 26), se o utilizador indicar que esteve no número de telefone residencial durante menos de quatro meses , 0 número de telefone residencial E informações de fonte relacionadas podem ser preferencialmente verificadas em comparação com uma fonte de assistência de directório electrónico, para melhor moeda em comparação com uma base de dados offline. Durante o processamento de qualquer informação de licença do condutor de entrada de utilizador na fase de autenticação de primeiro nível 32 (mas de preferência não no passo de pré-processamento 26), quaisquer outras verificações no banco de dados de licenças de condução podem ser preferencialmente implementadas, por exemplo, Base de dados de licenças. As informações desse banco de dados externo geralmente derivam do departamento oficial de registros de veículos motorizados ou informações de reivindicações de seguros, cujo conteúdo pode variar de acordo com o estado de emissão. Etapa 54 atribui valores e prioridades a cada entrada de resposta pelo usuário. As informações de maior significado podem ser atribuídas a um maior valor ou prioridade. 0 registo de transacção 112 (ilustrado nas Figuras 13-16) inicializado no passo 22 é utilizado ao longo do processo de autenticação 10 para manter o registo dos resultados de entrada e autenticação do utilizador. Depois de processadas as consultas apropriadas e todos os resultados armazenados no registo de transacções 112, o registo de transacções 112 é utilizado para determinar uma pontuação de autenticação relativamente ao pedido. 0 passo 56 calcula a pontuação de autenticação total e, opcionalmente, uma pontuação para cada fonte de dados, campo de dados, etc. Os resultados são categorizados como um grande hit (B) , um hit regular (R) , um hit possível (P) ou Sem sucesso (N) dependendo dos resultados. Esses resultados podem então ser combinados com os resultados do processo de autenticação de segundo nível 40 para determinar uma pontuação global de certeza de autenticidade, como ilustrado nas Figs. 23-28 e discutidos abaixo. O processo de autenticação 10 determina se uma ou mais das classificações de autenticação são maiores ou iguais a um valor ou limiar predeterminado de autenticação no passo 58. Se as classificações de autenticação forem superiores ou iguais ao valor de autenticação predeterminado, o processo de autenticação 10 processa Uma decisão de autenticação no passo 60 e depois termina no passo 62.

Se um ou mais dos resultados forem inferiores ao seu valor de autenticação predeterminado correspondente, o processo de autenticação 10 determina se o nível de certeza atinge um nível de certeza predeterminado no passo 64. Se o nível de certeza estiver abaixo do nível de certeza predeterminado, a autenticação O processo 10 termina no passo 66. Caso contrário, o processo de autenticação 10 determina se são necessárias informações de primeiro tipo corrigidas ou adicionais no passo 68. Se nenhuma outra informação for necessária, a autenticação prossegue para o passo 40, autenticação de segundo nível. Se as informações de entrada do usuário precisam ser revisadas, o processo de autenticação 10 pode retornar ao passo 14 ou etapa 16.

As Figs. 31 a 33 ilustram um conjunto de consultas associadas ao passo de pré-processamento 26 e à autenticação de primeiro nível 32 num exemplo de sessão de autenticação de acordo com o invento. Como pode ser visto nas figuras, estas fases da invenção consultam e processam informação de tipo carteira para atingir um primeiro nível de confiança sobre a autenticidade da identidade do utilizador. A fig. 3 é um fluxograma que ilustra o processo de autenticação de segundo nível 40 com mais pormenor. O processo de autenticação de segundo nível 40 começa com o passo 310. A etapa 310 acede a informações de segundo tipo disponíveis de fontes de dados, tais como um ficheiro de crédito. A Etapa 312 solicita ao utilizador informações de segundo tipo de dentro daquela determinada como estando disponível no passo 310. A Etapa 314 determina se a entrada do utilizador corresponde à informação acedida.

Na execução do processo de autenticação de segundo nível 40, o servidor de autenticação 120 pode aceder à base de dados de crédito 160. A base de dados de crédito 160 pode ser preferencialmente implementada, por exemplo, utilizando um ficheiro de crédito de consumo Equifax ™ comercialmente disponível no formato de ficheiro ACRO.

As consultas podem ser transmitidas para trás e para a frente entre o servidor de aplicação 130 e o servidor de autenticação 120 durante o processo de autenticação de segundo nível, utilizando o formato de consulta System-to-System 93 (STS) para estes tipos de ficheiros de dados, como será apreciado por pessoas Especialista na técnica. As informações de linha de crédito retornadas da base de dados de crédito 160 podem estar no formato fixo de arquivo

System-to-System (FFF), consistente com a configuração do arquivo ACRO. 0 processo de autenticação de segundo nível 40 executa a pesquisa no banco de dados de crédito 160 para coincidir com a entrada do utilizador em relação aos dados nesse ficheiro. A pesquisa pode ser realizada de acordo com o formato de pesquisa ACRO L90, com resultados novamente categorizados como um grande hit (B), um hit regular (R), um possível hit (P) ou nenhum hit (N) dependendo de Resultados que, numa concretização, são devolvidos ao servidor de autenticação 120 começando na posição de segmento de cabeçalho ACRO 285 num segmento de 13 bytes. Correspondências ou nenhuma correspondência são retornadas como sinalizadores lógicos dentro desse segmento de cabeçalho.

Se a informação coincide, o processo de autenticação 10 proporciona uma autenticação de grau mais elevado no passo 316 ou emite outro grau de autenticação no passo 318. Se a informação não corresponder, o processo de autenticação 10 pode emitir uma autenticação de grau inferior, regressar ao passo 312 ou termina no passo 324.

Um exemplo de marcação pontual utilizado na autenticação de segundo nível de acordo com a invenção é ilustrado nas Figs. 20 e 21. A matriz de pontuação 906 da Fig. 20 Inclui um conjunto de valores pontuais para valores pontuais relacionados com contas de linha comercial que o utilizador pode ter, numa escala móvel de acordo com o grau relativo de significância de várias contas. Em geral, e como indicado na matriz de peso relativo da Fig. 21, a identificação adequada de um nome de credor é dado maior peso em relação ao montante do pagamento mensal ou termos de dados da conta.

Na Fig. 22, as pontuações de certeza resultantes são classificadas de acordo com quatro categorias de grande sucesso (B) , regular hit (R) , provável hit (P) , e nenhum hit (N) . Diferentes combinações de contas podem levar a pontuações máximas diferentes, de acordo com a confiabilidade ou a importância das contas disponíveis para a etapa 40 de autenticação de segundo nível.

Após a conclusão tanto do passo de autenticação de primeiro nível 32 como do passo de autenticação de segundo nível 40, os resultados de todas as verificações podem ser montados para determinar uma contagem de certeza de autenticidade global, cujos valores estão ilustrados na matriz de pontuação total de certeza 918 das Figs. 23-28. Em geral, nessas figuras, grandes hits em arquivos de crédito (autenticação de segundo nível) contribuem para maiores pontuações gerais de certeza, que são normalizadas de 0 a 100. No entanto, de preferência, nenhum cheque qualifica ou desqualifica um usuário de autenticação.

Em vez disso, de acordo com a invenção, a ponderação agregada de toda a resposta do utilizador é tida em conta numa variedade de gamas de pontuação possíveis, dependendo de quão altamente as informações fornecidas se correlacionam com a colecção completa de fontes de dados utilizadas pela invenção. Os nineis de pontuarão podem ser agregados como mostrado na matriz de atribuiifo 92 0 da Fig. 29 para desenvolver uma categorização em camadas (B, R, P, N) para todos os níveis de autenticação e gerar respostas de acordo com a tabela de limiar 922 como ilustrado na Fig. 30. Enquanto nifs niferos numificos específicos si f mostrados nessas matrizes, deve ser apreciado que as diferentes pontuações e nifeis si f seleccioni^eis ou escali^eis de acordo com as necessidades de aplicarão, na inveni^o.

As Figs. 34 a 36 ilustram um conjunto de consultas no formato de captura de ecrã associado ao passo de autenticação de segundo nível 40 num exemplo de sessão de autenticação de acordo com o invento. Em geral, nesta fase, o processo de autenticação 10 identifica e acede a informação de linha comercial (crédito) para consultar dados de natureza específica e privada, o que aumenta o perfil de segurança do utilizador. No exemplo mostrado, ambas as contas de crédito e comerciante ou linha de comércio são consultadas para identidade credor e montantes. A identificação precisa resulta na autenticação, seguida pela emissão de um certificado digital 902 conforme desej ado. O sistema e o método da invenção são personalizáveis para permitir que um fornecedor que opera um servidor de autenticação 120 defina vários parâmetros, incluindo os limiares ou níveis predeterminados em diferentes pontos do processo de autenticação 10. Se o nível de autenticação ou de certeza predeterminado não tiver sido Alcançado para uma determinada fonte de dados ou campo de dados, o usuário pode não ser elegível para autenticação, ou um grau mais elevado de autenticação.

Se um utilizador conclui com êxito o pré-processamento, primeira e segunda autenticação, numa concretização a invenção pode emitir um certificado digital 902 para o utilizador, como ilustrado nas Figs. 37-41. Conforme ilustrado nas Figs. 37-40, depois de uma indicação de autenticação bem sucedida, o utilizador é direccionado para a identificação de entrada e informações de desafio ou de palavra-passe para gerar e armazenar o certificado digital 902. O certificado digital 902 contém um conjunto de campos incluindo a identificação do utilizador, um número de série digital de certificado, Período de validade, bem como informações relacionadas ao emissor do certificado digital e dados de impressões digitais para o certificado digital. 0 certificado digital 902 pode ser preferencialmente armazenado de forma segura no cliente 110, ou seja, protegido pelo utilizador Identificação e desafio ou consulta de senha antes gue o destinatário possa liberar o certificado digital 902 para outras transações, como ilustrado nas Figs. 37 e 38. O certificado digital 902 pode ser um ficheiro de dados armazenado num formato legível por máquina comum que, após libertação adequada pelo utilizador, pode ser apresentado a outros servidores de autenticação para transacções posteriores,

Como evidência de identidade e evitando a necessidade de reautenticar o usuário para eventos posteriores. Conforme ilustrado, o certificado digital 902 contém um campo de expiração, mas o certificado pode ser gerado para persistir indefinidamente. O certificado digital 902 pode ser actualizado utilizando um processo de autenticação completo ou abreviado 10 de acordo com a Acordo com o grau de segurança exigido para determinadas transações futuras. Por exemplo, um certificado digital 902 pode ser emitido registando um grau de confiança médio da identidade do utilizador, mas para executar uma transacção sensível, o utilizador pode necessitar de actualizar e actualizar o certificado digital 902 para executar essa transacção posterior.

Embora ilustrado com dois níveis de processamento de autenticação, será compreendido que a invenção contempla três ou mais níveis de autenticação realizando verificações adicionais utilizando bases de dados adicionais ou solicitando ao utilizador mais informações, quando apropriado para os requisitos de transacção. Qualquer dos níveis do processo de autenticação 10 pode ser implementado através de um formato de consulta interactivo, por exemplo, utilizando uma caixa de verificação de múltipla escolha. Em nenhum momento durante a apresentação da consulta interativa é o usuário apresentado com respostas potenciais revelando apenas informações corretas, De modo que a informação de identificação não pode ser capturada simplesmente entrando no processo de autenticação 10. Além disso, na implementação da invenção é possível seguir todo o processo de autenticação 10 com um passo de criação de perfil de consumidor, no qual a identidade de utilizador agora autenticada está associada à compra , Viagens, informações geográficas e outras informações que permitam uma atividade de marketing ou transação mais direcionada.

Em geral, na execução do processo de autenticação 10 da invenção, as respostas às questões de consulta interactivas recebem a ponderação relativa mais elevada, seguidas por verificações de autenticação contra o ficheiro de crédito de um utilizador, seguidas por informação de telefone e, em seguida, informação de licença de condutor.

Conforme ilustrado na Fig. 4 e descrito acima, o passo de pré-processamento 26 pode ser conduzido antes da hierarquia de níveis de autenticação e incluir vários procedimentos preliminares, principalmente concebidos para assegurar consistência no formato. A discussão voltará ao passo de pré-processamento 26 para descrever a fase de pré-processamento com mais detalhe em conjunção com as Figs. 5-8. Entender-se-á que várias combinações de normalização 400, verificação de formatação 410, verificação de consistência 420 e verificação de validade de dados 430 podem ser incorporadas no passo de pré-processamento 26. Conforme ilustrado na Fig. 1, depois do passo de pré-processamento 26 ser executado, é feita uma decisão 28 se a autenticação deve prosseguir. A decisão 28 pode resultar num retorno ao passo inicial 14 ou no fim do processo automatizado de autenticação 10 no passo 30.

Se o passo de pré-processamento 26 incluir uma verificação de formatação 410, o seguinte processo pode ser seguido. Os dados de entrada do usuário são verificados na etapa 500 para determinar se ele está devidamente formatado. Por exemplo, os dados podem ser verificados para verificar se os campos obrigatórios foram inseridos (por exemplo, nome de usuário) ou se o número apropriado de caracteres foi inserido (por exemplo, nove dígitos para um número de segurança social). Se o resultado da etapa de decisão 500 é que os dados não estão na forma apropriada, é feita uma determinação no passo 510 se o utilizador foi previamente solicitado a obter estas informações. O processo de autenticação 10 pode ser configurado para permitir um número predeterminado de oportunidades para o utilizador introduzir dados no formato correcto. Se o número de tentativas exceder o número predeterminado, o processo pode terminar No passo 520. Se o número predeterminado de oportunidades não tiver sido excedido, o utilizador pode ser solicitado a introduzir os dados no formato correcto no passo 530. Se os dados estiverem no formato correcto, o processo prossegue para o passo 540. A fig. 6 representa o processo para padronização 400 dos dados. No passo 600 é feita uma determinação se os dados estão na forma padrão apropriada. Por exemplo, o endereço postal do usuário pode ser verificado para nomes de ruas com erros ortográficos ou pontuação desnecessária. Se a determinação 600 encontrar os dados não padronizados, é feita uma determinação 610 se os dados não standard podem ser corrigidos. Se os dados puderem ser corrigidos, podem ser realizados no passo 620 por processos internos ou outros. Se os dados não puderem ser corrigidos, uma determinação é feita no passo 630 se o utilizador foi solicitado a obter estas informações anteriormente. O processo de autenticação pode ser configurado para permitir um número predeterminado de oportunidades para o utilizador introduzir dados no formato correcto. Se o número de tentativas exceder o número predeterminado, o processo pode terminar No passo 640. Se o número predeterminado de oportunidades não tiver sido excedido, o utilizador pode ser solicitado a introduzir dados padrão no passo 650. Se os dados estiverem na forma padrão, o processo prossegue para o passo 660. A fig. 7 representa o processo para determinar a validade 430 dos dados. Por exemplo, a validade pode ser verificada ao determinar no passo 700 se os dados são válidos (por exemplo, o número de segurança social corresponde a qualquer número de segurança social encontrado na tabela publicada falecida ou fraudulenta). Se a determinação é feita de que os dados são inválidos, uma determinação 710 é feita no passo 710 se o utilizador foi solicitado a obter estas informações anteriormente. Se o número de tentativas exceder o número predeterminado, o processo pode actualizar o registo de transacção no passo 720 para reflectir a presença dos dados inválidos.

Depois do registo de transacção 112 ser actualizado no passo 720, é feita uma determinação adicional no passo 730 se o processo pode continuar com estes dados inválidos. Caso contrário, o processo pode terminar no passo 740. Se puder, o processo pode prosseguir para o passo 750. Se o número predeterminado de oportunidades não tiver sido excedido, o utilizador pode ser solicitado a introduzir dados válidos no passo 760. Se os dados É válida, o processo prossegue para o passo 750.

Um processo semelhante pode ser seguido para determinar se os dados são consistentes no passo 420, como ilustrado na Fig. 8. No passo 760, a determinação é feita se os dados de entradas de campo separadas são consistentes. Por exemplo, os dados podem ser verificados para verificar se o código de área digitado corresponde ao CEP introduzido. Se for feita a determinação de que os dados introduzidos pelo utilizador não são consistentes, é feita uma determinação no passo 770 se o utilizador foi previamente solicitado a fornecer estas informações. Se o número de tentativas exceder o número predeterminado, o processo pode actualizar o registo de transacção 112 no passo 780 para reflectir a presença dos dados inconsistentes.

Depois do registo de transacção 112 ser actualizado 780, é feita uma determinação adicional no passo 790 de se o processo pode prosseguir com estes dados inconsistentes. Caso contrário, o processo pode terminar no passo 800. Se puder, o processo pode prosseguir para o passo 810. Se o número predeterminado de oportunidades não tiver sido excedido, o utilizador pode ser solicitado a introduzir dados válidos no passo 820. Se os dados É válido, o processo prossegue para o passo 810 e a próxima verificação de pré-processamento.

As Figs. 9-11 mostram um exemplo da utilização de uma matriz para verificar informação de endereço na validade de processamento 430 ou consistência 420. Como mostrado, o processo de verificação, que pode ser implementado usando o PostalSoft comercialmente disponível, gera uma matriz de valores de endereço para determinar certas Informação de Endereço. FIG. 10 mostra um exemplo de certos códigos de erro que podem ser gerados para alertar as respostas do utilizador de acordo com o formato PostalSoft quando os valores introduzidos, tais como o código postal, não estão no formato apropriado. FIG. 11 mostra um exemplo de determinadas acções e mensagens de acordo com outros tipos de dados introduzidos durante o processamento para a consistência 420.

De um modo geral, existem várias formas de administrar as consultas nos vários níveis de autenticação da invenção, dependendo dos requisitos da transacção. Se o utilizador estiver disponível no momento da aplicação para um diálogo interactive (por exemplo, pedido da Internet), um questionário de múltipla escolha é de preferência criado dinamicamente pelo processo de autenticação 10 e apresentado ao utilizador, através do cliente 110, para ser completado.

As alternativas de escolha múltipla para cada questão são preferencialmente seleccionadas com base nos viés regionais do utilizador, se aplicável, e são concebidas para tornar mais difícil para um candidato fraudulento adivinhar correctamente as respostas. Ou seja, as seleções em potencial para vários provedores de linha de crédito ou de comerciante são fornecidas na mesma região geográfica geral que o endereço residencial do usuário, de modo que os fornecedores de contas de linha de crédito não são obviamente errados com base na localização. 0 usuário aponta e clica em suas seleções, ou fornece respostas de alguma outra maneira adequada. As respostas fornecidas pelo utilizador são então devolvidas ao processo de autenticação 10 pelo cliente 110 para avaliação automatizada.

Se o utilizador não estiver presente no momento da aplicação (por exemplo, envio de lotes), as informações necessárias para administrar a validação são fornecidas no pedido inicial. Se o utilizador fornecer números de contas, a etapa de autenticação de segundo nível 40 tentará fazer as comparações automaticamente. No entanto, se as comparações não podem ser feitas automaticamente ou os números de conta não são fornecidos, as comparações podem ser realizadas manualmente através da intervenção humana. Os resultados são devolvidos ao passo de autenticação de segundo nível 40 para avaliação final. A fig. 18 ilustra um exemplo de autenticação realizada de acordo com o processo de autenticação 10 da invenção. Em geral, conforme ilustrado na figura, o usuário apresenta o nome, número de segurança social, data de nascimento, endereço de e-mail e endereço, seguido pelo número de telefone residencial e dados da licença de motorista. Essas informações são aceitas e processadas através do passo de pré-processamento 26 e do passo de autenticação de primeiro nível 32, após o que é determinado que os dados são consistentes e merecem prosseguir para o passo de autenticação de segundo nível 40.

No passo de autenticação de segundo nível 40, uma sequência de questões é apresentada numa consulta interactiva dirigida

Para informações de conta de hipoteca, solicitando informações de credor e quantidade seguido por outras informações de conta de comerciante. Após a autenticação bem sucedida, o utilizador é perguntado se deseja gerar o certificado digital 902, que é gerado registando a autenticação bem sucedida e protegendo o certificado digital 902 por meio de dados de identificação e de pergunta de desafio.

Qualquer ou todos os passos de processamento descritos acima podem ser invocados selectivamente ou rearranjados para constituir um processo completo de autenticação 10. Os requisitos da transacção determinarão quais processos combinar para necessidades particulares de autenticação. E possível configurar várias implementações diferentes como ofertas padrão. A parte que emprega o sistema de autenticação (fornecedor) pode usar essas ofertas padrão ou personalizar uma configuração para suas necessidades. Com qualquer implementação, a invenção permite flexibilidade na determinação da certeza da autenticidade, quer através da configuração do processo quer do estabelecimento de limiares de certidão.

Na prática da invenção, no caso de tempo de inactividade temporário ou outra indisponibilidade de qualquer das fontes de dados usadas para comparação, a invenção pode reverter para uma fonte de backup para esse tipo particular de informação (que pode ser geralmente consistente mas Não como atual), substituir outra fonte de dados, ou tomar outra ação. A Fig. 42 ilustra uma concretização de autenticação remota offline da invenção, em que algum processamento incluindo a entrega de um ID validado é conduzido usando correio ordinário. Conforme ilustrado na Fig. 42, nesta concretização, um sistema de autenticação remoto 1002 controla dois objectos de processamento, um objecto de autenticação remoto com um campo de número de segurança social 1004 e um objecto de autenticação remota sem um campo de número de segurança social 1006. 0 sistema de autenticação remota 1002 invoca a autenticação remota Objecto 1004 quando um utilizador apresentou um número de segurança social, num pedido on-line para uma transacção de crédito ou outra. O objecto de autenticação remota 1004 pode invocar o passo de pré-processamento 26, para processar verificações de campo padrão como nas outras formas de realização acima. Nesta concretização, em parte devido aos requisitos para entrega de correio, a falha de um ou mais campos de dados para normalização de endereços, tais como erros de código postal, campos em branco, endereços externos e não entregues pode resultar num estado de falha 1018. O estado de falha 1018 também pode ser alcançado quando a idade é inferior a um nível predeterminado, ou não são cumpridas as verificações de segurança social padrão como descrito acima. Outros fatores que podem resultar em um estado de falha 1018 incluem correspondências de mistura relativas números de telefone, números de segurança social e indicadores de vítimas de fraude presentes em um arquivo de crédito.

Se o objecto de autenticação remoto 1004 determinar que o utilizador atingiu uma pontuação suficiente durante o passo de pré-processamento 26 e quaisquer outros passos de processamento, o estado de passagem 1008 pode ser atingido. A emissão on-line de um certificado digital 902 ou outra autenticação pode ocorrer. No entanto, se o objecto de autenticação remoto 1004 determinar que a pontuação do utilizador se situa entre aqueles designados para um estado de passagem 1008 e um estado de falha 1018, o objecto de autenticação remota pode oferecer um estado de autenticação offline 1010, em que a verificação é transmitida utilizando correio normal.

Nesta condição, o estado de autenticação offline 1010 invoca o filtro de correio 1012, que testa os correspondentes na primeira inicial, último nome, um número de casa e código postal de pelo menos uma base de dados de endereços, assim como a consistência de idade e ano de nascimento E um número de segurança social que seja válido ou não mostre mais do que um pequeno número de transposições de dígitos. Podem ser aplicados outros critérios. Se for atingida uma pontuação suficiente no processamento do filtro de correio 1012, é atingido um estado de correio 1014 no qual as informações de endereçamento introduzidas são utilizadas para transmitir um PIN ou outra informação de identificação ao utilizador por correio normal. Se não for atingida uma pontuação suficiente no filtro de correio 1012, é atingido um estado de falha 1016, nenhuma verificação é enviada pelo correio e o processamento termina.

Se um utilizador deixar de fornecer um número de segurança social, como ilustrado na Fig. 42 é passado para o objecto de autenticação remoto 1006, o qual pode aplicar o passo de pré-processamento 26 e outras etapas para testar as informações de utilizador introduzidas. Se a informação de utilizador introduzida não atinge um limiar predeterminado, o controlo passa para um estado de falha 1022. Se for atingida uma pontuação de autenticação suficiente, o processamento prossegue para o objecto de autenticação offline 1020. O objecto de autenticação offline 1020 invoca o filtro de capacidade de correio 1024, Fornecido sem um número de segurança social para determinar se a padronização de endereços, relacionados com a idade, endereço-relacionados, ou bandeiras de fraude estão presentes. Se uma pontuação de autenticação suficiente for atingida no filtro de capacidade de correio 1024, o controlo passa para o estado de correio 1026, no qual um PIN de identificação válido é transmitido ao utilizador no endereço introduzido utilizando correio normal. Inversamente, se o filtro de capacidade de correio 1024 não for satisfeito, é atingido um estado de falha 1028 no qual nenhum material é enviado e o processamento termina.

Uma concretização do sistema de autenticação remota 1002 é ilustrada com mais pormenor na Fig. 43, em que um objecto de fornecimento de segurança social 1030 testa se o utilizador é capaz de fornecer um campo de número de segurança social. Se o utilizador é capaz de proporcionar um campo de número de segurança social, o controlo prossegue para passar o módulo de teste 1032, que pode executar o passo de pré-processamento 26, o passo de autenticação de primeiro nivel 32, o passo de autenticação de segundo nivel 40 ou outro processamento. Se o usuário passar esses níveis de autenticação com uma pontuação suficiente, o controle passa para um estado de ícone recebido 1034, fornecendo ao usuário um ícone de autenticação on-line, certificado digital 902 ou outra verificação emitida.

Se o módulo de teste de passagem 1032 não for passado, um objecto de erro fatal 1036 pode testar erros fatais nos campos de dados de segurança social, de endereços, relacionados com a idade ou outros campos de dados desejados. Se o objecto de erro fatal 1036 não detectar um erro fatal, o controlo passa para um filtro de capacidade de correio 1038 que testa a capacidade de correio utilizando o código postal e o estado, o nome, a possibilidade de entrega e outras verificações de campo, após o que é introduzido um estado de correio 1040 se o utilizador Estabeleceu com sucesso informações confiáveis. Depois de inserir o estado de correio 1040, o PIN pode ser enviado por correio normal e um ícone de utilizador emitido no estado de ícone recebido 1042. Inversamente, se o objecto de erro fatal 1036 ou o filtro de capacidade de correio 1038 não estiverem satisfeitos com as informações que o utilizador tem Introduzido, é introduzido um estado de falha 1044 e o processamento termina sem transmitir um ID por correio ou um ícone a ser emitido.

Conforme ilustrado na Fig. 44, alternativamente se o utilizador não é capaz de fornecer um número de segurança social para o objecto de teste de segurança social 1030, então o controlo passa para o objecto de erro fatal 1046. Se nenhum erro fatal for detectado pelo objecto de erro fatal 1046, o controlo é passado para o filtro de capacidade de correio 1048, que testa as informações de correspondência entregues, como acima. Se o filtro de capacidade de correio 1048 for satisfeito, o estado de correio 1050 é atingido em que uma identificação de PIN regular é enviada por correio para o utilizador, Após o que é atingido um estado de ícone recebido 1052, emitindo ao utilizador uma identificação de ícone online. Por outro lado, se o objecto de erro fatal 1046 ou o filtro de capacidade de correio 1048 não forem satisfeitos, é atingido um estado de falha 1054 e o processamento termina. A descrição anterior do sistema de autenticação e método da invenção é ilustrativa e as variações na construção e implementação ocorrerão para os especialistas na técnica. Por exemplo, embora a invenção tenha sido geralmente descrita como envolvendo um único utilizador que fornece informação de autenticação numa única sessão interactiva ou, alternativamente, em modo batch, tanto as consultas como a entrada do utilizador podem ser fornecidas em tempos diferentes utilizando diferentes modos de entrada, quando a transacção o permitir. Este pode ser o caso, por exemplo, quando a transação envolve a criação de uma assinatura online para publicações ou serviços.

Para um outro exemplo, embora a invenção tenha sido descrita num ambiente cliente / servidor no qual um utilizador inicia uma transacção utilizando um computador pessoal ou outro dispositivo através de uma rede de computadores, o utilizador pode iniciar a Sobre outras redes. 0 utilizador, por exemplo, pode conduzir uma transacção utilizando um telefone celular equipado com um mostrador alfanumérico que permite ao utilizador introduzir dados de teclado através da rede celular móvel.

Ainda para outro exemplo, embora a invenção tenha sido ilustrada em termos de um consumidor individual iniciando uma transacção de rede, a invenção pode também verificar a identidade de outras entidades tais como corporações, escolas, unidades governamentais e outras que procuram transaccionar negócios uma rede. Essas entidades podem ser de natureza internacional. Consequentemente, o âmbito da invenção é limitado apenas pelas seguintes reivindicações.

Lisboa, 17 de Abril de 2017

REFERÊNCIAS CITADAS NA DESCRIÇÃO

Esta lista de referências citadas pelo Titular tem como único objectivo ajudar o leitor e não forma parte do documento de patente europeia. Ainda que na sua elaboração se tenha tido o máximo cuidado, não se podem excluir erros ou omissões e a EPO não assume qualquer responsabilidade a este respeito.

Documentos de Pedidos de Patente citadas na descrição

US 5712914 A US 5436972 A

Claims (19)

1. REIVINDICAÇÕES

   1. Processo (10) de autenticação de um utilizador numa rede, compreendendo o referido método: Executar um primeiro passo de autenticação (32) com base num primeiro tipo de informação; Executar pelo menos uma segunda etapa de autenticação (40) com base num segundo tipo de informação diferente do primeiro tipo de informação, sendo o referido método caracterizado por: Armazenar um registo de transacção (22) do primeiro passo de autenticação (32); Em que pelo menos um do primeiro passo de autenticação (32) e do segundo passo de autenticação (40) compreende gerar uma consulta interactiva, compreendendo a consulta interactiva pelo menos uma pergunta com respostas de escolha múltipla, em que nem todas as respostas são respostas correctas.
2. 2. Método (10) de acordo com a reivindicação 1, em que a rede compreende a Internet. Processo (10) de acordo com a reivindicação 1, caracterizado por a primeira informação compreender pelo menos uma das informações de nome, informação de endereço, informação de número de segurança social, informação de número de telefone e informação de licença de condutor.
3. 4. Método (10) de acordo com a reivindicação 1, em que a segunda informação compreende pelo menos uma informação de cartão de crédito, informação de hipoteca, outra informação de empréstimo e informação de pagamento mensal.
4. 5 - Processo (10) de acordo com a reivindicação 1, caracterizado por a consulta interactiva compreender uma pergunta que solicita ao utilizador o nome de um credor e uma quantidade de pagamento correcta, em que existem respostas de escolha múltipla para cada nome do credor e o montante de pagamento correcto, Apenas um dos quais está correto. Processo (10) de acordo com a reivindicação 1, caracterizado por o segundo tipo de informação compreender informações relativas a contas de crédito às quais o utilizador é uma parte, a informação relativa a contas de crédito compreende informação de empréstimo hipotecário, em que o utilizador é solicitado a identificar em Pelo menos um de: I) informações sobre credores hipotecários; e li) informações sobre o montante do empréstimo hipotecário.
5. 7 - Processo (10) de acordo com a reivindicação 1, caracterizado por a realização do primeiro passo de autenticação compreender ainda: I) obter (14, 16) o primeiro tipo de informação do utilizador; li) recuperar (24) informação de identificação de utilizador a partir de uma fonte de dados; Iii) comparação (52) do primeiro tipo de informação fornecida pelo utilizador com as informações de identificação do utilizador Recuperados da fonte de dados; e Iv) determinar (56) um nivel de correspondência entre o primeiro tipo de informação fornecido pelo utilizador e a informação de identificação de utilizador recuperada da fonte de dados; E em que a fonte de dados para o primeiro tipo de informação é utilizada para identificar a disponibilidade do segundo tipo de informação para o utilizador. Processo (10) de acordo com a reivindicação 1, compreendendo ainda: Executar um processo de reconhecimento de padrões para detectar irregularidades potenciais em pelo menos um do primeiro tipo de informação e do segundo tipo de informação.
6. 9.- Processo (10) de acordo com a reivindicação 1, compreendendo ainda: Executar uma etapa de autenticação remota (1004) com base em pelo menos um do primeiro tipo de informação e do segundo tipo de informação. - Processo (10) de acordo com a reivindicação 1 ou 9, compreendendo ainda: Executar uma autenticação offline (1010) com base em pelo menos um do primeiro tipo de informação e do segundo tipo de informação.
7. 11. Processo (10) de acordo com a reivindicação 10, em que o passo de realização da autenticação offline (1010) compreende a filtragem através de um filtro de capacidade de correio (1012) pelo menos um do primeiro tipo de informação e do segundo tipo de informação.
8. 12. Um sistema (110, 120, 130, 152) para autenticar um utilizador numa rede, compreendendo o referido sistema: Uma interface de entrada (110) para receber entrada do utilizador; E um processador (120, 152), ligado à interface de entrada (110) e configurado para: Executar um primeiro passo de autenticação (32) com base num primeiro tipo de informação; E executar pelo menos um segundo passo de autenticação (40) com base num segundo tipo de informação diferente do primeiro tipo de informação, caracterizado por: o processador (120, 152) estar configurado para armazenar um registo de transacção (112) do primeiro passo de autenticação (32); Em que o processador gera uma consulta interactiva, compreendendo a consulta interactiva pelo menos uma pergunta com respostas de escolha múltipla em que nem todas as respostas são respostas correctas.
9. 13. Sistema (110, 120, 130, 152) de acordo com a reivindicação 12, em que a rede compreende a Internet.
10. 14. Sistema (110, 120, 130, 152) da reivindicação 12, em que a primeira informação compreende pelo menos uma informação de nome, informação de endereço, informação de número de segurança social, informação de número de telefone e informação de licença de condutor.
11. 15. Sistema (110, 120, 130, 152) de acordo com a reivindicação 12, em que a segunda informação compreende pelo menos uma informação de cartão de crédito, informação de hipoteca, outra informação de empréstimo e informação de pagamento mensal.
12. 16. Sistema (110, 120, 130, 152) de acordo com a reivindicação 12, em que a consulta interactiva compreende uma pergunta que pergunta ao utilizador o nome de um credor e uma quantidade de pagamento correcta, em que existem respostas de escolha múltipla para cada um do nome do credor E o valor de pagamento correto, apenas um dos quais está correto.
13. 17. Sistema (110, 120, 130, 152) da reivindicação 12, em que o primeiro tipo de informação compreende informação de tipo carteira E o segundo tipo de informação compreende informação do tipo não carteira relativa a contas de crédito à qual o Usuário é uma festa.
14. 18. Sistema (110, 120, 130, 152) de acordo com a reivindicação 17, em que o segundo tipo de informação compreende ainda empréstimo hipotecário em formação; E em que o segundo passo de autenticação compreende ainda um pedido para o utilizador identificar pelo menos uma das seguintes: informação de credor hipotecário; E informação do montante do empréstimo hipotecário.
15. 19. Sistema (110, 120, 130, 152) de acordo com a reivindicação 12, em que o primeiro passo de autenticação compreende ainda: I) obter (14, 16) o primeiro tipo de informação do utilizador; Ii) recuperar (24) informação de identificação de utilizador a partir de uma fonte de dados; Iii) comparação (52) do primeiro tipo de informação fornecida pelo utilizador com a informação de identificação de utilizador recuperada da fonte de dados; e Iv) determinar (52) um nível de correspondência entre o primeiro tipo de informação fornecido pelo utilizador e a informação de identificação de utilizador recuperada da fonte de dados; E em que a informação de identificação de utilizador recuperada da fonte de dados é utilizada para identificar a disponibilidade do segundo tipo de informação para o utilizador.
16. 20. Sistema (110, 120, 130, 152) de acordo com a reivindicação 12, em que o processador executa um processo de reconhecimento de padrões para detectar irregularidades potenciais na entrada fornecida pelo utilizador.
17. 21. Sistema (110, 120, 130, 152) de acordo com a reivindicação 12, em que o processador executa um passo de autenticação remota baseado em pelo menos um do primeiro tipo de informação e do segundo tipo de informação.
18. 22. Sistema (110, 120, 130, 152) de acordo com a reivindicação 12 ou 21, em que o processador executa uma autenticação offline baseada em pelo menos um do primeiro tipo de informação e do segundo tipo de informação.
19. 23. Sistema (110, 120, 130, 152) de acordo com a reivindicação 22, em que a autenticação offline compreende a aplicação de um filtro de capacidade de correio (1012) ao pelo menos um do primeiro tipo de informação e do segundo tipo de informação. Lisboa, 17 de Abril de 2017