BR112012010644B1

BR112012010644B1 - método para fornecer dados durante um processo de seleção de aplicativos de pagamento emv, e sistema para seleção de aplicativo com a capacidade de apresentar dados dinâmicos a um usuário do sistema em uma tela de um terminal de pagamento

Info

Publication number: BR112012010644B1
Application number: BR112012010644-9A
Authority: BR
Inventors: Iversen Shaun
Original assignee: Multos International Pte Ltd
Priority date: 2009-11-05
Filing date: 2010-11-05
Publication date: 2021-01-12
Also published as: EP2320395A1; AU2010317018B2; AU2010317018A1; US20120323942A1; US9600954B2; CA2779545A1; CA2779545C; EP2497069A1; CN102725778B; WO2011054935A1; BR112012010644A2; CN102725778A

Abstract

MÉTODO PARA FORNECER DADOS DURANTE UM PROCESSO DE SELEÇÃO DE APLICATIVO, DE UM DISPOSITIVO DE PROCESSAMENTO PARA UM DISPOSITIVO DE INTERFACE, E DISPOSITIVO DE INTERFACE. A presente invenção se refere a um método para fornecer dados durante um processo de seleção de aplicativo, a partir de um dispositivo de processamento para um dispositivo de interface, pelo fato dele compreender uma etapa de modificar, dinamicamente, pelo menos uma parte dos dados de transação a transação pelo menos parte dos ditos dados sendo dados dinâmico.

Description

MÉTODO PARA FORNECER DADOS DURANTE UM PROCESSO DE SELEÇÃO DE APLICATIVOS DE PAGAMENTO EMV, E SISTEMA PARA SELEÇÃO DE APLICATIVO COM A CAPACIDADE DE APRESENTAR DADOS DINÂMICOS A UM USUÁRIO DO SISTEMA EM UMA TELA DE UM TERMINAL DE PAGAMENTO

[0001] A invenção se refere ao campo dos aplicativos de pagamento EMV.

[0002] A invenção trata especialmente de um método para fornecer dados durante um processo de Seleção de Aplicativo.

[0003] EMV é uma norma bem conhecida para a interoperação de Cartões de Circuito Integrado (ICC), também conhecidos como cartões com chip ou cartões inteligentes, com terminais de pagamento, também conhecidos como dispositivos de interface (IFD), utilizados para iniciar transações financeiras. A norma EMV define a interação nos níveis físico, elétrico, de dados e de aplicativos entre os dispositivos de segurança, como, por exemplo, cartões inteligentes e dispositivos de processamento, que processam esses dispositivos seguros, principalmente um POS ou um caixa eletrônico equipado com um leitor de cartão inteligente para transações financeiras. Partes do padrão são fortemente baseadas no padrão de interface de cartões inteligentes, definido na ISO 7816.

[0004] Durante o processo EMV de uma Seleção de Aplicativo, os titulares do cartão podem escolher qual Aplicativo de Pagamento EMV, presente no cartão de circuito integrado, deve ser selecionado para iniciar e processar a transação. Para ajudar na seleção, o terminal de pagamento pode exibir um mnemônico, que permita ao titular do cartão identificar o aplicativo a ser utilizado para a transação. O mnemônico descritivo apresentado é fornecido ao terminal pelo Aplicativo de Pagamento EMV.

[0005] Cada Aplicativo de Pagamento EMV presente em um ICC contém um arquivo chamado File Control Information (FCI) (Informações para Controle de Arquivo). Durante o processo EMV de Seleção de Aplicativo, a FCI para cada Aplicativo de Pagamento EMV presente no cartão inteligente, e mutuamente assistido pelo terminal, é transferida do ICC para o terminal. Cada FCI inclui um Nome de Aplicativo Preferido opcional e um Rótulo de Aplicativo obrigatório, associados a cada Aplicativo de Pagamento EMV. Para permitir que o titular do cartão escolha qual Aplicativo de Pagamento EMV presente no cartão de circuito integrado deve ser selecionado, para iniciar e processar a operação, o terminal exibe o Nome do Aplicativo Preferido, se presente, ou o Rótulo do Aplicativo.

[0006] O mnemônico apresentado, seja ele o Nome do Aplicativo Preferido ou o Rótulo do Aplicativo, geralmente fornece uma descrição da funcionalidade associada ao Aplicativo de Pagamento EMV subjacente. Exemplos típicos incluem: "Crédito", "Débito" ou "Poupança". Esse mnemônico é estático, o que significa que seu valor se mantém constante, uma vez que o Aplicativo de Pagamento EMV foi carregado para o ICC. Ele permanece estático durante toda a vida útil do aplicativo.

