BR112016003819B1

BR112016003819B1 - Método para autenticar e autorizar uma transação envolvendo um provedor de terminal de um produto ou um serviço

Info

Publication number: BR112016003819B1
Application number: BR112016003819-3A
Authority: BR
Inventors: Yuexi CHEN
Original assignee: Gemalto S.A
Priority date: 2013-08-30
Filing date: 2014-09-01
Publication date: 2022-11-16
Also published as: US20160203468A1; BR112016003819A2; SG11201600918PA; WO2015028664A1; EP2843605A1; CN105593883A; CN105593883B; JP2016534459A; EP3039627B1; US10579987B2; EP3039627A1; JP6401278B2

Abstract

MÉTODO PARA AUTENTICAR E AUTORIZAR UMA TRANSAÇÃO ENVOLVENDO UM PROVEDOR DE TERMINAL DE UM PRODUTO OU UM SERVIÇO E UM APLICATIVO MÓVEL DE UM DISPOSITIVO MÓVEL DO USUÁRIO. A presente invenção se refere, de modo geral, a sistemas e métodos para autenticar transações através de uma comunicação simplex. Para permitir confiar na transação com um pagamento por um código de imagem, tal como o código de QR, a invenção propõe meios para autenticar a dita transação. Para isto, quando o aplicativo móvel para pagamento for carregado, de preferência, em um elemento de segurança do dispositivo móvel do usuário, um processo de registro é ativado. Durante esse processo de registro em um servidor, uma conta do usuário é criada e um conjunto de números imprevisíveis de quantidade N é gerado. Esse conjunto de números imprevisíveis é transmitido ao aplicativo móvel para pagamento, para armazenamento. O aplicativo para pagamento usa o conjunto armazenado de números imprevisíveis de transação para as próximas N transações realizadas pelo aplicativo móvel para pagamento, para cálculo do criptograma de transação. O mesmo número imprevisível de transação é recuperado no lado do servidor durante o processo de autorização da transação.

Description

CAMPO TÉCNICO

[0001] A invenção se refere a sistemas e a métodos para autenticar transações através de uma comunicação simplex, que ocorre em apenas uma direção. De maneira mais particular, a invenção se refere a sistemas e a métodos para autenticar transações feitas num terminal de ponto de vendas/ serviços ("POS"), que são pagas com um código de imagem de pagamento.

[0002] De maneira mais particular, a invenção se refere a sistemas e a métodos para pagamento com um código de QR exibido num dispositivo móvel de pagamento em um terminal comercial.

FUNDAMENTOS DA TÉCNICA

[0003] Cartões de pagamento bem conhecidos são usados por milhões de pessoas em todo o mundo para facilitar vários tipos de transações comerciais. Em uma transação normal envolvendo a compra de um produto ou serviço em um estabelecimento comercial, o cartão de pagamento é apresentado em um terminal de ponto de venda ("terminal de POS"), localizado em um estabelecimento comercial. O terminal de POS pode ser um leitor de cartões ou dispositivo semelhante, que seja capaz de acessar dados armazenados no cartão de pagamento, onde esses dados incluem dados de identificação e autenticação. Os dados lidos do cartão de pagamento são fornecidos ao sistema de processamento de transações comerciais e, em seguida, ao adquirente, que normalmente é um banco ou outra instituição que administra a conta do comerciante.

[0004] Para garantir a segurança e a interoperabilidade global de cartões de pagamento baseados em chip, padrões EMV são bem conhecidos, que definem a interação entre cartões de pagamento compatíveis com EMV e terminais de POS compatíveis com EMV. Portanto, para aceitar pagamentos EMV, comerciantes têm de implantar terminais de POS compatíveis com EMV, que suportem protocolos de comunicação em sentido duplo. O hardware de tais terminais de POS compatíveis com EMV, sua implantação e sua manutenção implicam em custos consideráveis para os comerciantes.

[0005] Embora esses instrumentos de pagamento existentes funcionem bem, principalmente devido ao fato de que as operadoras de cartões protegem os clientes, transmitindo as perdas para comerciantes e bancos, é evidente que bancos, comerciantes e clientes desejam um método simples e seguro para realizar transações financeiras.

[0006] Hoje, a tecnologia revolucionou a maneira que os clientes fazem compras e ampliou o leque de canais de varejo. Na verdade, dispositivos móveis, como telefones celulares, desempenham um papel cada vez mais versátil na vida diária. Muitos novos recursos e serviços estão sendo desenvolvidos, em uma tentativa de expandir telefones celulares para além de seu papel tradicional de transmissão de voz e mensagens.

[0007] Mecanismos para usuários executar transações estão evoluindo com a tecnologia atual. Esses mecanismos incluem comunicação por bluetooth, comunicação de curta distância (NFC), digitalização de código de resposta rápida (QR), comunicação por Wi-Fi, e similares.

[0008] No caso, em que a experiência de pagamento é automatizada por uma instalação de comunicação de curta distância (NFC), a instalação deve ter um terminal de pagamento compatível com NFC, o que é inconveniente para a instalação por causa das despesas do hardware, software e suporte associadas com o fato de ter dispositivos habilitados para NFC no local. Além disso, para que o cliente utilize o mecanismo NFC, o smartphone do cliente precisa ter informações sensíveis nele armazenadas, tais como: números de cartão de crédito, números de fidelidade e assim por diante. Mesmo o melhor software ainda está sujeito a potenciais invasões e concessões, se o smartphone for adquirido ou se uma conexão remota puder ser feita para o smartphone.

[0009] No caso de uma transação, que usa códigos de QR (Resposta Rápida) ou códigos de barras, que concedem uma maneira mais fácil de pagar aos clientes, informações circulam entre três partes da transação: o vendedor (com seu POS), o comprador (com o seu telefone celular), e um servidor do sistema de pagamento (banco ou semelhante). O vendedor, quando ele precisa realizar uma transação para vender um ou mais produtos, solicita um código de barras ou um código de Resposta Rápida (QR) para o POS. O código de barras ou o código de QR é exibido ou impresso e fornecido para o comprador, que o captura através de um dispositivo móvel e envia, por SMS, Wifi, rede, Internet .., para o servidor. O servidor verifica a identidade do comprador. Uma vez que essa identidade é verificada, o servidor envia para o vendedor uma notificação de pagamento realizado, com a qual o vendedor pode fechar a venda e entregar as mercadorias e recibo de compra.

[00010] Este método tem a desvantagem de necessitar o uso do POS e ocupar o servidor com muitas trocas de informações, o que pode ser crítico em alguns períodos do ano, devido à enorme quantidade de transações necessárias.

