BRPI0616470A2 - leitor, cartão, aparelho, e, aparelho leitor para reduzir um tempo de interação para uma transação sem contato, e para evitar um ataque de intermediários na transação sem contato - Google Patents

Abstract

MéTODO PARA AUMENTAR RESOLUçãO DE COR, E, ISPOSITIVO. A invenção relaciona-se a um método para aumentar resolução de cor e particularmente para obter resolução de 18 bits em um mostrador usando uma memória temporária de quadro de sistema de 16 bits por pixel. A invenção usa lógica para criar valores de pixel intermediários entre valores de cor de 16 bpp. A invenção propõe armazenar a imagem no memória temporária de quadro de sistema sempre com um número fixo de bits e usando Tremor de Difusão de Erro. Então, um filtro de pós-processamento é provido para prover a resolução de cor aumentada usando um maior número de bits por pixel como aceito pelo meio de exibição. A invenção também relaciona-se a um dispositivo explorando o método.

Description

"LEITOR, CARTÃO, APARELHO, E, APARELHO LEITOR PARAREDUZIR UM TEMPO DE INTERAÇÃO PARA UMA TRANSAÇÃOSEM CONTATO, E PARA EVITAR UM ATAQUE DEINTERMEDIÁRIOS NA TRANSAÇÃO SEM CONTATO"

REFERÊNCIA CRUZADA PARA PEDIDOSRELACIONADOS

Este pedido reivindica o benefício da prioridade do Pedido dePatente dos Estados Unidos Provisório No. 60/721.454, depositado em 28 deSetembro de 2005, e Pedido de Patente dos Estados Unidos Provisório No.60/807.775, depositado em 19 de Julho de 2006.

C. DECLARAÇÃO RELATIVA A ACORDOS DEPESQUISA DE PATROCÍNIO FEDERAL - NÃO APLICÁVEL

D. PARTES A JUNTAR AO ACORDO DE PESQUISA -NÃO APLICÁVEL

E. INCORPORAÇÃO DE MATERIAL SUBMETIDO EMCD - NÃO APLICÁVEL

F. FUNDAMENTOS

Este pedido descreve uma invenção que é relacionada,geralmente e em várias realizações, a um dispositivo, sistema e método parareduzir um tempo de interação para uma transação sem contato.

Tecnologias de comunicação sem contato e sem fio tem setornado mais difundidas em anos recentes. Na industria de pagamento,pagamento sem contato tem um número de vantagens sobre ambastecnologias de tira magnética tradicional e protocolos de pagamento baseadosem contato de chip. Por exemplo, cartões de pagamento tradicionais sãoconhecidos por operar relativamente lentos, e cartões de tira magnética sãoconhecidos por não serem suficientemente seguros. Cada uma destastecnologias requer adicionalmente um encaixe em um leitor de terminal queprecisa ser mantido por um comerciante.Pagamento sem contato não requer uma fenda de encaixe naqual inserir o cartão. O consumidor mantém controle sobre o cartão emeramente posiciona o cartão próximo ao leitor do terminal todas as vezesque for necessário. As especificações tradicionais adotadas pela industria depagamento para pagamento com chip baseado em contato, geralmenterequerem que o consumidor posicione o cartão próximo ao leitor de terminalpor diferentes vezes e/ou por períodos estendidos de tempo, no sentido decompletar uma transação. Com ambos comerciantes e consumidoresdesejando tempos de transação rápidos, transações sem contato executadas deacordo com especificações tradicionais deixam de satisfazer às exigências domercado.

Comerciantes e consumidores estão também demandando queas transações sem contato sejam mais seguras. Embora cartões baseados emtira magnética sem contato emitidos mais recentemente possam ser maisseguros que cartões de tira magnética, tais cartões baseados em tira magnéticasem contato são tipicamente projetados somente para transações em linha.Para transações sem contato fora de linha executadas de acordo com asespecificações tradicionais, as transações podem ser susceptíveis a váriasintromissões fora de linha, tipos de ataques geralmente referidos comoataques de capa ("sleeve "), ataques de cavalo de Tróia, etc.

Em um tipo de ataque de capa, um dispositivo interceptadados transmitidos sem fio a partir de um leitor de cartão que é destinado aum cartão sem contato. O dispositivo altera os dados e subseqüentementetransmite os dados alterados ao cartão. Ao invés de receber os dadostransmitidos pelo leitor de cartão, o cartão recebe os dados alteradostransmitidos pelo dispositivo. O cartão subseqüentemente processa os dadosalterados e transmite uma mensagem relacionada aos dados alterados ao leitorde cartão. O leitor de cartão subseqüentemente concede aprovação datransação, com base na informação presente na mensagem transmitida pelocartão. Em um outro tipo de ataque de capa, um dispositivo intercepta dadostransmitidos sem fio a partir do cartão que são destinados ao leitor de cartão.O dispositivo altera os dados e subseqüentemente transmite os dados alteradosao leitor de cartão. O dispositivo altera os dados e subseqüentementetransmite os dados alterados ao leitor de cartão. Ao invés de receber os dadostransmitidos pelo cartão, o leitor de cartão processa os dados alterados econcede a aprovação da transação com base na informação presente nos dadosalterados transmitidos pelo dispositivo. Em outros tipos de ataques de capa odispositivo pode causar uma negativa de serviço, não enviando os dadosinterceptados ao cartão ou leitor de cartão.

Em um tipo de ataque de cavalo de Tróia, software maliciosoembutido no cartão altera dados válidos antes da informação ser enviada aoleitor de cartão. O leitor de cartão definitivamente concede aprovação para atransação, com base nos dados alterados. Em um outro tipo de ataque decavalo de Tróia, software malicioso embutido no leitor de cartão altera dadosválidos antes do processo de autorização. O leitor de cartão definitivamenteconcede aprovação para a transação, com base nos dados alterados.

