BR112015003152A2 - método e sistema para ativar a emissão de bilhete/pagamentos móvel sem contato via um aplicativo de telefone móvel - Google Patents

Abstract

"método e sistema para ativar a emissão de bilhete/pagamentos móvel sem contato via um aplicativo de telefone móvel, a presente invenção refere-se a um método para emissão de bilhete/pagamentos móvel sem contato usando um aplicativo disponível no telefone móvel. a presente invenção também se refere a um sistema, um servidor e um telefone móvel adequado para conduzir tal método

Description

«MÉTODO E SISTEMA PARA ATIVAR A EMISSÃO DE BIEHEIE/PAGAMENTOS MÓVEL SEM CONTATO VIA ÜM APLICATIVO DE TELEFONE. MÓVEL” [0001] A presente invenção refere-se a um método para emissão de bilhete/pagamentos móvel sem contato, usando um aplicativo disponível no telefone móvel. A presente invenção também se refere a um sistema, um servidor e um telefone móvel adequado para conduzir tal método.

HISTÓRICO DA TÉCNICA [0002] O desenvolvimento de soluções de emissão de bilhete usando cartões inteligentes teve um crescimento significativo ao longo da última década em um número significativo de mercados. A migração de cartões inteligentes de contato para sem contato para aplicativos de emissão de bilhete iniciou há alguns anos, enquanto o uso de telefones móveis de NFC (Comunicações de Campo Proximo) para emissão de bilhete está atualmente em um estágio ínieial.

[0003] -Os pagamentos estão liderando o número de iniciativas de NFC no mundo, porém ainda existe incerteza sobre o cronograma para ampla disponibilidade de terminais de Ponto de Venda sem contato nos locais mercantis.

[0004] O número crescente de aparelhos de telefone ativados por NFC disponíveis torna os prestadores de serviço e ecossistema de NEC como partes para aspirar um negócio e canal potenciais de emissão de bilhete/pagamento telefone móvel. Nenhuma dúvida que o telefone móvel oferece ao usuário, em comparação às soluções de cartão inteligente sem contato, uma experiência melhorada em termos de interface de usuário e provisionamento remoto.

[0005] As soluções sem contato mais populares para emissão de bilhete/pagamentos são denominadas «com base em SIM'⁵, que significa que o aplicativo de transporte/pagameutos e as credenciais de usuário são armazenadas em um elemento seguro de cartão SIM, detidas pela operadora correspondente de telecomunicação; então, neste contexto, os prestadores de serviço de transporte/pagamento chegarão a um acordo com a operadora de telecomunicações para-prestar os serviços de emissão de bilheíe/pagamento de NFC; desse modo, os prestadores de serviço de transporte/pagamento podem ser limitados de modo que eles prestam seus próprios serviços via o telefone móvel como, usando essa solução, parte do serviço é prestado dentro do domínio da operadora de telecomunicações.

[0006] Isso pode, portanto, ser de interesse para os prestadores de serviço terem acesso às novas soluções seguras que podem estar totalmente disponíveis dentro do próprio domínio da entidade de transporte/pagmnento, porém ainda favorecido com todos os benefícios fornecidos pela emissão de bilhete/pagamentos sem contato com base no uso de telefones móveis de NEC,

DIVULGAÇÃO DA INVENÇÃO [0007] Um objeto da invenção é, portanto, para fornecer aos prestadores de serviço de transporte/pagamento um método seguro que pode ser totalmente realizado em seu próprio domínio, assim auxiliando-os para continuar a manter o controle total de seu branding de serviço, negócio e provisíonamento para emissão de bilhete/paganienios móveis de NFC, evitando restrições de terceiro.

[0008] Esse objeto é atingido em conformidade com a reivindicação 1 ao fornecer um método para ativar a emissão de bilhete/pagamentos móvel sem contato via um aplicativo de telefone móvel, o método compreendendo as seguintes etapas:

[0009] (a) Um usuário paga ao prestador de serviço determinados serviços de emissão de bilhete/pagamento.

[00010] (b) Associado ao pagamento e ao direito concedido correspondente pm usar com relação aos serviços de emissão de bílhete./pagamento, um módulo de servidor de emissão de bilhete/pagamentos prepara as credenciais de emissão de bilhete/pagamento para uso pelo usuário registrado e envia os mesmos ao telefone móvel de usuário registrado.

[00011] (e) O telefone móvel de usuário recebe as credenciais e armazenaas para uso no sistema de emissão de bilhete sem contato de transporte, no caso das credenciais de emissão de bilhete, ou para uso nos pagamentos móveis sem contato, no caso de credenciais de pagamento.

[00012] O referido método c caracterizado pelo fato de que cada credencial é inequivocamente associada ao telefone móvel de usuário registrado e a um código de ativação e parcialmente ativa o telefone móvel para acesso de emissão de bilhete sem contato, no caso das credenciais de emissão de bilhete, ou para pagamentos

3/3 6 móveis sem contato, no caso de credenciais de pagamento; onde a capacitação de telefone móvel para cada acesso de emissão de bilhete sem contato (ou pagamento móvel sem contato) também exige que o usuário insira um Número de Identificação Pessoal (PIN) no aplicativo de emissão de bilhete/pagamento de telefone móvel; o módulo de servidor de emissão de bilhete/pagamentos· envia, as credenciais ao telefone móvel de usuário registrado após validação com êxito de uma Senha Única (OTP) recebida do aplicativo de emissão de bilhete/pagamentos de telefone móvel.

[00013] De acordo com a presente invenção, somente os usuários registrados pode obter as credenciais de emissão de bílhete/pagamento após o pagamento, e a utilização de tais credenciais é associada ao telefone móvel selecionado no processo de registro (e a um código de ativação) e a um Número de Identificação Pessoal selecionado pelo usuário, então a autenticação de dois fatores é exigida. Ainda por cima, as credenciais são somente enviadas ao aplicativo de telefone móvel de usuário registrado após verificar um OTP gerado por tal aplicativo de telefone móvel após a interação de usuário, de modo que o processo de download de credenciais seja adequadamente controlado pelo usuário e pelo prestador de serviço de transporte/pagamentos.

[00014] O módulo de servidor de emissão de bilhete/pagamentos pode ser pelo menos parcialmente incluído no meio de processamento de dados do prestador de serviço. Todo ou parte do mesmo pode ser detido ou operado por um prestador externo confiável do prestador de serviço. Como um exemplo, diversos prestadores de serviço de transporte podem compartilhar um módulo comum, de emissão de bilhete servidor ao chegar a um acordo entre eles, evitando a complexidade de soluções com base em SIM. em termos de contratos adicionais com operadoras de telecomunicações;

[00015] Em uma realização particular, o módulo de servidor de emissão de bilhete/pagamentos divide o direito concedido de emissão de bilheto/pagamento em diversas partições e gera uma credencial independente para cada uma dessas partições.

[00016] Em uma realização particular, um primeiro conjunto de credenciais c enviado ao aplicativo de telefone móvel, e novas credenciais são enviadas ao

4/^6 aplicativo de telefone móvel quando solicitado com êxito do dispositivo móvel de usuário, até o limite do direito concedido de usar os serviços de emissão de bilhete/pagamento sem contato. Desse modo, o sistema pode monitorar e limitar em qualquer momento o número de credenciais disponível no telefone móvel para acesso de emissão de bilhete/pagamentos.

[00017] Em uma realização particular, pelo menos uma credencial é desativada em (ou excluída de) o aplicativo de telefone móvel ao enviar uma mensagem de desativação (ou exclusão) do módulo de servidor de emissão de bilhete/pagamentos ao- aplicativo de telefone móvel de usuário.

[00018] Em outra realização particular, o direito de usar os serviços de emissão de bilhete/pagamento pode ser estendido pelo usuário pagando pelo mesmo, então as novas partições de direito de emissão de bilhete/pagamento podem ser dinamicamente geradas no módulo de servidor de emissão de bilhete/pagamentos, [00019] Em outra realização particular, o aplicativo de telefone móvel limita a solicitação de novas credenciais com base nas informações sobre as credenciais que já estão armazenadas no telefone móvel. Então, se, p.ex., o número de credenciais estiver abaixo de um limiar, o usuário é lembrado que a conectividade de dados é exigida para disponibilidade de novas credenciais.

[00020] Em uma realização particular, as credenciais de emissão de bilhete/pagamento são bloqueadas no aplicativo de telefone móvel após um número de inserções erradas cio Número de Identificação Pessoal, e uma mensagem de aviso é enviada ao módulo de servidor de emissão de bílhete/pagamentos, [00021] Em uma realização particular, o módulo de servidor de emissão de bilhete/pagamentos bloqueia o direito concedido de emissão de bílhete/pagamentos após um número de verificações erradas de um OTP recebido do aplicativo de telefone móvel, e uma mensagem de bloqueio de credenciais é enviada ao aplicativo de telefone mó vel.

[00022] Desse modo, a entidade de transporte/pagamenlos pode monitorar as inserções erradas de PÍN ocorrendo justamente previamente a uma tentativa de acesso de emissão de bilhete/pagamento ou aquelas ocorrendo dentro de um processo de renovação de credenciais.

<