[00011] No caso de uma transação on-line, uma maioria de sites de comércio eletrônico (e-commerce) e comércio eletrônico móvel (m-commerce) na internet usa métodos de pagamento ad hoc. Por exemplo, se uma pessoa quiser comprar café on-line, essa pessoa precisa registrar e criar uma conta com um comerciante de café online, inserindo suas informações pessoais e financeiras em websites. Além disso, esse processo para criação de conta deve ser repetido com outros vendedores para outras compras. Esse processo é inconveniente para todas as partes envolvidas. O comerciante deve manter um sistema dedicado de pagamento e gestão de contas. O cliente deve criar contas separadas com vários estabelecimentos, além de lembrar as informações sobre nome de usuário e senha para o site de cada estabelecimento. Com esse sistema de pagamento, quando o consumidor estiver disposto a pagar, o terminal/ sistema de POS pode imprimir ou exibir um código de barras bidimensional (2D) ou código de Resposta Rápida (QR), juntamente com os detalhes da transação. O comerciante fornece isso para o consumidor, que digitaliza o código com seu dispositivo móvel. O código de imagem digitalizado é ligado com o telefone móvel do consumidor, que pode então ser direcionado para o pagamento da transação, para a conta do usuário, através do dispositivo móvel.

[00012] Esse sistema de pagamento tem o inconveniente de necessitar do uso de dados de conexão entre a conta do usuário e o dispositivo móvel durante o pagamento, o que pode ser crítico, quando os dados de conexão não estiverem disponíveis durante o pagamento.

[00013] Um problema com a variedade de mecanismos existentes usados para interagir com clientes é que muitas vezes os clientes são obrigados a estabelecer uma conexão, antes de uma transação poder ser concluída. Isso representa um risco de segurança, que alguns clientes não querem correr, e também retarda a transação.

[00014] Além disso, o pagamento com código de QR não é compatível com protocolos de transação EMV, porque ele não é uma comunicação duplex. Portanto, não é possível fazer um tipo de transação EMV que permita autenticar as transações usando apenas um código de QR.

[00015] À medida que recursos de computação móvel e desenvolvimento de infraestrutura robusta de rede sem fio se unem, fica claro que existe um desejo crescente para sistemas de pagamento com código de imagem mais rápidos, baratos, seguros e mais convenientes para realizar transações financeiras, que possam ser compatíveis com protocolos padrão, tais como padrão EMV.

[00016] Como resultado, existe uma grande necessidade de realizar transações financeiras entre indivíduos, sem ter que depender da conexão de dados móveis ou suporte a comunicação duplex, como NFC, enquanto sendo capaz de autenticar a transação.

SUMARIO DA INVENÇÃO

[00017] A presente invenção resolve os anteriormente mencionados inconvenientes de segurança da autenticação de uma transação numa comunicação unilateral versus uma comunicação dupla tradicional e segura (transações com EMV).

[00018] A presente invenção se refere a um sistema e a um método para autenticar uma transação entre um aplicativo móvel para pagamento em um dispositivo móvel e um operador comercial, por meio de uma comunicação unilateral. Assume-se ainda que essas transações são encaminhadas para o emissor do aplicativo móvel para pagamento, através de um protocolo e canal seguro, que está fora do escopo da presente invenção.

[00019] As técnicas no presente documento fornecem mecanismos, que permitem a um consumidor (cliente ou usuário) pagar por sua transação sem necessitar: um terminal móvel de ponto de venda (POS), um cartão de crédito/ débito a ser entregue ou um tap em comunicação de curta distância (NFC). Em vez disso, um código de imagem de pagamento é usado para pagar a transação. Hoje, código de imagem de pagamento, como pagamento por código de QR ou pagamento por código de barras, é cada vez mais popular no domínio de pagamento móvel, uma vez que ele não requer nenhum outro hardware adicional que não sejam acessórios pessoais comuns já adquiridos pela maioria da população, tais como smartphones, tablets ou dispositivos similares com interfaces de câmera. O pagamento é concluído, quando um scanner de imagem do operador comercial lê o código de imagem de pagamento exibido no dispositivo móvel do usuário.

[00020] Esse tipo de pagamento não requer hardware adicional, que suporte o protocolo de comunicação duplex; ele só precisa de um visor, que geralmente é a tela do telefone celular do consumidor, para exibir o código de QR, e um scanner de código de QR, que pode ser scanner de código de QR da caixa registadora ou uma câmera de telefone celular do operador comercial, para digitalizar o código de QR, que é exibido na tela do telefone celular do consumidor.

[00021] Para aceitar o pagamento de código de QR, o adquirente só precisa integrar uma parte de software na caixa registadora ou telefone celular do operador comercial, sendo o custo quase zero.

[00022] Para permitir confiança à transação com um pagamento por um código de imagem, a presente invenção propõe meios para autenticar a referida transação. Por isso, quando o aplicativo móvel para pagamento for baixado, de preferência, em um elemento de segurança do dispositivo móvel do usuário, um processo de registro é ativado. Durante esse processo de registro com o servidor, uma conta do usuário é criada e um conjunto de números imprevisíveis de transação em quantidade N é gerado. Esse conjunto de números imprevisíveis é transmitido de forma segura para o aplicativo móvel para pagamento e armazenado de forma segura no interior do elemento de segurança. O aplicativo para pagamento utiliza os N números imprevisíveis de transações armazenados para as próximas N vezes de transações realizadas pelo aplicativo móvel para pagamento, de maneira sequencial. O mesmo conjunto de números imprevisíveis é armazenado na base de dados do servidor, e utilizado pelo servidor para as próximas N transações de autenticação, de maneira sequencial. O número imprevisível de transação gerado é usado estritamente uma vez para uma transação.

[00023] Com referência de sequências, o servidor é capaz de autenticar a transação utilizando o algoritmo de autenticação de transação padrão, que envolve número imprevisível de transação e chaves compartilhadas entre aplicativo para pagamento e servidor. O algoritmo de transação padrão pode ser processo de transação EMV, processo de transação Mifare, ou processo de transação Calypso. Esses padrões são bem conhecidos pela pessoa versada na arte e não necessitam ser aqui mais detalhados.

[00024] As formas de realização descritas neste relatório descritivo são dirigidas para o processo de transação EMV, por ser conhecido que ele pode ser adequado a qualquer padrão de transação. Durante um processo de pagamento, o operador comercial mostra o valor a pagar no terminal de verificação. O consumidor inicia o aplicativo móvel para pagamento em seu dispositivo móvel. O titular do cartão insere o valor da transação em seu dispositivo móvel. O aplicativo móvel para pagamento seleciona o primeiro número imprevisível de transação não utilizado e elabora um pedido de autorização EMV padrão. Esse pedido de autorização compreende um valor de transação inserido pelo consumidor, um criptograma de transação gerado usando uma chave EMV, a partir de uma lista de dados de transação, que inclui o valor da transação, número imprevisível de transação e outros dados financeiros relacionados. Uma vez que o pedido de autorização é gerado, o número imprevisível de transação atualmente usado é marcado como usado no elemento de segurança. O aplicativo móvel para pagamento gera um código de imagem de pagamento, que compreende o pedido de autorização. O referido código de imagem de pagamento pode ser um código de QR. O operador comercial digitaliza o código de QR exibido no dispositivo móvel do consumidor.