Para uma dada transação fora de linha, um ataque deintromissão ("man in the Jniddle") pode ser utilizado para reduzir a quantia datransação como reconhecido definitivamente pelo cartão e pelo leitor decartão. Por exemplo, para uma dada transação fora de linha envolvendo aaquisição de bens de um comerciante, o leitor de cartão pode transmitir dadossem fio destinados ao cartão, o que indica que o valor da transação é igual a$15. Entretanto, antes dos dados serem recebidos pelo cartão, o dispositivointercepta os dados e altera os dados de tal modo que os dados alteradosindicam que o valor da transação é somente igual a $1. Uma vez que o cartãosubseqüentemente recebe os dados alterados e transmite a mensagemrelacionada aos dados alterados ao leitor de cartão, o leitor de cartãosubseqüentemente concede aprovação de uma transação igual a somente $1.Ao receber a aprovação, o comerciante libera as mercadorias acreditando quea quantia da transação aprovada foi igual a $15. A diferença entre a quantia datransação real e a quantia da transação reduzida pode afetar a quantiadefinitivamente recebida pelo comerciante a partir de um emissor do cartão.

G. BREVE SUMÁRIO DA INVENÇÃO

Em um aspecto geral, esta aplicação descreve um leitor. Deacordo com várias realizações, o leitor compreende uma interface sem contatoe um módulo de transação. O módulo de transação é acoplado à interface semcontato, e é estruturado e arranjado para processar uma transação com menosde meio segundo de tempo de interação entre um cartão e o leitor.

Em um outro aspecto geral, este pedido descreve um cartão.De acordo com várias realizações, o cartão compreende um módulo detransação estruturado e arranjado para comunicação sem fio, e o cartão éestruturado e arranjado para operar em um modo de chip e um modo de dadosde tira magnética.

Em um outro aspecto geral, este pedido descreve um sistema.De acordo com várias realizações, o sistema compreende um leitor e umcartão. O leitor compreende uma interface sem contato e um módulo detransação. O cartão é estruturado e arranjado para se comunicar com o leitor,via interface sem contato. O módulo de transação é acoplado à interface semcontato. O módulo de transação é acoplado à interface sem contato e éestruturado e arranjado para processar uma transação sem contato com menosde meio segundo de tempo de interação entre o cartão e o leitor.

Em um outro aspecto geral, este pedido descreve um métodopara reduzir um tempo de interação para uma transação sem contato. Deacordo com várias realizações, o método compreende, em um leitor, executarpelo menos um processo de gerenciamento de risco baseado na transação,antes de energizar uma interface sem contato, iniciar comunicação com umcartão utilizado para a transação sem contato, receber informação associadaao cartão e terminar a comunicação com o cartão antes de autorizar atransação sem contato.

Em um outro aspecto geral, o pedido descreve um método paraevitar um ataque de intromissão em uma transação sem contato. De acordocom várias realizações, o método compreende receber uma assinaturadinâmica que compreende um contador de transação de aplicação, um númeroimprevisível de terminal, uma quantia de transação, um código de moedacorrente de transação e um número de cartão imprevisível. O métodocompreende também receber um número de cartão imprevisível, recalcular aassinatura dinâmica usando o número de cartão imprevisível e memorizar atransação sem contato fora de linha se a assinatura dinâmica é validada.

Aspectos da invenção podem ser implementados por umdispositivo de computação e/ou um programa de computador armazenado emum meio legível por computador. O meio legível por computador podecompreender um disco, um dispositivo e/ou um sinal propagado.

H. DESCRIÇÃO DOS DESENHOS

Várias realizações da invenção são descritas aqui por meio deexemplo, em conjunto com as figuras a seguir.

Figura 1 ilustra várias realizações de um leitor para reduzir umtempo de interação para uma transação sem contato;

Figura 2 ilustra várias realizações de um sistema para reduzirum tempo de interação para uma transação sem contato;

Figura 3 ilustra várias realizações de um método para reduzirum tempo de interação para uma transação sem contato;

Figura 4 é um fluxograma simplificado ilustrando váriasrealizações de uma etapa de processamento de transação preliminar dométodo da Figura 3;

Figura 5 é um fluxograma simplificado ilustrando váriasrealizações de uma etapa de seleção de aplicação do método da Figura 3;Figura 6 é um fluxograma simplificado ilustrando váriasrealizações de uma etapa de autorização do método da Figura 3; e

Figura 7 ilustra várias realizações de um método para reduzirum tempo de interação para uma segunda transação sem contato.

I. DESCRIÇÃO DETALHADA DA INVENÇÃO

Deve ser entendido que pelo menos algumas das figuras edescrições da invenção foram simplificadas para focar em elementos que sãorelevantes para um entendimento claro da invenção, enquanto elimina, parafins de clareza, outros elementos que aqueles especialistas na técnicaverificarão que podem também constituir uma porção da invenção. Portanto,como tais elementos são bem conhecidos na técnica, e como não facilitamnecessariamente um melhor entendimento da invenção, uma descrição de taiselementos não é provida aqui.

Figura 1 ilustra várias realizações de um leitor 10 para reduzirum tempo de interação para uma transação sem contato. O leitor 10 pode serqualquer tipo de dispositivo que está estruturado e arranjado para secomunicar com um outro dispositivo, via uma interface sem contato. Deacordo com várias realizações, o leitor 10 pode ser um dispositivo docomerciante que está integrado a um dispositivo de ponto de venda, ou umdispositivo de comerciante que é separado, porém está em comunicação comum dispositivo de ponto de venda. Conforme usado aqui, a frase "tempo deinteração" refere-se ao tempo de interação entre o leitor 10 e um outrodispositivo, e não inclui o tempo requerido para entrar em linha paraautorização ou para o leitor validar uma assinatura estática ou dinâmica paraautenticação de dados fora de linha. O leitor 10 pode ser utilizado cominfraestrutura de sistema de pagamento existente para mercados que requeremtempos de transação mais rápidos que aqueles associados a protocolos depagamentos tradicionais. De acordo com várias realizações, o leitor 10 podeser utilizado para reduzir o tempo de interação a menos de aproximadamente500 milissegundos.