[0007] Dados envolvidos em uma transação EMV são encapsulados e transportados dentro de objetos de dados, chamados de etiquetas (tags). Por exemplo, a Etiqueta '50' é o Rótulo de Aplicativo e a Etiqueta '9F12' é o Nome do Aplicativo Preferido.

[0008] A norma EMV define os valores de etiqueta, os comprimentos máximos dos valores, formato e contexto da etiqueta. Por exemplo, o valor de etiqueta ’9F12', que corresponde ao Nome do Aplicativo Preferido, como o mnemônico associado a um Aplicativo de Pagamento EMV, é exibido pelo terminal durante a Seleção do Aplicativo. O comprimento máximo de etiqueta '9F12' é dado pela norma EMV como 16 bytes.

[0009] A norma EMV não permite alterar o valor de etiquetas, que são localizadas dentro das Informações de Controle de Arquivo (FCI). Por esta razão, o valor do Nome do Aplicativo Preferido é dito ser estático ao longo do ciclo de vida do aplicativo.

[00010] Existe a necessidade de fornecer um método, que permita que o mnemônico exibido ao titular do cartão durante o processo de Seleção do Aplicativo varie ao longo do curso do ciclo de vida do cartão.

[00011] É um objetivo da invenção fornecer uma forma de comunicar informações, de composição e comprimento variados, ao titular do cartão durante o processo EMV de Seleção de Aplicativo.

[00012] De acordo com um aspecto da invenção, um método é apresentado para fornecer dados durante um processo de Seleção de Aplicativo, através de um dispositivo de processamento para um dispositivo de interface, em que ele compreende uma etapa de modificar dinamicamente, pelo menos, parte dos ditos dados, de transação para transação, pelo menos a dita parte de dados sendo dados dinâmicos.

[00013] Graças a esse método, o mnemônico exibido ao titular do cartão durante a Seleção do Aplicativo EMV pode ser alterado ao longo do ciclo de vida do aplicativo EMV.

[00014] De acordo com outros aspectos da invenção:

- o método pode compreender, se os ditos dados contiverem dados estáticos, a concatenação dos ditos dados estáticos com os ditos dados dinâmicos;
- o método pode compreender a determinação do valor e do comprimento dos ditos dados dinâmicos;
- o método pode compreender a formatação dos ditos dados dinâmicos;
- o método pode compreender a criação de um formato de etiqueta - comprimento - valor (TLV), a partir dos dados dinâmicos formatados;
- os dados podem ser um Nome de Aplicativo Preferido;
- o método pode compreender o uso de um host remoto como dispositivo de processamento;
- o método pode compreender o uso um cartão de circuito integrado como dispositivo de processamento;
- os dados dinâmicos podem ser incorporados a Informações de Controle de Arquivo do cartão de circuito integrado, criando Informações Dinâmicas de Controle de Arquivo de comprimento variável;
- o método pode compreender o retorno das informações dinâmicas de controle de arquivo em resposta a um comando recebido pelo dispositivo de processamento do dispositivo de interface.

[00015] Graças a esse método, os dados incorporados ao mnemônico podem refletir um valor variável ou dinâmico, que pode representar um balanço monetário ou de pontos, ou uma sequência de texto.

[00016] Esta alteração de dados pode ser administrada online, isto é, em um host remoto, ou offline, isto é, no cartão. A informação comunicada é dinâmica, isto é, ela pode mudar de transação para transação.

[00017] Esse método proporciona vantajosamente uma maneira, pela qual os emissores podem comunicar várias informações para o titular do cartão, no momento da seleção do aplicativo EMV.

[00018] Outro objetivo da invenção é fornecer um dispositivo de interface adaptado para trocar dados com um dispositivo de processamento adaptado para processar o método, de acordo com uma das reivindicações anteriores.

[00019] A invenção será agora descrita, a título de exemplo, com referência aos desenhos que a acompanham.

[00020] A fim de que a maneira, pela qual as vantagens e características acima citadas e outras mais da invenção são obtidas, uma descrição mais particular da invenção brevemente acima descrita será apresentada por referência.

[00021] Não obstante quaisquer outras formas, que possam incidir no âmbito da presente invenção, formas de realização preferidas da invenção serão agora descritas, apenas a título de exemplo, com referência aos desenhos anexos nos quais:
as FIGs. 1, 1a, 1b, 1c mostram, esquematicamente, arquiteturas de um ICC, de acordo com diferentes formas de realização;
a FIG. 2 mostra, esquematicamente, um diagrama de fluxo de um método, de acordo com a presente invenção;
a FIG. 3 mostra, esquematicamente, um exemplo de um Registro de FCI;
a FIG. 4 e a FIG. 5 mostram, esquematicamente, respectivamente um terminal, antes e depois de uma transação, de acordo com uma forma de realização da presente invenção.