[00025] O operador comercial envia o pedido de autorização decodificado do código de QR digitalizado para o servidor. O servidor verifica o pedido de autorização recebido. A partir do conteúdo do pedido de autorização recebido, o servidor recupera o número imprevisível de transação correspondente armazenado na sua base de dados. O número imprevisível de transação recuperado é marcado como usado na base de dados do servidor. O criptograma da transação do pedido de autorização é enviado para o banco do emissor, com o número imprevisível de transação recuperado. O banco do emissor valida o pedido de autorização utilizando o algoritmo EMV padrão, que envolve uma chave EMV e a mesma lista de dados de transação. O operador comercial é finalmente notificado do resultado, a partir do banco do emissor, diretamente ou através do servidor, do pedido de autorização.

[00026] A invenção se baseia em uma transação unidirecional entre o dispositivo móvel e o operador comercial. Com a maneira proposta para autenticar a transação, não é necessário executar uma autenticação mútua entre o aplicativo para pagamento e o emissor para autenticar a transação.

[00027] Aspectos das formas de realização da presente invenção se referem, em geral, a um método para autenticar uma transação com um código de imagem fornecido por um aplicativo móvel para pagamento através de um dispositivo móvel do usuário, caracterizado pelo fato de: - gerar um conjunto de números imprevisíveis de transação para transações futuras com EMV por um servidor, - enviar o conjunto gerado de números imprevisíveis de transação para o aplicativo móvel para pagamento, que se encontra no elemento de segurança do dispositivo móvel do consumidor, - armazenar o conjunto recebido de números imprevisíveis de transação dentro dispositivo móvel do consumidor, - armazenar o mesmo conjunto de números imprevisíveis de transação na base de dados do servidor, - utilizar o número imprevisível de transação armazenado no elemento de segurança em sequência para gerar criptograma EMV de pedido de autorização de transação, - gerar um código de imagem a partir da mensagem do pedido de autorização da transação, - exibir o código de imagem no visor do dispositivo móvel do usuário, - digitalizar o código de imagem, decodificar a mensagem do pedido de autorização e enviar o pedido de autorização decodificado para o servidor, - recuperar o número imprevisível de transação a partir da base de dados do servidor, - encaminhar o pedido de autorização a um banco do emissor com o número imprevisível de transação recuperado para aprovação final do pedido de autorização da transação.

[00028] Aspectos das formas de realização da presente invenção se referem, em particular, a um método para autenticar e autorizar uma transação envolvendo um provedor de terminal de um produto ou de um serviço e a um aplicativo móvel de um dispositivo móvel do usuário, caracterizado pelo fato de: - durante um processo de registro do aplicativo móvel a um servidor: - operar o servidor para gerar um conjunto de números imprevisíveis de transação, - operar o servidor para enviar o referido conjunto gerado de números imprevisíveis de transação para o aplicativo móvel, - durante a autenticação e autorização da transação: - operar o aplicativo móvel para selecionar um número imprevisível de transação não utilizado armazenado, dito número imprevisível de transação não utilizado e selecionado permitindo identificar a referida transação, - operar o aplicativo móvel para elaborar uma mensagem de pedido de autorização da transação a partir do número imprevisível de transação selecionado, - operar o aplicativo móvel para codificar o pedido de autorização em um dado de comunicação simplex, - operar o provedor de terminal para receber e decodificar os dados de comunicação simplex, - operar o provedor de terminal para enviar para o servidor os dados de comunicação simplex decodificados para autenticação e autorização da transação, - operar o servidor para verificar uma concordância de um número imprevisível de transação entre o conteúdo da mensagem do pedido de autorização da transação decodificada e o banco de dados do número imprevisível de transação do servidor, - se a verificação for bem sucedida, operar o servidor para adicionar o número imprevisível de transação coincidente à mensagem do pedido de autorização, - operar o servidor para enviar o pedido de autorização da transação a um emissor, - operar o servidor para receber, do emissor, o resultado de autorização da transação, que indica se tal transação foi, ou não, autenticada e autorizada, - operar o servidor para encaminhar o resultado de autorização da transação para o provedor do terminal.

[00029] Para se obter essas vantagens e outras mais, e em conformidade com a finalidade da invenção, como incorporada e amplamente descrita, a invenção propõe um método para autenticar e autorizar uma transação, que envolve um provedor de um produto ou de um serviço e um aplicativo móvel de um dispositivo móvel do usuário, caracterizado pelo fato de: - gerar um conjunto de números imprevisíveis de transação por um servidor, - enviar o referido conjunto gerado de números imprevisíveis de transação para o aplicativo móvel, - selecionar um número imprevisível de transação não utilizado e armazenado no aplicativo móvel para a identificação da referida transação, - elaborar uma mensagem do pedido de autorização da transação a partir do número imprevisível de transação selecionado, - codificar o pedido de autorização em dados de comunicação simplex, - receber e decodificar os dados de comunicação simplex e enviar, do provedor para o servidor, os dados de comunicação simplex decodificados para autenticação e autorização da transação, - recuperar o número imprevisível de transação no servidor, - adicionar o número imprevisível de transação recuperado ao pedido de autorização, - enviar o pedido de autorização da transação para um emissor através do servidor, - receber o resultado de autorização da transação, a partir do emissor, indicando se tal transação foi, ou não, autenticada e autorizada.

[00030] Em vários outros métodos, para receber os dados de comunicação simplex, um terminal de digitalização do provedor digitaliza o pedido de autorização codificado.

[00031] Em vários outros métodos, os dados de comunicação simplex representam um código de imagem, como um código de QR ou um código de barras, esse código de imagem sendo exibido no dispositivo móvel do usuário para ser digitalizado pelo provedor e enviado ao servidor. Os dados de comunicação simplex também podem ser um som modulado, uma vibração modulada ou uma mensagem de etiqueta NFC.

[00032] Em vários outros métodos, quando o número imprevisível de transação selecionado for adicionado à mensagem de pedido de autorização da transação elaborada, em seguida, o servidor compara o número imprevisível de transação selecionado recebido com o número imprevisível de transação recuperado. Se a comparação for bem sucedida, o servidor adiciona o número imprevisível de transação recuperado ao pedido de autorização e o envia para o emissor.

[00033] Em vários outros métodos, o número imprevisível de transação não utilizado é selecionado, de acordo com uma sequência predeterminada. O número imprevisível de transação é recuperado pelo servidor, de acordo com um identificador único do usuário e com a sequência predeterminada. Em vários outros métodos, o número imprevisível de transação pode ser recuperado pelo servidor a partir do identificador único do usuário, um índice associado ao número imprevisível de transação selecionado, que é adicionado ao pedido de autorização e a sequência predeterminada.

[00034] Em vários outros métodos, o número imprevisível de transação não utilizado é selecionado de forma aleatória, e em que um índice é associado ao referido número imprevisível selecionado da transação, e em que o número imprevisível de transação é recuperado pelo servidor a partir de um identificador único do usuário e do índice associado ao número imprevisível selecionado da transação.