O leitor 10 compreende uma interface sem contato 12 e ummódulo de transação 14, acoplados à interface sem contato. O módulo detransação 14 é estruturado e arranjado para processar uma transação semcontato com menos da metade de um segundo de tempo de interação entre oleitor IOe um outro dispositivo. O módulo de transação 14 pode também serestruturado e arranjado para efetuar autenticação de dados estática e/ouautenticação de dados dinâmica conforme descrito em mais detalhe abaixo.De acordo com várias realizações, o leitor 10 compreende adicionalmente ummódulo de segurança 16 acoplado ao módulo de transação 14. O módulo desegurança 16 é estruturado e arranjado para evitar um ataque de intromissãoem uma transação sem contato.

Cada um dos módulos 14, 16 pode ser implementado emhardware ou em firmware. De acordo com várias realizações, os módulos 14,16 podem ser implementados como aplicações de software, programas decomputador, etc., utilizando qualquer linguagem de computador adequada(por exemplo, C, C++, Delphi, Java, JavaScript, Perl, Visual Basic, VBScript,etc.) e pode ser realizado permanentemente ou temporariamente em qualquertipo de máquina, componente, equipamento físico ou virtual, meio dearmazenagem ou sinal propagado capaz de fornecer instruções a umdispositivo. O código de software pode ser armazenado com uma série deinstruções ou comandos em um meio legível por computador, de tal modo quequando um processador lê o meio, as funções aqui descritas são executadas.Conforme usado aqui, o termo "meio legível por computador" pode incluir,por exemplo, dispositivos de memória magnéticos e ópticos tais comodisquetes, discos compactos de ambas variedades de somente leitura ouescrevíveis, controladores de disco óptico e controladores de disco rígido. Ummeio legível por computador pode também incluir armazenagem de memóriaque pode ser física, virtual, permanente, temporária, semi permanente e/ousemi temporária. Um meio legível por computador pode incluiradicionalmente um ou mais sinais propagados, e tais sinais propagados podemou não ser transmitidos em uma ou mais ondas de portadora. Embora osmódulos 14, 16 sejam mostrados na Figura 1 como dois módulos separados,um especialista na técnica verificará que a funcionalidade dos módulos 14, 16pode ser combinada em um único modo.

Figura 2 ilustra várias realizações de um sistema 20 parareduzir um tempo de interação para uma transação sem contato. Conformeusado aqui, o termo "cartão" refere-se a qualquer tipo de dispositivo que podese comunicar com o leitor 10 através da interface sem contato 12. De acordocom várias realizações, o cartão 22 pode ser um cartão inteligente, umtelefone móvel, um assistente digital pessoal, etc. O cartão 22 é estruturado earranjado para se comunicar com o leitor 10 via interface sem contato 12. Deacordo com várias realizações, o cartão 22 compreende um módulo detransação 24 estruturado e arranjado para cooperar com o leitor 10 paraexecutar a transação sem contato. O cartão 22 pode compreenderadicionalmente um módulo de segurança 26 estruturado e arranjado paracooperar com o leitor 10 para evitar um "ataque de intromissão" na transaçãosem contato. Os módulos 24, 26 podem ser similares aos módulos 14, 16 doleitor 10. De acordo com várias realizações, o cartão 22 pode ser um cartão demodo dual que é estruturado e arranjado para operar em um modo de chip ouem um modo de dados de tira magnética (utilizando dados equivalentes aTrilha 2). O modo de operação utilizado pelo cartão 22 pode ser determinadopelo cartão 22 com base nas capacidades do leitor 10.

O sistema 20 pode compreender adicionalmente uma rede 28acoplada ao leitor 10 e um emissor 30. A rede 28 pode ser qualquer tipoadequado de rede conhecido na técnica, pode ser acoplada ao leitor 28 dequalquer maneira adequada conhecida na técnica, e pode ser acoplada aoemissor 30 de qualquer maneira adequada conhecida na técnica. A rede 28pode incluir qualquer tipo de sistema de fornecimento incluído, porém nãolimitada a uma rede de área local (por exemplo, Ethernet), uma rede de áreaextensa (por exemplo, a Internet e/ou World Wide Web), uma rede telefônica(por exemplo, analógica, digital, com fio, sem fio, PSTN, ISDN, GSM, GPRSe/ou xDSL), uma rede comutada por pacotes, uma rede rádio, uma rede detelevisão, uma rede de cabo, uma rede de satélite, e/ou qualquer outra rede decomunicações com fio ou sem fio configurada para transportar dados. A rede28 pode incluir elementos, tais como, por exemplo, nós intermediários,servidores proxy, roteadores, chaves e adaptadores configurados paradirecionar e/ou fornecer dados.

Figura 3 ilustra várias realizações de um método 40 parareduzir um tempo de interação para uma transação sem contato. O método 40pode ser implementado pelo sistema 20 da Figura 2. O método 40compreende as etapas gerais de processamento de transação preliminar 42,processamento de descoberta 44, seleção de aplicação 46, processamento deaplicação 48 e autorização de transação 50.

Para minimizar o tempo de interação entre o cartão 22 e oleitor 10 para uma dada transação, a etapa de processamento de transaçãopreliminar 42 é executada pelo leitor 10, antes de requerer que o cartão 22seja apresentado. Durante a etapa de processamento de transação preliminar42, o leitor 10 executa certos processos de gerenciamento de risco baseadosem transação. Por exemplo, de acordo com várias realizações, o leitor 10 podeobter a quantia de transação e comparar a quantia de transação com um limitede transação, um limite de piso, um limite de método de verificação dedetentor do cartão, etc. Uma vez que a etapa de processamento de transaçãopreliminar 42 é completada, o leitor 10 pode orientar um detentor do cartãopara apresentar o cartão 22. Com base no processamento de transaçãopreliminar, o leitor 10 pode requerer que a transação seja terminada,processada em linha ou processada fora de linha. Um fluxogramasimplificado ilustrando várias realizações da etapa de processamento detransação preliminar 42 é mostrado na Figura 4.