[00022] A presente invenção pode ser compreendida, de acordo com a descrição detalhada aqui fornecida.

[00023] Um método, de acordo com a presente invenção, proporciona uma maneira de se comunicar informação, de composição e comprimento variáveis, para o titular do cartão durante o processo EMV de Seleção de Aplicativo.

[00024] Na descrição seguinte, "n" se refere a um comprimento de uma FCI principal, enquanto um "L" se refere a um comprimento de uma FCI dinâmica. A presença de um símbolo de apóstrofo (’) em nomes de variáveis indica que o comprimento é constante ao longo do ciclo de vida do aplicativo; o valor de uma variável atribuída com um símbolo de apóstrofo (’) pode variar de cartão para cartão, mas não após o aplicativo ter sido personalizado, isto é, após o aplicativo ter sido carregado no ICC, o comprimento permanece constante. Finalmente, o uso de aspas simples ao longo deste relatório descritivo indica notação hexadecimal (HEX).

[00025] A Fig. 1 mostra um método, de acordo com uma primeira forma de realização da presente invenção, em que a informação a ser comunicada a um titular do cartão durante o processo de Seleção de Aplicativo EMV é um saldo da conta.

[00026] Um ICC 200, adequado para se comunicar com um terminal 210, contém pelo menos um Aplicativo de Pagamento EMV 201.

[00027] O terminal 210 no ponto de serviço é, por exemplo, um dispositivo acolhedor de cartão equipado com um leitor de cartão com chip. O terminal 210 interage com o ICC 200, de acordo com o modelo cliente-servidor. De acordo com as normas EMV, comandos (C-APDU), conforme especificado na ISO 7816-4, são enviados do terminal 210 ao ICC 200. Respostas (R-APDU) para esses comandos são, então, enviadas do ICC 200 para o terminal 210. Nesta forma de realização, o método é processado pelo Aplicativo de Pagamento EMV 201 em si. Neste caso, o Aplicativo de Pagamento EMV é dito incorporar uma funcionalidade associada a uma Exibição Dinâmica do Nome do Aplicativo (D-AND). Essa funcionalidade é realizada dentro do Aplicativo de Pagamento EMV 201, além de todas as outras funcionalidades necessárias para o processamento correto de uma transação, em conformidade com as normas EMV.

[00028] Algumas variantes da arquitetura, em que o método pode ser processado, são mostradas nas Figuras 1a, 1b, 1c.

[00029] Como representado na Figura 1a, a funcionalidade associada à D-AND pode, por exemplo, residir dentro de um aplicativo que existe fora do Aplicativo de Pagamento EMV. Um Aplicativo Intermediário 202 engloba todas as funcionalidades associadas à D-AND, e está localizado, de forma que ele atue como um intermediário entre o terminal 210 e o Aplicativo de Pagamento EMV 203. O aplicativo Intermediário 202, atuando como intermediário, recebe todos os comandos (C-APDUs) enviados pelo terminal 210, e processa o comando, se o C-APDU exigir funcionalidade D-AND, ou envia o C-APDU ao Aplicativo de Pagamento EMV 203. De um modo semelhante, o Aplicativo Intermediário 202 recebe todas as respostas (R-APDUs) enviadas pelo Aplicativo de Pagamento EMV 203, e processa a resposta, se o R-APDU necessitar funcionalidade D-AND, ou envia o R-APDU ao terminal 210. Por exemplo, o Aplicativo Intermediário 202 pode ser um aplicativo Shell MULTOS, que faz interface com o Aplicativo de Pagamento EMV.

[00030] Alternativamente, como mostrado na Figura 1b, a funcionalidade associada à D-AND pode residir em um aplicativo, que faz interface com um Aplicativo de Pagamento EMV, quando a funcionalidade associada à D-AND é necessária. Nesta forma de realização, o Aplicativo de Pagamento EMV 204 compreende a lógica e os dados necessários para processar adequadamente uma transação, de acordo com normas EMV. Quando a funcionalidade associada à D-AND é necessária, o Aplicativo de Pagamento EMV 204 acessa um Aplicativo Delegado 205, através de comandos entendidos pelo Aplicativo Delegado 205. O Aplicativo Delegado 205 pode realizar a funcionalidade desejada, associada à D-AND, e fornecer uma resposta, que seja compreendida pelo Aplicativo de Pagamento EMV 204. Tais comandos e respostas trocadas entre o Aplicativo de Pagamento EMV 204 e o Aplicativo Delegado 205 não precisam, necessariamente, estar em conformidade com o formato dos C-APDUs ou R-APDUs definidos pelo EMV.