[00035] Em vários outros métodos, o número imprevisível de transação é marcado como utilizado na unidade de armazenamento após a etapa de seleção e a etapa de recuperação. Quando os números imprevisíveis de transação armazenados no aplicativo móvel para pagamento forem todos marcados como usados, em seguida, um novo conjunto de números imprevisíveis de transação é gerado pelo servidor e enviado para o aplicativo móvel para o armazenamento.

[00036] Em vários outros métodos, a transmissão do conjunto gerado de números imprevisíveis de transação a partir do servidor para o aplicativo móvel para pagamento é protegida: - através da aplicação de um algoritmo de criptografia, que envolve chave(s) compartilhada(s) entre o servidor e o aplicativo móvel para pagamento, e/ou - através da aplicação de um algoritmo de criptografia, que envolve chave(s) compartilhada(s) entre o servidor e o aplicativo móvel para pagamento.

[00037] Em vários outros métodos, o aplicativo móvel e o conjunto de números imprevisíveis da transação são armazenados em um elemento de segurança do dispositivo móvel.

[00038] Em vários outros métodos, a transação é uma transação financeira, que está em conformidade com o padrão de transação EMV, padrão de transação Mifare ou padrão de transação Calypso.

[00039] O método da presente invenção tem muitas vantagens tecnológicas, entre elas: - nenhum impacto na infraestrutura EMV existente, - alto nível de segurança através da utilização de aplicativos móveis para pagamento armazenados no elemento de segurança, - nenhuma necessidade da instalação de POS NFC, - redução do custo de instalação e manutenção para rede de pagamento, - um número cada vez maior de operadores comerciais já está equipado com scanner de código de QR e o custo do scanner de código de QR é muito menor que o custo do POS NFC, - não há necessidade de dados móveis durante o pagamento e não depende de dados móveis para pagamento, - rapidez do processo de pagamento por parte do consumidor, - o consumidor tem mais confiança, uma vez que o valor da transação é inserido por ele mesmo, - simplicidade, - design ergonômico e - total independência da infraestrutura EMV.

BREVE DESCRIÇÃO DOS DESENHOS

[00040] A descrição detalhada a seguir será mais bem compreendida com os desenhos, nos quais: a FIG. 1 ilustra as diferentes entidades envolvidas em uma transação com um código de imagem de pagamento, de acordo com uma forma de realização da presente invenção. A FIG. 2 é um fluxograma lógico, de acordo com uma forma de realização exemplar da presente invenção, durante uma fase de registro de um aplicativo para pagamento. A FIG. 3 é um fluxograma de transação, de acordo com uma forma de realização exemplar da presente invenção.

DESCRIÇÃO DETALHADA DAS FORMAS DE REALIZAÇÃO DA INVENÇÃO

[00041] A presente invenção não é específica para qualquer implementação de hardware ou software em particular, e está em um nível conceitual acima das especificidades de implementação. Deve ficar claro que várias outras formas de realização e variações da invenção podem ser produzidas, sem se afastar do espírito ou escopo da invenção. O a seguir é fornecido para ajudar na compreensão da implementação prática de formas de realização particulares da invenção.

[00042] Os mesmos elementos foram designados com os mesmos números de referência nos diferentes desenhos. Para maior clareza, apenas os elementos e etapas, que forem úteis para a compreensão da presente invenção, foram mostrados nos desenhos e serão descritos.

[00043] Além disso, os mecanismos de comunicação de dados entre as partes e seu ambiente também não foram detalhados, sendo a presente invenção aqui novamente compatível com os mecanismos usuais.

[00044] Além disso, as linhas de conexão mostradas nas várias figuras aqui contidas têm a intenção de representar exemplos de relações funcionais e/ou ligações físicas entre os vários elementos. Deve-se notar que muitas conexões físicas ou relações funcionais alternativas ou adicionais podem estar presentes em um sistema prático. Além disso, as várias entidades na FIG. 1 podem se comunicar através de qualquer meio de comunicação adequado (incluindo a Internet), usando qualquer protocolo de comunicação adequado.

[00045] Além disso, quando uma ação é dita como sendo executada por um terminal, ela é de fato executada por um microprocessador nesse terminal controlado por códigos de instruções gravados numa memória de programa no referido terminal. Uma ação também é atribuída a um aplicativo ou software. Isso significa que parte dos códigos de instrução, que constituem o aplicativo ou software, é executada pelo microprocessador.

[00046] A FIG. 1 mostra entidades envolvidas em um fluxograma para gerenciar o aplicativo móvel para pagamento 10 em um dispositivo móvel de comunicação 11. Para simplificar a descrição, apenas uma de cada entidade é mostrada na FIG. 1. Entende-se, no entanto, que formas de realização da tecnologia podem incluir mais do que uma de cada entidade. Além disso, algumas formas de realização da tecnologia podem incluir menos do que todas as entidades mostradas na FIG. 1. A FIG. 1 representa um exemplo do sistema, em que um ambiente de processamento do servidor 12 e um emissor 13 são implementados.

[00047] O dispositivo móvel 11 compreende um elemento de segurança 15. O elemento de segurança 15 no interior do dispositivo móvel 11 é usado para receber e armazenar dados e aplicativos, que exijam um alto grau de segurança. Numa forma de realização preferida, o aplicativo para pagamento 10 é instalado no elemento de segurança 15. O elemento de segurança 15 é fornecido para o dispositivo móvel 11 por um emissor do elemento de segurança. O emissor do elemento de segurança pode não ser necessariamente um membro do processo de pagamento ou a mesma entidade que o emissor 13 do pagamento. Por exemplo, o emissor do elemento de segurança pode ser um operador de rede móvel (MNO) ou o fabricante do dispositivo móvel 11.

[00048] O aplicativo móvel para pagamento 10 é um software ou um aplicativo que fornece recursos de pagamento, que possam ser implementados dentro do elemento de segurança 15, que está dentro do dispositivo móvel 11. O aplicativo móvel para pagamento 10 fornece as funcionalidades para gerenciar informações de pagamento do usuário e gerar assinatura da transação. Durante uma transação de pagamento, o aplicativo móvel para pagamento 10 transmite os dados de pagamento para o servidor 12 através de um operador comercial 14 numa comunicação simplex.

[00049] O aplicativo móvel para pagamento 10 faz interface com um software de interface do usuário no dispositivo móvel 11 para a interação do usuário (por exemplo, para inserir e visualizar informações). O software de interface do usuário também se comunica com o aplicativo móvel para pagamento 10, para exibir informações de transação do pagamento para o operador comercial 14.

[00050] Tal como aqui utilizado, o termo "emissor" engloba qualquer entidade que emite e mantém uma conta financeira (por exemplo, crédito, débito ou pré-pago) e o aplicativo móvel para pagamento 10 associado à conta financeira. De maneira alternativa, o emissor 13 pode não emitir o aplicativo móvel para pagamento 10 diretamente e, em vez disso, pode acordar com outra parte, para emitir o aplicativo móvel para pagamento 10, como o servidor 12. O emissor pode ser um banco.