A etapa de processamento de descoberta 44 segue a etapa deprocessamento de transação preliminar 42. Uma vez que o cartão 22 éapresentado e está dentro do alcance do leitor 10, o leitor 10 energiza ainterface sem contato 12 e estabelece comunicação com o cartão 22 viainterface sem contato 12, durante a etapa de processamento de descoberta 44.Se o leitor 10 detecta cartões sem contato múltiplos 22 dentro de seu alcance,o leitor 10 pode indicar a condição a um detentor do cartão e pode requisitarque somente um cartão 22 seja apresentado para a transação. Em adição, umleitor 10 pode abortar uma transação durante a etapa de processamento dedescoberta 44 e desenergizar a interface sem contato 12 sob o comando de umcomerciante ou após um período de interrupção predefinido.

A etapa de seleção de aplicação 46 segue a etapa deprocessamento de descoberta 44. Durante a etapa de seleção de aplicação 46,o leitor 10 transmite uma primeira mensagem de comando (por exemplo,SELECIONE PPSE) ao cartão 22. A primeira mensagem de comando podeservir como uma requisição para uma lista de identificadores de aplicação,rótulos de aplicação e indicadores de prioridade de aplicação para aplicaçõesque são suportadas pelo cartão 22 e estão acessíveis via interface sem contato12. Sensível à primeira mensagem de comando, o cartão 22 constrói tal lista etransmite a lista ao leitor 10. De acordo com várias realizações, a lista podeser provida dentro da informação de controle de arquivo (FCI) transmitida aoleitor 10. O leitor 10 então utiliza a lista transmitida pelo cartão 22 paraconstruir uma lista de aplicações comum ao leitor 10 e ao cartão 22. Apósconstruir a lista de aplicações comuns, o leitor 10 transmite uma segundamensagem de comando (por exemplo, SELECIONE AID) para o cartão 22. Asegunda mensagem de comando pode servir como uma requisição paraconduzir a transação utilizando uma aplicação específica a partir da lista deaplicações comuns. De acordo com várias realizações, a aplicação específicapode ser a aplicação comum tendo a prioridade mais alta, conforme indicadopelos indicadores de prioridade de aplicação previamente transmitidos pelocartão 22. Sensível à segunda mensagem de comando, o cartão 22 transmiteuma requisição ao leitor 10 para prover vários detalhes concernentes àscapacidades do leitor IOe exigências específicas de transação do leitor 10. Deacordo com várias realizações, os detalhes requeridos podem ser providos emuma lista de objetos de dados de terminal (por exemplo, PDOL) associada aoleitor 10. Se a lista de objetivos de dados de terminal inclui um elemento dedados particular (por exemplo, qualificadores de transação do terminal), oprocesso avança para a etapa de processamento de aplicação 48. De outromodo, o leitor 10 pode terminar a transação ou tentar processar a transaçãoatravés de uma outra interface. Um diagrama de fluxo simplificado ilustrandovárias realizações da etapa de seleção de aplicação 46 é mostrado na Figura 5.

Durante a etapa de processamento de aplicação 48, o leitor 10transmite uma terceira mensagem de comando (por exemplo, GPO) ao cartão22, sensível à requisição do cartão para detalhes concernentes a capacidadesdo leitor 10 e exigências de transação específicas do leitor 10. A terceiramensagem de comando é estruturada de tal modo que pode ser utilizada nolugar de três comandos separados requeridos por especificações prévias.Reduzindo o número de comandos e respostas requeridos para completar atransação sem contato, o tempo de interação requerido entre o cartão 22 e oleitor 10 é adicionalmente minimizado. A terceira mensagem de comandopode compreender valores para qualquer número de elementos de dadosrequeridos pelo cartão 22. Vários valores de elementos de dados indicam otipo de transações suportadas pelo leitor 10, se o processamento fora de linhae/ou em linha é suportado ou requerido pelo leitor 10, cujos métodos deverificação de detentor do cartão são suportados ou requeridos pelo leitor 10,etc. Os elementos de dados podem compreender qualificadores de transaçãode terminal, a quantia da transação, um número imprevisível de terminal, umcódigo de moeda corrente de transação, e quaisquer outros dados requeridospelo cartão 22 em sua resposta à segunda mensagem de comando.

Com base no tipo de transações suportadas pelo leitor 10, ocartão 22 então executa um número de processo de gerenciamento de riscoassociados a um tipo de transação particular. De acordo com váriasrealizações, os processos de gerenciamento de risco podem incluir verificarum indicador de cartão interno para proteger contra rompimento da transação,comparar um valor de um código de moeda corrente da aplicação com umvalor de um código de moeda corrente de transação, comparar o número deentradas de número de identificação pessoal com um limite predeterminado,determinar se um método de verificação de detentor de cartão é requerido,comparar a quantia de transação com um limite de valor inferior associado aum cartão 22, comparar a quantia de transação com uma quantia de transaçãototal cumulativa associada ao cartão 22, comparar um valor de um contadorde transação consecutiva com um valor de limite de transação consecutiva,etc. Efetuando os processos de gerenciamento de risco citados neste ponto datransação, em oposição a ser efetuado em um ponto mais tarde de acordo comespecificações tradicionais, o tempo de interação entre o cartão 22 e o leitor10 é adicionalmente minimizado. Com base no processamento degerenciamento de risco, o cartão 22 pode requerer que a transação sejaatenuada, processada em linha ou processada fora de linha. Em seguida àconclusão dos processos de gerenciamento de risco, o cartão 22 constrói aresposta apropriada para a terceira mensagem de comando e transmite aresposta ao leitor 10. A informação incluída na resposta pode variar,dependendo de se o cartão 22 deseja que a transação seja autorizada em linha,autorizada fora de linha ou terminada. Por exemplo, quando o cartão 22deseja que a transação seja autorizada em linha, a resposta pode incluir umcontador de transação de aplicação (ATC) que indica o número de transaçõesprocessadas pelo cartão, um criptograma de aplicação gerado pelo cartão 22utilizando o contador de aplicação de transação e dados de terminal (porexemplo, o número imprevisível de terminal e a quantia de transação)incluídos na terceira mensagem de comando, um perfil de intercâmbio deaplicação (AIP) que indica suporte a características de gerenciamento derisco, dados de aplicação de emissor e dados equivalentes a Trilha 2, e váriosoutros elementos de dados.