[000'23J Em uma realização particular, para as transações on-line de pagamento móvel sem contato, uma segunda parte da credenciai é calculada pelo próprio aplicativo de telefone móvel, usando o valor de transação e o PIN de usuário como entradas para gerar um resultado de OTP (a segunda parte da credencial). As primeiras e segundas partes da credencial são usadas para a transação de pagamento móvel sem contato e a verificação de tal OTP pelo módulo de servidor de pagamento é exigida para aceitar ou negar a transação. Então, obtendo vantagem do fato que o valor de transação é conhecido pelo banco emitente durante o processo on-line de transação, o desafio para esse OTP poder usar isso e ainda ser verificado como pane do processo de autorização on-line.

[00024] Em outra realização particular para as transações on-line de pagamento móvel sem contato, uma segunda parte da credencial é calculada pelo próprio aplicativo de telefone móvel, usando o PIN de usuário como entrada para gerar um resultado de OTP sendo a segunda parte da credencial, onde as primeiras e segundas partes da credencial são usadas para a transação de pagamento móvel sem contato e a verificação de tal OTP pelo módulo de servidor de pagamento é exigida com a finalidade de aceitar ou negar a transação, Esta realização exige que o usuário insira o PIN (porém não o valor de transação) para o cálculo de resultado de OTP, de modo que o processo preparatório de pagamento via o aplicativo de pagamento de telefone móvel é mais simples do que na realização anterior.

[00025] Em uma realização particular, uma transação de pagamento on-line sem contato móvel que usa as primeiras e segundas partes da credencial já foi aceita (“a primeira transação”) e pelo menos uma transação adicional que posteriormente usa pelo menos parte das mesmas primeiras e segundas partes da credencial (“as transações sucessivas”) é aceita com base na verificação de OTP da primeira transação.

[00026] Como um exemplo particular, além de um pagamento on-line sem contata móvel inicial (ou uma pré-autorização de pagamento), os comerciantes, tais como, hotéis, empresas de aluguel de carro, etc., por vezes posteriormente cobram do usuário determinados custos adicionais (p.ex., uma empresa de aluguel de carro cobra o combustível consumido ao usuário). Esta realização permite ao módulo de servidor de pagamentos ativar o aceite das transações sucessivas- com base na assinatura eletrônica da primeira transação (verificação de OTP com êxito associada â primeira transação).

[000271 Em uma realização particular, cada uma das transações sucessivas é correspondida à primeira transação com base no uso de pelo menos parte das primeiras e segundas partes da credencial.

[00028] Em outra realização particular, cada uma das transações sucessivas é correspondida á primeira transação com base no uso de pelo menos parte das primeiras e segundas partes da credencial e uso de pelo menos um parâmetro adicional, esse parâmetro sendo incluído no fluxo de transação da primeira transação e transações sucessivas. Em um exemplo particular, pelo menos um parâmetro adicional é o código de comerciante.

[00029] Em uma realização particular, existe um número máximo pré-defimdo de credenciais armazenado no telefone móvel em determinado momento e o aplicativo de telefone móvel limita os pagamentos off-line móveis sem contato usando tais credenciais até o valor de transação máximo agregado de pagamentos off-line. Então, realizar os pagamentos off-line para um valor superior agregado exige que o usuário corretamente insira o valor de PIN, de modo que o módulo de servidor de pagamentos envie novas credenciais ao telefone móvel de usuário registrado e o aplicativo de pagamento de telefone móvel definirá novamente o valor de transação agregado de pagamentos off-line para o máximo.

[00030] Em um exemplo particular, o número máximo de credenciais é x e o valor agregado máximo para transações off-line usando tais credenciais é yy ouro. Se o. usuário realizar um pagamento móvel sem contato off-line para z euro, a quantia máxima de pagamentos off line usando as credenciais restantes (x-1) é (vy z) euro. O aplicativo de pagamento de telefone móvel solicita novas credenciais; se a verificação de OTP no módulo de servidor de pagamentos estiver correta, uma nova credencial é enviada ao aplicativo de pagamento de telefone móvel e o valor de transaçao agregado máximo para pagamentos offline é definido novamente para yy euro.

'Λ><>

[00031] Em uma realização particular, o usuário seleciona através de seu aplicativo de pagamento de telefone móvel para efetuar um pagamento de internet e a segunda parte da credencial junto com pelo menos uma parte da primeira parte da credencial é usada para realizar tal pagamento. Então, desse modo, o usuário pode selecionar via seu aplicativo de pagamento de telefone móvel um subconjunto de uma credencial pareíalmente calculada, para efetuar um pagamento de internet.

[00032] Em uma realização particular, uma transação de internet que usa pelo menos uma parte da primeira parte da credencial e a segunda parte da credencial já foi aceita (‘a primeira transação”) e pelo menos uma transação adicional que posteriormente usa a mesma pelo menos uma parte da primeira parte da credencial e a segunda parte da credenciai (“as transações sucessivas”) é aceita com base na verificação de OTP da primeira transação.

[00033] Em uma realização particular, cada uma das transações sucessivas é ligada à primeira transação com base no uso de pelo menos uma parte da primeira parte da credencial e segunda parte da credencial.

[00034] Em uma realização particular, cada uma das transações sucessivas é ligada, à primeira transação com base no uso de pelo menos uma parte da primeira parte da credencial e segunda parte da credencial e o uso de pelo menos um parâmetro adicional, sendo esse parâmetro incluído no fluxo de transação da primeira transação e transações sucessivas.

[00035] Em uma realização particular, o usuário paga determinados produtos e/ou serviços em um ou diversos comerciantes associados, e pelo menos um comerciante transfere parte de tais quantias de transações ao prestador dos serviços de emissão de liilhete/pagamentos para que ele ofereça determinados serviços de emissão de bilhete/pagamentos ao usuário. Então, nesta realização, pelo menos um comerciante gerencia o pagamento de tais quantias de transações em nome do usuário, no contexto de um programa de fidelidade oferecido peio(s) come.rciante(s), [00036] Tipicamente, os programas de fidelidade oferecidos pelos comerciantes lornecem ao usuário os pontos, acumulados após cada compra, e aqueles somente podem ser resgatados em um conjunto redutor de comerciantes associados. A realização anterior permite a pelo menos um comerciante oferecer aos seus clientes

8/36 (com uma ferramenta de fidelidade) os serviços de emissão de bilhete/pagamento cujo escopo de utilização é muito mais amplo do que aquele do conjunto reduzido mencionado de comerciantes.

[00037] Em uma implantação particular, o usuário pode utilizar seu aplicativo de pagamento de telefone móvel para pagar os comerciantes até o limite das quantias de transações .acumuladas como resultado das diferentes compras em pelo menos um comerciante. Observe que tais pagamentos poderíam ser efetuados em uma multiplicidade de comerciantes sem a necessidade de qualquer contrato entre pelo menos um comerciante onde as compras originais foram feitas e os comerciantes onde os pagamentos são feitos usando tais quantias de transações acumuladas.

[OüO.38] Em outra implantação particular, as quantias de transações acumuladas são usadas para conceder ao usuário determinados direitos para usar os serviços de emissão de bi lhete. Então, o usuário será capaz, de usar sett aplicativo de emissão de bilhete de telefone móvel para acessar os serviços de emissão de bilhete em uma multiplicidade de pontos de acesso (p.ex., para acessar qualquer ônibus municipal).

[00039] Em uma realização particular, um ou diversos comerciantes pagam ao prestador de serviços de emissão de bilhete/pagamento determinados serviços de emissão de bilhete/pagamento para o usuário, no contexto de um programa de fidelidade oferecido pelo(s) comerciante(s). Da mesma forma, quando o usuário paga, por determinados produtos e/ou serviços em pelo menos um comerciante, pelo menos- um comerciante transfere parte de tais quantias de transações ao prestador de serviços de emissão de bilhetWpagamento para que ele ofereça determinados serviços de emissão de bilhete/pagamento ao usuário. De modo semelhante â realização anterior, nesta realização, pelo menos um comerciante gerencia o pagamento de tais serviços e tais quantias de transações em nome do usuário, no contexto de um programa de fidelidade oferecido pelo(s) comerciante(s)>

[ 00040] Em uma realização particular, existe um número pré-definido máximo da primeira parte de um conjunto de credenciais para pagamentos off-line móveis sem contato que pode ser armazenado no telefone móvel em determinado instante de tempo e, assim que o período de validade da primeira parte de cada uma de tais credenciais expirar, o aplicativo de pagamento de telefone móvel limita os

9/36 pagamentos off-line móveis sem contato que usam tal primeira parte de cada uma de tais credenciais. Então, para realizar os pagamentos off-line móveis sem contato assim que tal primeira parte do conjunto de credenciais para pagamentos off-line móveis sem contato tiver expirado, o usuário deve corretamente inserir o valor de PIN, de modo que o módulo de servidor de pagamentos envie novas primeiras partes válidas de credenciais para pagamentos off-line móveis sem contato ao telefone móvel de usuário registrado.

[00041] Λ Patente WO ()3/()38719 descreve um método onde um cartão ímancelro virtual de uso único é gerado off-line, a ser usado para um pagamento de internet ou uma transação do tipo E.MV-M.SD sem contato (dados de fita magnética). Porém tal solução não pode ser utilizada para gerar um cartão financeiro virtual de uso único para uma transação do tipo de chip EMV & PIN sem contato, devido ao fato de que unia chave derivada será calculada no lado do servidor e enviada ao aplicativo de telefone móvel antes da tentativa de pagamento (com a finalidade de evitar armazenar a chave de emitente no telefone móvel)' então a geração de um cartão financeiro virtual de uso único para uma transação de chip EMV & PIN sem contato exige o manuseio de um processo on/off-lme para cada cartão gerado. A última realização acima corresponde- à exigência de atualização on-line, porém também associa de modo vantajoso uma segunda parte gerada offline móvel da credencial ao valor de transação e ao PIN de usuário, assim criando uma solução conveniente e altamente robusta de pagamento.

[00042] De acordo com a presente invenção, é ainda fornecido am sistema para ativar uma emissão de bilhete/pagamentos móvel sem contato via um aplicativo de telefone móvel, o referido sistema compreendendo:

[00043] - meio de registro para registrar usuários para serviços de emissão de bilhete^againento, [00044] - meio de pagamento para permitir ao usuário pagar pelos serviços de emissão de bíihete./pagamentò, [00045] ~ meio de geração de credenciais para preparar no módulo de servidor de emissão de bilhete/pagamentos, e com base nos direitos concedidos de emissão de bilhete/pagímiento, credenciais de emissão de bilhete/pagamento para uso pelo

10/36 usuário registrado; e meio de transmissão para enviá-las ao telefone móvel de usuário registrado; e meio de recepção e armazenamento para receber no telefone móvel as credenciais e armazeni-las para uso no sistema de emissão de bilhete sem contato de transporte (ou para uso nos pagamentos móveis sem contato, no caso das credenciais de pagamento), caracterizado pelo fato de que o referido sistema móvel compreende o meio de processamento para inequivocamente associar cada credencial que parcialmente ativa para o telefone móvel o acesso de emissão de bilhete sem contato (ou para pagamentos móveis sem contato), ao telefone móvel de usuário registrado e a um código de ativação; meio de processamento e verificação para permitir a capacitação de telefone móvel para cada acesso de emissão de bilhete sem contato (ou pagamento móvel sem contato), que também é com base no usuário inserir um Número de Identificação Pessoal (PIN) no aplicativo de emissão de bllhete/pagamento de telefone móvel; meio de processamento e transmissão no aplicativo de emissão de bilhete/pagamento de telefone móvel para calcular um OTP e enviá-lo ao módulo de servidor de emissão de Whete/pagamentos; e meio de processamento e verificação no módulo de servidor de emissão de bílhete/pagamentos para validar o OTP recebido.

BREVE DESCRIÇÃO DOS DESENHOS [00046] Na seguinte descrição detalhada de algumas possíveis realizações, outros recursos e vantagens da invenção aparecerão, cada descrição sendo- feita com referência aos desenhos a seguir;

[00047] A Figura l.a é um diagrama esquemático que geralmente ilustra os blocos funcionais principais da invenção, como uma extensão de um sistema de transporte de legado;

[00048] Λ Figura I.b é um diagrama esquemático ilustrando uma realização de um sistema de emissão de bilhete de acordo com a invenção;

[00049] A .Figura Lc é um diagrama esquemático ilustrando outra realização de um sistema de emissão de bilhete de acordo com a invenção;

Η'36 (00()50] A Figura 2.a é um diagrama esquemática que geralmente ilustra os blocos funcionais principais da invenção, como uma extensão de um sistema de pagamento de legado;

[00051] Λ Figura 2.b é um diagrama esquemático ilustrando uma realização de um sistema de pagamento de acordo com a invenção;

[00052] A Figura 2.C é um fíuxograma ilustrando parcialmente uma realização de um método de acordo com a invenção;

[00053] A Figura 2,d é um fíuxograma ilustrando parcialmente uma realização de um método de acordo com a invenção;

[00054] A Figura 2.e é uni fíuxograma ilustrando parcialmente uma realização de um método de acordo eom a invenção;

[00055] A Figura 2.f é um. fíuxograma ilustrando parcialmente uma realização de um método de acordo com a invenção;

[00056] A Figura 2,g é um fíuxograma ilustrando parcialmente uma realização de um método de acordo com a invenção;

DESCRIÇÃO DETALHADA [00057] A Figura l.a é um diagrama esquemático que geralmente ilustra os blocos funcionais principais da invenção, como uma extensão de um sistema de transporte de legado; essa figura mostra um sistema de transporte de legado 300a de um prestador de serviço, suportando cartões inteligentes sem contato (então, um usuário desse sistema pode ter disponível um cartão inteligente sem contato para acessar os serviços de transporte via os dispositivos de .controle de acesso de emissão de bilhete 400a), Ao usar o canal de distribuição de rede 200a. os usuários 100a podem tomar as providências necessárias para, contratar pelo menos um serviço, para obter pelo menos um título de transporte (perfil) associado a tal pelo menos um serviço e para carregar/recatregar pelo menos um título de transporte. Neste exemplo geral, o canal de distribuição de rede pertence a um banco parceiro e o usuário também é cliente nesse banco, então ele pode pagar via a página de web usando uma mídia de assinatura eletrônica fornecida pelo banco.

[00058] Quando o usuário solicitar, via o canal de distribuição de rede, os serviços móveis de emissão de bilhete- relacionados à presente invenção (e pagar por

12/36 eles de acordo com um método acordado entre, p.ex., o banco mencionado e o prestador de serviço de emissão de bilhete), o sistema de transporte de legado encaminha a solicitação para o módulo de servidor de emissão de bilhete 50Ôa da invenção. Os blocos tencionais principais desse módulo são ilustrados nesta figura.

[00059] A Figura l ,b fornece os detalhes adicionais sobre os blocos tencionais da figura La e é um diagrama esquemático ilustrando uma realização de um sistema de emissão de bilhete de acordo com a invenção, para ativar a emissão de bilhete sem contato móvel via um aplicativo de telefone móvel; a Figura 1 .b mostra o processo do registro de usuário para serviços móveis de emissão de bilhete até a prestação desses serviços.

(00060] Na etapa (1), o usuário baixa o aplicativo de telefone móvel de emissão de bilhete de uma loja de aplicativos 700 em seu telefone móvel ativado sem contain, [00061] No contexto da invenção, o usuário paga por determinados serviços de emissão de bilhete solicitados ao prestador de serviços. Na etapa (2) desta realização, o usuário solicita os serviços de emissão de bilhete via um canal de distribuição de rede e confirma o pagamento via esse meio (p.ex., mesmo cenário do que aquele descrito na figura 1 .a: o canal de distribuição de rede pertence a um banco parceiro), Na etapa (3), a solicitação é enviada ao sistema de transporte de legado e então encaminhada ao módulo de servidor de emissão de bilhete» Nesta realização, o módulo de registro do módulo de servidor de emissão de bilhete recebe na etapa (3) uma referência de cliente e uma referência de direito de transporte.

[00062] Associado ao pagamento e ao direito concedido correspondente para usar os serviços relacionados de emissão de bilhete, um módulo de servidor de emissão de bilhete prepara as credenciais de emissão de bilhete para uso pelo usuário registrado e envia-as ao telefone móvel de usuário registrado, conforme aqui detalhado abaixo.

[00063] Na etapa (4), o módulo de registro do módulo de servidor de emissão de bilhete designa um direito de transporte ao usuário (representado na fig. l.b como cartão “A” no módulo de servidor), com base na referência recebida de direito de transporte, e essas informações são armazenadas no banco de dados do módulo de servidor de emissão de bilhete (referência de cliente A). Então, o módulo- de registro solicita ao módulo de credenciais de usuários para gerar uma única credencial (representada na fig. 1 .b como cartão ^MVMC(A)” no módulo de servidor), e é ligado à referência de cliente de transporte e o direito de transporte no banco de dados do módulo de servidor de emissão de bilhete (referência de cliente <ó VMC(A)),. A credencial gerada tem uma data de expiração de modo que não possa ser usada após a expiração.

[00064] Na etapa (5), o módulo de credenciais de usuário solicita ao módulo de segurança um código de ativação; de modo que um código de ativação com determinada data de expiração é gerado pelo módulo de segurança e armazenado no banco de dados do módulo de servidor de emissão de bilhete (referência de cliente <x> Aef VMC(A) AC). Um código de ativação não pode ser usado após a expiração, Na etapa (6), o código de ativação é enviado do módulo de registro ao sistema de transporte de legado, encaminhado ao canal de distribuição de rede e exibido ao usuário.

[00065] Na etapa (7), o usuário insere o código de ativação no aplicativo de emissão de bilhete de telefone móvel e, na etapa (8), o telefone móvel envia ao módulo de segurança do módulo de servidor de emissão de bilhete, p.ex., via https, o [código de ativação e o hash (número de identidade de telefone móvel & código de ativação)].

[00066] Na etapa (9), o módulo de segurança verifica se o código de ativação está correto; se sim, o módulo de segurança armazena o valor de hash no banco de dados do módulo de servidor de emissão de bilhete, de modo que os links são agora conforme segue: referência de cliente <=> A4> VMC(A) AC <fehash (ID&.AC).

[00067] Na etapa (10), o cartão ⁴*A* é pre-personalizado no aplicativo de telefone móvel, [00068] A pré-personalização refere-se à etapa anterior à personalização: e a prépersonalização/personalização do cartão “A” refere-se â prépersonalização/personalização do aplicativo de emissão de bilhete sem contato móvel da invenção para operar em “modo de emulação de cartão” para serviços de ϊ-4736 emissão de bilhete sem contata móvel, equivalentemente a um aplicativo de emissão de bilhete com base em SIM operando em “modo de emulação de cartão” para serviços de emissão de bilhete sem contato móvel (p.ex._? emulando a tecnologia subjacente mtfare DESFIRE). A personalização total de cartão “A” no aplicativo de emissão de bilhete, de telefone móvel exibe baixar as credenciais do módulo de servidor de emissão de bilhete para o aplicativo de emissão de bilhete de telefone móvel, conforme aqui descrito abaixo.

[Ô0069] Quando- a etapa (10) terminar, o usuário já está registrado no sistema da invenção, porém receber as credenciais no aplicativo de emissão de bilhete de telefone móvel ainda está pendente. Neste estágio, cada credencial c inequivocamente associada ao telefone móvel de usuário registrado e a um código de ativação e parcialmente ativa o telefone móvel para acesso de emissão de bilhete sem contato.

[00070] Na etapa (11), o usuário é estimulado para selecionar um Número de Identificação Pessoal (PIN) para serviços de emissão de bilhete sem contato móvel. O valor de PIN não é armazenado no aplicativo de emissão de bilhete de telefone móvel, porém ê enviado de modo seguro na etapa (12) ao módulo de segurança do módulo de servidor de emissão de bilhete., junto com uma Senha Única (OTP) calculada usando o valor de PIN (e o Código de Ativação e valor de hash(AC&lD), para ser capaz de designar no módulo de servidor de emissão de bilhete o PIN selecionado e o resultado de OTP para a referência correta de cliente).

[00071] Na etapa (13), o módulo de segurança armazena o PIN no banco de dados de módulo de servidor de emissão de bilhete, junto com as chaves e parâmetros para calcular um resultado de OTP com base em PIN. Todo esse armazenamento é rotulado no banco de dados da figura l.b como dados de ^i<OTP(PIN)T De modo que os links e armazenamento no banco de dados são agora os seguintes: referência de cliente A<$ VMC(A) AC $>hash (UMAC) OTP(PIN).

[00072] Ainda na etapa (13), o módulo de servidor de emissão de bilhete calcula um resultado de OTP usando o PIN de usuário armazenado c chaves de OTP c parâmetros, e compara, o resultado com aquele recebido no módulo de segurança do

15/3ί>

aplicativo de emissão de bilhete de telefone móvel. Se a validação tiver êxito, então as credenciais de emissão de bilhete podem ser enviadas do módulo de credenciais de usuário ao aplicativo de emissão de bilhete de telefone móvel. Então, o módulo de servidor de emissão de bilhete envia as credenciais ao telefone móvel de usuário registrado após validação com êxito de uma Senha Üníca (OTF) recebida do aplicativo de emissão de bilhete de telefone móvel.

[00073] Na etapa (14), as credenciais de emissão de bilhete são enviadas ao aplicativo de emissão de bilhete de telefone móvel; o telefone móvel de usuário recebe as credenciais e armazena-as para uso no sistema de emissão de bilhete sem contato de transporte (então, o processo de personalização dc cartão ⁴W’ é então concluído). Em uma realização, as credenciais foram cifradas no módulo de segurança usando o PIN, então, para que o aplicativo de emissão de bilhete de telefone móvel possa usar uma credencial recebida e armazenada, é exigido que o usuário insira seu código de PIN.

[00074] O usuário registrado pode, na etapa (15), usar o telefone móvel para acessar os serviços de transporte. Na etapa (1.5), o usuário inserirá, seu código de PIN no aplicativo de emissão de bilhete de telefone móvel antes de tentar acessar o sistema de controle de acesso de emissão de bilhete 400; então, a capacitação de telefone móvel para cada acesso de emissão de bilhete sem contato também exige que o usuário inserir um código dc identidade pessoal (PIN) no aplicativo de emissão de bilhete de telefone móvel.

[00075] Na etapa (16), o módulo de credenciais de usuário do módulo de servidor de emissão de bilhete está ciente que as credenciais de emissão de bilhete foram recebidas com êxito e armazenadas no aplicativo de emissão de bilhete de telefone móvel (sucesso na etapa 14), então a confirmação é enviada ao distribuidor de web, que efetua pagamento do encargo final e informa o usuário (p.ex., via um SMS ou um alerta de página de web de distribuidor).

[00076] A Figura l.c é um diagrama esquemático ilustrando outra realização de um sistema de emissão de bilhete de acordo com a invenção, para ativar a emissão de bilhete sem contato móvel via um aplicativo de telefone móvel; a Figura Lc

16/36 mostra o processo do registro de usuário para serviços móveis de emissão de bilhete até a prestação de tais serviços.

[00077] Esta realização obtém como referência aquele da figura l.b com determinadas varilncias doravante descritas. As etapas (1), (2) e (3), são as mesmas do que na figura I .b.

[00078] Associado ao pagamento e ao direito concedido correspondente para usar os serviços relacionados de emissão de bilhete, um módulo de servidor de emissão de bilhete prepara as credenciais de emissão de bilhete para uso pelo usuário registrado e envia-as ao telefone móvel de usuário registrado, conforme aqui detalhado abaixo. Porém, nesta realização, o módulo de servidor de emissão de bilhete divide o direito concedido de emissão de bilhete em diversas partições e gera uma credencial independente para cada uma de tais partições.

[00079] Então, na etapa (4), o módulo de servidor de emissão de bilhete designa um direito de transporte ao usuário (representado na fig, 1 x como cartão “A'^? no módulo de servidor), ligado a um conjunto de credenciais (representado na fig. l,c como cartões ⁴ⁱVMC(A)l^M para “VMC(A)n” no módulo de servidor) e para uma referência de cliente de transporte e armazena esses links no banco de dados do módulo de servidor de emissão de bilhete (referência de cliente A<A VMC(A)i, i~l ...,n).

[00080] Na etapa (5), um código de ativação ê gerado e armazenado no banco de dados do módulo de servidor de emissão de bilhete (referência de cliente A4> VMC(A)i, i~1. ...n AC). Na etapa (6), o Código de Ativação é enviado ao sistema de transporte de legado, encaminhado ao canal de distribuição de rede e exibido ao usuário.

[00081 ] As etapas (7), (8) e (9) são as mesmas que na figura 1 .b, de modo que os links após a etapa (9) são conforme segue: referência de cliente <=> A^> VMC(A)i, i-l...n AC 4»hash(ID&:AC).

[00082] Na etapa (10), o cartão ⁿA” é pré-personalizado no aplicativo de telefone móvel.

[00083] Conforme na realização l.b, a prê-personalízação refere-se â etapa anterior à personalização; e a pré-personaiização/personalizaçãí) de cartão “A”

17/36 refere-se â pré-personalização/personalização do aplicativo de emissão de bilhete sem contato móvel da invenção para operar em “modo de emulação de cartão” para os serviços de emissão de bilhete sem contato- móvel, equivalentemente a um aplicativo de emissão de bilhete com base em SIM operando em “modo de emulação de cartão” para os serviços de emissão de bilhete sem contato móvel. A personalização total do cartão “A” no aplicativo de emissão de bilhete de telefone móvel exige o download de credenciais do módulo de servidor de emissão de bilhete ao aplicativo de emissão de bilhete de telefone móvel, conforme aqui descrito abaixo.

[00084] Quando a etapa (10) termina, o usuário já está registrado no sistema da invenção, porém receber as credenciais no aplicativo de emissão de bilhete de telefone móvel ainda está pendente. Neste estágio, cada credencial é inequivocamente associada ao telefone móvel de usuário registrado e a um código de ativação e parcialmente ativa o telefone móvel para acesso de emissão de bilhete sem contato.

[00085] Na etapa (11), o usuário é estimulado para selecionar um Número de Identificação Pessoal (PIN) para os .serviços de emissão de bilhete sem contato móvel. O valor de PIN não é armazenado no aplicativo de emissão de bilhete de telefone móvel, porém é enviado de modo seguro na etapa (12) ao módulo de servidor de emissão de bilhete, junto com uma Senha Uníca (OTP) calculada usando o valor de PIN (e o Código de ativação e valores de hash (AC&ID), para ser capaz de-designar no módulo de servidor de emissão de bilhete o .PIN selecionado e o resultado de OTP para a referência correta de cliente).

[ÜÕ086] Na etapa (13), o PIN é armazenado no banco de dados de módulo de servidor de emissão de bilhete, junto com as chaves e parâmetros para, calcular um resultado de OTP com base em PIN, Todo esse armazenamento é rotulado no banco de dados da figura Lc como dados de “OTP(PIN)”. De modo que os links e armazenamento no banco de dados são agora os seguintes: referência de cliente A4> VMC(A)í, M ...a<b AC «Abash (IDfeAC) o OTP (PIN).

[(1(1087] Ainda na etapa. (13), o módulo de servidor de emissão de bilhete calcula um resultado de OTP usando as chaves e parâmetros armazenados de PIN e OTP de

W36 usuário, e compara o resultado com aquele recebido do aplicativo de emissão de bilhete de telefone móvel. Se a validação tiver êxito, então as credenciais de emissão de bilhete podem ser enviadas ao aplicativo de emissão de bilhete de telefone móvel. Então, o módulo de servidor de emissão de bilhete envia as credenciais ao telefone móvel de usuário registrado após validação com êxito de uma Senha Única (OTP) recebida do aplicativo de emissão de bilhete de telefone móvel [00088] Na etapa (14), um primeiro conjunto de credenciais (p.ex., credenciais de i~l até i~j, j<n) é enviado ao aplicativo de emissão de bilhete de telefone móvel; o telefone movei de usuário recebe as credenciais e annazena-as para, uso no sistema de emissão de bilhete sem contato de transporte (então, o processo de personalização de cartão ⁴*A” é então concluído para usar as credenciais r-1. até i~j). [Ô00S9] O usuário registrado pode, na etapa (15), usar o telefone móvel para acessar os serviços de transporte. Na etapa (15), o usuário inserirá seu código de PIN no aplicativo de emissão de bilhete de telefone móvel antes de tentar acessar o sistema de controle de acesso de emissão de bilhete 400; então, a capacitação de telefone móvel para cada acesso de emissão de bilhete sem contato também exige que o usuário insira um código de identidade pessoal (PIN) no aplicativo de emissão de bilhete de telefone movei.

[00090] Na etapa (16), o módulo de servidor de emissão de bilhete está ciente que um primeiro conjunto de credenciais de emissão de bilhete foi recebido com êxito c armazenado no aplicativo de emissão de bilhete de telefone móvel (sucesso na etapa 14) então a confirmação é enviada ao distribuidor de web, que efetua o pagamento do encargo final e informa o usuário (p.ex., via um SMS ou um alerta de página de web de distribuidor).

[00091] Novas credenciais são enviadas ao aplicativo de telefone móvel quando solicitado sucessivamente do dispositivo móvel de usuário, até o limite do direito concedido para usar os serviços de emissão de bilhete sem contato.

[00092] Na etapa (17), o módulo de credenciais do aplicativo de emissão de bilhete de telefone móvel detecta que novas credenciais são exigidas e envia a mensagem de solícitar_credenciais ao módulo de servidor de emissão de bilhete.

19/36

Essa mensagem contém um resultado de Senha Única (QTP), calculado usando o valor de PIN (e o Código de ativação e os valores de hash (AC&ID), para ser capaz de designar no módulo de servidor de emissão de bilhete o resultado de OTP para a referência correta de cliente). Em uma realização, o aplicativo calcula o OTP obtendo vantagem de o usuário inserir seu código de PIN ao tentar acessar o sistema de transporte de emissão de bilhete. Em outra realização, o usuário é estimulado para inserir seu código de PIN para que o resultado de OTP seja calculado.

[00093.] Conforme na segunda parte da etapa (13), o módulo de servidor de emissão de bilhete calcula um resultado de OTP usando o PIN armazenado de usuário e Chaves de OTP e parâmetros, e compara o resultado com aquele recebido do aplicativo de emissão de bilhete de telefone móvel. Se a validação tiver êxito, então mais credenciais de emissão de bilhete podem ser enviadas ao aplicativo de emissão de bilhete de telefone móvel. Então, o módulo de servidor de emissão de bilhete envia mais credenciais ao telefone móvel de usuária registrado após validação com êxito de uma Senha Única (OTP) recebida do aplicativo de emissão de bilhete de telefone móvel [00094] Na etapa (18), um novo conjunto de credenciais (p.ex», credenciais de i»|41 até i~k» k<n) é enviado ao aplicativo de emissão de bilhete de telefone móvel; o telefone móvel de usuário recebe as credenciais e armazena-as para uso no sistema de emissão de bilhete sem contato de transporte (então, o processo de personalização do cartão ^WA” é então concluído para usar as credenciais i~j +1 até i-k).

[00095] Nesta realização, as etapas (17), (13) e (18) são repetidas até as credenciais até a credencial i^::::n ser enviada ao telefone móvel, e são recebidas e armazenadas no aplicativo de emissão de bilhete de telefone móvel para uso no sistema de emissão de bilhete sem contato de transporte.

[00096] Todas essas credenciais, até a credencial n, podem ser usadas na etapa (15) pelo usuário registrado para acessar os serviços de transporte. Na etapa (15), o usuário inserirá seu código de PIN no aplicativo de emissão de bilhete de telefone móvel antes de tentar acessar o sistema de controle de acesso de emissão de bilhete 400; então, a capacitação de telefone móvel para cada acesso de emissão de bilhete

20/36 sem contato também exibe que o usuário insira um código de identidade pessoal (PIN) no aplicativo de emissão de bilhete de telefone móvel.

[(10()97] O direito de usar os serviços de emissão de bilhete pode ser estendido pelo usuário pagando peto mesmo, então as novas partições de direito de emissão de bilhete podem ser dinamicamente geradas no módulo de servidor de emissão de bilhete. Então, p.ex., após uma nova execução das etapas (2) e (3), as partições de i-n+1 até i™m podem ser geradas em uma nova execução do processo de etapa (4), e a credencial de mrH-1 até i™m pode ser enviada com êxito ao telefone móvel e recebida e armazenada no aplicativo de emissão de bilhete de telefone móvel de acordo com as etapas repetidas (17), (13) e (18) para uso no sistema de emissão de bilhete sem contato de transporte.

[00098] Em um exemplo particular, o usuário paga 50€ via o canal de distribuição de rede e o direito concedido de transporte permite que ele acesse os serviços de emissão de bilhete de ônibus de Zona A durante o mês de abril (30 dias). O módulo de servidor de emissão de bilhete prepara a credencial 1 para uso no primeiro dia do mês,... e a credencial 30 para uso no último dia do mês. As primeiras cinco credenciais são enviadas ao aplicativo de telefone móvel antes de iniciar o mês, após receber um valor correto de OIT; no caso em que ainda exista credenciais disponíveis de telefone móvel para quatro dias restantes, a mensagem de so.ticitar_credencíais é enviada para solicitar as credenciais para 1 dia extra, obtendo vantagem de o usuário inserir o PIN para acessar os serviços móveis de emissão de bilhete; no caso em que exista credenciais disponíveis para três dias restantes, a solicitação será para 2 dias extras, obtendo vantagem de o usuário inserir o PIN para acessar os serviços móveis de emissão de bilhete; no caso em que exista credenciais disponíveis para 2 ou somente 1 dia, o usuário será estimulado para inserir seu código de PIN no aplicativo de emissão de bilhete de telefone móvel para que novas credenciais sejam solicitadas, recebidas e armazenadas (até o limite de credenciais de 5 dias disponíveis no telefone móvel).

[00099] Em outro exemplo particular, o usuário paga 40€ via o eanal de distribuição de rede e o direito concedido de transporte permite a ela 40 viagens de ônibus dentro da Zona A. As primeiras cinco credenciais, uma por viagem, são

2J.36 enviadas ao aplicativo de telefone móvel, após receber um valor correto de OTP; no caso em que exista ainda credenciais disponíveis de telefone móvel para quatro viagens restantes, a mensagem de solícitar_credenciais é enviada para solicitar credenciais pata 1 viagem extra, obtendo vantagem de o usuário inserir o PIN para acessar os serviços móveis de emissão de bilhete; no caso em que exista ainda credenciais disponíveis para três viagens restantes, a solicitação será para 2 viagens extras, obtendo vantagem de o usuário inserir o PIN para acessar os serviços móveis de emissão de bilhete; no caso em que exista ainda credenciais disponíveis para 2 ou somente 1 viagem, o usuário será estimulado para inserir seu código de PIN no aplicativo de emissão de bilhete de telefone móvel para que novas credenciais sejam solicitadas, recebidas e armazenadas (até o limite de 5 viagens credenciais disponíveis no telefone móvel).

[0001 GO] Então, o aplicativo de telefone móvel limita a solicitação de novas credenciais com base nas informações sobre as credenciais que já estão armazenadas no telefone móvel. De modo vantajoso, esse recurso permite ao prestador de serviços de emissão de bilhete monitorar e controlar o número de credenciais disponível no telefone móvel de usuário, assim mantendo parte do direito concedido no módulo de servidor de emissão de bilhete, [000101] As operações ou módulo de segurança no módulo de servidor de emissão de bilhete podem solicitar pele menos uma credencial a ser desativada em. (ou excluída de) o aplicativo de telefone móvel ao enviar uma mensagem de desativação (ou exclusão) do módulo de servidor de emissão de bilhete ao aplicativo de telefone móvel de usuário. Então, o prestador de serviços de emissão de bilhete pode ainda gerenciar o ciclo ao vivo de credenciais quando já disponível no aplicativo de telefone móvel, [000102] Em uma realização, as credenciais de emissão de bilhete são bloqueadas no aplicativo de telefone móvel após um número de inserções erradas do Número de Identificação Pessoal, e uma mensagem de aviso c enviada ao módulo de servidor de emissão de bilhete. Em outra realização, o módulo de servidor de emissão de bilhete bloqueia o direito concedido de emissão de bilhete após um número de verificações erradas de um OTP recebido do aplicativo de telefone móvel, e uma

22/36 mensagem de bloqueio de credenciais é enviada ao aplicativo de telefone movei. Desse modo, o prestador de serviços de emissão de bilhete tem ferrímientas de gestão de PIN e segurança disponíveis tanto no aplicativo quanto no lado do módulo de servidor de emissão de bilhete.

[000103] O módulo de segurança periodicamente verifies a validade dos códigos de ativações e credenciais de modo que possam ser usados apôs a expiração. Em um exemplo, se um código de ativação ou credencial for usado após sua data de expiração, uma mensagem é enviada ao sistema de transporte de legado para informar sobre esse evento.

[000104] A Figura 2,a é um diagrama esquemático que geralmente ilustra os blocos funcionais principais da invenção, como uma extensão de um sistema de pagamento de legado; esta figura mostra uni sistema de pagamento de legado 3000a de um prestador de serviço de banco (/entidade de meio de pagamentos), suportando cartões inteligentes de contato e sem contato para pagamentos (então, um usuário deste sistema pode ter disponível um cartão inteligente financeiro de contato/scm contato para pagar nos locais de comerciante equipados com um Terminal de Ponto de Venda de contato/sem contato 4000a). Os usuários 1000a podem solicitar, via o canal de distribuição de rede 2000a, os cartões inteligentes financeiras para pagamentos de débito/crédito/pré-pago. Neste exemplo, o canal de distribuição de rede pertence ao banco que detêm o sistema de pagamento de legado e o usuário também ê cliente nesse banco, então ele pode confirmar o pagamento para cartões financeiros solicitados e ativá-los posteriormente via a página de web, usando um meio de assinatura eletrônica fornecido pelo banco, [0001.05] Quando o usuária solicitar, via o canal de distribuição de rede, os serviços móveis de pagamento relacionados à presente invenção (é a capacidade de usar pelo menus um cartão móvel financeiro para os pagamentos móveis sem contato) e pagar por eles (o usuário paga pela capacidade solicitada) usando o meio de assinatura eletrônica do banco, o sistema de pagamentos de legado encaminha a solicitação para o módulo de servidor de pagamentos 5000a da invenção. Os blocos funcionais principais deste modulo são ilustrados nesta figura.

23/36 [000106] A Figura 2>b fornece os detalhes adicionais sobre os blocos funcionais da figura 2,a e é utn diagrama esquemático ilustrando uma realização de um sistema de pagamento de acordo com a invenção, para ativar os pagamentos móveis sem contato via um aplicativo de telefone móvel; a Figura 2.b mostra o processo do registro de usuário para serviços móveis de pagamento até a prestação de tais serviços.

[000107] Na etapa (1). o usuário baba o aplicativo de pagamentos de telefone móvel de uma loja de aplicativos 7000 em seu telefone móvel ativado sem contato.

[000108] No contexto da invenção, o usuário paga por determinados serviços de pagamento solicitados ao prestador de serviços. Na etapa (2) desta realização, o usuário solicita os serviços de pagamento (deve-se solicitar a capacidade de usar pelo menos um cartão móvel financeiro para pagamentos móveis sem contato) via um canal de distribuição de rede e confirma o pagamento via esse meio (o usuário paga pela capacidade solicitada). Nesta realização, o mesmo cenário do que aquele descrito na figura 2.a se aplicar o canal de distribuição de rede pertence ao banco. Na etapa (3), a solicitação é enviada ao sistema de pagamentos de legado e então encaminhada ao módulo de servidor de pagamentos.

[000109] Associado ao pagamento e ao direito concedido correspondente para usar os serviços relacionados de pagamento, um módulo de servidor de pagamentos prepara as credenciais de pagamento para uso pelo usuário registrado e envia-as ao telefone móvel de usuário registrado, conforme aqui detalhada abaixo. Nesta realização, o modulo de servidor de pagamentos divide o direito concedido de pagamentos em diversas partições e gera uma credencial independente para cada uma de tais partições.

(000110] Na etapa (4), o módulo de servidor de pagamentos designa um direito de pagamentos ao usuário (representado na fig. 2.b como cartão “A” no módulo de servidor), ligado a um conjunto de credenciais (representado na fig. 2,b como Cartões *ΎΜ£(Α)1* até “VMC(A)n” no módulo de servidor) e para uma referência de cliente de pagamentos e armazena esses links no banco de dados de módulo de servidor de pagamentos (referência de cliente VMC(A)i, i^:::: I . ..n).

24/36 [000111] Ha etapa (5), um código de ativação é gerado e armazenado no banco de dados de módulo de servidor de pagamentos (referência de cliente <=> VMC(A)i, I~I ...n êi> AC). Na etapa (6), o Código de Ativação é enviado ao sistema de pagamentos de legado, encaminhado ao canal de distribuição de rede e exibido ao usuário.

[000112] Na etapa (7), o usuário insere o código de ativação no aplicativo de pagamento de telefone móvel e, na etapa (8), o telefone móvel envia ao módulo de servidor de pagamentos, p.ex., via https, o [código de ativação e o hash(mtmero de identidade de telefone móvel & código de ativação)].

[000113] Na etapa (9), o valor de hash é armazenado no módulo de servidor de pagamentos, de modo que os links são agora conforme segue: referência de cliente 40 A<& VMC(A)i, i“l ...n AC ^hash(ID&AC).

[000114] Na etapa (10), o cartão «A* é pré-personalizado no aplicativo de telefone móvel.

[000115] Â pré-personalização refòrc-se â etapa anterior à personalização; e a prépersonalização/personalização de cartão «A” refere-se à prépersonalização/pctsonalízação do aplicativo de pagamento móvel sem contato da invenção para operar em «modo de emulação de cartão’ para serviços de pagamento móvel sem contato, equivalentemente a um aplicativo de pagamento com base em SIM operando em “modo de emulação de cartão” para os serviços de pagamento móvel sem contato (tais como, pagamentos de chip EMV & FIN). A personalização total de cartão «A” no aplicativo de pagamento de telefone móvel exige o download de credenciais do módulo de servidor de pagamentos ao aplicativo de pagamento de telefone móvel, conforme aqui descrito abaixo.

[000116] Quando a etapa (10) termina, o usuário já está registrado o sistema da invenção, porém o recebimento das credenciais no aplicativo de pagamento de telefone móvel ainda está pendente. Neste estágio, cada credencial é inequivocamente associada ao telefone móvel de usuário registrado e a um código de ativação e parcialmente ativa o telefone móvel para serviços de pagamento sem contato nos locais de comerciante.

25/36 [000117] Na etapa (li), o usuário é estimulado para selecionar um Número de Identificação Pessoal (PIN) para serviços de pagamento móvel sem contato. O valor de PIN nlo é armazenado no aplicativo de pagamento de telefone móvel, porém ê enviado de modo seguro na etapa (12) ao módulo de servidor de pagamentos, junto com uma Senha Uniea (OTP) calculada usando o valor de PIN (e o Código de Ativação e valores de hash (AC&ID), para ser capaz de designar no módulo de servidor de pagamentos o PIN selecionado e o resultado de OTP para a referência correta de cliente).

[000118] Na etapa (13), o PIN é armazenado no banco de dados de módulo de servidor de pagamentos, junto com as chaves e parâmetros para calcular um resultado OTP com base em PIN. Todo esse armazenamento é rotulado no banco de dados da figura l.c como dados de *OTP(PIN)^V. De modo que os links e armazenamento no banco de dados são agora o .seguinte: referência de cliente A <2 VMC(A)i, foi ...n ¢2 AC^hashflD&AC) ® OTP(PIN).

[000119] Ainda na etapa (13), o módulo de servidor de pagamentos calcula um resultado de OTP usando o PIN armazenado de usuário e chaves de OTP e parâmetros, e compara o resultado com aquele recebido do aplicativo de pagamento de telefone móvel. Se a validação tiver êxito, então as credenciais de pagamento podem ser enviadas ao aplicativo de pagamento de telefone móvel. Então, o módulo de servidor de pagamentos envia as credenciais ao telefone móvel de usuário registrado após validação com êxito de uma Senha Uniea (OTP) recebida do aplicativo de pagamento de telefone móvel [000120] Na etapa (14), um primeiro conjunto de credenciais (p.ex., credenciais de foi até foj, j<n) é enviado ao aplicativo de pagamento de telefone móvel; o telefone móvel de usuário recebe .as credenciais e armazena-as para uso nos locais de comerciante equipados com Terminais de Ponto de Venda sem contato (então, o processo de personalização do cartão ç então concluído para usar as credenciais foi até foj).

[000121] O usuário registrado pode, na etapa (15), usar o telefone móvel para pagar nos comerciantes equipados com Terminais de Ponto de Venda sem contato. Na etapa (15), o usuário inserirá seu código de PIN no aplicativo de pagamento de

26/36 telefone móvel antes de tentar pagar no Terminal de Ponto de Venda sem contato 4000; então, a capacitação de telefone móvel para cada pagamento móvel sem contato também exige que o usuário Insira um código de .identidade pessoal (PIN) no aplicativo de pagamento de telefone móvel.

[000122] Na etapa (16), o módulo de servidor de pagamentos está ciente que um primeira conjunto de credenciais de pagamento foi recebido -com êxito e armazenado no aplicativo de pagamento de telefone móvel (sucesso na etapa 14), então a confirmação ê enviada ao distribuidor de web, que efetua o pagamento do encargo final e informa o usuário (p.ex., via um SMS ou um alerta de página de web de distribuidor).

[000123] Novas credenciais são enviadas ao aplicativo de telefone móvel quando solicitado sucessivamente do dispositivo móvel de usuário, até o limite do direito concedido para usar os serviços de pagamento sem contato.

[000124] Na etapa (17), o aplicativo de pagamento de telefone móvel detecta que novas credenciais são exigidas, e envia uma mensagem de solicitar credenciais ao módulo de servidor de pagamentos. Essa mensagem contêm um resultado de Senha Unlca (OTP), calculado usando o valor de PIN (e o Código de ativação e valores de hash (AC&ID), para ser capaz de designar no módulo de servidor de pagamentos o resultado de OTP para a referência correta de cliente). Em uma realização, o aplicativo calcula o OTP obtendo vantagem de o usuário inserir seu código de PIN ao tentar efetuar um pagamento móvel sem contato em um local de comerciante. Em outra- realização, o usuário é estimulado para inserir seu código de PIN para, que o resultado de OTP seja calculado.

[000125] Conforme na segunda parte da etapa (13), o módulo de servidor de pagamentos calcula um resultado de OTP usando o PIN armazenado de usuário e chaves de OTP e parâmetros, e compara o resultado com aquele recebido do aplicativo de pagamento de telefone móvel Se a validação tiver êxito, então mais credenciais de pagamento podem ser enviadas ao aplicativo de pagamento de telefone móvel Então, o módulo de servidor de pagamentos envia mais credenciais ao telefone móvel de usuário registrado após validação com êxito de uma Senha Unica (OTP) recebida do aplicativo de pagamento de telefone móvel.

27/36 [000126] Na etapa (18), um novo conjunto de credenciais (p.ex., credenciais de i“JH até k<n) é enviado ao aplicativo de pagamento de telefone móvel; o telefone móvel de usuário recebe as credenciais e annaz.ena-as para uso nos pagamentos móveis sem contato (então, o processo de personalização do cartão “A” é então concluído para usar as credenciais i^:::j+l até r^::k).

[000127] Nesta realização, as etapas (17), (13) e (18) são repetidas até as credenciais até a credencial i~n serem enviadas ao telefone móvel, e são recebidas e armazenadas no aplicativo de pagamento de telefone móvel para uso nos pagamentos móveis sem contato.

[000128] Todas essas credenciais, até a credencial n, podem ser usadas na etapa (15) pelo usuário registrado para pagamentos móveis .sem contato. Na etapa (15), o usuário inserirá seu código de PIN no aplicativo de pagamento de telefone móvel antes de tentar pagar no Terminal de Ponto de Venda sem contato de comerciante; então, a capacitação de telefone móvel para cada pagamento móvel sem contato também exige que o usuário insira um código de identidade pessoal (PIN) no aplicativo de pagamento de telefone móvel [060129] (.) direito de usar os serviços de pagamento pode ser estendido pelo usuário pagando pelo mesmo, então novas partições de direito de pagamento podem ser dinamicamente geradas no módulo de servidor de pagamentos» Então, p.ex., após uma nova execução de etapas (2) e (3), as partições de í™nv 1 até i~m podem ser geradas em uma nova execução do processa da etapa (4), e a credencial de imH-l até i™m pode ser enviada sucessivamente ao telefone móvel e recebida c armazenada no aplicativo de pagamento de telefone móvel de acordo com as etapas repetidas (17), (13) e (18) para uso nos pagamentos móveis sem contato» [000130] Em um exemplo particular, o usuário paga 20P via o canal de distribuição de rede e o direito concedido de pagamento permite que ele realize as operações de pagamentos sem contato, via seu aplicativo móvel sem contato, e de acordo com um esquema tradicional de produto de crédito, nos Terminais de Ponto de Venda sem contato de comerciante durante 1 ano. O módulo de servidor de pagamentos prepara as credenciais para uso durante o período anual, cada um somente válido para uma única tentativa de pagamento. As primeiras cinco

28/¾ credenciais são enviadas ao aplicativo de telefone móvel ao iniciar o período, após receber um valor correto de OTF; no caso em que exista ainda credenciais disponíveis de telefone móvel para quatro operações restantes de pagamento, a mensagem de solicitar credenciais é enviada para solicitar credenciais para I pagamento extra, obtendo vantagem de o usuário inserindo o PIN para uma tentativa de pagamento móvel sem contato em um local de comerciante; no caso em que exista ainda credenciais disponíveis para três operações restantes de pagamento, a solicitação será para 2 pagamentos extras, obtendo vantagem de o usuário inserindo o PIN para uma tentativa de pagamento móvel sem contato em um local de comerciante; no caso em que exista ainda credenciais disponíveis para 2 ou somente 1 operação de pagamento, o usuário será estimulado para inserir seu código de PIN no aplicativo de pagamento de telefone móvel para que novas credenciais sejam solicitadas, recebidas e armazenadas (até o limite de 5 credenciais de pagamento disponíveis no telefone móvel).

[000131] Então, o aplicativo de telefone móvel limita a solicitação de novas credenciais com base nas informações sobre as credenciais que já estão armazenadas no telefone móvel. De modo vantajoso, esse recurso permite ao prestador de serviços de pagamento para monitorar e controlar o número de credenciais disponível no telefone móvel de usuário, assim mantendo parte do direito concedido no módulo de servidor de pagamentos.

[000132] As operações ou módulo de segurança no módulo de servidor de pagamentos podem solicitar que pelo menos uma credencial seja desativada em (ou excluída de) o aplicativo de telefone móvel ao enviar uma mensagem de desativação (ou exclusão) do módulo de servidor de pagamentos ao aplicativo de telefone movei de usuário. Então, o prestador de serviços de pagamento pode ainda gerenciar o ciclo ao vivo de credenciais quando já disponível no aplicativo de telefone móvel.

[000133j Em. uma realização, as credenciais de pagamento são bloqueadas no aplicativo de telefone móvel após um número de inserções erradas do Número de Identificação Pessoal, e uma mensagem de aviso é enviada ao módulo de servidor de pagamentos. Em outra realização, o módulo de servidor de pagamentos bloqueia

29/36· o direito concedido de pagamentos após um número de verificações erradas de um OTP recebido do aplicativo de telefone móvel, e uma mensagem de bloqueio de credenciais é enviada ao aplicativo de telefone móvel Desse modo, o prestador de serviços de pagamento tem ferramentas de gestão de PIN e segurança disponíveis tanto no aplicativo quanto no lado do módulo de servidor de pagamentos.

[000134] A Fígura 2,c é um tluxograma ilustrando parcialmente uma realização de um método de acordo com a invenção.

[000135] Nesta realização, para as transações on-line de pagamento móvel sem contato, uma. segunda, parte do credencial de pagamento é calculada pelo próprio aplicativo de pagamento de telefone móvel, usando o valor de transação e o PIN de usuário como entradas para gerar um resultado de OTP (a segunda parte da credencial). As primeiras e segundas partes da credencial são usadas para a transação de pagamento móvel sem contato e verificação de tal OTP pelo módulo de servidor de pagamento é exigida com a finalidade de aceitar ou negar a transação.

[000136] Em outra realização para transações on-line de pagamento móvel sem contato, uma segunda parte da credencial é calculada pelo próprio aplicativo de telefone móvel, usando o PIN de usuário como entrada para gerar um resultado de OTP sendo a segunda parte da credencial As primeiras e segundas partes da credencial são usadas para a transação de pagamento móvel sem contato e verificação de tal OTP pelo módulo de servidor de pagamento é exigida com a finalidade de aceitar ou negar a transação.

[000137] Em am ambiente de chip de EMV & PIN, um número de PAN é designado a um cartão de EMV fornecido ao usuário (cartão (A)). Esse cartão inclui outro conjunto de dados que são parte da própria credencial data de caducidade (CD), CVV e chave derivada para cálculo de criptograma.

[000138] Nesta realização, a credencial de. pagamento para cartão VMC(A)Í é primelramentc gerada no módulo de servidor de pagamentos, então, PAN, CD, CVV e chave derivada são calculados no lado de servidor e enviada, junto com BIN, ao aplicativo móvel de pagamentos. Em um exemplo particular, o número de

PAN é gerado usando o hash (ID&AC) e a referência de cliente como dados de entrada, [000139] Durante o processo de pagamento on-line que usa essa credencial de pagamento de VMC(A)i, o PIN é inserido no aplicativo de pagamento de telefone móvel, Nesta realização, o valor de transação (a quantia de pagamento) também ê inserido pelo usuário nó aplicativo de pagamento de telefone móvel de modo tanto o valor de transação quanto o PIN de usuário são entradas para gerar um resultado de OTP (a segunda parte da credencial). Em um exemplo particular, o OTP é um resultado de 7 dígitos, CD' (4 dígitos) e CW (3 dígitos). CD’ será uma data de caducidade válida no sistema de meio de pagamentos.

[000140] A tentativa, de transação de pagamento sem contato é realizada usando 1MN/PAN/CD7CVV’ e o criptograma como credenciais de modo que a primeira parte da credencial foi calculada no lado de servidor e a segunda parte no aplicativo de pagamento de telefone móvel, usando o PIN e o valor de transação como dados de entrada.

[000141] O módulo de servidor de pagamentos processa o PAN recebido e obtém os dados de referência de cliente <&. dispositivo, de modo que possa designar a transação para uma conta particular (PIN, Chaves de OTP, etc.). No contexto de uma transação on-line, o valor de transação é conhecido no lado de servidor e o PIN é armazenado no modulo de servidor de pagamentos de modo que o OTP possa ser verificado pelo módulo de servidor de pagamentos. Se a verificação de OTP tiver êxito, as credenciais são validadas e a transação pode ser autorizada no host do banco como sendo uma transação de cartão (A). As mensagens de resposta ao banco adqnirente referir-se-ão, não obstante, a uma transação de VMC(A)L [000142} De modo vantajoso, calcular parte da credencial no aplicativo de pagamentos de telefone móvel fornece ao usuário e ao sistema um nível superior de segurança no ciclo ao vivo de credenciais de pagamento.

[000143] A Figura 2.d é um fíuxograma ilustrando parcíalmeníe úma realização de um método de acordo com a invenção. A primeira parte do gráfico mostra um pagamento on-line sem contato móvel (1) como aquele descrito na figura 2.c, onde a primeira parte de uma credencial é constituída por BIN.ZPAN/CS2CD./CVV’ & a

31/36 chave derivada e a segunda parte relacionasse aos valores de CD‘& CVV* calculados no celular (o criptograma. é calculado com base na chave derivada).

[000144] No contexto desta realização, tal transação de pagamento on-line sem contato móvel (1) que usa as primeiras e segundas partes da credencial já foi aceita (“a primeira 'transação’*) e pelo menos uma transação adicional (2) que posteriormente usa pelo menos parte das mesmas primeiras e segundas partes da credencial f ‘as transações sucessivas”) é aceita com base na verificação de OTP da primeira transação.

(000145] A Figura 2,d também ilustrou um DDBB dos valores de PAN/CD’/CVV* das transações previamente aceitas de pagamento on-line. sem contato móvel, que os servidores para os fins de rastrear se uma transação particular é unia sucessiva ou não. Então, cada uma das transações sucessivas é correspondida à primeira transação com base no uso de pelo menos parte das primeiras e segundas partes da credencial, [000146] Em outra realização particular, cada uma das transações sucessivas é correspondida à primeira transação com base no uso de pelo menos parte das primeiras e segundas partes da credencial e o uso de pelo menos um parâmetro adicional, esse parâmetro sendo incluído no fluxo de transação da primeira transação e transações sucessivas. Em um exemplo particular, pelo menos um parâmetro adicional é o código de comerciante. Então, nesta realização, o DDBB das transações previamente aceitas de MVC também deve incluir pelo menos um parâmetro adicional mencionado.

[000147] Por vezes, uma credencial necessária para um pagamento de internet é um subconjunto da credencial exigido para um pagamento móvel sem contato de modo que seria possível realizar um pagamento de internet usando tal subconj unto.

[000148] Em uma realização, o usuário seleciona através de seu aplicativo de pagamento de telefone móvel para efetuar um pagamento de internet e a segunda parte da credencial (valores de CD‘ & CW na figura 2.d.l) junto com pelo menos uma parte da primeira parte da credencial (BIN/PAN7CS na figura 2,d. 1) são usadas para realizar tal pagamento.

32/36 [000149] A mesma lógica já descrita na figura 2.d para pagamentos on-line sem contato móvel,· relacionados a aceitar as transações sucessivas da base da assinatura eletrônica verificada de uma primeira transação, também pode ser aplicada aos pagamentos de internet. Então, em uma realização, uma transação de internet que usa pelo menos uma parte da primeira parte da credencial e a segunda parte da credencial já foi aceita (“a primeira transação·’) e pelo menos w transação adicional que posteriormente usa a mesma pelo menos uma parte da primeira parte da credencial e a segunda parte da credenciai (“as transações sucessivas”) é aceita com base na verificação de OTP da primeira transação.

(0()0150] Em uma realização particular, cada uma das transações sucessivas é ligada à primeira transação com base no uso de pelo menos uma parte da primeira parte da credencial e a segunda parte da credencial. Em outra realização, pelo menos um parâmetro adicional podería ser adicionado para tomar o processo de correspondência mais eficiente, sendo esse parâmetro incluído no fluxo de transação da primeira transação e transações sucessivas.

[009151] A Figura 2.e é um lluxograma ilustrando parcialmente uma realização de um método para pagamentos off-line móveis sem contato de acordo com a invenção.

[000152] Esse diagrama mostra um número máximo pré-definido de (10) credenciais armazenadas no telefone móvel em determinado tempo e o aplicativo de telefone móvel limita os pagamentos off-line móveis sem contato usando tais credenciais até o valor máximo de transação agregado de pagamentos off-line. .Então, efetuar os pagamentos off-line para um valor superior agregado exige que o usuário corretamente insira o valor de PIN, de modo que o módulo de servidor de pagamentos envie novas credenciais ao telefone móvel de usuário registrado e o aplicativo de pagamento de telefone móvel definirá novamente o valor de transação agregado de pagamentos offdine ao máximo.

[000153] As etapas (1) e (Γ) ilustra o usuário efetuando um pagamento off-line sem contato móvel e a autorização sendo enviada ao módulo de servidor de pagamentos em modo de 'lote. Então, para transações off-line móveis sem contato, o módulo de servidor de pagamentos verifica o OTP a posteriori.

33/36 [000154] Na etapa (2), um processo de atualização de credenciais pode ser realizado, obtendo vantagem que o usuário inseriu o valor de PIN com relação a um pagamento. Se o valor de PIN não estiver correto, o processo de atualização de credenciais não ocorrerá.

[000155] As credenciais disponíveis em Τ=0 são associadas a um valor de quantia máximo para pagamentos off-line móveis sem contato. A etapa (3) mostra como o valor de quantia máximo para pagamentos off-line móveis sem contato diminui para (XX - Y) euro após pagamentos em T 1 e como o valor de quantia disponível para pagamentos off-line e atualizado para o valor máximo de X euro após um processo de atualização de credenciais com êxito (resultado de uma inserção correta de valor de PIN no celular pelo usuário).

[000156] A Figura 2.f é um fluxograma ilustrando parcialmente outra realização de um método para pagamentos off-line móveis sem contato de acordo com a invenção.

[000157] Nesta realização, existe um número pré-defímdo máximo da primeira parte de um conjunto de credenciais para pagamentos off-line moveis sem contato que pode ser armazenado no telefone móvel em determinado instante de tempo e, assim que o período de validade da primeira parte de cada uma de tais credenciais, expirar, o aplicativo de pagamento de telefone móvel limita os pagamentos off-line móveis sem contato que usam tal primeira parte de cada uma de tais credenciais.· Então, para realizar os pagamentos off-line móveis sem contato assim que tal primeira parte do conjunto de credenciais para pagamentos móveis off-line sem contato tiver expirado, o usuário deve coríetamente inserir o valor de PIN, de modo que o módulo de servidor de pagamentos enviará novas primeiras partes válidas das credenciais para pagamentos offline móveis sem contato ao telefone móvel de usuário registrado.

[000158] A Etapa (1) ilustra o usuário inserindo o PIN para solicitar a primeira parte de um conjunto de credenciais para pagamentos offline móveis sem contato. O valor de OTP(PlN) é verificado e, se correto, aquelas credenciais parç-ialmente calculadas são baixadas no celular. Em um exemplo particular, somente uma credencial será baixada, com uma validade de poucos minutos.

34/36 [000159] O processo (2) mostra um pagamento off-line sem contato móvel O usuário insere o PIN via o aplicativo móvel de pagamento e agita o celular próximo ao Terminal de Ponto dc Venda de comerciante (FOS). O aplicativo móvel de pagamento- então recebe do POS. a quantia de transação e o tipo de transação (offline), seleciona uma credenciai parcialmente calculada para os pagamentos off-line e calcula o OTP (quantia de transação, PIN) e a criptograma para o pagamento offline.

[000160] Na etapa (3), as transações off-line móveis sem contato são enviadas ao módulo de servidor de pagamentos em modo de lote. Conforme o usuário foi estimulado a inserir novamente o PIN no processo (2), o módulo de servidor de pagamentos será capaz de verificar o PIN a -posteriori.

[000161] A Figura 2.g é um fluxograma ilustrando parcialmente uma realização de um método de acordo com a invenção, e fornece um método alternativo para o usuário pagar ao prestador de serviço para determinados serviços de emissão de bilhetc/pagamento.

[000162] A Figura 2.g.l levemente modifica o processo descrito com relação â figura l.b, de modo que a etapa (2) ê agora dividida nas etapas (2.a) até (2.d). Na etapa (2.a), um ou diversos comerciantes pagam /Vm nome do usuário” ao prestador óe serviços de emissão de bilhete por determinados serviços de emissão de bilhete para o usuário, no contexto de um programa de fidelidade oferecido pelo(s) comerciante(s). Em um exemplo particular, o(s) comerciante(s) paga(m) pelo direito de transporte representado como cartão “A” no módulo de servidor e a credencial de VMC(A) é então gerada pelo módulo de servidor de emissão de bilhete.

[000163] Na etapa (2.b), o usuário solicita (já. pagos) os serviços de emissão de bilhete via o canal de distribuição de rede e o processo continua conforme descrito com relação à figura 1 .b.

[000164] Posteriormente, o usuário paga por determinados produtos e/ou serviços em um ou diversos comerciantes associados (etapa (2.c)), e pelo menos um comerciante transfere parte de tais quantias de transações ao prestador de serviços de emissão de bilhete (etapa (2.d)) para que ele ofereça determinados serviços de emissão de bilhete ao usuário. Em uma implantação particular, as quantias de

35/36 transações acumuladas são usadas para conceder os direitos de usuário novas credenciais de VMC(A). Então, graças a um programa de fidelidade tratado para pagar os direitos de emissão de bilhete em nome do usuário, o usuário será capaz de usar seu aplicativo de emissão de bilhete de telefone móvel para acessar os serviços de emissão de bilhete em uma multiplicidade de pontos de acesso (p.ex., para acessar qualquer Ônibus municipal).

[000165] Equivalentemente, a figura 2.g.2 modifica o processo descrito com relação à figura 2.b, de modo que tal etapa (2) é agora dividida nas etapas (2.a) até (2.d). Na etapa (2.a), uni ou diversos comerciantes pagam “em nome do usuário’* ao prestador de serviços de pagamento para determinados serviços de pagamento para o usuário, no contexto de um programa de fidelidade oferecido pelo(s) comercianfe(s), Em um exemplo particular, o(s) comerciante(s) paga(m) pelo direito de pagamentos representado como cartão A'^A nó modulo de servidor e as credenciais de VMC(A)i são então geradas pelo módulo de servidor de pagamentos. [(1()1)166] Na etapa (2.b), o usuário solicita (já. pagos) os serviços de pagamento via o canal de distribuição de rede e o processo contínua conforme descrito com relação à figura 2.b.

[000167] Posteriormente, o usuário paga por determinados produtos e/ou serviços em um ou diversos comerciantes associados (etapa (2.c)), e pelo menos um comerciante transfere parte de tais quantias de transações ao prestador de serviços de pagamento (etapa (2.d)) para que ele ofereça determinados serviços de pagamento ao usuário. Em uma implantação particular, o usuário pode utilizar seu aplicativo de pagamento de telefone móvel para pagar nos comerciantes até o limite das quantias de transações acumuladas como um resultado das diferentes compras em pelo menos um comerciante. Então, através desta realização, o usuário pode pagar em qualquer comerciante suportando os pagamentos móveis sem contato (ao invés de usar o ponto de fidelidade de loop fechado em um conjunto reduzido de comerciantes associados), (000168] Embora a presente invenção tenha sido descrita em detalhes para fins de ilustração, fica entendido que tal detalhe é exclusivamente para tal finalidade, e as variações podem ser lá feitas por aqueles com habilidade na técnica sem desviar do

36/36 escopo da invenção. Desse modo, enquanto as realizações preferidas do método e do sistema, móvel foram descritas em referência ao ambiente em que foram desenvolvidas, elas são meramente ilustrativas dos prmcipios da invenção. Outras realizações e configurações podem ser concebidas sem desviar do escopo das reivín di cações anexas, [000169] Além disso, embora as realizações da invenção descritas com referência aos desenhos compreendam mecanismo de computador e processos realizados em mecanismo de computador, a invenção também se estende aos programas de computador, particularmente programas de computador em um portador, adaptado para colocar a invenção em prática. O programa pode estar na forma de código fonte, código objeto, uma fonte intermediária de código e código objeto, tal como, em forma parcialmente compilada, ou em qualquer outra forma adequada pára uso na implantação dos processos de acordo com. a invenção. O portador pode ser qualquer entidade ou dispositivo capaz de transportar o programa. Por exemplo, o portador pode compreender um meio de armazenamento, tal como, um ROM, por exemplo, um CD-ROM ou um ROM semicondutor, ou um meio de gravação magnética, por exemplo, um disco flexível ou disco rígido. Além disso, o portador pode ser um portador transmissível, tal como, um sinal elétrico ou ótico que pode ser transmitido via cabo elétrico ou ótico ou por rádio ou outro meio. Quando o programa e incorporado em um sinal que pode ser transmitido diretamente por um cabo ou outro dispositivo ou meio, o portador pode ser constituído por tal cabo ou outro dispositivo ou meio. Altemativamente, o portador pode ser um circuito integrado em. que o programa é embutido, o circuito integrado sendo adaptado para realizar, ou para uso na realização de, os processos relevantes.

Claims (25)

1, MÉTODO E SISTEMA PARA ATIVAR A EMISSÃO DE BILHETE/PAGAMENTOS MÓVEL SEM CONTATO VIA UM APLICATIVO DE TELEFONE MÓVEL, o método compreendendo as seguintes- etapas:

(a) um usuário paga a um prestador de serviço pelos serviços de emissão de bilhete/pagamento;

(b) associado ao pagamento e a um direito concedido correspondente para usar os serviços relacionados de emissão de bilhete/pagamento, um módulo de servidor de emissão de bilhete/pagamentos prepara as credenciais de emissão de bilhete/pagâmento para uso pelo usuário e envia-as ao telefone móvel do usuário;

(c) o telefone móvel do usuário recebe as credenciais e armazena-as para uso em um sistema de emissão de bilhete sem contato de transporte, no caso das credenciais de emissão de bilhete, ou para uso nos pagamentos móveis sem contato, no caso das credenciais de pagamento;

(d) o referido método ecaraeterizado pelo tato de que cada credencial preparada é inequivocamente associada ao telefone móvel do usuário registrado e a um código de ativação e parcialmente ativa o telefone móvel para acesso de emissão de bilhete sem contato, no caso das credenciais de emissão de bilhete, ou para pagamentos móveis sem contato, no caso das credenciais de pagamento; onde a capacitação de telefone móvel pata cada acesso de emissão de bilhete sem contato- ou pagamento móvel sem contato também exige ao usuário inserir um número de identificação pessoal (PIN) no aplicativo de emissão de bilhete/pagamento de telefone móvel; o módulo de servidor de emissão de bilhete/págamentos envia as credenciais ao telefone móvel de usuário registrado apôs validação com êxito de uma Senha Única (OTP) recebida do aplicativo de emissão de bilhete/pagamentos de telefone móvel.

2. MÉTODO, de acordo com a reivindicação 1 é caracterizado onde o módulo de servidor de emissão de bilhete/pagamentos divide o direito concedido de emissão de bühete/pagamento em diversas partições e gera uma credencial independente para cada uma de tais partições,

2/6

3< MÉTODO, de acordo com a reivindicação 2 é caracterizado onde um primeiro conjunto de credenciais é enviado ao aplicativo de telefone móvel, e novas credenciais são enviadas ao aplicativo de telefone móvel quando sucessivamente solicitado do dispositivo móvel de usuário, até o limite do direito concedido para usar os serviços de emissão de bilhete/pagamento sem contato.

4. .MÉTODO, de acordo com quaisquer das reivindicações 1 até 3 é caracterizado onde pelo menos uma credencial é desativada em, ou excluída de, o aplicativo de telefone móvel ao enviar uma mensagem de desativação ou exclusão do módulo de servidor de emissão de bilhete/pagamentos ao aplicativo de telefone móvel de usuário.

5. MÉTODO, de acordo com quaisquer das reivindicações 1 até 4 é caracterizado onde o direito de usar os serviços de emissão de bílbete/pagamento pode ser estendido pelo usuário pagamento pelo menos, de modo que a nova emissão de bilhete/partições de direito de pagamento possa ser dinamicamente gerada no módulo de servidor de emissão de bilhete/pagamentos.

6» MÉTODO, de acordo com quaisquer das reivindicações 1 até 5 é caracterizado onde o aplicativo de telefone móvel limita a solicitação de novas credenciais com base nas informações sobre as credenciais que já estão armazenadas no telefone móvel.

7. MÉTODO, de acordo com quaisquer das reivindicações 1 até 6é caracterizado onde as credenciais de emissão de bilhete/pagamento são bloqueadas no aplicativo de telefone móvel após um número de inserções erradas do Número de Identificação Pessoal, e uma mensagem de aviso é enviada ao módulo de servidor de emissão de bilhete/pagamentos.

8. MÉTODO, de acordo com quaisquer das reivindicações 1 até 7 é caracterizado onde o módulo de servidor de emissão de bilhete/pagamentos bloqueia o direito concedido de emissão de bilhete/pagamentos após um número de verificações erradas de um OTP recebido do aplicativo de telefone móvel, e uma mensagem de bloqueio de credenciais é enviada ao aplicativo de telefone móvel.

9. MÉTODO, de acordo com quaisquer das reivindicações 1 até 8 é caracterizado onde, para as transações on-line de pagamento móvel sem contato, uma segunda parte da credenciai é calculada pelo próprio aplicativo de telefone móvel usando o valor de transação e o PIN de usuário como entradas para, gerar um resultado de OTP sendo a segunda parte da credencial, onde as primeiras e segundas partes da credencial são usadas para a transação de pagamento móvel sem contato e a verificação de tal OTP pelo módulo de servidor de pagamento é exigida com a finalidade de aceitar ou negar a transação.

10. MÉTODO, de acordo com quaisquer das reivindicações 1 até 8 é caracterizado onde, para as transações on-line de pagamento móvel sem contato, uma segunda parte da credencial é calculada pelo próprio aplicativo de 'telefone móvel, usando o PIN de usuário como entrada para gerar um resultado de OTP sendo a segunda parte da credencial, onde as primeiras e segundas partes da credencial são usadas para a transação de pagamento móvel sem contato e a verificação de tal OTP pelo módulo de servidor de pagamento é exigida com a finalidade de aceitar ou negar a transação.

11. 'MÉTODO, de acordo com a reivindicação 9 ou 10 é caracterizado onde uma transação de pagamento on-line sem contato móvel que usa as primeiras e segundas partes da credencial já foi aceita Ça primeira transação”) e pelo menos uma transação adicional que posteriormente usa pelo menos parte das mesmas primeiras e segundas partes da credencial (“as transações sucessivas”) é aceita com base na verificação de OTP da primeira transação,

12. MÉTODO, de acordo com a reivindicação 11 é caracterizado onde cada uma das transações sucessivas é correspondida à primeira transação com base no uso de pelo menos parte das primeiras e segundas partes da credencial.

13. MÉTODO, de acordo com a reivindicação II é caracterizado onde cada uma das transações- sucessivas é correspondida à primeira transação com base no uso de pelo menos parte das primeiras e segundas partes da credencial e o uso de pelo menos um parâmetro adicional, esse parâmetro sendo incluído no fluxo de transação da primeira transação e transações sucessivas.

14. MÉTODO, de acordo com quaisquer das reivindicações I até 8 é caracterizado onde existe um número máximo pré-defintdo de credenciais armazenado no telefone móvel em determinado tempo e o aplicativo de pagamento de telefone móvel limita os pagamentos off-line móveis sem contato usando tais credenciais até o valor máximo de transação agregado de pagamentos off-line.

15. MÉTODO, de acordo com quaisquer das reivindicações 9 ou 10 é caracterizado onde o usuário seleciona através de seu aplicativo de pagamento de telefone móvel para efetuar um pagamento de internet e a segunda parte da credencial junto com pelo menos uma parte da primeira parte da credencial are usadas para realizar tal pagamento.

16. MÉTODO, de acordo com a reivindicação 15 é caracterizado onde uma transação de internet que usa pelo menos uma parte da primeira parte da credencial e a segunda parte da credencial já tiver sido aceita (“a primeira transação·') e pelo menos uma transação adicional que posterionuente usa a mesma pelo menos uma parte da primeira parte da credencial e a segunda parte da credencial (^was transações sucessivas'’) é aceita com base na verificação de OTP da primeira transação.

17. MÉTODO, de acordo com a reivindicação 16 é caracterizado onde cada uma das transações sucessivas é ligada à primeira transação com base no uso de pelo menos urna parte da primeira parte da credencial e a segunda parte da credencial.

18. MÉTODO, de acordo com a reivindicação 16 é caracterizado onde cada uma das transações sucessivas é ligada à primeira transação com base no uso de pelo menos uma parte da primeira parte da credencial e a segunda parte da credencial e o uso de pelo menos um parâmetro adicional, sendo esse parâmetro incluído no fluxo de transação da primeira transação e transações sucessivas.

19. MÉTODO, de acordo com quaisquer das reivindicações 1 até 18 é caracterizado onde o usuário paga por determinados produtos e/ou .serviços em um ou diversos comerciantes associados, e pelo menos um comerciante transfere parte de tais quantias de transações ao prestador de serviços de emissão de

5/6 bilhete/pagatnentos para que ele ofereça determinados serviços de emissão de bilhete/pagamentos ao usuário.

2(1. MÉTODO, de acordo com a reivindicação 19, onde um ou diversos comerciantes pagam ao prestador de serviços de emissão de bilhete/pagamento para determinados serviços de emissão de bilhete/pagamento para o usuário.

21. MÉTODO, de acordo com quaisquer das reivindicações I até 8 é caracterizado onde existe um número pré-defmido máximo da primeira parte de um conjunto de credenciais para pagamentos off-line móveis sem contato que pode ser armazenado no telefone móvel em determinado instante de tempo e, assim que o periodo de validade da primeira parte de cada uma de tais credenciais expirar, o aplicativo de pagamento de telefone móvel limita os pagamentos off-line móveis sem contato que usam tal primeira parte de cada uma de tais credenciais.

22. PROGRAMA DE COMPUTADOR é caracterizado por compreender as instruções de programa para fazer com que um computador conduza o método de quaisquer das reivindicações 1 a 21.

23. 'PROGRAMA DE COMPUTADOR, de acordo com a reivindicação 22 é caracterizado incorporado em um meio de armazenamento.

24. PROGRAMA DE COMPUTADOR, de acordo com a reivindicàçãõ 22 é caracterizado suportado em um sinal de portador.

25. MÉTODO E SISTEMA PARA ATIVAR A EMISSÃO DE BILHETE/PAGAMENTOS MÓVEL SEM CONTATO VIA UM APLICATIVO DE TELEFONE MÓVEL, o referido sistema compreendendo:

meio de registro para registrar os usuários para serviços de emissão de bilhete/pagamento, meio de pagamento para permitir ao usuário pagar pelos serviços de emissão de bilhete/pagamento, meio de geração de credenciais para preparar no módulo de servidor de emissão de bilhete/pagamentos, e com base nos direitos concedidos de emissão de bilhete/pagamento, as credenciais de emissão de bilhete/pagamento para uso pelo usuário registrado; e meio de transmissão para enviar as referidas credenciais ao

6/6 telefone móvel de usuário registrado; e meio de recepção e armazenamento para receber no telefone movei as credenciais e armazená-las para uso em um sistema de emissão de bilhete sem contato de transporte, no caso das credenciais de emissão de bilhete, ou para uso nos pagamentos móveis sem contato, no caso das credenciais de pagamento,caracterizado pelo referido sistema compreenderam meio de processamento para associar inequivocamente cada credencial que parcialmente ativa o telefone móvel para acesso de emissão de bilhete sem contato, no caso de credenciais de emissão de bilhete, ou para pagamentos móveis sem contato, no caso das credenciais de pagamento, para o telefone móvel de usuário registrado e para um código de ativação; meio de processamento e verificação para permitir a capacitação de telefone móvel para cada acesso de emissão de bilhete sem contato ou pagamento móvel sem contato, que também é com base no usuário inserir um Número de Identificação Pessoal (PIN) no aplicativo de emissão de bílhete/pagamento de telefone móvel; meio de processamento e transmissão no aplicativo de emissão de bílhete/pagamento de telefone móvel para calcular um OTP e enviá-lo ao módulo de servidor de emissão de bilhete/pagamentos: e meio de processamento e verificação no módulo de servidor de emissão de bílhete/pagamentos para validar o OTP recebido.

26. SISTEMA, de acordo com a reivindicação 25 é caracterizado onde õ sistema conduz, um método de acordo com quaisquer das reivindicações 1 até 2 L