[00051] O aplicativo móvel para pagamento 10 é carregado no elemento de segurança 15, no interior do dispositivo móvel do usuário 11. O aplicativo móvel para pagamento 10 pode ser previamente carregado na fase de fabricação ou personalização do elemento de segurança 15, antes que o elemento de segurança 15 seja entregue ao usuário. O aplicativo móvel para pagamento 10 também pode ser baixado pelo usuário na fase posterior à emissão do elemento de segurança 15, através de uma rede de comunicação, a partir da base de dados do emissor 13 ou de outras entidades.

[00052] O dispositivo móvel 11 pode estar em qualquer forma adequada para o dispositivo de pagamento de imagem. Por exemplo, dispositivos móveis de comunicação adequados 11 podem ser compactos e portáteis, para que eles possam caber em uma carteira e/ou bolso de um usuário (por exemplo, tamanho de bolso). O dispositivo móvel 11 normalmente compreende um processador, uma memória, dispositivo de entrada, dispositivos de saída, e dispositivos geradores de código de imagem, onde todos são operacionalmente acoplados ao processador. Exemplos específicos de dispositivos móveis de comunicação 11 podem incluir telefones celulares ou sem fio, tablets, smartphones, assistentes pessoais digitais (PDAs), computadores portáteis, e semelhantes. Embora um dispositivo móvel de comunicação 11 seja referido no presente pedido, formas de realização da presente invenção podem ser implementadas com um número de diferentes dispositivos móveis de usuário, capazes de se comunicar com as entidades aqui descritas e gerar códigos de imagem.

[00053] De acordo com uma forma de realização, o código de imagem de pagamento pode ser um código de resposta rápida (QR), qualquer outro tipo de código, ou qualquer combinação formada de tipos de códigos dos mesmos, ou a eles associada.

[00054] O ambiente de processamento do servidor 12 pode ser um computador servidor ou uma série de computadores servidores, que são configurados para se comunicarem com o operador comercial 14. O servidor 12 se comunica com o emissor 13. O servidor 12 pode ser implementado por emissores, adquirentes, fornecedores de serviços de terceiros, ou gerenciadores de serviços confiáveis. O servidor 12 pode ser utilizado para facilitar a autenticação da transação através do código de imagem de pagamento 17. Por exemplo, o servidor 12 pode receber uma comunicação a partir do operador comercial 14, que é indicativa do conteúdo de código de imagem de pagamento 17 e pode facilitar uma transação de compra em resposta à comunicação.

[00055] O operador comercial 14 pode ser implementado, usando, por exemplo, um ou mais servidores. De maneira específica, o operador comercial pode ser atendido por um servidor e uma base de dados que são gerenciados por um provedor. O operador comercial 14 pode representar um terminal de verificação do operador comercial, um dispositivo móvel, um computador, e/ou um servidor, por exemplo. O operador comercial 14 pode ser usado pelo usuário, para fazer uma compra com o código de imagem de pagamento. O operador comercial 14 contém um scanner 16. O scanner 16 pode ser um scanner de código de QR, um scanner de código de barras, um scanner de SKU, uma câmera controlada por software de reconhecimento de imagem ou qualquer outro tipo de scanner de código de imagem. O scanner 16 pode ser utilizado para digitalizar o código de imagem de pagamento 17.

[00056] A comunicação segura bem conhecida pode ser estabelecida entre o operador comercial 14, o emissor 13 e o servidor 12. Essa comunicação segura pode ser estabelecida com um canal de camada de soquetes segura (SSL) autenticado de forma mútua. Essa comunicação segura pode usar padrões de criptografia de dados, como, por exemplo, RSA com uma chave de pelo menos 1024 bits, padrão de criptografia de dados triplo (DES), padrão de criptografia avançado (AES) de 128 bits, um algoritmo de criptografia de fluxo RC4, utilizando um comprimento de chave mínimo de 128 bits etc.. Esses padrões de criptografia podem ser utilizados para criar a sessão segura. Qualquer outra forma adequada de comunicação segura entre essas entidades pode ser implementada, conforme reconhecida por uma pessoa versada na técnica.

[00057] Após o aplicativo móvel para pagamento 10 ser carregado no elemento de segurança 15 do dispositivo móvel 11, o usuário pode iniciar um processo de registro e criar uma conta de usuário no servidor 12.

[00058] A FIG. 2 ilustra um exemplo de fluxograma para registrar o aplicativo móvel para pagamento 10 no servidor 12. Aqui, o fluxo do processo entre o elemento de segurança 15 e o servidor 12 é representado com setas rotuladas, nas quais respectivos números são atribuídos. O fluxo é entendido como sendo realizado de forma sequencial, de cima para baixo, como indicado pelos números crescentes. No entanto, deve-se notar que pode haver várias instâncias desse protocolo executadas em paralelo, sem ordem específica.

[00059] A FIG. 2 é um fluxograma, que descreve um conjunto de funções 20, que podem ser executadas de acordo com uma forma de realização exemplar. O conjunto de funções 20 pode ser realizado para registar o aplicativo móvel para pagamento do usuário 10 no servidor 12. O conjunto de funções 20 é mostrado dentro das etapas 21 a 32. Uma descrição dessas etapas é mostrada a seguir.

[00060] Na etapa 21, o aplicativo móvel para pagamento 10 apresenta um ícone de registro (não mostrado) no dispositivo móvel 11, que o usuário pode ativar, a fim de iniciar um processo de registro. O ícone de registro pode incluir o texto "Registrar" ou algum outro texto ou símbolo.

[00061] Na etapa 22, o aplicativo móvel para pagamento 10 exibe um campo de entrada de forma livre no dispositivo móvel do usuário 11, no qual o usuário é solicitado a inserir o identificador do usuário. Esse identificador do usuário pode ser um Número de Rede Digital com Integração de Serviços de Terminal Móvel ('MSISDN', o número de telefone celular do usuário), um número de conta primária ("PAN") de uma conta de pagamento, ou um Número Identificador Nacional. O identificador do usuário também pode ser algum outro identificador único do usuário. Numa outra forma de realização, o identificador de usuário também pode ser obtido automaticamente a partir do aplicativo móvel para pagamento 10, do elemento de segurança 15 ou do dispositivo móvel do usuário 11.

[00062] O aplicativo móvel para pagamento 10 transmite, através do dispositivo móvel, o identificador único do usuário para o servidor 12, na etapa 23. O servidor 12, na etapa 24, realiza uma pesquisa para verificar se uma conta de usuário associada ao identificador único do usuário já existe na sua base de dados. Se essa conta de usuário não existir, o servidor 12 pode responder para o dispositivo móvel do usuário 11 com, por exemplo, um SMS contendo um código PIN uma única vez, na etapa 25. Na etapa 26, o usuário pode, em seguida, inserir o código PIN em um campo correspondente exibido no dispositivo móvel do usuário 11, através do aplicativo móvel para pagamento 10. Na etapa 27, o dispositivo móvel 11 retorna o código PIN inserido pelo usuário para o servidor 12, que valida o PIN devolvido, na etapa 28. Se a validação do PIN for bem sucedida, a nuvem 12, na etapa 29, cria uma conta de usuário na sua base de dados e pode notificar o aplicativo móvel para pagamento 10, que o registro foi bem sucedido. Para fins dessa descrição, o código PIN não precisa ser inteiramente numérico, embora ele possa ser inteiramente numérico. Um código PIN, que não for inteiramente numérico, pode ser um código PIN alfanumérico.