Quando o cartão 22 deseja que a transação seja autorizada forade linha, a resposta à terceira mensagem de comando pode incluir umcontador de transação de aplicação (ATC) que indica o número de transaçõesprocessadas pelo cartão. A resposta pode também incluir uma assinaturadinâmica gerada pelo cartão 22, utilizando o contador de transação deaplicação, os dados de terminal (por exemplo, o número imprevisível determinal, a quantia de transação e a moeda corrente de transação) incluídos naterceira mensagem de comando, e um número imprevisível de cartão. Aresposta pode incluir adicionalmente um criptograma de aplicação geradopelo cartão 22, utilizando o contador de transação de aplicação e dados determinal (por exemplo, o número imprevisível de terminal e a quantia detransação) incluídos na terceira mensagem de comando. Em adição, a respostapode incluir um localizador de arquivo de aplicação (AFL) que indica alocalização de arquivos e gravações relacionados à aplicação, um perfil deintercâmbio de aplicação (AIP) que indica suporte para características degerenciamento de risco, dados de aplicação de emissor e vários outroselementos de dados. De acordo com várias realizações, o cartão 22 podeincrementar o contador de transação de aplicação antes de seu cálculo docriptograma de aplicação e assinatura dinâmica. Se o tamanho da assinaturadinâmica excede um limiar predeterminado, a assinatura dinâmica pode serretornada na etapa de autorização 50, em resposta a uma quarta mensagem decomando descrita abaixo. De acordo com várias realizações, o criptograma deaplicação gerado pelo cartão 22 compreende menos elementos de dados doque os criptogramas de aplicação utilizados pelas especificações prévias.Utilizando menos elementos de dados para gerar o criptograma da aplicação,o tempo de processamento global é reduzido e o tempo de interação entre ocartão 22 e o leitor 10 é adicionalmente minimizado.

A etapa de autorização 50 segue a etapa de processamento deaplicação 48. Após o leitor 10 receber a resposta para a terceira mensagem decomando do cartão 22, o cartão 22 pode ser removido do alcance do leitor 10,quando a transação deve ser autorizada em linha. Portanto, o cartão 22 não érequerido para permanecer dentro do alcance do leitor 10 enquanto aautorização em linha é requisitada e executada. Por ser capaz de remover ocartão 22 neste ponto do processo de transação, o tempo de interação entre ocartão 22 e o leitor 10 é adicionalmente minimizado. O leitor 10 pode entãoenviar o criptograma da aplicação, provido pelo cartão 22 em resposta àterceira mensagem de comando, em linha ao emissor 30. Com base em umaresposta subseqüentemente recebida pelo emissor 30, o leitor 10 aprova oudeclina da transação.

Quando a transação deve ser autorizada fora de linha, o leitor10 transmite uma quarta mensagem de comando (por exemplo, LERGRAVAÇÃO) ao cartão 22, após receber a resposta à terceira mensagem decomando a partir do cartão 22. A quarta mensagem de comando pode servircomo uma requisição para as gravações indicadas no localizador de arquivode aplicação (AFL) providas pelo cartão 22 em resposta à terceira mensagemde comando. Sensível à quarta mensagem de comando, o cartão 22 transmiteas gravações apropriadas ao leitor 10. Portanto, o cartão 22 não é requerido apermanecer dentro do alcance do leitor 10, enquanto a autorização fora delinha é executada. Por ser capaz de remover o cartão 22 neste ponto noprocesso de transação, o tempo de interação entre o cartão 22 e o leitor 10 éadicionalmente minimizado. O leitor 10 pode então verificar se o cartão 22expirou. Se o leitor 10 determina que o cartão 22 não expirou, o leitor 10 podeentão efetuar autenticação de dados fora de linha. O tipo de autenticação dedados fora de linha efetuado, dados de autenticação estáticos (SDA) ou dadosde autenticação dinâmicos (DDA) são determinados com base no perfil deintercâmbio de aplicação (AIP) provido pelo cartão 22 em resposta à terceiramensagem de comando.

Para autenticação de dados estática, o leitor 10 tenta validar aassinatura estática provida pelo cartão 22 em resposta à terceira mensagem decomando. A autenticação de dados estáticos envolve validar dados deaplicação importantes para assegurar que os dados não tenham sido alteradosfraudulentamente. Se a assinatura estática é validada, a transação é aprovadafora de linha. De outro modo, a transação pode ser enviada em linha outerminada. Para autenticação de dados dinâmicos, o leitor 10 tenta validar aassinatura dinâmica provida pelo cartão 22, em resposta à terceira mensagemde comando. A autenticação de dados dinâmicos envolve validar dados deaplicação importantes para assegurar que os dados não tenham sido alteradosfraudulentamente e que o cartão 22 é genuíno. De acordo com váriasrealizações, a validação da assinatura dinâmica pode compreender utilizar ocontador de transação de aplicação (ATC) e o número imprevisível determinal providos pelo cartão 22 em resposta à terceira mensagem decomando, para recalcular a assinatura dinâmica. Se a assinatura dinâmica évalidada, o leitor 10 gera uma mensagem de liberação que inclui ocriptograma provido pelo cartão 22 em resposta à terceira mensagem decomando e outros dados relacionados. De outro modo, a transação pode serenviada em linha ou terminada. De acordo com várias realizações, se aassinatura dinâmica não é validada, o leitor 10 pode enviar a transação emlinha utilizando o criptograma previamente recebido do cartão 22. Então, oleitor 10 pode gerar uma requisição em linha com um criptograma fora delinha. Um fluxograma simplificado ilustrando várias realizações da etapa deautorização 50 é mostrado na Figura 6.

Conforme descrito abaixo, o método 40 pode ser utilizado paraminimizar o tempo de interação entre o cartão 22 e o leitor 10 para umatransação sem contato por menos de aproximadamente 500 milissegundos.