[00031] De acordo com outra alternativa, o ICC também pode conter aplicativos clássicos de pagamento EMV 206, que não usam funcionalidade D-AND e não fazem interface com aplicativos que processam tal funcionalidade, como mostrado na Figura 1c.

[00032] Como descrito em todas as três formas de realização acima, cada Aplicativo de Pagamento EMV presente no ICC 200 contém uma FCI, que deve ser transferida do ICC 200 para o terminal 210. Cada FCI inclui o Nome Preferencial do Aplicativo opcional e o Rótulo do Aplicativo obrigatório associado a cada Aplicativo de Pagamento EMV.

[00033] O Aplicativo de Pagamento EMV usando funcionalidade D-AND é personalizado com uma FCI, cujos conteúdos e comprimentos são inteiramente conhecidos. Este Registro de FCI original é referido como a FCI principal. Todos os valores que compreendem a FCI principal, incluindo comprimentos, são conhecidos e permanecem constantes ao longo do ciclo de vida do aplicativo. A FCI principal, como um todo, é estática e não muda durante o ciclo de vida do aplicativo.

[00034] O Aplicativo de Pagamento EMV usando funcionalidade D-AND é capaz de formatar e incorporar um Nome de Aplicativo Preferido de comprimento variável dentro da FCI principal. Isto requer a alteração dos parâmetros de comprimento dentro da FCI principal. A alteração da FCI principal, por incorporação do Nome do Aplicativo Preferido, e alteração dos parâmetros de comprimento, resulta em uma nova FCI. A FCI alterada é referida como a FCI dinâmica. Uma vez que a FCI dinâmica incorpora um valor do Nome Preferencial do Aplicativo, que é variável em conteúdo e comprimento, os parâmetros de comprimento da FCI dinâmica são desconhecidos durante o carregamento do aplicativo para o cartão de circuito integrado (ICC). Os parâmetros de comprimento são, por conseguinte, determinados pela funcionalidade associada à D-AND.

[00035] Independentemente de onde a funcionalidade associada à D-AND reside em um ICC, ou seja, de onde o método, de acordo com a invenção, é processado, esse método para fornecer um mnemônico dinâmico para um titular do cartão compreende as seguintes etapas, tal como representado na Figura 2.

[00036] Por exemplo, como mostrado na Figura 4, existem dois Aplicativos de Pagamento EMV mutuamente suportados pelo terminal de pagamento EMV 210 e o ICC 200: um aplicativo, que utiliza a funcionalidade D-AND, e outro aplicativo com um Nome de Aplicativo Preferido estático de, digamos, "Crédito". O terminal de pagamento EMV fornece uma exibição para o titular do cartão, como ilustrada na Figura 4. O titular do cartão, em seguida, indica sua seleção desejada, apertando um dos botões associados a qualquer um dos mnemônicos apresentados.

[00037] Na descrição seguinte, o titular do cartão escolhe o aplicativo, que utiliza a funcionalidade D-AND.

[00038] Numa etapa 100 da Figura 2, é assumido que o Aplicativo de Pagamento EMV foi executado de uma maneira, que está de acordo com as normas EMV. Um comando EMV SELECT (Selecionar EMV) ("C-APDU") foi recebido do terminal 210 pelo ICC 200, indicando que o Aplicativo de Pagamento EMV usando funcionalidade D-AND deve ser selecionado. O processo EMV de Seleção de Aplicativo é inteiramente definido dentro das normas EMV. Após a recepção de um EMV SELECT (Selecionar EMV) C-APDU, indicando que o aplicativo utilizando funcionalidade D-AND deve ser selecionado, o Aplicativo de Pagamento EMV 201 é programado, de modo a executar as etapas, conforme representado na Figura 2.

[00039] Após a recepção de um EMV SELECT (Selecionar EMV) C-APDU, indicando que o aplicativo utilizando funcionalidade D-AND deve ser selecionado, em uma etapa 110, é necessário compor o Nome Preferido do Aplicativo Dinâmico.

[00040] O Nome Preferido do Aplicativo Dinâmico é composto por dois componentes: Um Descritor Estático e um Saldo Dinâmico DB.

[00041] O componente Descritor Estático S é específico por execução e é, opcionalmente, definido pelo emissor. O componente Descritor Estático S é definido, antes do Aplicativo de Pagamento EMV ser carregado no ICC. Ele é opcional, em que o Nome Preferencial do Aplicativo Dinâmico pode ser composto apenas do Saldo Dinâmico. A ordem de S e DB, ao compreender o Nome do Aplicativo Dinâmico Preferencial, é arbitrária.

[00042] Nesta forma de realização, como também mostrado na Figura 4, o componente Descritor Estático S é, por exemplo, definido como um mnemônico estático "Pre-Paid_$". O Descritor Estático S não muda ao longo do ciclo de vida do cartão. Como representado, S precede DB.