[00063] Em outra forma de realização, se a conta de usuário não existir, na etapa 24, o servidor de nuvem 12 pula para a etapa 29 e cria uma conta de usuário na sua base de dados, sem o pedido de uma inserção de PIN.

[00064] Numa forma de realização, o aplicativo móvel para pagamento 10 pode criar um perfil de usuário no servidor 12, para que ele solicite que o usuário insira os atributos do usuário, como o primeiro nome do usuário, o último nome do usuário, data de nascimento, um endereço de e-mail, um endereço físico, identificação do emissor 13, O dispositivo móvel passa os dados para o servidor 12, que armazena essas informações na conta de usuário recém criada em sua base de dados.

[00065] Quando a conta do usuário for criada, o servidor 12 gera, na etapa 30, um conjunto de números imprevisíveis de transação em N quantidades, de maneira sequencial. Esses números imprevisíveis de transação podem ser em conformidade com formato e qualidade do número imprevisível de transação EMV.

[00066] O servidor 12 gera uma mensagem, que pode compreender um valor de código de autenticação de mensagem ("MAC") e dados criptografados. O dado criptografado é o resultado da criptografia do conjunto de números imprevisíveis de transação gerados com uma chave de criptografia de sessão ENC compartilhada com o elemento de segurança 15. O valor MAC é o resultado de uma operação MAC em, pelo menos, uma parte sobre o conteúdo da mensagem. A operação MAC utiliza uma chave de sessão MAC compartilhada com o elemento de segurança 15 e um algoritmo de verificação de soma criptográfico para produzir o valor MAC, que mais tarde pode ser utilizado para assegurar que os dados não foram modificados.

[00067] Essas chaves de sessão são utilizadas para proteger a confidencialidade e integridade das mensagens trocadas entre o aplicativo móvel para pagamento 10 e o servidor 12.

[00068] Na etapa 31, o servidor 12 pode enviar, para o elemento de segurança 15, a mensagem que compreende os dados criptografados e o valor MAC. O aplicativo móvel para pagamento 10 calcula um valor MAC. O valor MAC computado é comparado com o valor MAC recebido, para verificar se a mensagem recebida foi alterada. Numa forma de realização, se a verificação do valor MAC falhar, o fluxo do processo pode ser interrompido e o aplicativo móvel para pagamento pode notificar o servidor 12, que o valor MAC está adulterado. Se o valor MAC for verificado com êxito, o elemento de segurança 15 pode descriptografar os dados criptografados com a chave de sessão ENC compartilhada.

[00069] Em formas de realização, o conjunto de números imprevisíveis de transação gerados pelo servidor 12, na etapa 30, pode ser enviado para o aplicativo móvel para pagamento 10 de forma clara, sem criptografia e MAC, de forma clara com MAC, ou em mensagem criptografada sem MAC.

[00070] O conjunto descriptografado de números imprevisíveis de transação gerados é, de preferência, armazenado na memória do elemento de segurança, que não é acessível por uma parte externa.

[00071] A FIG. 3 ilustra um exemplo de um fluxograma de transação 40 numa forma de realização. Durante uma compra em um estabelecimento comercial, o fluxo da transação é iniciado com uma ação do usuário. Na verdade, o fluxo de transação 40 é ativado pelo usuário através da interação com o aplicativo móvel para pagamento 10, devido, por exemplo, a um clique sobre o ícone do referido aplicativo móvel para pagamento exibido no dispositivo móvel 11.

[00072] Na etapa 41, o usuário pode, em seguida, inserir um valor da transação de compra em um campo correspondente exibido no dispositivo móvel do usuário. Na etapa 42, o dispositivo móvel 11 envia o valor da transação inserido pelo usuário para o aplicativo móvel para pagamento 10 no formato, que está em conformidade com o padrão EMV.

[00073] Quando o valor for recebido, o aplicativo móvel para pagamento 10 verifica se o número imprevisível de transação não utilizado, que foi gerado pelo servidor 12 nas etapas anteriores 30-32, permanece na etapa 43. Se não houver nenhum número imprevisível de transação não utilizado restante no aplicativo móvel para pagamento 10 no elemento de segurança 15, então, um comando é enviado na etapa 44, para o servidor 12 gerar outro conjunto de números imprevisíveis de transação. As etapas 30 a 32 da Fig. 2 são realizadas novamente, quando o servidor 12 receber esse comando de geração. Se houver número(s) imprevisível(is) de transação não utilizado(s) restante(s) no aplicativo móvel para pagamento 10 no elemento de segurança 15, o aplicativo móvel para pagamento 10 seleciona um número imprevisível de transação não utilizado. Numa forma de realização, número imprevisível de transação não utilizado é selecionado, de acordo com uma sequência predeterminada, na etapa 45. Quando utilizado, o referido número imprevisível de transação é marcado, como selecionado.

[00074] Numa outra forma de realização, o aplicativo móvel para pagamento 10 seleciona, de forma aleatória, um número imprevisível de transação não utilizado, em vez de usar uma sequência predeterminada. Numa forma de realização, um índice pode ser associado ao número de transação imprevisível selecionado. Nesse caso, o índice é acrescentado no pedido de autorização. Numa forma de realização preferida, na etapa 46, o aplicativo móvel para pagamento executa um processo de transação EMV.

[00075] No fim desse processo, uma mensagem de resposta, em conformidade com o formato EMV, é gerada pelo aplicativo móvel para pagamento 10. Essa mensagem de resposta compreende um criptograma de transação. Essa mensagem é gerada, utilizando o valor da transação inserido pelo usuário na etapa 41 e número imprevisível de transação selecionado na etapa 45, envolvendo várias chaves e elementos de dados, que são definidos no padrão EMV. Numa forma de realização, a mensagem de resposta é transmitida para o dispositivo móvel do usuário na etapa 47. O dispositivo móvel do usuário, em seguida, codifica a mensagem de resposta em um formato de código de imagem e exibe o referido código de imagem codificado 17 no dispositivo móvel, na etapa 48. Numa outra forma de realização, o aplicativo móvel para pagamento 10 codifica a mensagem de resposta em um código de imagem. O código de imagem transmitido para o dispositivo móvel do usuário é exibido.

[00076] O código de imagem pode ser um código de resposta rápida (QR). O código pode ser um código de barras, ou qualquer outro tipo de imagem de código. O código pode ser lido ou digitalizado através de um dispositivo móvel. Na etapa 49, o código é digitalizado pelo scanner do operador comercial 16 a partir da tela do dispositivo móvel.

[00077] Tal como aqui utilizado, o termo "digitalizar" pode se referir a qualquer processo para determinar um código ou outra informação, tal como do código de imagem.