Para evitar um ataque de capa fora de linha na transação sem contato, váriasrealizações do método 40 podem utilizar um novo tipo de autenticação dedados dinâmicos. Para transações fora de linha, o cartão 22 pode utilizar ocontador de transação de aplicação (ATC) e o número imprevisível de cartão,juntamente com o número imprevisível de terminal, a quantia da transação e ocódigo de moeda corrente da transação incluídos na terceira mensagem decomando (por exemplo, GPO) para criar a assinatura dinâmica. O localizadorde arquivo de aplicação (AFL) que é subseqüentemente enviado com aassinatura dinâmica ao leitor 10 na resposta à terceira mensagem de comando,indica gravações contendo os certificados RSA e dados relacionados aautenticação de dados dinâmicos. Portanto, durante a etapa de autenticação50, o leitor 10 pode ler um certificado do emissor, um certificado de cartãosem contato, e dados relacionados a autenticação de dados dinâmicos. Deacordo com várias realizações, o leitor 10 pode utilizar o contador detransação de aplicação (ATC), o número imprevisível de cartão, o númeroimprevisível de terminal, a quantia de transação e o código de moeda correnteda transação recebidos do cartão 22, em resposta à quarta mensagem decomando para recalcular a assinatura dinâmica para fins de validação. Eminstâncias em que a transação sem contato tenha sido submetida a um ataquede capa, o recálculo não coincidirá com a assinatura dinâmica previamenterecebida do cartão 22. Para tais instâncias, o leitor 10 pode declinar outerminar a transação sem contato.

Figura 7 ilustra várias realizações de um método 60 parareduzir um tempo de interação para uma segunda transação sem contato queocorre em seguida à requisição para autorização em linha na etapa 50 dométodo 40. De acordo com várias realizações, o método 60 pode compreenderuma porção do método 40. O método 60 pode ser implementado pelo sistema20 da Figura 2. O método 60 pode ser utilizado para minimizar o tempo deinteração entre o cartão 22 e o leitor 10 para a segunda transação sem contato,para menos de aproximadamente 500 milissegundos. De acordo com váriasrealizações, o método 60 compreende as etapas gerais da segunda requisiçãode transação 62, seleção de aplicação 64, processamento de aplicação 66 eaprovação de transação 68.

A segunda transação sem contato não é uma transaçãofinanceira. Como a segunda transação sem contato compreende o cartão 22ser apresentado dentro do alcance do leitor 10 por uma segunda vez, oprocesso pode ser referido como um processamento de retorno do cartão.

Antes do início do processo, durante a primeira transação descrita acima,ambos leitor 10 e cartão 22 podem indicar um ao outro que suportamprocessamento de retorno de cartão. Por exemplo, o leitor 10 e o cartão 22podem indicar seu suporte de processamento de retorno de cartão durante aetapa de seleção de aplicação 46 da primeira transação.

Após a requisição para a autorização em linha na etapa 50 dométodo 40, o leitor 10 ou o cartão 22 (via detentor do cartão) pode requisitar asegunda transação sem contato durante a segunda etapa de requisição detransação 62. De acordo com várias realizações, o leitor 10 pode requisitar asegunda transação sem contato durante a segunda etapa de requisição detransação 62, quando uma resposta do emissor à requisição de autorização emlinha compreende uma mensagem a ser fornecida ao cartão 22. Tal mensagempode ser utilizada para prover atualizações ou reinícios de contagem para ocartão 22, ou para bloquear a conta. Por exemplo, em uma resposta deautorização em linha, o emissor 30 pode incluir uma mensagem de escrita naresposta que requisita que o cartão 22 seja apresentado por uma segunda vez.

Desta maneira, o emissor 30 pode ser capaz de bloquear subseqüentemente aconta, repor a capacidade de gasto fora de linha, aumentar o limite de gastofora de linha, etc., mesmo se o cartão 22 não tiver requisitado que estasatitudes sejam tomadas. Para orientar o detentor do cartão a apresentar ocartão 22 por uma segunda vez, o leitor 10 pode exibir uma mensagemindicando que tempo de processamento de cartão adicional é requerido, umamensagem requisitando apresentar, por favor, o cartão novamente, etc.

De acordo com outras realizações, o cartão 22 pode requerer asegunda transação no sentido de receber uma recarga quando a capacidade degasto fora de linha do cartão se torna baixa. Por exemplo, quando acapacidade de gasto fora de linha do cartão torna-se baixa, o cartão 22, viadetentor do cartão, pode requisitar uma recarga, requisitando uma autorizaçãoem linha e provendo a quantia de gasto disponível corrente. Para assegurarque o cartão 22 sendo apresentado é o mesmo cartão 22 que foi apresentadopara a primeira transação, o cartão 22 pode ser autenticado durante a segundaetapa de requisição de transação 62.

A etapa de seleção de aplicação 64 segue a segunda etapa derequisição de transação 62. A etapa de seleção de aplicação 64 do método 60pode ser similar à etapa de seleção de aplicação 46 do método 40 descritoacima. Durante a etapa de seleção de aplicação 64, o leitor 10 transmite umamensagem de comando (por exemplo, SELECIONE VSDC AID) ao cartão22. A mensagem de comando pode servir como uma requisição para conduzira segunda transação, utilizando uma aplicação específica a partir da lista deaplicações comuns previamente construídas pelo leitor 10. Sensível àmensagem de comando, o cartão 22 transmite uma PDOL ao leitor 10. APDOL pode ser similar à PDOL transmitida ao leitor 10 durante a etapa deseleção de aplicação 46 do método 40 descrito acima. Se a PDOL inclui umelemento de dados particular (por exemplo, qualificadores de transação determinal), o processo avança para a etapa de processamento de aplicação 66.

A etapa de processamento de aplicação 66 segue a etapa deseleção de aplicação 64. A etapa de processamento de aplicação 66 pode sersimilar à etapa de processamento de aplicação 48 do método 40 descritoacima, porém é diferente em que nenhum processamento de transaçãofinanceira é envolvido. Durante a etapa de processamento de aplicação 66, oleitor 10 transmite uma outra mensagem de comando (por exemplo, GPO) aocartão 22. Ao receber a mensagem de comando, o cartão 22 constrói umaresposta enviada e transmite a resposta ao leitor 10.