[00043] Deve ficar claro que DB pode preceder S, e que mais de um Descritor Estático S pode estar presente dentro de um Nome do Aplicativo Dinâmico Preferido.

[00044] O Nome do Aplicativo Dinâmico Preferencial suplanta o Nome do Aplicativo Preferido definido pelo EMV. Assim sendo, o Nome do Aplicativo Dinâmico Preferencial deve seguir as restrições de formatação impostas pela EMV. O Nome do Aplicativo Dinâmico Preferencial é, portanto, atualmente limitado a um comprimento de dezesseis caracteres, com cada caractere sendo equivalente a um byte de dados. O comprimento do Descritor Estático (L’s, com o símbolo do apóstrofo indicando um comprimento constante) é igual a dez, com oito caracteres para "Pre-Paid" ("pré-pago"), um caractere para um espaço em branco, e um caractere para um sinal de dólar $.

[00045] O Saldo Dinâmico DB é específico por transação. O DB engloba dados, que são previstos mudarem ao longo do ciclo de vida do Aplicativo de Pagamento EMV. Nesta forma de realização e, como também mostrado na Figura 4, o Saldo Dinâmico DB reflete o Saldo Offline, isto é, uma quantidade, armazenada pelo Aplicativo de Pagamento EMV, que é prevista ser alterada durante o ciclo de vida do cartão. O DB se altera para cada transação ou periodicamente, dependendo do uso do cartão específico, ou dos requisitos do emitente, para comunicar ao titular do cartão.

[00046] Deve ficar claro que a natureza dos dados representados no DB não é um exemplo limitado. O DB não precisa incluir informação de saldo por si só, e pode incluir qualquer informação, que o emissor do cartão deseja comunicar ao titular do cartão durante o processo EMV de Seleção do Aplicativo.

[00047] O valor do Saldo Dinâmico, e do comprimento resultante, é determinado na etapa 111. Aqui, o Saldo Offline Atual, mantido pelo Aplicativo de Pagamento EMV, é tido como "23457", conforme mostrado na Figura 4.

[00048] Uma vez que o componente Saldo Dinâmico DB é determinado, o Saldo Dinâmico DB é formatado na etapa 112. O processo de formatação inclui qualquer manipulação do componente dinâmico DB, como a inclusão ou remoção de caracteres, números decimais, vírgulas, preenchimento ou espaços em branco. A natureza exata do formato desejado é determinada antes do carregamento do Aplicativo de Pagamento EMV no ICC 200. No exemplo da Figura 4, um valor decimal é adicionado, para fornecer dois pontos decimais. "23457" se torna "234,57".

[00049] Após a formatação, a Descritor Estático S e o Saldo Dinâmico DB são concatenados na etapa 113. O descritor dinâmico DB formatado é colocado imediatamente após o Descritor Estático S. Isso resulta em "Pre-Paid_$234,57", que é de dezesseis caracteres de comprimento.

[00050] O comprimento do Nome do Aplicativo Dinâmico Preferencial LA é igual à soma do comprimento do Descritor Estático L's mais o comprimento do Saldo Dinâmico (LDB): LA = L’s + LDB.

[00051] O comprimento do Nome do Aplicativo Dinâmico Preferencial LA não deve ser maior do que 16: LA ≤ 16.

[00052] Uma vez que L’s é conhecido e estático, LDB ≤ 16 -L’s, o que significa que o comprimento máximo do componente de Saldo Dinâmico LDB é igual a 16 menos o comprimento do Descritor Estático L’s escolhido pelo Emissor. Isto é verificado na etapa 114.
Aqui,
S = "Pre-Paid_$", que em hexadecimal é ’5072652D506169642024’
L’s = 10
DB = "234,7", que em hexadecimal é '3233342E3537'
LDB = 6
Por isso,
LA = L's + LDB = 10 + 6 = 16

[00053] Que não é maior do que os 16 caracteres máximos admissíveis ou, mais especificamente,
10 ≤ 16 - 6

[00054] Uma vez que o comprimento desse Nome do Aplicativo Dinâmico Preferencial formatado não é superior a 16, nenhuma formatação adicional é exigida.

[00055] Quando o Nome do Aplicativo Dinâmico Preferencial formatado for menor do que dezesseis caracteres de comprimento, enchimento pode ser adicionado para atingir um comprimento desejado, mas sem exceder 16 caracteres, tal como especificado por EMV para o Nome de Aplicativo Preferido.