[00078] O código digitalizado é comunicado ao operador comercial 14 através do scanner 16. O operador comercial 14, em seguida, decodifica o código digitalizado, na etapa 50, para recuperar as informações por ele contidas. O operador comercial pode adicionar, à mensagem de resposta, o código de identificação do operador comercial e um endereço de repositório.

[00079] O operador comercial 14, na etapa 51, transmite a mensagem de resposta para o servidor 12, para autenticar e autorizar a transação.

[00080] Na etapa 52, o servidor 12 primeiro extrai o identificador de usuário a partir da mensagem de resposta. Desse identificador de usuário extraído, o servidor recupera o número imprevisível de transação utilizado para essa transação, a partir de sua base de dados, de acordo com a forma de sequência predeterminada. O servidor 12 marca o número imprevisível de transação recuperado, como utilizado na sua base de dados. O servidor 12, então, faz um pedido de autorização EMV compreendendo o criptograma de transação da mensagem de resposta e no qual o número imprevisível de transação recuperado é adicionado.

[00081] Na etapa 53, o servidor 12 envia o pedido de autorização para o emissor 13. O emissor 13, na etapa 54, verifica o conteúdo do pedido de autorização, de acordo com os procedimentos definidos no padrão EMV, usando o valor inserido pelo usuário na etapa 41 e número imprevisível de transação recuperado pelo servidor 12 na etapa 52, juntamente com outros elementos de dados extraídos a partir do pedido de autorização, envolvendo várias chaves e elementos de dados, que são definidos no padrão EMV.

[00082] O emissor 13 produz uma resposta ao pedido de autorização recebido, de acordo com os dados financeiros do usuário, na etapa 55, quando a verificação na etapa 54 for bem sucedida. Essa resposta pode ser um código de resultado de transação, aceitar ou recusar a transação, um criptograma da resposta de autorização

[00083] Na etapa 56, o emissor 13 envia a resposta para o servidor 12. O servidor 12, na etapa 57, recebe a resposta da transação. O servidor 12 encaminha, para o operador comercial 14, o código de resultado da transação extraído a partir da resposta, na etapa 58. O operador comercial 14 recebe o resultado de autorização da transação, na etapa 59.

[00084] A invenção é simples e fácil de implementar, e não exige hardware adicional por parte do operador comercial. Ao aplicar a criptografia EMV, fraude e roubo podem ser eliminados, devido ao desvio do código de imagem. Ao armazenar um conjunto de números imprevisíveis de transação no interior do aplicativo móvel para pagamento 10 no elemento de segurança 15, a exigência de comunicação duplex para a transação EMV é removida.

[00085] Em outra forma de realização, na etapa 46 da FIG. 3, no fim do processo de transação EMV, a mensagem de resposta gerada pelo aplicativo móvel para pagamento 10 compreende também o número imprevisível de transação selecionado na etapa 45. Na etapa 52, o servidor 12 extrai o identificador de usuário a partir da mensagem de resposta. Desse identificador de usuário extraído, o servidor 12 recupera o número imprevisível de transação utilizado para essa transação, a partir de sua base de dados, de acordo com a forma de sequência predeterminada. O servidor 12 marca o número imprevisível de transação recuperado, como utilizado na sua base de dados. O servidor 12 compara o número imprevisível de transação na mensagem de resposta com o número imprevisível de transação recuperado da sua base de dados. Com essa verificação, o servidor 12 é capaz de identificar, se o pedido de autorização é, ou não, de um verdadeiro aplicativo móvel para pagamento 10 e de um verdadeiro elemento de segurança 15. Se o número imprevisível de transação for verificado com sucesso, o servidor 12, então, faz, na etapa 52, o pedido de autorização EMV compreendendo o criptograma de transação da mensagem de resposta e no qual o número imprevisível de transação recuperado é adicionado. Se, por outro lado, a verificação do número imprevisível de transação falhar, o fluxo do processo pode ser interrompido e o servidor pode notificar o aplicativo móvel para pagamento, de que o número imprevisível de transação está adulterado.

[00086] Em outra forma de realização, na etapa 46, um índice da transação escolhida pode ser adicionado à mensagem de resposta. Em seguida, na etapa 52, o servidor 12 pode recuperar o número imprevisível de transação utilizado para essa transação, a partir de sua base de dados, através do índice mostrado na mensagem de resposta, em vez de utilizar uma forma de sequência predeterminada.

[00087] Em outra forma de realização, na etapa 45, o número imprevisível de transação não utilizado é escolhido, de maneira aleatória, em vez de usar uma sequência predeterminada. Neste caso, para facilitar, a recuperação de um índice é associada ao referido número imprevisível de transação não utilizado, selecionado. Na etapa 46 da FIG. 3, no fim do processo de transação EMV, a mensagem de resposta gerada pelo aplicativo móvel para pagamento 10 compreende o índice associado. Na etapa 52, o servidor 12 extrai o identificador de usuário a partir da mensagem de resposta. A partir desse identificador do usuário extraído e dos índices associados, o servidor 12 recupera o número imprevisível de transação usado para essa transação, a partir de sua base de dados. O servidor 12 faz, na etapa 52, o pedido de autorização EMV compreendendo o criptograma de transação da mensagem de resposta e no qual o número imprevisível de transação recuperado é adicionado.

[00088] Em outra forma de realização, na etapa 45, o número imprevisível de transação não utilizado, associado a um índice, é selecionado de maneira aleatória. Na etapa 46 da FIG. 3, no fim do processo de transação EMV, a mensagem de resposta gerada pelo aplicativo móvel para pagamento 10 compreende o número imprevisível de transação com o seu índice. Na etapa 52, o servidor 12 extrai o identificador de usuário a partir da mensagem de resposta. A partir desse identificador de usuário e do índice recebido, o servidor 12 recupera o número imprevisível de transação utilizado para essa transação, a partir de sua base de dados.

[00089] O servidor 12 compara o número imprevisível de transação na mensagem de resposta com o número imprevisível de transação recuperado a partir de sua base de dados. Se o número imprevisível de transação for verificado com sucesso, o servidor 12, então, faz, na etapa 52, o pedido de autorização EMV compreendendo o criptograma de transação da mensagem de resposta e no qual o número imprevisível de transação recuperado é adicionado. Se, por outro lado, a verificação do número imprevisível de transação falhar, o fluxo do processo pode ser interrompido e o servidor pode notificar o aplicativo móvel para pagamento, de que o número imprevisível de transação está adulterado.

[00090] Em outra forma de realização, outro método de comunicação simplex pode substituir os processos de codificação, exibição, digitalização e decodificação do código de imagem, da etapa 48 até a etapa 50, para transmitir a mensagem de resposta de transação do aplicativo móvel para pagamento 10 para o operador comercial 14, através do dispositivo móvel do usuário 11. O método de comunicação simplex pode ser um som modulado, uma vibração modulada, uma mensagem de etiqueta NFC, que sejam suportados pelo dispositivo móvel do usuário.

[00091] A expressão "transação" pode ser usada em seu sentido mais amplo. Ou seja, ela não pode ser limitada à transação financeira, como aqui descrita, mas também pode cobrir qualquer transação para acessar um serviço de um prestador de serviços, e qualquer transação que ocorra através de uma comunicação simplex.