A etapa de aprovação de transação 68 segue a etapa deprocessamento de aplicação 66. De acordo com várias realizações, se oemissor 30 decide recarregar a capacidade de gasto fora de linha associada aocartão 22, o emissor 30 pode transmitir um criptograma de resposta e aprovara transação ou incluir uma mensagem escrita com um código de autenticaçãode mensagem (MAC). O criptograma ou MAC podem servir para assegurarque as atualizações, reinícios de contagem, etc., sejam apenas feitas ao cartão22 associados ao emissor 30.

Conforme descrito acima, o método 60 pode ser utilizado paramudar parâmetros de risco de cartão, contadores de cartão, estado de cartão,etc. Por exemplo, com respeito a mudar parâmetros de risco de cartão, ométodo 60 pode ser utilizado para aumentar o limite de gasto fora de linha,aumentar o limite de transação único, permitir que o cartão execute transaçõesem duas ou mais moedas correntes diferentes, mude a taxa de conversão demoeda corrente utilizada, etc. Com respeito a mudar contadores de cartão, ométodo 60 pode ser utilizado, por exemplo, para reiniciar a quantidade degasto disponível fora de linha, etc. Com respeito a mudar o estado do cartão, ométodo 60 pode ser utilizado para bloquear ou desbloquear uma aplicaçãoparticular. Um especialista na técnica verificará que o método 60 pode serutilizado para trocar outros parâmetros, contadores, etc.

Embora várias realizações da invenção tenham sido descritasaqui por meio de exemplo, aqueles especialistas na técnica verificarão quevárias modificações, alterações e adaptações às realizações descritas podemser realizadas, sem se afastar do espírito e escopo da invenção definida pelasreivindicações anexas. Por exemplo, de acordo com várias realizações, oleitor 10, sistema 20 e/ou método 40 descritos acima podem ser modificadospara evitar tipos análogos de "ataques de capa" em conjuntos portáteis semfio, pen drives, e outros dispositivos que utilizam a transmissão de informaçãosem fio. Adicionalmente, várias realizações do om60 podem ser utilizadaspara processar transações relacionadas a conversões de moeda corrente,programas de fidelidade, etc.

Claims (10)

1. Leitor, caracterizado pelo fato de compreender:uma interface sem contato;um módulo de transação acoplado à interface sem contato, emque:o módulo de transação é estruturado e arranjado para:descobrir a presença de um dispositivo depagamento sem contato dentro de uma distância predeterminadaa partir do leitor;energizar a interface sem contato quando dadescoberta da presença do dispositivo de pagamento sem contatodentro de uma distância predeterminada a partir do leitor, em quea interface sem contato energizada permite a comunicação entreo dispositivo de pagamento sem contato e o leitor;enviar para o dispositivo de pagamento semcontato, através da interface sem contato, uma requisição paradados; ereceber, a partir do dispositivo de pagamento semcontato, através da interface sem contato, os dados requisitados;processar:a transação sem contato com menos demeio segundo de tempo de interação entre o dispositivo depagamento sem contato e o leitor; ea autenticação de dados dinâmica e estáticautilizando os dados requisitados; eum módulo de segurança acoplado ao módulo de transação,em que o módulo de segurança é arranjado e estruturado para evitar umataque de intermediários na transação sem contato.

2. Cartão, emitido por um emissor, caracterizado pelo fato decompreender:um módulo de transação estruturado e arranjado:para comunicação sem fio, em que o cartão é estruturadoe arranjado para operar em ambos um modo de chip e um modo dedados de tira magnética;para cooperar com um leitor para:ser descoberto por estar dentro de uma distânciapredeterminada do leitor;receber do leitor uma primeira mensagem decomando que contém uma requisição para uma lista deaplicativos que são suportados pelo cartão para conduzir umatransação sem contato;enviar ao leitor, em resposta à primeira mensagemde comando, a lista requisitada de aplicativos;receber do leitor uma segunda mensagem decomando requisitando a condução da transação sem contatoutilizando um dos referidos aplicativos da lista de aplicativos;enviar, em resposta à segunda mensagem decomando, uma requisição para prover um dos tipos de transaçãosem contato suportado pelo leitor;receber uma terceira mensagem de comandocontendo o requisitado um tipo da referida transação sem contatosuportado pelo leitor;enviar, em resposta à terceira mensagem decomando:uma requisição para autorização fora delinha da transação sem contato; eum endereço na memória do cartão dosdados relativos à um daqueles do referido aplicativo dalista de aplicativos;receber, em resposta à requisição para aautorização fora de linha da transação sem contato, uma quartamensagem de comando contendo uma requisição para os dadosrelativos à um daqueles do referido aplicativo da lista deaplicativos no endereço na memória do cartão;enviar, em resposta à quarta mensagem decomando, os dados requisitados relativos à um daqueles doreferido aplicativo da lista de aplicativos; eexecutar a transação sem contato que incluicomunicações interativas com o emissor do cartão com menos de meiosegundo de tempo de interação entre o cartão e o leitor; eum módulo de segurança estruturado e arranjado para cooperarcom o leitor para evitar um ataque de intermediários em uma transação semcontato.

3. Aparelho, caracterizado pelo fato de compreender:um cartão emitido por um emissor; eum leitor, compreendendo:uma interface sem contato;um módulo de transação, acoplado à interface semcontato; e estruturado e arranjado para:descobrir a presença do cartão dentro de umadistância predeterminada a partir do leitor;energizar a interface sem contato quando dadescoberta da presença do cartão dentro da distânciapredeterminada a partir do leitor, em que a interface sem contatoenergizada permite a comunicação entre o cartão e o leitor;enviar para o cartão, através da interface semcontato, uma requisição para dados; ereceber, a partir do cartão, através da interfacesem contato, os dados requisitados;processar uma transação sem contato com menosde meio segundo de tempo de interação entre o cartão e o leitor; eum módulo de segurança, acoplado ao módulo detransação e estruturado para cooperar com o cartão para evitar,utilizando-se os dados requisitados, um ataque de intermediários natransação sem contato; eem que o cartão está estruturado e arranjado para comunicarcom o leitor através da interface sem contato, e inclui:um módulo de transação estruturado e arranjado para:enviar ao leitor:uma requisição para informação; eos dados requisitados;receber, a partir do leitor:as informações requisitadas; ea requisição para dados, eum módulo de segurança estruturado e arranjado paracooperar com o leitor para evitar utilizando-se as informaçõesrequisitadas, um ataque de intermediários na transação sem contato.