[00056] Se o comprimento do Nome do Aplicativo Dinâmico Preferencial exceder o valor máximo admissível, isto é, se LA for superior a dezesseis caracteres, então é desejável implementar uma formatação adicional, de modo a atingir um comprimento aceitável. Na verdade, procedendo com um Nome do Aplicativo Dinâmico Preferencial formatado, que é maior do que dezesseis caracteres, pode fazer com que o terminal 210 aborte a transação, ou exiba indevidamente o Nome do Aplicativo Dinâmico Preferencial para o titular do cartão. Uma vez que o Nome do Aplicativo Dinâmico Preferencial foi composto, seu valor é colocado em formato de etiqueta - comprimento - valor (TLV) na etapa 115. A etiqueta para o Nome do Aplicativo Dinâmico Preferencial é ’9F12', que é definida dentro das normas EMV. No exemplo do Nome do Aplicativo Dinâmico Preferencial formatado "Pre-Paid_$234,57", o comprimento é de dezesseis caracteres. Em notação hexadecimal, o número 16 é representado por '10'. Além disso, em notação hexadecimal, "Pre-Paid_$234,57" é representado por '507262D5061696420243233342E3537'. A etiqueta TLV para o Nome do Aplicativo Dinâmico Preferencial formatado é, portanto, ’9F12 10 5072652D5061696420243233342E3537’.

[00057] Uma vez que a etiqueta TLV para o Nome do Aplicativo Dinâmico Preferencial formatado foi obtida, ele está pronto para ser incorporado à FCI principal, criando assim a FCI dinâmica.

[00058] A FCI principal é, então, acessada e recuperada, o que é realizado na etapa 120.

[00059] Na Fig. 3 é mostrado a estrutura de tópicos de um registro típico de FCI do EMV. Nessa estrutura de tópicos, quatro objetos de dados: etiquetas '9F11', '5F2D', '87' e '50' constituem o Modelo Proprietário de FCI. O Modelo Proprietário de FCI, etiqueta 'A5', juntamente com a etiqueta '84', constituem o Modelo de FCI. O Modelo de FCI é representado pela etiqueta '6F'.

[00060] Dentro da FCI, cada etiqueta é seguida por um byte de comprimento, indicando o comprimento dos dados associados a essa etiqueta. Cada byte de comprimento é, por sua vez, seguido por dados de um comprimento igual ao indicado pelo byte de comprimento. Tal formato é comumente referido como formato de etiqueta - comprimento - valor (TLV). O byte de comprimento após a etiqueta '6F' e a etiqueta 'A5' indica, respectivamente, o comprimento do Modelo de FCI e o comprimento do Modelo Proprietário de FCI. Estes dois valores de comprimento são atribuídos, respectivamente, às variáveis nFT e nPT.

[00061] Usando a estrutura de tópicos de uma FCI típica representada na Figura 3 como uma base para a FCI principal do exemplo da Figura 4, uma FCI principal típica, com atuais valores de comprimento e de dados, é como se segue: '6 F 25
84 07 A0000000041010
A5 lA
50 0A 4D617374657243617264
87 01 81
5F2D 04 656E6672
9Fll 01 01'

[00062] Acima, cada etiqueta é mostrada em uma linha separada. Na realidade, todos os dados acima são concatenados. Eles foram divididos para facilitar a compreensão.

[00063] O comprimento do Modelo de FCI, nFT, é igual a '25' e o comprimento do Modelo Proprietário de FCI, nPT, é igual a '1A'. O comprimento da FCI principal completa, nF, não mostrada, é '27'.

[00064] A FCI principal, isto é, a FCI definida e personalizada para o aplicativo utilizando a funcionalidade associada à D-AND, é estática. Assim, todos os valores associados à FCI principal, incluindo comprimentos, são conhecidos e permanecem constantes ao longo do ciclo de vida do aplicativo. No exemplo acima citado:

- o comprimento do Registro de FCI (nF) = '27' = 39 bytes;
- o comprimento do Modelo de FCI (nFT) = '25' = 37 bytes;
- o comprimento do Modelo Proprietário de FCI (nPT) = '1A' = 26 bytes.

[00065] Uma vez que a etiqueta TLV para o Nome do Aplicativo Dinâmico Preferencial formatado foi incorporada à FCI principal, criando assim a FCI dinâmica, o valor de todos os três bytes de comprimento acima se altera.

[00066] Uma vez que a etiqueta TLV para o Nome do Aplicativo Dinâmico Preferencial formatado foi obtida e a FCI principal foi recuperada, a FCI dinâmica é criada na etapa 130.

[00067] A funcionalidade associada à D-AND tem o Aplicativo de Pagamento EMV incorporando o Nome do Aplicativo Dinâmico Preferencial à FCI principal, por adição da etiqueta TLV para o Nome do Aplicativo Dinâmico Preferencial ao Modelo Proprietário de FCI.