Claims

1. MÉTODO PARA AUTENTICAR E AUTORIZAR UMA TRANSAÇÃO ENVOLVENDO UM PROVEDOR DE TERMINAL DE UM PRODUTO OU UM SERVIÇO E UM APLICATIVO MÓVEL DE UM DISPOSITIVO MÓVEL DO USUÁRIO, caracterizado pelo fato de: - operar o servidor de autenticação para gerar um conjunto de números imprevisíveis de transação, - operar o dispositivo móvel para receber e armazenar o conjunto gerado de números imprevisíveis de transação gerados, durante a autenticação e autorização da transação; - operar o aplicativo móvel para selecionar um número imprevisível de transação não utilizado e armazenado, dito número imprevisível de transação não utilizado e selecionado permitindo identificar a referida transação, - o aplicativo móvel elabora uma requisição de autorização a partir de um algoritmo de autenticação de transação padrão, referida requisição de autorização compreendendo um criptograma computado de acordo com o algoritmo de autenticação de transação padrão a partir de pelo menos o número imprevisível de transação selecionado associado à transação, chaves padrão e uma lista de dados de transação definidos pelo algoritmo de autenticação de transação padrão, e no qual um identificador único do usuário é adicionado ao requerimento de autorização, - operar o aplicativo móvel para codificar o pedido de autorização em código de pagamento de imagem, referido código de pagamento de imagem sendo enviado a partir do aplicativo móvel para o terminal de um provedor por pagamento, - referido terminal de um provedor compreendendo meios configurados para decodificar o código de pagamento de imagem recebido e para enviar a requisição de autorização decodificada ao servidor para autenticação, - operar o servidor de autenticação para extrair o identificador único do usuário adicionado à requisição de autorização e para recuperar um número imprevisível de transação previamente armazenado na base de dados do servidor baseada no identificador único extraído do usuário e a sequência prédeterminada, - operar o servidor de autenticação para enviar a um emissor para autorização da transação do número imprevisível de transação recuperado e o criptograma do requerimento de autorização, referido emissor autorizando a transação mediante verificar o conteúdo do requerimento de autorização de acordo com procedimentos definidos em um algoritmo de autenticação de transação padrão mediante usar o número imprevisível de transação recuperado recebido, e no qual o terminal de um provedor ser notificado pelo emissor de um resultado indicando se referida transação é ou não autenticada e autorizada.

2. MÉTODO, de acordo com a reivindicação 1, caracterizado pelo fato de o algoritmo de autenticação de transação padrão ser um processo de transação EMV, um processo de transação Mifare, ou um processo de transação Calypso.

3. MÉTODO, de acordo com qualquer uma das reivindicações 1 e 2, caracterizado pelo fato de a requisição de autorização compreender o número imprevisível de transação selecionado pelo aplicativo móvel: - a partir do conteúdo da requisição de autorização decodificada, o servidor recupera o número imprevisível de transação a partir de um conjunto de números imprevisíveis de transação previamente armazenados em sua base de dados; - o número imprevisível de transação recuperado é comparado ao número imprevisível de transação selecionado recebido na requisição de autorização decodificada; - se a comparação for bem sucedida, o servidor adiciona o número imprevisível de transação recuperado ao criptograma e envia isso ao emissor para autorização da transação.

4. MÉTODO, de acordo com qualquer uma das reivindicações 1 a 3, caracterizado pelo fato de o código de imagem de pagamento ser um código de imagem tal como um código de QR ou um código de barras, esse código de imagem sendo exibido no dispositivo móvel do usuário, para ser digitalizado pelo terminal de um provedor e enviado para o servidor de autenticação.

5. MÉTODO, de acordo com qualquer uma das reivindicações 1 a 4, caracterizado pelo fato de o número imprevisível de transação não utilizado ser selecionado de acordo com uma sequência pré-determinada e na qual o número imprevisível de transação é recuperado pelo servidor de acordo com um identificador único de do usuário adicionado a requisição de autorização de criptograma e a sequência pré-determinada.

6. MÉTODO, de acordo com qualquer uma das reivindicações 1 a 4, caracterizado pelo fato de, quando a número imprevisível de transação é recuperado pelo servidor a partir do identificador único do usuário, um índice associado ao número imprevisível de transação selecionado que é adicionado a requisição de autorização e a sequência pré-determinada.

7. MÉTODO, de acordo com qualquer uma das reivindicações 1 a 4, caracterizado pelo fato de o número imprevisível de transação não utilizado ser selecionado randomicamente e no qual um índice é associado ao referido número imprevisível de transação selecionado e na qual o número imprevisível de transação é recuperado pelo servidor a partir de um identificador único do usuário e o índice associado ao número imprevisível de transação selecionado adicionado a requisição de autorização de criptograma.

8. MÉTODO, de acordo com qualquer uma das reivindicações 1 a 7, caracterizado pelo fato do número imprevisível de transação ser marcado, como utilizado no armazenamento após a etapa de seleção e a etapa de recuperação.

9. MÉTODO, de acordo com qualquer uma das reivindicações 1 a 8, caracterizado pelo fato de, quando os números imprevisíveis de transação armazenados no aplicativo móvel para pagamento forem todos marcados, tal como utilizados, então um novo conjunto de números imprevisíveis de transação é gerado pelo servidor e enviado para o aplicativo móvel para armazenamento.

10. MÉTODO, de acordo com qualquer uma das reivindicações 1 a 9, caracterizado pelo fato da transmissão do conjunto gerado de números imprevisíveis de transação, a partir do servidor para o aplicativo móvel para pagamento, ser protegida: - por aplicar um algoritmo de criptografia, que envolve chave(s) compartilhada(s) entre o servidor e o aplicativo móvel para pagamento, e/ou - por aplicar um algoritmo de integridade, que envolve chave(s) compartilhada(s) entre o servidor e o aplicativo móvel para pagamento.

11. MÉTODO, de acordo com qualquer uma das reivindicações 1 a 10, caracterizado pelo fato do aplicativo móvel e do conjunto de números imprevisíveis de transação serem armazenados num elemento de segurança do dispositivo móvel.

12. MÉTODO, de acordo com qualquer uma das reivindicações 1 a 11, caracterizado pelo fato de o criptograma ser adicionalmente computado a partir de uma quantidade da transação inserida pelo usuário no dispositivo móvel, dados financeiros do usuário.

13. MÉTODO, de acordo com qualquer uma das reivindicações 1 a 12, caracterizado pelo fato do dispositivo móvel ser um telefone celular ou sem fio, um tablet, um smartphone, um assistente pessoal digital (PDA), um pager, e computadores portáteis.

14. SISTEMA, caracterizado pelo fato de compreender um aplicativo móvel de um dispositivo móvel de usuário, um provedor de terminal de um produto ou um serviço, um servidor de autenticação e um emissor para autenticação e autorização de uma transação, no qual referida transação é autenticada e autorizada de acordo com qualquer das reivindicações 1 a 13.