4. Aparelho leitor, caracterizado pelo fato de compreender:um meio para iniciar a comunicação com um dispositivo depagamento sem contato utilizado para uma transação sem contato através de:energizar uma interface sem contato com o dispositivode pagamento sem contato quando detecta-se o dispositivo depagamento sem contato dentro de uma faixa predeterminada a partir doaparelho leitor, em que a interface sem contato energizada permite acomunicação entre o cartão e o leitor; eenviar para o dispositivo de pagamento sem contato,através da interface sem contato, uma primeira mensagem de comandoque contém uma requisição para uma lista de aplicativos que sãosuportados pelo dispositivo de pagamento sem contato para conduzir atransação sem contato;um meio para receber, através da interface sem contato, emresposta à primeira mensagem de comando, a lista requisitada de aplicativos;um meio para enviar para o dispositivo de pagamento semcontato, através da interface sem contato, uma segunda mensagem decomando que requisita a condução da transação sem contato utilizando umdos referidos aplicativos da lista de aplicativos;um meio para receber, através da interface sem contato, emresposta à segunda mensagem de comando, uma requisição a partir dodispositivo de pagamento sem contato para prover um tipo de transação semcontato suportado pelo leitor;um meio para enviar, através da interface sem contato, umaterceira mensagem de comando para o dispositivo de pagamento sem contatoque contém o um tipo requisitado da referida transação sem contato suportadapelo leitor;um meio para receber a partir do dispositivo de pagamentosem contato, através da interface sem contato, em resposta à terceiramensagem de comando:uma requisição para autorização fora de linha datransação sem contato; eum endereço relacionado aos dados para dito aplicativoda lista de aplicativos;um meio para enviar, através da interface sem contato, emresposta à requisição para a autorização fora de linha, uma quarta mensagemde comando para o dispositivo de pagamento sem contato que contém umarequisição para os dados no endereço para o referido aplicativo da lista deaplicativos;um meio para receber, a partir do dispositivo de pagamentosem contato, através da interface sem contato, em resposta à quarta mensagemde comando, os dados requisitados no endereço para o referido aplicativo dalista de aplicativos;um meio para terminar, em resposta ao recebimento dos dadosrequisitados no endereço para o referido aplicativo da lista de aplicativos, acomunicação com o dispositivo de pagamento sem contato através dainterface sem contato; eum meio que, após a referida terminação da comunicação como dispositivo de pagamento sem contato, utiliza os dados requisitados noendereço para o referido aplicativo da lista de aplicativos, executa aautorização fora de linha da transação sem contato, em que o tempo entre oenvio da primeira mensagem de comando e a terminação da comunicaçãoatravés da interface sem contato com o dispositivo de pagamento sem contatoé de menos do que meio segundo.

5. Aparelho leitor, de acordo com a reivindicação 4,caracterizado pelo fato de adicionalmente compreender:um meio para ler a partir do dispositivo de pagamento semcontato:uma assinatura dinâmica que inclui:um contador de transação de aplicativo;um código da moeda da transação; eum número imprevisível do dispositivo depagamento sem contato;um meio para recalcular a assinatura dinâmica que utiliza onúmero imprevisível do dispositivo de pagamento sem contato; eum meio para validar, utilizando a assinatura dinâmica, em quea autorização fora de linha da transação sem contato não é executada a não serque a assinatura dinâmica seja validada pelo meio para validação.

6. Aparelho leitor, de acordo com a reivindicação 4,caracterizado pelo fato de adicionalmente compreender:um meio para restabelecer a comunicação com o dispositivo depagamento sem contato através da interface sem contato; eum meio para completar uma segunda dita transação semcontato com menos de meio segundo de interação entre o dispositivo depagamento sem contato e a leitora.

7. Aparelho leitor, de acordo com a reivindicação 6,caracterizado pelo fato de que a segunda dita transação sem contato é umatransação sem contato não financeira.

8. Aparelho leitor, de acordo com a reivindicação 6,caracterizado pelo fato de que o meio para completar a segunda dita transaçãosem contato adicionalmente compreende um meio para transmitir, através dainterface sem contato, uma mensagem que contém uma mudança na memória no dispositivo de pagamento sem contato.

9. Aparelho leitor, caracterizado pelo fato de compreender:um meio para descobrir a presença de um dispositivo depagamento sem contato dentro de uma distância predeterminada a partir doaparelho leitor;um meio para energizar uma interface sem contato quando dadescoberta da presença do dispositivo de pagamento sem contato dentro dadistância predeterminada a partir do aparelho leitor, em que a interface semcontato energizada permite a comunicação entre o dispositivo de pagamentosem contato e o aparelho leitor;um meio para ler a partir do dispositivo de pagamento semcontato, através da interface sem contato, uma assinatura dinâmica a partir dodispositivo de pagamento sem contato, a assinatura dinâmica que inclui:um código de moeda de transação; eum número imprevisível do dispositivo de pagamentosem contato;um meio para recalcular a assinatura dinâmica que utiliza onúmero imprevisível do dispositivo de pagamento sem contato;um meio para validar, utilizando a assinatura dinâmica;um meio para autorizar fora de linha a transação sem contato,se a assinatura dinâmica é validada; eum meio para completar uma transação sem contato commenos de meio segundo de interação entre o dispositivo de pagamento semcontato e o aparelho leitor.

10. Aparelho leitor, de acordo com a reivindicação 9,caracterizado pelo fato de que o meio para ler adicionalmente lê umcriptograma a partir do dispositivo de pagamento sem contato quecompreende um contador de transação de aplicativo; e o aparelho leitoradicionalmente compreende um meio para requisitar que a transação semcontato seja processada em linha com o criptograma se a assinatura dinâmicanão for validada pelo meio de validação.