[00068] Na etapa 131, a etiqueta de TLV para o Nome do Aplicativo Dinâmico Preferencial formatado '9F12 10 5072652D061696420243233342E3537' é adicionada às etiquetas, que compõem o Modelo Proprietário de FCI na FCI principal.

[00069] Por adição da etiqueta TLV ao Nome do Aplicativo Dinâmico Preferencial para o Modelo Proprietário de FCI, o comprimento do Modelo Proprietário de FCI nPT é obviamente alterado. Além disso, devido ao fato do Modelo Proprietário de FCI estar localizado no Modelo de FCI, uma mudança no comprimento do Modelo Proprietário de FCI resulta numa mudança no comprimento do Modelo de FCI, nFT.

[00070] Em seguida, na etapa 132, a funcionalidade associada à D-AND altera os comprimentos do Modelo Proprietário de FCI e do Modelo de FCI, para refletir a inclusão do Nome do Aplicativo Dinâmico Preferencial. Valores de comprimento da FCI principal, nPT e nFT, são alterados para indicar corretamente os valores de comprimento do Modelo Proprietário de FCI e do Modelo de FCI, LPT e LFT, respectivamente, na FCI dinâmica.

[00071] Como visto anteriormente, o Nome do Aplicativo Dinâmico Preferencial, em formato TLV, a ser incluído na FCI retornada para o IFD é:
’9F12 10 5072652D5061696420243233342E3537’

[00072] O comprimento do Nome do Aplicativo preferencial em formato TLV (LATLV) é sempre LATLV = LA + 3. Isto considera dois bytes para a etiqueta e um byte para o comprimento.

[00073] Aqui, LA ='10' = 16 bytes de comprimento.

[00074] Portanto, LATLV = '13' = 19 caracteres de comprimento.

[00075] A etapa 132 determina todos os valores de comprimento dentro da FCI principal, que são impactados pelo acréscimo do Nome do Aplicativo Dinâmico Preferencial em formato TLV. Os comprimentos impactados são o comprimento do Modelo Proprietário de FCI (LPT) e o comprimento do Modelo de FCI (LFT).
LPT = nPT + LATLV LFT = nFT + LATLV

[00076] A funcionalidade associada à D-AND também re-calcula todo o Registro LF de FCI dinâmica.
LF = nF + LATLV L

[00077] O LF não está incluído na FCI principal em si, mas sim é retornado ao terminal 210, como parte de uma etapa intermediária no processo EMV de Seleção de Aplicativo, necessária para identificar explicitamente o comprimento exato do Registro de FCI, em conformidade com as normas EMV.

[00078] No exemplo acima citado, a FCI principal é:
’6F 25
84 07 A0000000041010
A5 1A
50 0A 4D617374657243617264
87 01 81
5F2D 04 656E6672
9F11 01 01'
Onde,
nFT = '25' = 37 bytes
nPT = 'lA' = 26 bytes
nF (não mostrado) = '27' = 39 bytes

[00079] Conforme acima determinado, o Nome do Aplicativo Dinâmico Preferencial em formato TLV a ser acrescentado é '9F12 10 5072652D5061696420243233342E3537' de comprimento '13'

[00080] Então, a FCI dinâmica é:
'6F 38
84 07 A0000000041010
A5 2D
50 0A 4D617374657243617264
87 01 81
5F2D 04 656E6672
9Fll 01 01
9F12 10 5072652D5061696420243233342E3537'
Onde,
LFT = nFT + LATLV = ’25’+ ’13’ = ’38’= 56 bytes
LPT = nA + LATLV = ’lA’+ ’13’ = ’2D' = 45 bytes

[00081] Aqui, LFT e LPT são exatamente ’13’ (19) bytes maiores do que nFT e nA. 19 é o valor de LATLV.

[00082] O comprimento da FCI dinâmica completa a ser retornada ao terminal é:
LF = nF + LATLV = ’27’+ ’13’ = ’3A’ = 58 bytes

[00083] Uma vez que a FCI dinâmica foi criada, na etapa 140, o Aplicativo de Pagamento EMV retorna a FCI dinâmica em resposta à EMV SELECT (Selecionar EMV) C-APDU.

[00084] O provimento da resposta (R-APDU), em conformidade com a recepção de um comando EMV SELECT (Selecionar EMV) (C-APDU), está de acordo com as normas EMV e, portanto, está fora do escopo de funcionalidade diretamente associado à D-AND.

