BRPI0411286B1 - sistema para autenticar a transação comercial efetuada pelo proprietário de um cartão junto a um comerciante em uma rede eletrônica; estrutura de dados para transportar informações e método para a autenticação da transação comercial - Google Patents

sistema para autenticar a transação comercial efetuada pelo proprietário de um cartão junto a um comerciante em uma rede eletrônica; estrutura de dados para transportar informações e método para a autenticação da transação comercial Download PDF

Info

Publication number
BRPI0411286B1
BRPI0411286B1 BRPI0411286A BRPI0411286A BRPI0411286B1 BR PI0411286 B1 BRPI0411286 B1 BR PI0411286B1 BR PI0411286 A BRPI0411286 A BR PI0411286A BR PI0411286 A BRPI0411286 A BR PI0411286A BR PI0411286 B1 BRPI0411286 B1 BR PI0411286B1
Authority
BR
Brazil
Prior art keywords
authentication
cardholder
bytes
aav
mac
Prior art date
Application number
BRPI0411286A
Other languages
English (en)
Inventor
Arthur D Kranzley
Bruce J Rutherford
Mark Wiesman
Stephen W Orfei
Original Assignee
Mastercard International Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from PCT/US2004/017756 external-priority patent/WO2005001618A2/en
Application filed by Mastercard International Inc filed Critical Mastercard International Inc
Publication of BRPI0411286A publication Critical patent/BRPI0411286A/pt
Publication of BRPI0411286B1 publication Critical patent/BRPI0411286B1/pt

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G06Q20/027—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP] involving a payment switch or gateway
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3827—Use of message hashing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/04—Billing or invoicing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Marketing (AREA)
  • Signal Processing (AREA)
  • Power Engineering (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Storage Device Security (AREA)
  • Control Of Vending Devices And Auxiliary Devices For Vending Devices (AREA)

Abstract

"sistema para autenticar a transação comercial efetuada pelo proprietário de um cartão junto a um comerciante em uma rede eletrônica; estrutura de dados para transportar informações e método para a autenticação da transação comercial". trata-se de uma estrutura de dados formatada que é fornecida para transportar os resultados de programas de autenticação de comércio eletrônico, que são utilizados para autenticar as transações comerciais automáticas do titular de um cartão. a estrutura de dados, que possui no máximo 20 bytes de extensão, é designada para compatibilizar-se com os protocolos de mensagem segura em 3-d utilizados em comércio eletrônico. a estrutura de dados inclui campos designados que incluem um código de autenticação de comerciante, que vincula as informações do proprietário do cartão com a transação comercial. os algoritmos de pagamento seguro são fornecidos para uso pelos programas de autenticação de comércio eletrônico que geram os resultados da autenticação no formato desejado. em um algoritmo de pagamento seguro, uma tecla secreta é usada para criptografar uma concatenação do número da conta do proprietário do cartão com informações provenientes dos campos designados da estrutura de dados. em outro algoritmo de pagamento seguro os parâmetros de qualidade de serviço de teclas secretas são usados para criptogratar uma concatenação do número da conta do proprietário do cartão, o prazo de validade do e o código de serviço do cartão. em ambos os casos, porções dos resultados da criptografia são usadas para definirem o código de autenticação do comerciante.

Description

"SISTEMA PARA AUTENTICAR A TRANSAÇÃO COMERCIAL· EFETUADA PELO PROPRIETÁRIO DE UM CARTÃO JUNTO A UM COMERCIANTE EM UMA REDE ELETRÔNICA; ESTRUTURA DE DADOS PARA TRANSPORTAR INFORMAÇÕES E MÉTODO PARA A AUTENTICAÇÃO DA TRANSAÇÃO COMERCIAL".
ANTECEDENTES DA INVENÇÃO A presente invenção refere-se a sistemas e métodos para autenticar transações comerciais conduzidas pelas partes em redes eletrônicas abertas, tais como a Internet. Em particular, a invenção se refere à autenticação de operações transacionadas via Internet, nas quais os clientes efetuam pagamentos através de cartões de pagamentos, com a inclusão de cartões de crédito.
Atualmente o comércio eletrônico é popular. A condução de transações comerciais nas redes eletrônicas, tais como a Internet apresenta agora as vantagens tantas vezes falada de conveniência, preços módicos, alcance e opções mercadológicas tanto para clientes como para os comerciantes. Contudo, o anonimato da Internet acarreta para o comércio ou venda por atacado o perigo de fraude e abuso. 0 comerciante acha aconselhável autenticar a venda, certificá-la, confirmar a venda, assegurar sua aceitação, garantir o pagamento e controlar o anonimato. Da mesma forma, quem compra quer controlar a autenticação da venda, a integridade da mesma, recorrer por uma venda em liquidação, confirmar a venda, privacidade e anonimato. 0 pedido de patente N2 ü.S. 10/096.271, cedido à mesma cessionária do presente, depositado em 11 de março de 2002, ora incorporado integralmente ao presente à guisa de referência, descreve um sistema e método para garantir o pagamento seguro de transações comerciais que utilizam o software de usuário no terminal de cliente, para receber um pacote de dados de páginas da Rede a serem usados para exibir uma página da Rede, que pode incluir um ou mais campos ocultados. A página da Rede, com a transação e dados do proprietário do cartão, é enviada para o comerciante como os dados da compra. 0 comerciante pode submetê-la eletronicamente, por exemplo, ao emissor, para autenticação e autorização da transação de pagamento.
Os emissores de cartão e outras instituições financeiras agora oferecem ou utilizam protocolos de transação via Internet padronizados para aperfeiçoar a performance de transação on-line e para acelerar o crescimento do comércio eletrônico. Sob alguns protocolos padronizados (por exemplo, Protocolo 3-D Secure™ desenvolvido pelo Visa Internacional) emissores de cartão ou bancos de emissão podem autenticar transações desse modo reduzindo a probabilidade de fraude e contra ordem atribuídos a transações não autorizadas de proprietário do cartão. A presença de uma transação autenticada pode ter como resultado um emissor que admite a responsabilidade pela fraude caso isso ocorra independente dos esforços para autenticar o proprietário do cartão durante uma compra online. Os emissores de cartão ou bancos de emissão podem assegurar aos comerciantes que estes serão pagos com relação a transações de autenticadas pelo emissor. 0 protocolo 3-D Secure™ é compatível e reforça os programas de autenticação oferecidos pelos emissores de cartão (por exemplo, Verificado pelo Visa ou MasterCard SecureCode™} para autenticar consumidores para comerciantes durante transações comerciais realizadas à distância tais como aquelas associadas com a Internet. 0 Protocolo 3-D Secure™ alavanca a funcionalidade de criptografia de camada de Soquete Segura (SSL) existente e proporciona segurança aumentada através da autenticação de emissor do proprietário do cartão durante a sessão de compras online. Uma parte de software chamado Plug In Mercantil (MPI) é usado por comerciantes que participam para trocar mensagens, passar informações e participantes de consulta a fim de estabelecer uma sessão de autenticação entre o proprietário do cartão e seu emissor de cartão durante uma compra online.
Os serviços de Protocolo 3-D Secure são baseados sobre um modelo de três domínios-o domínio emissor, o receptor e o domínio de interoperabilidade. 0 emissor é responsável por gerenciar o registro de proprietários de cartão no serviço, e para autenticar proprietários de cartão durante as transações on-line. O receptor é responsável por definir procedimentos de modo que os comerciantes que participam em transações via Internet operem sob um acordo com o receptor, e para proporcionar processo de "programa/interface de suporte ao sistema" (back-end), para transações autenticadas. 0 domínio de interoperabilidade facilita a troca de transações entre os outros dois domínios com um protocolo comum e serviços compartilhados. Os proprietários de cartão e seus bancos podem vir sob domínio emissor, os comerciantes e seus bancos podem vir sob "domínio receptor". A comunicação entre bancos de emissão e recepção ou instiruições financeiras e infra-estrutura de emissor de cartão podem vir sob "Domínio de Interoperabilidade". Muito embora transações efetuadas com bancos e comerciantes compatíveis com 3-D Secure, um consumidor pode ter a mesma experiência de compra via Internet conforme anteriormente, exceto pelo fato que existe uma janela de autenticação separada ou uma tela instantânea proveniente do banco do proprietário do cartão para determinar se a parte que transaciona é realmente o proprietário de registro. 0 fluxo de transação para uma transação de compra online via Internet sob o protocolo pode ser como a seguir: (1) Os consumidores preenchem dados de pagamento em locais de Rede de Comerciante na configuração usual, através de uma conexão de Camada de Soquetes Segura (SSL) criptografada. (2) O Comerciante então envia uma mensagem através de um MPI para um Diretório, que pergunta sucessivamente ao emissor de cartão, para descobrir se o consumidor está registrado no programa 3-D Secure. (3) O emissor de cartão responde ao Diretório com uma mensagem que indica se o proprietário do cartão está registrado e, sendo assim, proporciona um endereço de Rede para o banco que emitiu o cartão. Essa mensagem é então processada e uma resposta transmitida ao Comerciante. (4) 0 comerciante então envia uma mensagem para o banco de emissão, através do dispositivo de proprietário do cartão, para a sessão de rubrica e autenticação entre o proprietário do cartão e o emissor de cartão onde detalhes de transação tais como o nome do Comerciante e a quantia de transação também podem ser apresentados ao proprietário do cartão para confirmação. (5) 0 banco emissor irá então ocupar uma janela de autenticação para a informação de detalhamento de proprietário do cartão relacionada com a transação tais como nome e quantia de comerciante, mensagem de segurança pessoal, e uma área de resposta onde detalhes de autenticação podem ser lançados pelo proprietário do cartão. (6) 0 consumidor aprova a transação em uma entre uma variedade de formas, dependenao como o banco de emissão escolhe para implementar o sistema. As opções podem variar entre lançar uma senha estática ou PIN para utilizar um cartão inteligente e um Leitor de Cartão Pessoal (PRC) para gerar uma autenticação de ficha. (7) 0 emissor pode processar a transação e o dado de proprietário do cartão para autenticação. Se a autenticação for válida, o emissor envia uma mensagem para o comerciante que indica que a autenticação foi bem sucedida. 0 emissor também notifica o comerciante se a autenticação falhou ou não foi capaz de ser completada. A mensagem pode incluir um Valor de Autorização de Proprietário de Conta (AAV) que codifica os resultados de processo de codificação.
Leva-se em conta agora as formas para aumentar os sistemas e métodos para autenticar os consumidores que usam cartões de crédito ou débito para pagamento em transações eletrônicas. A atenção é direcionada aos dados e algoritmos que são usados para autenticar seguramente o consumidor ou cartão para pagamento do comerciante. As soluções devem ser preferencialmente compatíveis com implementações de indústria de protocolos comuns tipo 3-D Secure e outros padrões de indústria tais como o padrão EMV para cartões inteligentes.
SUMÁRIO DA INVENÇÃO
De acordo com a presente invenção, os programas de autenticação que são compatíveis com os protocolos 3-D Secure são proporcionados para autenticar transações de cartão de proprietário online. Os programas de autenticação usam um Servidor de Controle de Acesso (ACS) para autenticar transações de proprietário de cartão. Os Algoritmos de Pagamentos Seguros (SPA) são aplicados pelo ACS para informação de proprietário de cartão e transação para gerar um Valor de Autenticação de Proprietário de Conta (AAV) criptografado, que é atribuído a uma transação autenticada. 0 AAV gerado possui uma estrutura de dado que é adequada para inclusão em mensagens de protocolo 3-D Secure.
Em modalidades preferidas da invenção, a estrutura de dado possui um comprimento de não mais que aproximadamente 20 bytes de caracteres codificados com Base 64. O primeiro byte pode ser um byte de controle, os bytes 2-9 podem representar um sinal numérico de um nome de comerciante, e o byte 10 identifica o ACS particular que autentica a transação de proprietário de cartão. Vários métodos de autenticação (por exemplo, baseado em senha, baseado em circuito integrado, ou métodos de identificação de PC) podem ser usados pelo ACS para autenticar a transação de proprietário de cartão. 0 byte 11 da estrutura de dado MV identifica o método de autenticação e as chaves de criptografia secretas que são usadas pelo ACS para gerar um Código de Autenticação de Comerciante (MAC). Os bytes 12-15 da estrutura de dado AAV identificam um número de seqüência de transações processadas pelo ACS, e os bytes 16-20 representam o MAC. O SPA pode incluir processos de criptografia adequados para gerar os valores de MAC para uma transação particular. Um processo de criptografia utiliza uma chave secreta para criptografar uma concatenação de um número da conta e campos 1-6 (ou bytes 1-15) do proprietário do cartão do AAV. Os primeiros 40 bits (ou 5 bytes binários) do resultado de criptografia são designados para o campo MAC. Em outro processo de criptografia, um par de chaves de Padrão de Criptografia de Dados (DES) é usada para criptografar uma concatenação do número da conta do proprietário do cartão , prazo de validade do cartão e código de serviço para gerar um número de Código de Verificação de Proprierário de Cartão (CVC2) de três dígitos. Esse número de três dígitos é convertido em decimal de código binário que então é usado para povoar um byte e um byte e meio do campo MAC na estrutura de dado AAV. Os três bytes e um byte e meio restantes do campo MAC podem ser controlados e povoados com zeros binários.
As mensagens eletrônicas de Protocolo 3-D Secure, que incluem dados AAV, podem ser sinalizados digitalmente pelo servidor de controle de Acesso (ACS). O comerciante recebe uma mensagem que contém o dado AAV pode ser requerido para validar a assinatura digital em conformidade com o Protocolo 3-D Secure antes de extrair ou usar o dado AAV. Os comerciantes podem transferir o dado AAV e o dado MAC em particular para mensagens de solicitação de autorização de pagamento.
As características adicionais da invenção, sua natureza, e várias vantagens serão mais aparentes a partir da seguinte descrição detalhada e dos desenhos em anexo.
BREVE DESCRIÇÃO DOS DESENHOS A Figura 1 é uma ilustração esquemática de um programa de autenticação exemplificativo que utiliza Algoritmos de Pagamentos Seguros (SPA) para gerar Valores de Autenticação de Proprietário de Cartão (AAV} para transações de pagamento, de acordo com os princípios da presente invenção. A Figura 2 é uma ilustração esquemática da estrutura de um Campo de Conta de Proprietário de Cartão Universal, que é usado para transportar a saída dos Algoritmos de Pagamento Seguros (SPA) da Figura 1, de acordo com os princípios da presente invenção. A Figura 3 é uma ilustração de algumas etapas e enlaces de mensagem entre entidades que estão envolvidas em um processo de autenticação de transação de pagamento exemplificativo, de acordo com os princípios da presente invenção. A Figura 4 é uma ilustração esquemática de interação entre a autenticação exemplificativa e as entidades de autorização envolvidas nas entidades de autenticação e autorização de transações de pagamento online.
Através das Figuras, a menos que de outra maneira determinada, as mesmas referências numéricas e caracteres são usados para indicar características, elementos, componentes, ou partes similares das modalidades ilustradas.
DESCRIÇÃO DETALHADA DA INVENÇÃO A presente invenção proporciona soluções para autenticar partes à distância em uma transação eletrônica. Em particular, as soluções referem-se a Aplicações de Pagamento Seguro (por exemplo, Figura 1 SPA 135) que são usadas para autenticar um proprietário de cartão que participa à distância da transação eletrônica. As soluções podem ser usadas para autenticação de transação nas plataformas de comércio eletrônico de padrão de indústria, tais como plataformas de comércio eletrônico compatível com 3-D Secure, e em ambientes de comércio não eletrônico tais como encomenda pelo correio e encomenda por telefone ou dispositivos móveis onde uma ficha de autenticação ou código pode ser usado pelo emissor para autenticar o proprietário de cartão. A Tabela 1 é um glossário de diversos dos termos, acrônimos ou abreviaturas que são usados na descrição do presente documento. TABELA 1 0 SPA 135 pode incluir algoritmos de criptografia (isto é, algoritmos "HMAC" e "CVC2") que são usados para gerar Valores de Verificação de Autorização de Proprietário de Cartão (CAVV) em formatos que são compatíveis com os formatos de mensagem 3-d Secure. 0 SPA 135 pode ser integrado com qualquer programa de autenticação adequado que os emissores podem escolher ou implementar para autenticar seus proprietários de cartão. Os programas de autenticação podem incluir soluções baseadas em cartões inteligentes e baseadas em senhas (por exemplo, Figura 1 programa de autenticação baseado em circuito integrado 141 e programa de autenticação baseado em senha 3-D Secure 142) . Os programas de autenticação também podem incluir outras soluções, baseadas, por exemplo, na identificação de PC.
Um programa de autenticação onde as Aplicações de Pagamento Seguras (SPA 135) inventivas que são utilizadas podem ser uma solução ou programa para proteger as transações eletrônicas conduzidas nas plataformas de comércio eletrônico que são compatíveis ccm os protocolos 3-D Secure. Para esse propósito SPA 135 é designado para utilizar e gerar resultados de autenticação em formato de dados que podem ser usados de forma legível em mensagens 3-D Secure. Em particular, uma estrutura de dado formatada com campos definidos e o comprimento de byte que pode ser usado para facilitar o transporte de resultados de autenticação em mensagens 3-D Secure.
Com o propósito de ilustrar a aplicação de SPA 135 em um programa de autenticação exemplifícativo 1000 (Figura 1), uma transação de pagamento com cartão é usada no presente documento como uma transação exemplificativa. Os participantes na transação de pagamento com cartão podem incluir um proprietário de cartão, um emissor, um comerciante e um receptor.
Um proprietário de cartão é um usuário autorizado de um cartão de pagamento emitido, por exemplo, por um elemento licenciado de programa de autenticação 1000. O proprietário de cartão pode usar o cartão de pagamento emitido para pagar por uma transação on-line com um comerciante. O programa de autenticação 1000 pode ser parte de um programa de autenticação ou serviços proporcionados por uma terceira parte (por exemplo, MasterCard) que, por exemplo, pode assegurar que a identidade e presença do proprietário de cartão sejam propriamente autenticadas antes do término da transação.
Um emissor é um elemento (por exemplo, uma instituição financeira) que emite o cartão de pagamento, que pode ser de marcas registradas (por exemplo, cartões MasterCard® e/ou Maestro®). O emissor garante o pagamento para uma transação autorizada que usa o cartão de pagamento de acordo com os regulamentos e legislação local de marcas de cartões de pagamento. O emissor pode ser responsável por determinar elegibilidade de proprietário de cartão para participar em programa de autenticação 1000, além de proporcionar serviços de autenticação para comerciantes ou outras partes.
Um comerciante é um varejista, ou qualquer outra pessoa, firma, ou corporação que, por exemplo, em conformidade com um acordo de subscrição mercantil, que concordam em aceitar emissores de cartões de pagamento para pagamento quando os mesmos são propriamente apresentados. Ao subscrever o programa de autenticação 1000, um comerciante pode oferecer um proprietário de cartão uma interação eletrônica autenticada através da Internet. Um comerciante que aceita cartões de pagamento pode ter um relacionamento adicional com o receptor. Os comerciantes que participam em programas de autenticação 1000 podem se beneficiar de diversas maneiras incluindo fraude reduzida e custas judiciais, volume de transação aumentado, proteção contra uso de cartão não autorizado, e acesso à base de cartão do emissor.
Um receptor é uma entidade que mantém relacionamentos com comerciantes e recebe os dados relacionados com uma transação a partir do comerciante ou aceitante de cartão. 0 receptor pode ser responsável por determinar a elegibilidade para participar em programa de autenticação 1000.
Como mostrado na Figura 1, o programa de autenticação exemplificatívo 1000, pode ser implementado com uma disposição ou plataforma de comércio eletrônico seguro com um número de componentes em camadas. Os componentes em camadas incluem camada de transporte de dados 100, camada de requerimento mercantil. 120, camada de autenticação 130, e plataforma de emissor 140. A camada de autenticação refere-se às Aplicações de Pagamento Seguras (SPA 135) que são dispostos para autenticar uma transação ou um pagamento. A camada de transporte de dados 100 refere-se à coleta de dados e infra-estrutura de transporte que é usada para comunicar informação de autenticação e resultados entre proprietário de cartão, emissor, comerciante e receptor. 0 transporte de dados pode ser, por exemplo, baseados em estruturas de dados padronizados, arquiteturas ou mecanismos tal como o Campo de Autenticação de Proprietário de Cartão Universal (UCAF). O UCAF pode geralmente ser definido como um comprimento variável, 32 campos de caracteres com uma estrutura de dados flexível que pode ser feito sob medida para sustentar as necessidades de uma variedade de seguranças de emissor e abordagens sobre autenticação. A Figura 2 mostra uma estrutura genérica de UCAF. Um primeiro byte de controle em UCAF contém o valor que é especifico para cada aplicação ou aspecto de pagamento de segurança. O restante dos bytes em UCAP pode incluir dado específico de aplicativo. Um fornecedor de autenticação ou autorização pode ser responsável por assinar e gerenciar valores de byte de controle UCAF e a estrutura de dados específicos de aplicação UCAF.
Uma definição de byte de controle exemplificativo pode ser conforme a seguir.
Emprego 3-D Secure SPA AAV para primeira transação e subseqüentes Valor Codificado com Base 64 j Valor Hexadecimal x'8C' Outra definição de byte de controle exemplificativo pode ser conforme a seguir: Emprego 3-D Secure SPA AAV para tentar Valor Codificado com Base 64 j Valor Hexadecimal x'86' Em implementações UCAF convencionais, o dado especifico de aplicativo pode ser definido como dado binário com um comprimento máximo de 24 bytes binários -que inclui o byte de controle. Contudo, algumas redes de autorização de transação limitam a passagem de dado binário em mensagens de autorização. Desta maneira, todos os dados UCAF gerados pelo SPA 135 em programa de autenticação 1000 pode ser codificado em Base 64 antes da inclusão em uma mensagem de autorização. A codificação com Base 64 produz uma representação de caractere do dado binário associado. A representação de caractere resultante é aproximadamente três vezes maior que o binário equivalente. Por essa razão, o campo UCAF pode geralmente ser definido com um comprimento máximo de 32 caracteres. Entretanto, para compatibilidade com troca de mensagens 3-D Secure em programa de autenticação 1000, o campo UCAF é limitado a 28 caracteres em comprimento. 0 Valor de Autenticação de Proprietário de Conta (AAV) é uma implementação específica de UCAF relacionado às plataformas de autenticação de emissor que incorporam o SPA. O AAV pode ser gerado pelo emissor e apresentado ao comerciante para disposição em uma solicitação de autorização de transação (ao receptor) mediante a autenticação bem-sucedida do proprietário de cartão pelo emissor. No caso de uma contra ordem ou outro processamento de disputa potencial, o AAV pode ser usado para identificar os parâmetros de processamento associados com a transação. 0 UCAF é um mecanismo que é usado para transmitir o AAV a partir do comerciante até o emissor com propósitos de autenticação durante o processo de autorização.
Com referencia renomada a Figura 1, a camada de requerimento de comerciante 110 refere-se às capacidades de comerciantes de interagir com outras camadas e o proprietário de cartão. Os comerciantes que participam em programa de autenticação 1000 podem implementar capacidades de software aplicativo (por exemplo, plug-ins Mercantis (MPI)) que são capazes processar mensagens 3-D Secure. O MPI serve como a aplicação de controle para o processamento de mensagens 3-D Secure. A camada de autenticação 130, que inclui o SPA 135 inventivo, representa o processo ou serviço de autenticação (por exemplo, proporcionado ou contratado por um emissor) para verificar domínio de conta de proprietário de cartão. Um emissor que usa, por exemplo, um servidor de controle de acesso (ACS) pode implementar a camada de autenticação 130/SPA135 em conjunção com um servidor/processo de validação AAV.
Os componentes ou entidades de rede de comercio eletrônico exemplificativo que são envolvidos no processo de autenticação podem para propósitos de ilustração ser organizados como pertencentes ao domínio de emissor, receptor ou interoperabilidade como mostrado na Tabela 2. TABELA 2 Com referência à Tabela 2, a funcionalidade presente no domínio emissor inclui um navegador de proprietário de cartão que pode agir como um conduto para transportar mensagens entre o MPI (no domínio receptor) e o servidor de controle de acesso (no domínio receptor). 0 software de proprietário de cartão referido, por exemplo, pode incluir software profissional para sustentar o uso de cartões inteligentes. O servidor de registro facilita o processo de registro de proprietário de cartão para uma implementação do emissor de 3-D Secure sob o programa de autenticação 1000. 0 servidor pode ser usado para efetuar a autenticação de proprietário de cartão inicial, assim como para atividades administrativas tais como reiniciar e visualizar histórico de pagamento em 3-D Secure. 0 servidor de controle de acesso proporciona pelo menos duas funções básicas durante o andamento de uma compra online. Primeiro, o ACS irá verificar se um número da conta de proprietário de cartão dado está registrado no programa 1000. Segundo, o ACS irá conduzir os processos de autenticação para identificação de proprietário de cartão. Para esse propósito, o ACS pode operar em conjunção ou incluir um servidor/processo de validação. Esse servidor/processo de validação AAV também pode ser usado para validar dados de autenticação de proprietário de cartão recebidos a partir de comerciantes ou receptores. A funcionalidade no domínio receptor pode incluir as funções de um Plug-In Mercantil (MPI) e um servidor de validação de assinatura. 0 MPI pode criar e processar mensagens de autenticação pagadoras e então retornar o controle para o software mercantil para depois processar a autorização. Os processos de autenticação MPI pode ser solicitados depois que um proprietário de cartão submete uma solicitação de compra, que inclui o número da conta a ser usado para o pagamento, mas antes para obter autorização para a compra. 0 servidor de validação de assinatura pode ser usado para validar uma assinatura digital em uma solicitação de compra que tenha sido autenticada com sucesso pelo emissor. A funcionalidade no domínio de interoperabilidade pode incluir um servidor de diretório. 0 servidor de diretório pode ser um servidor de diretório global, que proporciona capacidades de tomar decisões centralizadas para comerciantes registrados no programa de autenticação 1000. Baseado no número da conta contido em uma mensagem de solicitação de verificação de comerciante, o diretório pode primeiro determinar se o número da conta faz parte de uma faixa de cartão do emissor de cartão participante. Isto pode então direcionar solicitações elegíveis para o emissor ACS apropriado para processamento adicional. O domínio de interoperabilidade pode incluir uma autorização de certificado adequada para gerar e distribuir todas as entidades finais de hierarquia privada e certificados subordinados, como requerido, para os diversos componentes e para outras autoridades de certificado subordinado através de todos os três domínios. O processo de autenticação de proprietário de cartão em programa 1000 envolve trocas de mensagens e dados através dos três domínios. As seguintes mensagens entre domínio 3-D Secure exemplificativas podem ser usadas passo a passo no processo de autenticação: (1) Solicitação/Resposta de Verificação Par de Mensagens: VEReq/VERes Uma primeira etapa no processo de autenticação é checar ou validar que o número da conta de proprietário de cartão seja parte da faixa de cartão de um emissor que participa em programa de autenticação 1000. Para esse propósito, a mensagem de Resposta de Verificação VEReq, é enviada a partir do MPI para o diretório para checar a elegibilidade de faixa de cartão. Se o número da conta especificado for contido dentro de uma faixa de cartão elegível no diretório, essa mensagem pode então ser encaminhada a partir do diretório para o emissor do ACS para depois checar se o número da conta especificado é registrado e/ou ativado pelo emissor como um participante em programa 1000. O MPI pode possuir uma capacidade opcional para realizar o cachê nas faixas do cartão por cada emissor participante. Em tais casos, mensagens Solicitação/Resposta de Faixa de Cartão podem ser usadas pelo MPI para solicitar atualizações para os cachês de faixa de cartão a partir do diretório. Para comerciantes cujas faixas de cartão em cachê, as mensagens VEReq/VERes podem não ser utilizadas se o local de cachê indicar que o emissor não está registrado em programa de autenticação 1000. (2) Solicitação/Resposta de Autenticação Pagadora.
Par de Mensagens: PAReq/PARes Uma vez que foi determinado que o cartão de proprietário está registrado por um emissor ou é um participante ativo no programa 1000, o processo de autenticar o cartão de proprietário especifico envolve adicionalmente o emissor de cartão específico. As mensagens de Solicitação/Resposta de Autenticação Pagadora podem ser enviadas a partir do MPI para o cartão específico do emissor ACS para efetuar a autenticação. Nessa etapa do processo de autenticação em programa 1000, o cartão de proprietário pode ser apresentado com uma janela de autenticação. A janela de autenticação pode ser mostrada no navegador de proprietário de cartão e ser povoado com informação relevante pelo emissor. 0 proprietário de cartão pode ser solicitado para lançar uma senha, código ou ficha para identificação pessoal ou autenticação através da janela de autenticação mostrada. 0 cartão específico do emissor ACS pode então usar, por exemplo, o SPA 135 para autenticar a informação coletada ou lançada, e gerar consequentemente um Valor de Autenticação de Proprietário de cartão (AAV) . 0 AAV é transportado nas mensagens 3-D Secure PARes (Resposta de Autenticação Pagadora) em um campo de Valor de Verificação de Autenticação de Proprietário de Cartão (CAVV) designado em um UCAF. 0 CAAV é um dos campos de dados na parte de resposta do par de mensagens PAReq/PARes que retorna para o emissor para a solicitação de comerciante. 0 emissor pode colocar assinaturas digitais adequadas em suas respostas. O comerciante pode, depois, incluir o AAV recebido para um receptor para encaminhar ao emissor como parte de uma solicitação de autorização de pagamento/transação (Ver por exemplo a Figura 4). A Figura 3 mostra esquematicamente um processo de autenticação de cartão exemplificativo 300 para uma transação de proprietário de cartão sob programa de autenticação 1000. Com propósito de ilustração, a descrição de processo 300 supõe que o proprietário de cartão 310 está registrado por um emissor em programa de autenticação 1000 e tenha obtido uma senha ou código a partir do emissor para usar enquanto compra online em comerciantes participantes. O processo 3C0 também supõe que todos os canais de comunicação entre os componentes (por exemplo, proprietário de cartão 310, MPI 320, diretório 330 e emissor ACS 340) estão apropriadamente seguros usando os enlaces de protocolo de Camada de Soquete Segura (SSL) (Por exemplo, SSL-1, SS1-2, SS1-3, SS1-4, SSL-5 e SSL-6).
No processo 300 na etapa 352, o proprietário de cartão 310 pode comprar em local de Rede mercantil e, quando está pronto para sair, lança a informação de cartão de pagamento (por exemplo, o número da conta) e outra informação (por exemplo, informação de embarque) via enlace SSL-1. Uma vez que todas informações de pagamento e embarque foram lançadas, o comerciante pode dar ao proprietário de cartão 310 uma oportunidade para revisar a compra antes de enviar uma encomenda. A seguir na etapa 352, o MPI 320 pergunta ao diretório 320 via enlace SSL-2 para verificar o registro de proprietário de cartão 310 com um emissor especifico que usa a mensagem de solicitação de verificação VEReq. A etapa 352 pode opcionalmente ser efetuada localmente no MPI 320 via um cachê de diretório de cartão local Em resposta as mensagens VEReq, o diretório 330 pode determinar que um emissor particular é participante, e dessa maneira encaminha uma solicitação via enlace SSL-3 para o ACS 340 do emissor particular para verificar o estado de registro atual de proprietário de cartão 310. As respostas resultantes podem vazar sobre os mesmos enlaces (por exemplo, SSL-3 e SSL-2) para MPI 320. Se o ACS 340 indica que o proprietário de cartão 310 está registrado no programa 1000, o MPI 320 pode criar uma mensagem de Solicitação de Autenticação Pagadora e envia a mesma ao navegador do proprietário de cartão na etapa 354 via enlace SSL-4. A seguir na etapa 355, o navegador do proprietário de cartão pode redirecionar a mensagem o ACS 340 do emissor particular para iniciar autenticação de proprietário de cartão. Quando o ACS 340 recebe a mensagem de solicitação de autenticação Pagadora, isso pode causar o inicio de um diálogo de autenticação de usuário. Como parte do diálogo de autenticação de usuário, o ACS 340 pode causar uma janela de autenticação interativa separada para ser mostrada ao proprietário de cartão 310 para facilitar a senha, código ou outra entrada de dado pelo proprietário de cartão 310.
Na etapa 356, o ACS 340 (usando SPA 135) pode autenticar a senha ou código lançado pelo proprietário de cartão 310. O ACS 340 pode construir um SPA AAV de acordo com a implementação do fornecedor do programa de autenticação 3-D Secure. O ACS 340 pode construir e sinalizar digitalmente uma mensagem de resposta de autenticação pagadora apropriada. A mensagem de resposta de autenticação pagadora então volta (via enlace SSL-6) para o MPI 320. A janela de autenticação mostrada para o proprietário de cartão 320 pode desaparecer nesse ponto.
Depois que o processo de autenticação de proprietário de cartão foi completado, o comerciante pode ser requerido a passar o SPA AAV recebido para o receptor através do campo UCAF dentro de uma mensagem de autorização. O SPA AAV pode então ser passado ao longo a partir do receptor para o emissor como parte de processamento de mensagem de autorização convencional.
Quando recebido pelo emissor, o AAV pode ser validado como parte de processamento de solicitação de autorização, e arquivado no caso de qualquer disputa de proprietário de cartão que possa surgir mais tarde.
Formatos de mensagem e formatos de dado de versão 1.0.2 3-D Secure padrão podem ser usados para todas as comunicações de dados entre as partes ou entidades envolvidas. Especificamente, o SPA AAV que o ACS 3410 cria e retorna ao comerciante para inclusão em mensagens UCAF é 28 caracteres maior e contém um campo de 20 byte definido para 3-D Secure em codificação com Base 64. A Tabela 3 mostra uma estrutura ou formato de dados exemplificativa de um SPA AAV de 20 byte. TABELA 3 0$ emissores que proporcionam tanto identificação PC existente como outras soluções de autenticação (por exemplo, Figura 1) a fim de uma solução 3-D Secure possa diferenciar entre os valores AAV que eles recebem a partir de soluções de autenticações diferentes na mensagem de autorização correspondente. O AAV de 20 byte (por exemplo, Tabela 2) resultantes a partir de programa 1000 compatível 3-D Secure podem se diferenciar a partir de estruturas AAV de 28 bytes comuns (isto é, em programas que não são 3-D Secure) nas seguintes maneiras: A quantidade de transação e os códigos da moeda corrente não são incluídos no AAV de 20 byte como essa informação é incluída na mensagem PARes sinalizada; Um selo de transação mercantil (MTS) não é incluída como um identificador de transação (XID), que é incluída na mensagem PARes sinalizada, pode proporcionar a mesma funcionalidade. Ademais, o sinal numérico do campo de nome de comerciante é expandido. Como um resultado, somente edições mínimas do nome de comerciante podem agora ser requeridas para criar o sinal numérico SHA-1.
Um comerciante pode não ter que modificar o byte de controle para autorizações subseqüentes (por exemplo, expedições desmembradas). Para expedições desmembradas, o comerciante pode reenviar um MV original gerado Por implementações compatíveis 3-D Secure do programa 1000. 0 valor de byte de controle no SPA AAV de 20 bytes é baseado no resultado da solicitação de autenticação de proprietário de cartão (PAReq). Esse resultado pode ser indicado no campo estado de transação das mensagens de Resposta de Autenticação Pagadora (PARes) A Tabela 4 mostra valores exemplificativos do campo de estado de transação em uma mensagem PARes. TABELA 4 0 nome de comerciante contido na mensagem PAReq pode ser editado antes de criar o sinal numérico de nome de comerciante. As edições podem endereçar especificamente a codificação de Formato de Transformação Universal (UTF-8) mas também referencia para outros tipos de codificação Unicode.
Uma edição pode apagar qualquer seqüência de 8 byte UTF que não possua uma representação Unicode. Tal edição pode apagar qualquer 8 byte UTF que comece com o binário 1111 e todos os bytes subseqüentes que comecem com o binário 10.
Outra edição pode apagar qualquer següência de 8 byte UTF ou seqüência de byte com a seguinte representação Unicode: 0000 *a* 001F (caracteres de controle ASCI; 007F *a* 00A0 (caracteres de controle DEL e Cl; 00AD (hifen condicional); e 2000 *a* 206F (Pontuação Geral).
Tal edição pode apagar os seguintes 8 bytes UTF: Hex 00 *a* 1F
Hex 7F
Hex C2 80 a C2 A0 Hex C2 AD
Hex E2 80 *a* E2 81 AF
Ainda outra edição pode apagar qualquer entrelinhamento ou espaços posteriores, (por exemplo, bytes de UTF-8 Hex 20).
No caso de uma contra ordem ou outro processo de disputa potencial, o AAV de 20 byte pode ser usado para identificar os parâmetros de processamento associados com a transação. Entre outras coisas, o os valores de campo AAV podem identificar: • A posição física de onde a transação foi processada. • A seqüência numérica que pode ser usada para identificar positivamente a transação dentro do universo de transações para aquela posição. • A chave secreta usada para criar o MAC, que não somente assegura a integridade de dado AAV como também vincula toda a estrutura AAV para um PAN específico para implementações de 3-D Secure.
As dependências de campo no AAV podem ser estabelecidas para assegurar a identificação apropriada dos parâmetros de processamento. Essas dependências de campo podem ser consideradas quando construir ou configurar instalações ACS de emissor. Para cada ACS configurado com o mesmo identificador ACS: * 0 campo de Identificador de Chave BIN deve ser único para cada faixa de BIN processada pelo ACS identificado. A maior parte de emissores pode usar um conjunto de chaves para a maioria ou todas as faixas de BIN. Entretanto, essa configuração permite flexibilidade em uma escolha de vendedores de software que sustentam ou emissores que requerem o uso de um conjunto de chaves separadas. o 0 campo de Transação de Sequência Numérica deve ser único para cada AAV gerado pelo identificador ACS dentro do tempo que a contra ordem possa ocorrer.
As instalações ACS que possuem a capacidade de compartilhar chaves BIN e um conjunto comum de transações de seqüências numéricas através de instalações lógicas múltiplas ou maquinas físicas podem ser configuradas de forma vantajosa para usarem o mesmo identificador ACS. Alternativamente, um identificador ACS separado ou conjunto de identificadores ACS podem ser requeridos para cada instalação. Em casos onde uma facilidade ACS serve emissores múltiplos, mais de um emissor pode compartilhar um identificador ACS. Nesses casos, o valor de campo BIN para a transação associada pode torna-se um fator determinante em interpretar a posição de conteúdo de campo.
Os algoritmos particulares podem ser utilizados em SPA 135 para criar um valor de código de Autenticação Mercantil (MAC). Por exemplo, um algoritmo "HMAC" ou um algoritmo "CVC2" pode ser usado pelo ACS identificado pelo campo secundário do identificador ACS para criar valores MAC.
0 algoritmo HMAC gera um valor MAC criptograficamente baseado em uma chave secreta identificada pelo campo secundário do identificador de Chave BIN. Essa chave secreta é compartilhada com o emissor e vincula o número da conta de proprietário de cartão com o AAV pela concatenação dos seguintes dados: • 0 número da conta, conforme recebido pelo ACS na mensagem de Solicitação de Verificação (VEReq) que corresponde à mensagem de Solicitação de Autenticação Pagadora (PAReq) atual. 0 número da conta pode ser representado como um decimal de código binário, justificado à esquerda e aumentado à direta com F's hexadecimais até um comprimento de 20 dígitos (10 bytes). • Os 15 bytes mais à esquerda, campos de 1 a 6, do AAV que são construídos. O comprimento de chave secreta pode ser selecionado opcionalmente para ter um mínimo de 128 bits (16 bytes) e um máximo de 192 bits (24 bytes) . Qualquer intervenção no tamanho da chave (por exemplo, 160 bits) pode ser aceitável. O tamanho do comprimento de chave atual usado pode ser selecionado independentemente por cada implementação. 0 campo MAC dentro do SPA AAV definido por um programa de autenticação 3-D Secure (por exemplo, Programa 1000) pode ser povoado com os 40 bits mais à esquerda (5 bytes binários) do resultado criptográfico obtido por aplicar o algoritmo HMAC.
Os exemplos 1 e 2 ilustram a aplicação do algoritmo HMAC que usa chaves de 20 byte e 16 byte, respectivamente, para gerar valores SPA AAV. EXEMPLO 1 (Chave de 20 Byte) Número de conta adotada: 5432 109876543210 Nome de Comerciante Adotado: SPA Comércio, Inc. (Todos os caracteres ASCII, e nenhuma edição requerida). Byte de controle AAV adotado: 8C Primeiros 8 bytes, sinal numérico SHA-I de Nome de Comerciante = 7CA7 FBB6 058B 5114 ACS Id adotado = 01 Método de Autenticação Adotado = 1 (Senha) Chave BIN Id Adotada = I Número de Sequência de Transação Adotada = 0000002F
Chave Adotada(20 Bytes) = OBOBOBOBOBOBOBOBOBOBOBOBOBOBOBOBOBOBOBOB Portanto SHA-1 HMAC é baseado em 5432 109876543210 FFFF 8C 7CA7FBB6058B5114 0111 0000002F
Isso produz um MAC cujos 5 primeiros bytes são: 3547 BA1E FF
Logo, o AAV completo em hex é: 8C 7CA7FBB6058B5114 0111 0000002F 3547BA1EFF
Depois da codificação com Base 64, obtém-se o seguinte: jHyn+7YFiIEUAREAAAAvNUe6Hv8= EXEMPLO 2 (Chave de Byte 16) Número de Conta Adotada: 5432 109876543210 Nome de Conta de Comerciante Adotada: SPA
Comércio, Inc (Todos caracteres ASCII, e nenhuma edição requerida) Byte de controle adotado = 8C
Primeiros 8 bytes, sinal numérico SHA-1 de Nome de Comerciante = 7CA7 FBB6 058B 5114 ACS Id adotado = 01 Método de Autenticação Adotado = 1 (Senha) Chave BIN Id Adotada = 1 Número de Sequência de Transação Adotada = 0000002F
Chave Adotada (16 Bytes) = 00112233445566778899AABBCCDDEEFF
Portanto SHA-1 HMAC é baseado em 5432 109876543210 FFFF 8C 7CA7FBB6058B5114 0111 0000002F
Isso produz um MAC cujos 5 primeiros bytes são: EB27 FC7F AB
Logo, o AAV completo em hex é: 8C 7CA7FBB6058B5114 0111 0000002F EB27FC7FAB Depois da codificação com Base 64, obtém-se o seguinte: jHyn+7YFil EUAREAAAA v6yf8f6s= 0 algoritmo CVC2 também cria criptograficamente os valores de campo MAC. Em contraste com o algoritmo HMAC, que usa uma chave, o algoritmo CVC2 usa duas chaves de 64 bit DES identificadas pelo campo secundário do identificador de Chave BIN. No algoritmo CVC2, todas as etapas de criptografia e decriptografia podem usar formas do Modo do Livro de Códigos (ECB) de DES. 0 algoritmo CVC2 gera um valor CVC2 dígito 3 com três dígitos. 0 dado de entrada que é processado pelo algoritmo CVC2 para gerar esses valores CVC2 dígito 3 com três dígitos é mostrado na Tabela 5. TABELA 5 0 valor CVC2 de três dígitos resultante é convertido em forma decimal de código binário e povoado mais à esquerda com 2 bytes do campo secundário MAC com um entrelinhanento binário 0 usado para preencher o primeiro meio byte não usado. Os três bytes restantes do campo secundário MAC podem ser preenchidos com zeros binários. Por exemplo: CVC2 = 123 MAC
Campo secundário = 0123000000 (10 dígitos totais) 0 Exemplo 3 e a Tabela 6 ilustram a aplicação do algoritmo CVC2 e as etapas do processo envolvidos na aplicação do algoritmo para gerar valores SPA AAV. EXEMPLO 3 Número de Conta Adotada: 5432109876543210 Nome de Conta de Comerciante Adotada: SPA
Comércio, Inc (Todos caracteres ASCII, e nenhuma edição requerida) Byte de controle AA V adotado = 8C Primeiros 8 bytes, sinal numérico SHA-1 de Nome de Comerciante = 7CA7 FBB6 058B 5114 ACS Id adotado = 7 Método de Autenticação Adotado = 1 (Senha) Chave BIN Id Adotada = 1 Número de Seqüência de Transação Adotada 0000002F
Chave A = 0011223344556677 Chave B
8899AABBCCDDEEFF
Portanto, o cálculo do algoritmo CVC2 é baseado em Número de Conta = 5432109876543210 Data de Validade = 0047 Código de Segurança = 140 Isso produz um valor de três dígitos CVC2 = 439 (ver Tabela 6 para cálculo): Baseado no valor CVC2 calculado, o campo MAC = 0439000000 Logo, o AA V completo em hex é: 8C 7CA7FBB6058B5114 01 11 0000002F 0439000000 Codificação com Base 64, obtém-se: jHyn+7YFil EUAREMMvBDkAMA= As etapas de processamento ou cálculo que são usadas no Exemplo 3sao mostrados na Tabela 6. TABELA 6 Conforme definido pelo protocolo 3-D Secure, todas as mensagens PARes que retornam para o comerciante são digitalmente sinalizadas pelo emissor ACS do proprietário de cartão associado. Pode-se requerer que o comerciante valide a assinatura digital antes de extrair o SPA MV da mensagem PARes para inclusão de uma solicitação de autorização enviada ao receptor. Se um emissor sustenta tanto a implementação de 3-D Secure como outras plataformas de autenticação (por exemplo, plataformas de Autenticação PC) pode ser necessário distinguir entre as duas plataformas de autenticação durante o processamento da mensagem de solicitação de autorização. Isso pode ser realizado em uma das duas formas: 1. 0 primeiro caractere de código com base 64 é: a. "j" ou "h" para o SPA AAV dentro da implementação definida de 3-D Secure b. "g" ou "A" para a Autenticação SPA AAV PC 2. 0 byte de controle, convertido em binário, é também a. hexadecimal 8C ou hexadeciraal 86 pra o AAV definido para implementação do MasterCard de 3-D Secure b. hexadecimal 82 ou hexadecimal 02 para a autenticação SPA AAV PC.
Cada emissor participante no programa 1000 pode assegurar que o campo secundário do identificador ACS seja ajustado apropriadamente para indicar o algoritmo usado para criar o MAC. Uma falha para ajustar esse indicador corretamente pode resultar em validações impróprias durante o processo de autorização de transação/pagamento.
Embora a presente invenção tenha sido descrita em conexão com as modalidades exemplificativas especificas, deveria ser entendido que diversas alterações, substituições, e alterações óbvias para aqueles versados na técnica poderíam ser feitas nas modalidades mostradas sem que se abandone o espírito e o escopo da invenção.
REIVINDICAÇÕES

Claims (22)

1. Sistema para autenticar a transação comercial efetuada pelo proprietário de um cartão junto a um comerciante em uma rede eletrônica, sendo que o sistema é CARACTERIZADO pelo fato de compreender: uma camada de plataforma do emissor, que inclui ao menos um programa de autenticação segura em 3-D; uma aplicação de plug-in do comerciante (MPI); um algoritmo de pagamento seguro (SPA); e uma camada de transporte de dados, em que a plataforma do emissor compreende um servidor de controle de acesso (ACS) que utiliza o SPA para processar a transação e as informações do proprietário do cartão para autenticação por meio de um método de autenticação e para gerar um valor de Autenticação do Titular da Conta (AAV) e transportar o AAV através da camada de transporte de dados até o MPI, em que o AAV é uma estrutura de dados formatada, compatível com os protocolos de mensagem Segura em 3-D, em que a estrutura de dados formatada possui um comprimento de no máximo 20-bytes, com a inclusão dos bytes que identificam uma verificação do nome do comerciante, bytes que identificara o ACS, bytes que identificam o método de autenticação, bytes que identificam as chaves criptográficas secretas e bytes que incluem o código de autenticação de um comerciante (MAC).
2. Sistema, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que o AAV é uma estrutura de dados formatada que é codificada em Base 64.
3. Sistema, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que o SPA compreende urr. algoritmo de criptografia para gerar o MAC, no qual o algoritmo de criptografia usa uma tecla secreta identificada no AAV para criptografar uma concatenação do número de conta do proprietário do cartão e uma pluralidade dos campos dos bytes do AAV, com exceção dos bytes que representam o MAC, e em que uma porção dc resultado da criptografia forma os bytes do MAC no AAV.
4. Sistema, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que o SPA compreende um algoritmo de criptografia que gera o MAC, em que o algoritmo de criptografia utiliza um parâmetros de qualidade-de-serviço de teclas secretas A e B que são identificadas no AAV para criptografar uma concatenação do número de conta do proprietário do cartão, o prazo de validade do cartão e o código de serviço para gerar um campo de três dígitos CVC2, e usa o resultado para povoar dois bytes do MAC.
5. Sistema, de acordo com a reivindicação 4, CARACTERIZADO pelo fato de que os parâmetros de qualidade-de-serviço de teclas secretas A e B são teclas de 64-bits Padrão de Criptografia de Dados (DES).
6. Sistema, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que o ACS é configurado para gerar um AAV em resposta a uma mensagem de solicitação de autenticação de pagamento proveniente do MPI para o ACS.
7. Sistema, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que é configurado para transportar o MV em uma mensagem de resposta de autenticação de pagamento proveniente do ACS.
8. Sistema, de acordo com a reivindicação 7, CARACTERIZADO pelo fato de que o ACS é configurado adicionalmente para lançar uma assinatura digital na mensagem de resposta à autenticação de pagamento.
9. Sistema, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que o MPI é configurado para verificar a assinatura digital sobre uma mensagem de resposta da autenticação do pagamento que foi recebido.
10. Sistema, de acordo com a reivindicação 1, CARACTERIZADO pelo fato de que o MPI é configurado para extrair os campos MAC inclusos em uma mensagem de resposta da autenticação do pagamento que foi recebido do ACS e para colocar o MAC extraído em uma mensagem de solicitação de autorização de pagamento efetuado a terceiros.
11. Estrutura de dados para transportar informações sobre a autenticação da transação comercial do proprietário de um cartão efetuada entre partes interessadas em um ambiente seguro com 3D, sendo que a estrutura de dados compreende 20 bytes de caracteres codificados em Base 64, CARACTERIZADA pele fato de que o primeiro byte é ura byte de controle, os bytes 2-9 representam uma verificação do nome de um comerciante, o byte 10 identifica um servidor de controle de Acesso (ACS) que autentica a transação do proprietário do cartão, por meio de um método de autenticação, o byte 11 identifica o método de autenticação e as teclas de criptografia secretas que são utilizadas pelo ACS para gerarem um Código de Autenticação de Comerciante (MAC), os bytes 12-15 representara um número de sequência de transação, o qual identifica o número de uma transação processada pelo ACS, e os bytes 16-20 representam o MAC.
12. Estrutura de dados, de acordo com a reivindicação 11, CARACTERIZADA pelo fatc de que o MAC compreende porções de uma criptografia de uma concatenação do número da conta do titular do cartão com uma pluralidade de campos de bytes 1-15 da estrutura de dados, e em que uma única tecla identificada no byte 11 é usada para criptografia.
13. Estrutura de dados, de acordo com a reivindicação 11, CARACTERIZADA pelo fato de que o MAC compreende porções de uma criptografia de uma concatenação do número da conta do titular do cartão, com o prazo de valicade do cartão, e o código do serviço, e em que os parâmetros de qualidade-de-serviço de teclas A e B que são identificadas no byte 11 é usada para criptografia.
14. Estrutura de dados, de acordo com a reivindicação 13, CARACTERIZADA pelo fato de que o resultado da criptografia em três dígitos é usado para povoar dois bytes dos bytes 16-20 do MAC.
15. Estrutura de dados, de acordo com a reivindicação 13, CARACTERIZADA pelo fato de que o par de teclas secretas A e B consistem em teclas de 64 bits do Padrão de Criptografia de Dados (DES).
16. Método para a autenticação da transação comercial do proprietário de um cartão cm um comerciante em uma rede eletrônica em um ambiente Seguro com 3D, sendo que o método é CARACTERIZADO pelo fato de que compreende: usar um servidor de controle de Acesso (AC) para processar informações do proprietário do cartão e da transação comercial, a fim de autenticar o proprietário do cartão por meio de um método de autenticação; distribuir ura algoritmo de pagamento seguro (SPA) para gerar um valor de Autenticação de Contato do Proprietário (AAV), a fim de representar os resultados de autenticação, e transportar o AAV nas mensagens Seguras em 3-D até o comerciante, em que o AAV consiste em uma estrutura de dados formatados que possui um comprimento de no máximo 20 bytes, incluindo bytes que identificam uma verificação do nome do comerciante, bytes que identificam o ACS, bytes que identificam o método de autenticação, bytes que incluem um código de autenticação do comerciante (MAC), e bytes que identificam as teclas criptográficas secretas que são usadas pelo SPA para gerarem o MAC.
17. Método, de acordo com a reivindicação 16, CARACTERIZADO pelo fato de que o AAV é uma estrutura de dados formatada codificada em Base 64.
18. Método, de acordo com a reivindicação 16, CARACTERIZADO pelo fato de que a distribuição de um SPA compreende: usar uma tecla secreta identificada no AAV para criptografar uma concatenação do número da conta do proprietário de um cartão e ao menos porções dos bytes do AAV, salvo os bytes que representarem o MAC; e transferir uma porção do resultado da criptografia para os bytes MAC no AAV.
19. Método, de acordo com a reivindicação 16, CARACTERIZADO pelo fato de que a distribuição de um SPA compreende: usar os parâmetros de qualidade-de-serviço de teclas secretas A e B que são identificadas no AAV para criptografar uma concatenação do número da conta do proprietário de um cartão, o prazo de validade do cartão e o códxgo de serviço para gerar o campo CVC2 de três dígitos; e transferir o resultado para povoar dois bytes do MAC.
20. Método, de acordo com a reivindicação 17, CARACTERIZADO pelo fato de que os parâmetros de qualidade-de-serviço de teclas secretas A e B consiste em teclas de 64 bits em Padrão de Criptografia de Dados (DES).
21. Método, de acordo com a reivindicação 16, CARACTERIZADO pelo fato de que o transporte do AAV em mensagens seguras em 3-D para o comerciante compreende transportar o AAV em uma mensagem de resposta de autenticação de pagamento que é assinada digitalmente pelo ACS.
22. Método, de acordo com a reivindicação 21, CARACTERIZADO pelo fato de que compreende adicionalmente: primeiramente, a verificação por parte do comerciante da assinatura digital em uma mensagem de resposta de autenticação de pagamento recebido; e depois, a extração dos campos MAC, por parte do comerciante, a partir da mensagem de resposta de autenticação de pagamento recebido.
BRPI0411286A 2003-06-10 2004-06-10 sistema para autenticar a transação comercial efetuada pelo proprietário de um cartão junto a um comerciante em uma rede eletrônica; estrutura de dados para transportar informações e método para a autenticação da transação comercial BRPI0411286B1 (pt)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US47718703P 2003-06-10 2003-06-10
PCT/US2004/017756 WO2005001618A2 (en) 2003-06-04 2004-06-04 Customer authentication in e-commerce transactions
PCT/US2004/018658 WO2005001635A2 (en) 2003-06-10 2004-06-10 Systems and methods for conducting secure payment transactions using a formatted data structure

Publications (2)

Publication Number Publication Date
BRPI0411286A BRPI0411286A (pt) 2006-08-01
BRPI0411286B1 true BRPI0411286B1 (pt) 2016-12-20

Family

ID=35985301

Family Applications (1)

Application Number Title Priority Date Filing Date
BRPI0411286A BRPI0411286B1 (pt) 2003-06-10 2004-06-10 sistema para autenticar a transação comercial efetuada pelo proprietário de um cartão junto a um comerciante em uma rede eletrônica; estrutura de dados para transportar informações e método para a autenticação da transação comercial

Country Status (19)

Country Link
US (1) US7801825B2 (pt)
EP (1) EP1636680B1 (pt)
JP (1) JP2007517272A (pt)
KR (1) KR20060070484A (pt)
CN (1) CN1926567A (pt)
AU (2) AU2004252882A1 (pt)
BR (1) BRPI0411286B1 (pt)
CA (1) CA2529011A1 (pt)
CY (1) CY1117808T1 (pt)
DK (1) DK1636680T3 (pt)
ES (1) ES2581236T3 (pt)
HK (1) HK1090143A1 (pt)
HU (1) HUE029807T2 (pt)
MX (1) MXPA05013422A (pt)
PL (1) PL1636680T3 (pt)
PT (1) PT1636680T (pt)
SI (1) SI1636680T1 (pt)
WO (1) WO2005001635A2 (pt)
ZA (1) ZA200600211B (pt)

Families Citing this family (72)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7239226B2 (en) 2001-07-10 2007-07-03 American Express Travel Related Services Company, Inc. System and method for payment using radio frequency identification in contact and contactless transactions
US7493288B2 (en) 2001-07-10 2009-02-17 Xatra Fund Mx, Llc RF payment via a mobile device
US7249112B2 (en) 2002-07-09 2007-07-24 American Express Travel Related Services Company, Inc. System and method for assigning a funding source for a radio frequency identification device
US7360694B2 (en) * 2003-01-23 2008-04-22 Mastercard International Incorporated System and method for secure telephone and computer transactions using voice authentication
US7740168B2 (en) 2003-08-18 2010-06-22 Visa U.S.A. Inc. Method and system for generating a dynamic verification value
US7761374B2 (en) 2003-08-18 2010-07-20 Visa International Service Association Method and system for generating a dynamic verification value
US20050279827A1 (en) * 2004-04-28 2005-12-22 First Data Corporation Methods and systems for providing guaranteed merchant transactions
JP4843208B2 (ja) * 2004-09-30 2011-12-21 株式会社東芝 デジタルコンテンツ編集装置、デジタルコンテンツ編集方法、デジタルコンテンツ編集プログラムおよびデジタルコンテンツ編集プログラムを記録した記録媒体
WO2007061946A2 (en) 2005-11-18 2007-05-31 Lu Larry L Promoting interoperability of presence-based systems through the use of ubiquitous online identities
JP4564464B2 (ja) * 2006-01-05 2010-10-20 株式会社東芝 デジタルコンテンツ再生装置、方法およびプログラム
US8453925B2 (en) * 2006-03-02 2013-06-04 Visa International Service Association Method and system for performing two factor authentication in mail order and telephone order transactions
US7818264B2 (en) 2006-06-19 2010-10-19 Visa U.S.A. Inc. Track data encryption
US9065643B2 (en) 2006-04-05 2015-06-23 Visa U.S.A. Inc. System and method for account identifier obfuscation
JP4913530B2 (ja) * 2006-10-16 2012-04-11 株式会社野村総合研究所 暗号処理装置、暗号処理方法および暗号処理プログラム
US7823774B2 (en) * 2007-03-26 2010-11-02 International Business Machines Corporation Method, apparatus, and article of manufacture for automatic verification of transactions made over an insecure network
US8423479B2 (en) * 2007-05-07 2013-04-16 Yahoo! Inc. Trusted third party clearing house for lead tracking
US8121942B2 (en) 2007-06-25 2012-02-21 Visa U.S.A. Inc. Systems and methods for secure and transparent cardless transactions
WO2009001317A1 (en) * 2007-06-27 2008-12-31 Koninklijke Philips Electronics N.V. Secure authentication of electronic prescriptions
US9589152B2 (en) * 2007-09-19 2017-03-07 Visa U.S.A. Inc. System and method for sensitive data field hashing
WO2009044226A1 (en) * 2007-10-03 2009-04-09 Gmx Sas System and method for secure management of transactions
US20100027786A1 (en) * 2008-02-14 2010-02-04 Patrick Faith Dynamic encryption authentication
US8935528B2 (en) * 2008-06-26 2015-01-13 Microsoft Corporation Techniques for ensuring authentication and integrity of communications
CA2742963A1 (en) 2008-11-06 2010-05-14 Visa International Service Association Online challenge-response
US8826397B2 (en) * 2009-01-15 2014-09-02 Visa International Service Association Secure remote authentication through an untrusted network
WO2010111661A1 (en) * 2009-03-27 2010-09-30 Mastercard International Incorporated Methods and systems for performing a financial transaction
US8261977B2 (en) * 2009-03-27 2012-09-11 Mastercard International Incorporated Methods and systems for using an interface and protocol extensions to perform a financial transaction
EP2430112B1 (en) 2009-04-23 2018-09-12 The University of Chicago Materials and methods for the preparation of nanocomposites
US9715681B2 (en) 2009-04-28 2017-07-25 Visa International Service Association Verification of portable consumer devices
US10846683B2 (en) 2009-05-15 2020-11-24 Visa International Service Association Integration of verification tokens with mobile communication devices
WO2011057007A2 (en) * 2009-11-04 2011-05-12 Visa International Service Association Verification of portable consumer devices for 3-d secure services
US9105027B2 (en) 2009-05-15 2015-08-11 Visa International Service Association Verification of portable consumer device for secure services
US8534564B2 (en) 2009-05-15 2013-09-17 Ayman Hammad Integration of verification tokens with mobile communication devices
US9038886B2 (en) 2009-05-15 2015-05-26 Visa International Service Association Verification of portable consumer devices
US8893967B2 (en) 2009-05-15 2014-11-25 Visa International Service Association Secure Communication of payment information to merchants using a verification token
US8706556B2 (en) * 2009-11-06 2014-04-22 Mastercard International Incorporated Methods for risk management in payment-enabled mobile device
WO2011136730A1 (en) * 2010-04-28 2011-11-03 Show & Pay Ab A method and an apparatus for improved electronic transaction security
SG187832A1 (en) 2010-08-12 2013-03-28 Mastercard International Inc Multi-commerce channel wallet for authenticated transactions
US20120072346A1 (en) * 2010-09-16 2012-03-22 Yomir Sp System and method for securing and authenticating purchase transactions
EP2681701A4 (en) 2011-03-04 2014-08-20 Visa Int Service Ass INTEGRATION OF PAYMENT OPTIONS IN SAFE ITEMS OF COMPUTERS
WO2012142045A2 (en) * 2011-04-11 2012-10-18 Visa International Service Association Multiple tokenization for authentication
US10282724B2 (en) 2012-03-06 2019-05-07 Visa International Service Association Security system incorporating mobile device
US9576279B2 (en) * 2012-06-05 2017-02-21 Autoscribe Corporation System and method for registering financial accounts
US10304047B2 (en) * 2012-12-07 2019-05-28 Visa International Service Association Token generating component
US20150039506A1 (en) * 2013-08-05 2015-02-05 Mastercard International Incorporated Methods and systems for providing 3-d secure service on-behalf-of merchants
GB2517723A (en) * 2013-08-29 2015-03-04 Belegin Ltd Token verification
US9471913B1 (en) * 2013-10-23 2016-10-18 Compass Plus US, Corp. Method and system for cardless processing of E-invoicing
CN103561115B (zh) * 2013-11-19 2016-09-28 北京奇虎科技有限公司 实时获取电子码的方法、开放平台及系统
WO2015084797A1 (en) * 2013-12-02 2015-06-11 Mastercard International Incorporated Method and system for secure tranmission of remote notification service messages to mobile devices without secure elements
FR3018378A1 (fr) * 2014-03-12 2015-09-11 Enrico Maim Systeme et procede transactionnels a architecture repartie fondees sur des transactions de transferts d'unites de compte entre adresses
US20150317630A1 (en) * 2014-04-30 2015-11-05 MasterCard Incorporated International Method and system for authentication token generation
WO2016019163A1 (en) * 2014-07-30 2016-02-04 Visa International Service Association Authentication system with message conversion
US9906367B2 (en) * 2014-08-05 2018-02-27 Sap Se End-to-end tamper protection in presence of cloud integration
US9999924B2 (en) 2014-08-22 2018-06-19 Sigma Labs, Inc. Method and system for monitoring additive manufacturing processes
SG10201406521TA (en) * 2014-10-10 2016-05-30 Mastercard Asia Pacific Pte Ltd Methods and systems for secure online payment
US10891622B2 (en) * 2014-11-13 2021-01-12 Mastercard International Incorporated Providing online cardholder authentication services on-behalf-of issuers
US10786948B2 (en) 2014-11-18 2020-09-29 Sigma Labs, Inc. Multi-sensor quality inference and control for additive manufacturing processes
CN105825371A (zh) * 2015-01-07 2016-08-03 阿里巴巴集团控股有限公司 业务处理方法和装置
CN107428081B (zh) 2015-01-13 2020-07-07 西格马实验室公司 材料鉴定系统和方法
BR112017017425B1 (pt) * 2015-02-14 2024-04-30 Valimail Inc Meio de armazenamento legível por computador não transitório configurado para armazenar instruções de método e processo implementado por computador
US9825946B2 (en) * 2015-08-27 2017-11-21 Mastercard International Incorporated Method and system for enhanced validation of cryptograms in cloud-based systems
GB201516617D0 (en) * 2015-09-18 2015-11-04 Mastercard International Inc Verification for payment transations
US10207489B2 (en) 2015-09-30 2019-02-19 Sigma Labs, Inc. Systems and methods for additive manufacturing operations
US20170109752A1 (en) * 2015-10-15 2017-04-20 Mastercard International Incorporated Utilizing enhanced cardholder authentication token
GB201601796D0 (en) * 2016-02-01 2016-03-16 Comcarde Ltd Payment handling apparatus and method
CA3018326A1 (en) * 2016-03-21 2017-09-28 Mastercard International Incorporated Method and system for recording point to point transaction processing
PT3440823T (pt) * 2016-04-05 2020-12-04 Zamna Tech Limited Método e sistema para gestão de informações pessoais dentro de sistemas informáticos independentes e redes digitais
CN109644131B (zh) * 2016-07-15 2022-04-26 卡迪纳尔贸易公司 使用富化消息对授权桥接进行认证
US11080697B2 (en) 2017-10-05 2021-08-03 Mastercard International Incorporated Systems and methods for use in authenticating users in connection with network transactions
RU2755196C1 (ru) 2018-04-05 2021-09-14 Нокиа Текнолоджиз Ой Управление унифицированными идентификаторами подписки в системах связи
EP3857485A4 (en) * 2018-09-28 2022-06-22 JPMorgan Chase Bank, N.A. PROCEDURES FOR ENHANCED SECURITY FOR PERSONAL IDENTIFICATION NUMBER (PIN) TRANSACTIONS AND DEVICES THEREFOR
US11283621B1 (en) * 2019-11-13 2022-03-22 Worldpay, Llc Methods and systems for enhanced endpoint identity validation in electronic transactions
US11722500B2 (en) * 2020-04-01 2023-08-08 Paypal, Inc. Secure identity verification marketplace using hashed data and forward hashing search functions

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6044205A (en) * 1996-02-29 2000-03-28 Intermind Corporation Communications system for transferring information between memories according to processes transferred with the information
US7133845B1 (en) * 1995-02-13 2006-11-07 Intertrust Technologies Corp. System and methods for secure transaction management and electronic rights protection
US6157721A (en) * 1996-08-12 2000-12-05 Intertrust Technologies Corp. Systems and methods using cryptography to protect secure computing environments
US5809144A (en) * 1995-08-24 1998-09-15 Carnegie Mellon University Method and apparatus for purchasing and delivering digital goods over a network
US5748740A (en) * 1995-09-29 1998-05-05 Dallas Semiconductor Corporation Method, apparatus, system and firmware for secure transactions
US6138107A (en) * 1996-01-04 2000-10-24 Netscape Communications Corporation Method and apparatus for providing electronic accounts over a public network
US6038551A (en) * 1996-03-11 2000-03-14 Microsoft Corporation System and method for configuring and managing resources on a multi-purpose integrated circuit card using a personal computer
US6029150A (en) * 1996-10-04 2000-02-22 Certco, Llc Payment and transactions in electronic commerce system
US6590588B2 (en) * 1998-05-29 2003-07-08 Palm, Inc. Wireless, radio-frequency communications using a handheld computer
US7047416B2 (en) * 1998-11-09 2006-05-16 First Data Corporation Account-based digital signature (ABDS) system
FR2787273B1 (fr) 1998-12-14 2001-02-16 Sagem Procede de paiement securise
US6529885B1 (en) * 1999-03-18 2003-03-04 Oracle Corporation Methods and systems for carrying out directory-authenticated electronic transactions including contingency-dependent payments via secure electronic bank drafts
US7249097B2 (en) * 1999-06-18 2007-07-24 Echarge Corporation Method for ordering goods, services, and content over an internetwork using a virtual payment account
US20010032154A1 (en) * 1999-12-17 2001-10-18 Eric Schummer Internet communications and e-commerce platform
WO2001082246A2 (en) * 2000-04-24 2001-11-01 Visa International Service Association Online payer authentication service
EP1316171A4 (en) * 2000-08-04 2006-05-03 First Data Corp PERSONNEL AND CONTOUR DIGITAL SIGNATURE SYSTEM
US6915279B2 (en) * 2001-03-09 2005-07-05 Mastercard International Incorporated System and method for conducting secure payment transactions
JP2004535619A (ja) 2001-04-02 2004-11-25 マスターカード インターナシヨナル インコーポレーテツド 安全な決済取引を行うシステムと方法
US7707120B2 (en) * 2002-04-17 2010-04-27 Visa International Service Association Mobile account authentication service
US7349871B2 (en) * 2002-08-08 2008-03-25 Fujitsu Limited Methods for purchasing of goods and services

Also Published As

Publication number Publication date
DK1636680T3 (en) 2016-07-18
SI1636680T1 (sl) 2016-08-31
AU2011201884A1 (en) 2011-05-19
WO2005001635A2 (en) 2005-01-06
ZA200600211B (en) 2007-04-25
HK1090143A1 (zh) 2006-12-15
ES2581236T3 (es) 2016-09-02
EP1636680A4 (en) 2013-03-13
EP1636680B1 (en) 2016-04-13
PT1636680T (pt) 2016-07-15
JP2007517272A (ja) 2007-06-28
AU2004252882A1 (en) 2005-01-06
EP1636680A2 (en) 2006-03-22
CA2529011A1 (en) 2005-01-06
AU2011201884B2 (en) 2011-09-08
BRPI0411286A (pt) 2006-08-01
US20070143227A1 (en) 2007-06-21
KR20060070484A (ko) 2006-06-23
PL1636680T3 (pl) 2016-10-31
US7801825B2 (en) 2010-09-21
CY1117808T1 (el) 2017-05-17
HUE029807T2 (en) 2017-03-28
CN1926567A (zh) 2007-03-07
MXPA05013422A (es) 2006-03-17
WO2005001635A3 (en) 2006-10-12

Similar Documents

Publication Publication Date Title
BRPI0411286B1 (pt) sistema para autenticar a transação comercial efetuada pelo proprietário de um cartão junto a um comerciante em uma rede eletrônica; estrutura de dados para transportar informações e método para a autenticação da transação comercial
US7983987B2 (en) System and method for conducting secure payment transaction
US20170366530A1 (en) Mobile Account Authentication Service
US6915279B2 (en) System and method for conducting secure payment transactions
US20020152180A1 (en) System and method for performing secure remote real-time financial transactions over a public communications infrastructure with strong authentication
BRPI0808185A2 (pt) Métodos e um sistema para prover informações relativas a transações
JP2006527430A (ja) 商業取引における顧客認証システム及び方法
AU781671B2 (en) An improved method and system for conducting secure payments over a computer network
AU2011239307B2 (en) Systems and methods for conducting secure payment transactions using a formatted data structure
AU2002254513B8 (en) System and method for conducting secure payment transactions
WO2020099690A1 (es) Método y sistema para financiar compras con autenticación reforzada de cliente
AU2002254513A1 (en) System and method for conducting secure payment transactions
ZA200307558B (en) System and method for conducting secure payment transactions.

Legal Events

Date Code Title Description
B08F Application dismissed because of non-payment of annual fees [chapter 8.6 patent gazette]

Free format text: REFERENTE A 9A ANUIDADE.

B08G Application fees: restoration [chapter 8.7 patent gazette]
B08F Application dismissed because of non-payment of annual fees [chapter 8.6 patent gazette]

Free format text: REFERENTE AO NAO RECOLHIMENTO DA 11A ANUIDADE.

B08K Patent lapsed as no evidence of payment of the annual fee has been furnished to inpi [chapter 8.11 patent gazette]

Free format text: EM VIRTUDE DO ARQUIVAMENTO PUBLICADO NA RPI 2326 DE 04-08-2015 E CONSIDERANDO AUSENCIA DE MANIFESTACAO DENTRO DOS PRAZOS LEGAIS, INFORMO QUE CABE SER MANTIDO O ARQUIVAMENTO DO PEDIDO DE PATENTE, CONFORME O DISPOSTO NO ARTIGO 12, DA RESOLUCAO 113/2013.

B08H Application fees: decision cancelled [chapter 8.8 patent gazette]

Free format text: REFRENTE AO DESPACHO 8.11 NA RPI 2342 DE 24/11/2015

B08G Application fees: restoration [chapter 8.7 patent gazette]
B09A Decision: intention to grant [chapter 9.1 patent gazette]
B15K Others concerning applications: alteration of classification

Free format text: A CLASSIFICACAO ANTERIOR ERA: G06F 1/00

Ipc: G06Q 20/02 (2012.01)

B08F Application dismissed because of non-payment of annual fees [chapter 8.6 patent gazette]

Free format text: REFERENTE A TAXA DE RESTAURACAO DA 12A ANUIDADE.

B08G Application fees: restoration [chapter 8.7 patent gazette]
B16A Patent or certificate of addition of invention granted [chapter 16.1 patent gazette]

Free format text: PRAZO DE VALIDADE: 10 (DEZ) ANOS CONTADOS A PARTIR DE 20/12/2016, OBSERVADAS AS CONDICOES LEGAIS.