[00085] A FCI dinâmica retornada ao terminal 210 é seguida imediatamente por bytes de status SW1SW2 = ’90 00’, em conformidade com as normas EMV. Se, para uma transação subsequente, o componente Saldo Dinâmico for alterado, por exemplo, para um valor de $135,79, então, uma exibição é apresentada ao titular do cartão, como representado na Figura 5. O Saldo Dinâmico exibe um Saldo Offline, como parte do Nome do Aplicativo Preferido no terminal 210. O terminal 210 mostra o mnemônico modificado e atualizado para o titular do cartão.

[00086] Em ambos os casos descritos pelas imagens das Figuras 4 e 5, o mnemônico pré-pago exibido está associado ao mesmo Aplicativo de Pagamento EMV, no mesmo ICC. No entanto, o Nome do Aplicativo Preferido se torna dinâmico, através da implementação de funcionalidade associada à D-AND.

[00087] Deve ficar claro que a ordem de execução das etapas associadas à D-AND é apresentada de uma forma lógica, e que a ordem pode ser alterada. Por exemplo, a etapa 120, em que a FCI principal é acessada, pode ser executada antes da etapa 110, no qual o Nome do Aplicativo Dinâmico Preferencial é composto.

[00088] Além disso, é possível determinar matematicamente o comprimento da FCI dinâmica a ser retornado para o terminal, antes de realmente incorporar o Saldo Offline ao Nome do Aplicativo Preferido.

[00089] Como acima descrito, estes dados alterados podem ser administrados online, isto é, em um host remoto, ou offline, isto é, no cartão.

[00090] Graças a esse método, o mnemônico exibido permite que um emissor comunique informações variáveis ao titular do cartão, no momento da seleção do aplicativo EMV, por incorporação de um Nome de Aplicativo Preferido de comprimento variável à FCI, e retorno dessa FCI de comprimento variável para o terminal de pagamento 210.

Claims

MÉTODO PARA FORNECER DADOS DURANTE UM PROCESSO DE SELEÇÃO DE APLICATIVOS DE PAGAMENTO EMV, a partir de um cartão de circuito integrado para um dispositivo de exibição de um terminal de pagamento, em que o aplicativo de pagamento EMV está sendo selecionado patra iniciar e processar a transação, caracterizado pelo fato dele compreender as etapas de:
- - modificar dinamicamente pelo menos uma parte dos ditos dados de transação para transação no referido dispositivo de exibição, pelo menos parte dos ditos dados sendo dados dinâmicos, referidos dados dinâmicos sendo incorporados a uma informação de controle de arquivo do cartão de circuito integrado
- - criar uma informação de controle dinâmico de arquivo de comprimento variável, determinando o valor e o comprimento dos referidos dados dinâmicos;
- - formatar os referidos dados dinâmicos; e
- - criar um formato de marcador/ comprimento/ valor (TLV) a partir dos dados dinâmicos formatados.
MÉTODO, de acordo com a reivindicação 1, caracterizado pelo fato dele compreender, se ditos dados contiverem dados estáticos, a concatenação dos ditos dados estáticos e dos ditos dados dinâmicos.
MÉTODO, de acordo com qualquer uma das reivindicações 1 e 2, caracterizado pelo fato dos ditos dados serem um nome de aplicativo preferido.
MÉTODO, de acordo com qualquer uma das reivindicações 1 a 3, caracterizado pelo fato dele compreender o uso de um host remoto como dispositivo de processamento.
MÉTODO, de acordo com a reivindicação 1, caracterizado pelo fato dele compreender o retorno da informação de controle dinâmico de arquivo, em resposta a um comando recebido pelo dispositivo de processamento do dispositivo de interface.
SISTEMA PARA SELEÇÃO DE APLICATIVO COM A CAPACIDADE DE APRESENTAR DADOS DINÂMICOS A UM USUÁRIO DO SISTEMA EM UMA TELA DE UM TERMINAL DE PAGAMENTO, em que um aplicativo de pagamento EMV está sendo selecionado para iniciar e processar uma transação, em que dados mnemônicos dinâmicos estão associados com aplicativos selecionados, o sistema sendo caracterizado por compreender:
a tela do terminal de pagamento, a tela operável para exibir dados mnemônicos de aplicativo para um usuário durante um processo de seleção de aplicativo EMV a partir de um cartão de circuito integrado e para receber os dados mnemônicos de aplicativo do cartão de circuito integrado operável para produzir os dados mnemônicos associados a um aplicativo selecionado, modificando os dados mnemônicos associados ao aplicativo selecionado de transação em transação, os dados mnemônicos sendo incorporados em uma Informação de Controle de Arquivo do cartão de circuito integrado, criando uma Informação de Controle de Arquivo dinâmica de comprimento variável, determinando o valor e o comprimento de os referidos dados dinâmicos, a formatação dos referidos dados dinâmicos, a criação de um formato de valor de comprimento de etiqueta (TLV) a partir dos dados dinâmicos formatados.