BRPI0721200A2 - Método, e, meio legível por computador - Google Patents

Método, e, meio legível por computador Download PDF

Info

Publication number
BRPI0721200A2
BRPI0721200A2 BRPI0721200-3A2A BRPI0721200A BRPI0721200A2 BR PI0721200 A2 BRPI0721200 A2 BR PI0721200A2 BR PI0721200 A BRPI0721200 A BR PI0721200A BR PI0721200 A2 BRPI0721200 A2 BR PI0721200A2
Authority
BR
Brazil
Prior art keywords
payment device
data
transit
payment
transaction
Prior art date
Application number
BRPI0721200-3A2A
Other languages
English (en)
Inventor
Phil Dixon
Ayman A Hammad
William Alexander Thaw
Christian Aabye
Original Assignee
Visa Usa 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
Application filed by Visa Usa Inc filed Critical Visa Usa Inc
Publication of BRPI0721200A2 publication Critical patent/BRPI0721200A2/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/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/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
    • 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/4016—Transaction verification involving fraud or risk level assessment in transaction processing
    • 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/08—Payment architectures
    • G06Q20/085—Payment architectures involving remote charge determination or related payment 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/085—Payment architectures involving remote charge determination or related payment systems
    • G06Q20/0855—Payment architectures involving remote charge determination or related payment systems involving a third party
    • 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/20—Point-of-sale [POS] network 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/20—Point-of-sale [POS] network systems
    • G06Q20/204—Point-of-sale [POS] network systems comprising interface for record bearing medium or carrier for electronic funds transfer or payment credit
    • 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/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • 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/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • 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/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • 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
    • 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/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/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
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B15/00—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points

Description

“MÉTODO, E, MEIO LEGÍVEL POR COMPUTADOR” REFERÊNCIA CRUZADA A PEDIDOS RELACIONADOS
Este pedido reivindica prioridade e o benefício de Pedido US Serial No. 60/887.307, depositado em 30 de janeiro de 2007, intitulado "Contactless Bank Card Transit Payment", e Pedido US Serial No. 11/713.307, depositado em 1 de março de 2007, intitulado "Signature Based Negative List For Off-Line Payment Device Validation", os conteúdos inteiros de cada um de quais estão por este meio incorporados por referência.
FUNDAMENTOS A presente invenção relaciona-se geralmente a transações financeiras, particularmente a clientes pedindo transações financeiras com estabelecimentos comerciais, e mais particularmente a transações financeiras conduzidas com um dispositivo de pagamento portátil de instituição financeira emitido por uma instituição financeira, tal como um cartão de crédito, que pode ser usado ambos em uma transação de varejo e em uma transação de tarifa de trânsito.
Dispositivos de pagamento portáteis podem levar muitas formas e são usados em uma grande variedade de transações financeiras. Os dispositivos de pagamento portáteis podem incluir, por exemplo, cartões inteligentes, símbolos de pagamento, cartões de crédito, cartões de débito, cartões de valor armazenado, cartões pré-pagos, cartões sem contato, telefones celulares, dispositivos de Assistente Digital Pessoal (PDA), chaveiro, ou cartões inteligentes. As transações financeiras podem envolver, por exemplo, compras de varejo, tarifas de trânsito, acesso a tarifas de jurisdição, etc. Em todas as tais transações, os usuários de dispositivo de pagamento portátil (consumidores) estão preocupados com conveniência e os estabelecimentos comerciais com os quais eles negociam estão preocupados com facilidade de negociar com seus clientes-consumidores.
Preferivelmente, os dispositivos de pagamento portáteis de instituição financeira emitidos por uma instituição financeira (FIPPD) são usados de um modo on-line (por exemplo, um ponto de serviço que está conectado a um sistema de processamento de pagamento durante uma transação). A informação do FIPPD pode ser transmitida on-line para um emissor durante uma transação de pagamento de varejo para propósitos de autorizar o uso do FIPPD para essa transação. O emissor pode revisar parâmetros da transação tal como quantia de transação, história de crédito, autenticidade de cartão, e outros fatores ao determinar se ou não autorizar ou recusar a transação.
Porém, algumas transações mercantis não são on-line tal que esquemas de autenticação e verificação de FIPPD não são acomodados prontamente. Por exemplo, a habilidade para entrar on-line em um ambiente de trânsito tal como um sistema de metrô ou ônibus, ou um ambiente de acesso de jurisdição tal como um estádio ou sala de concertos, pode ser problemático por causa da falta de comunicação em tempo real e falta de sistemas de rede para tais ambientes. Isto é devido em parte à necessidade em tais ambientes para processar uma transação dentro de cerca de 300 ms, um padrão de indústria de sistema de trânsito, e por esse meio permitem 30 a 45 fregueses por minuto acessarem em uma instalação do sistema de trânsito tal como um metrô ou um ônibus. Além disso, um ônibus em uma rota de ônibus através da estrada pode não ter sistemas de comunicação sem fio ou outros para permitir qualquer diálogo em tempo real com qualquer outro sistema fora do ônibus, tal como para taxação de tarifa on-line ou autorização de tíquete/vale/cartão de admissão on-line. Portanto, esta ausência de conectividade de rede em um ambiente de trânsito apresenta uma dificuldade sempre que uma autenticação on-line do meio de acesso do consumidor, tal como um tíquete de admissão, vale ou cartão de acesso, é necessário a fim de determinar se, por exemplo, o consumidor está intitulado para acessar e tem fundos suficientes para cobrir o custo da transação desejada (tarifa para viajar no sistema de trânsito). Além disso, em um ambiente de trânsito, o valor da tarifa de trânsito pode não ser conhecido na hora de acesso pedido. Um cálculo de tarifa pode depender da distância de viagem atual, direção de viagem, locais de entrada e saída de estação, modo de viagem (metrô, ônibus, táxi), categoria de consumidor (estudante, sênior), e/ou tempos de uso (pico, fora de pico). Tais parâmetros podem ser desconhecidos antes de efetuar o serviço. Como tal, o processo de pagamento e coleta de tarifa de trânsito não pode ser executado efetivamente usando um processo de autenticação e aprovação on- line convencional.
Tradicionalmente, cálculo e coleta de tarifa de trânsito ocorreram em um sistema fechado. Em um sistema fechado, a companhia de trânsito pode emitir seu próprio dispositivo de pagamento portátil de trânsito, tal como um cartão inteligente de leitura/escrita, em que o dispositivo de pagamento portátil de trânsito leva as credenciais e dados necessários para permitir a conclusão de uma transação no próprio dispositivo de tarifa (torniquete, caixa de tarifa, ou outro Ponto de Serviço). Neste caso, não há nenhum processamento adicional requerido para determinação de tarifa na hora da transação fora da interação entre o cartão e o dispositivo de tarifa. Em lugar disso, o cartão é autenticado e lido pelo dispositivo de tarifa, lógica é executada pelo dispositivo de tarifa para aplicar política de tarifa de sistema de trânsito, e o cartão é atualizado (reescrito) para finalizar os detalhes de transação incluindo uma dedução de qualquer valor armazenado para o custo de tarifa. O dispositivo de tarifa pode adicionalmente examinar uma lista branca, uma lista positiva, uma lista quente, uma lista negativa e/ou uma lista negra utilizando o número de cartão, por exemplo, para determinar se a transação será completada e o titular de cartão será permitido acesso em uma instalação do sistema de trânsito tal como um terminal de metrô ou compartimento de passageiro de ônibus. O sistema de trânsito fechado, porém, tem suas desvantagens. Em um sistema de trânsito fechado, o dispositivo de pagamento portátil de trânsito e leitores de trânsito em cada estação ou rota devem ser capazes de executar computações de tarifa baseado em dados armazenados e recobrados do cartão de acesso de um passageiro, e terminais/leitores de cartão subseqüentes devem ser capazes de acessar dados escritos ao cartão de acesso do passageiro em estações prévias. Esta exigência coloca uma carga de processamento significante nos terminais de sistema de trânsito e/ou sistemas de processamento de tarifa e aumenta o custo de implementar a infra-estrutura para tais sistemas. Como taxas de tarifa e outra informação pertinente mudam geralmente com o tempo, isto também aumenta as demandas colocadas em tais sistemas para manutenção de precisão.
Além disso, um dispositivo de pagamento portátil de trânsito pode não ser compatível com todos os dispositivos de tarifa dentro do plano de viagem de um passageiro. Isto pode se tomar um problema significante se um consumidor desejar utilizar mais de um sistema de trânsito durante a baldeação do dia, tal como usando múltiplas agências de trânsito ou jurisdições dentro de uma única área geográfica que provê acesso de passageiro ambos na e entre jurisdições, cidades ou locais diferentes.
O presente ambiente de trânsito apresenta vários desafios,
incluindo:
• Uma necessidade comum que pode haver só um dispositivo de pagamento portátil de trânsito para cada agência ou grupo de trânsito de agências cooperativas que não pode ser usado para outras tais agências ou grupos;
• O desejo para acomodar expectativas de velocidade de transação do usuário de sistema de trânsito enquanto minimizando risco à agência de trânsito para coletar pagamento por serviços efetuados; e
• Quando um dispositivo de pagamento portátil é "somente de leitura", não tendo capacidades de escrita no Ponto de Serviço, os dispositivos de Pagamento Portáteis não podem armazenar os dados de cronologia de trânsito do passageiro - assim fazendo os cálculos de tarifa do passageiro um pouco difícil com tais dispositivos. Com tais transações off- 5 line, uma lista (isto é, uma lista branca de cartões elegíveis ou uma lista negativa de cartões rejeitados baseado no número de cartão único) armazenada a cada dispositivo de tarifa de trânsito é o mecanismo primário para impedir fraude. Isto é sub-ótimo desde que a lista negativa cresceria presumivelmente ilimitada quando mais FIPPD são emitidos.
Além do desejo do passageiro de sistema de trânsito por uma
velocidade de transação rápida ao acessar uma instalação de sistema de trânsito, há riscos de segurança e outros associados com o uso de um FIPPD que é projetado para autorização on-line quando é usado caso contrário em uma transação off-line. Estes riscos incluem, mas não estão limitados a:
· Autenticação/Fraude: a falta de autenticação de FIPPD em
tempo real cria um alto potencial para fraude por técnicas de falsificação;
• Cálculo de Custo de Tarifa: onde o custo de uma transação de trânsito é dependente da história de passageiro imediata para o cartão (entrada/saída/duração de viagem, transferências, etc.), a tarifa de trânsito do
passageiro não pode ser calculada em cada portão ou caixa de tarifa porque a história de viagem imediata do passageiro não pode ser armazenada, escrita ou residente em FIPPDs convencionais;
• Segurança/Armazenamento de Dados: proteção de dados de consumidor em um sistema de tarifa de trânsito pode se provar difícil.
Rastrear dados na forma de um número de conta primário (PAN) para um FIPPD requereria o sistema de trânsito coletar e armazenar estes dados seguramente, que não é algo que sistemas de tarifa de trânsito comumente fazem presentemente. Se implementado, este requisito apresenta assuntos de custo e segurança adicionados a ambos o sistema de trânsito e seus passageiros.
Cartões de pagamento são requeridos geralmente para entra on-line ao emissor durante a transação por propósitos de autorizar o uso do cartão para essa transação. O emissor pode revisar tais parâmetros como quantia de transação, história de crédito, autenticidade de cartão, e outros fatores ao determinar se ou não autorizar a transação.
Em alguns aplicativos de pagamento, a oportunidade para entra on-line ao emissor para autorização pode não ser possível na hora da transação. Isto pode ser devido a exigências de velocidade de transação, e/ou 10 exigências de conectividade no dispositivo de pagamento. Por exemplo, um dispositivo de tarifa de trânsito tal como um torniquete de metrô ou caixa de tarifa de ônibus deve completar uma transação dentro de menos de 300 milissegundos para permitir tempo para processar 30 a 45 passageiros por minuto como exigido nessa aplicação. Em outro exemplo, um ônibus de 15 trânsito ou um táxi pode estar na estrada sem comunicações em tempo real com o emissor para autorização. Nestes casos, o estabelecimento comercial (agência de trânsito, motorista de táxi, etc.) deve permitir a transação acontecer sem autorização e então processar a transação mais tarde depois que o titular de cartão é permitido proceder.
Porque o titular de cartão é permitido proceder previamente de
receber autorização do emissor, há oportunidade para fraude. Ao emissor não é permitida a oportunidade para autenticar o cartão ou autorizar baseado em outros parâmetros da transação, um fraudador com um cartão falso seria permitido proceder com a transação sem qualquer verificação e saldo.
Um mecanismo extensamente usado para restringir fraude em
aplicativos off-line é pela implementação de uma lista negativa (às vezes chamada lista negra ou lista quente). Cada dispositivo de processamento de pagamento off-line (como uma caixa de tarifa de ônibus) é provido, em uma base regular, com uma lista de números de cartão pensados serem falsos (ou fraudulento por outras razões). Durante o processamento da transação, o dispositivo de pagamento pode verificar o número de cartão contra a lista negativa e permitir ou negar a transação baseado nesta verificação e saldo.
Embora verificações de lista negativa provejam um mecanismo para restringir fraude em aplicações off-line, a própria lista negativa abre a porta para outros tipos de oportunidade de fraude baseado na exposição potencial dos números de cartão na lista negativa. No caso de um cartão de pagamento sendo usado para pagar por tarifas de trânsito, tarifas de táxi, ou bens de distribuidor automático, uma lista negativa seria feita necessariamente de números de conta de cartão de pagamento (isto é, Números de Conta Primários, ou PANs). O PAN é o número único provido pelo cartão durante a transação de pagamento e portanto seria o número colocado na lista negativa para negar seu uso. Se as listas negativas foram expostas ou comprometidas, a oportunidade para listas grandes de números de conta de cartão de pagamento seria possível.
Processadores de pagamento diferentes podem manter programas de segurança e proteção de informação de titular de cartão diferentes como também requer sistemas mercantis que processam informação de titular de cartão, tais como números de cartão de pagamento 20 (PANs), ser complacente com estes programas. Estes programas de segurança e proteção podem prover proteção requerendo que informação de titular de cartão que deve ser armazenada, seja feita dentro de um ou mais formatos codificados diferentes. Isto inclui dispositivos de tarifa de trânsito off-line, táxis, ou distribuidores automáticos que teriam que armazenar números de 25 PAN na forma de listas negativas. Porém, nem todos os estabelecimentos comerciais têm sistemas ou processos de criptografia impostos rigorosamente para proteger dados de titular de cartão como exigido. Além disso, técnicas de criptografia podem não ser seguras bastante para dispositivos desacompanhados achados em locais remotos que podem ser vulneráveis a ataque físico, invasão, e exposição de informação de conta de pagamento.
Dado o antecedente, seria um avanço na técnica proteger informação de titular de cartão, armazenada em listas negativas em aplicações off-line. Seria adicionalmente um avanço na técnica prover tal proteção em 5 qualquer ambiente off-line tais como coleta de tarifa de trânsito, pagamento de tarifa de táxis, pagamentos de distribuidores automáticos, acesso de jurisdição, medidores ou máquinas de estacionamento, ou outras aplicações que podem não ter conectividade ou tempo permitido para entrar on-line ao emissor por autorização de pagamento - incluindo onde o ambiente permite 10 cartões inteligentes ou de 'chip', se o cartão ou outro dispositivo de pagamento for um cartão por contato ou sem contato sem fio (por exemplo, Radiofreqüência) como são achados tipicamente no ambiente de trânsito.
O que é ainda precisado adicionalmente na técnica é o pagamento e coleta de transações utilizando um dispositivo de FIDDP dentro dos ambientes anteriores, incluindo tarifas de acesso para sistemas de trânsito e jurisdições, que superam os desafios e desvantagens da técnica anterior como publicado acima.
SUMÁRIO
Uma transação de pagamento pode ser conduzida em um esquema combinado utilizando uma dispositivo de pagamento portátil de instituição financeira (FIPPD). Durante a transação de um consumidor com um estabelecimento comercial para um bem ou serviço, informação do FIPPD pode ser lida a um terminal de ponto de serviço (POS).
Em uma implementação, leitura é feita no terminal de POS a 25 um estabelecimento comercial ao qual um dispositivo de pagamento é apresentado ao terminal de POS por um consumidor buscando conduzir uma transação para um bem ou serviço do estabelecimento comercial. O dispositivo de pagamento inclui um Número de Conta Primário (PAN) emitido por um emissor em um sistema de processamento de pagamento. Os dados lidos do dispositivo de pagamento incluem uma assinatura de não PAN correspondendo ao PAN. Uma verificação é feita de uma lista de assinaturas de não PAN mantidas pelo terminal de POS para determinar se a assinatura de não PAN lida dos dados no dispositivo de pagamento está na lista. Na base de 5 se a assinatura de não PAN está na lista, o consumidor é permitido completar a transação com o estabelecimento comercial.
Em outra implementação, um consumidor (passageiro) pode buscar acesso em uma instalação de trânsito a um terminal de POS de trânsito usando um FIPPD associado com uma conta dentro de um sistema de IO processamento de pagamento. O POS de trânsito pode ter um leitor, tal como um leitor de cartão sem contato que coleta dados de uma região de armazenamento de dados do FIPPD, incluindo a informação de conta do FIPPD. Os dados na região de armazenamento do FIPPD, junto com outra informação de transação tal como a hora e local de POS de trânsito, depois de 15 recobrar o mesmo, podem ser armazenados então em um local diferente do POS de trânsito.
Os dados na região de armazenamento do FIPPD que são lidos pelo leitor ocorrem quando um dispositivo de pagamento é apresentado ao leitor de sistema de trânsito por um passageiro buscando conduzir uma 20 transação de acesso para acesso a uma instalação do sistema de trânsito. O dispositivo de pagamento inclui um Número de Conta Primário (PAN) emitido por um emissor em um sistema de processamento de pagamento. Os dados lidos do dispositivo de pagamento incluem código de criptografia correspondendo exclusivamente ao dispositivo de pagamento. Sem 25 descriptografar o código de criptografia, uma verificação é feita off-line no leitor de sistema de trânsito de uma lista de outros códigos de criptografia para determinar se o código de criptografia para validação pode ser baseado na lista, e na base de se o código de criptografia está na lista, o passageiro é permitido acesso à instalação do sistema de trânsito. Em ainda outra implementação, dados são lidos a um leitor de trânsito em um sistema de trânsito ao qual um dispositivo de pagamento é apresentado ao leitor de sistema de trânsito por um passageiro buscando conduzir uma transação de acesso para acesso a uma instalação do sistema de 5 trânsito. Os dados estão nos campos de dados de Trilha 1 e/ou Trilha 2 de acordo com uma configuração de MSD, e o dispositivo de pagamento inclui um Número de Conta Primário (PAN) emitido por um emissor em um sistema de processamento de pagamento. Os dados lidos do dispositivo de pagamento incluem código de criptografia que corresponde exclusivamente ao 10 dispositivo de pagamento, onde o código de criptografia foi armazenado no dispositivo de pagamento pelo emissor, e criado usando uma ou mais chaves de criptografia e um algoritmo predeterminado. Um verificação do código de criptografia é feita no leitor de sistema de trânsito contra uma lista de outros tais códigos de criptografia para determinar se o código de criptografia está na 15 lista. Sem descriptografar o código de criptografia, o passageiro é permitido acesso à instalação do sistema de trânsito na base de se o código de criptografia está na lista.
Em cada uma da implementação precedente, a lista que é verificada pode ser uma lista branca, uma lista negra, ou uma combinação disso, que é atualizada baseado em políticas do sistema de estabelecimento comercial ou de trânsito.
BREVE DESCRIÇÃO DOS DESENHOS A presente invenção será descrita no contexto das figuras de desenho anexas, onde os mesmos números são usados ao longo da exposição e figuras para referenciar mesmos componentes e características:
Figura 1 é um diagrama de nível de bloco ilustrando um sistema de processamento de pagamento exemplar;
Figura 2 é um diagrama de nível de bloco ilustrando um sistema de processamento de pagamento trânsito fechado exemplar; Figura 3 é um diagrama de nível de bloco ilustrando um sistema de processamento de pagamento de trânsito aberto exemplar que é compatível com o sistema de processamento de pagamento visto na Figura 1;
Figura 4 é um fluxograma ilustrando um processo exemplar por qual um dispositivo de pagamento portátil de instituição financeira pode ser usado no ambiente do sistema de processamento de pagamento de trânsito aberto ilustrado na Figura 3;
Figura 5 é um fluxograma ilustrando um processo exemplar pelo qual um passageiro pode ganhar acesso a uma instalação de acesso usando o FIPPD 130;
Figura 6 é um fluxograma ilustrando um processo exemplar para validar o uso de um passageiro de um dispositivo de pagamento portátil de instituição financeira a um sistema de trânsito para acesso a uma instalação de trânsito; e
Figura 7 é um fluxograma ilustrando um processo exemplar de
criar uma procuração única para uma conta emitida por uma instituição financeira, onde a procuração está em um dispositivo de pagamento portátil emitido pela instituição financeira, onde o dispositivo de pagamento portátil pode ser usado por um consumidor em uma transação com um 20 estabelecimento comercial, e onde o estabelecimento comercial pode verificar a procuração única contra uma lista de outras tais procurações para determinar se completar a transação com o consumidor.
DESCRIÇÃO DETALHADA Implementações facilitam a proteção de informação de titular 25 de cartão usada para validar uma transação entre um estabelecimento comercial e consumidor. A informação de titular de cartão é transformada pelo estabelecimento comercial pelo uso de uma assinatura de cartão. A informação de titular de cartão transformada pode ser verificada contra uma ou mais listas mantidas remotas de ambos o emissor da informação de titular de cartão e remotas de um terminal de ponto de serviço ao qual o consumidor negocia com o estabelecimento comercial. A informação de titular de cartão armazenada em um dispositivo de pagamento e usada pelo consumidor não precisa ser alterada durante a transação.
5 A assinatura de cartão pode ser um valor criptográfico, tal
como um que está baseado em chaves de criptografia e um algoritmo que é personalizado (armazenado) em um cartão sem contato pelo emissor do cartão de pagamento, dispositivo de pagamento, etc. A assinatura de cartão, por exemplo, pode ser calculada e validada no dispositivo de pagamento (tal 10 como um terminal de Ponto de venda (POS), uma caixa de tarifa de agência de trânsito, um distribuidor automático, etc.), assim provendo um mecanismo para detectar e prevenir o uso de cartões falsos que não conterão o valor criptográfico correto. Aqui, este mecanismo previne o uso de cartões falsos porque o cartão não foi criado com o próprio algoritmo ou chaves. Em lugar 15 disso, o valor de assinatura de cartão será baseado em algum conjunto de dados, tal como um valor que é único para cada cartão e pode ser calculado baseado em técnicas de criptografia. O número de assinatura de cartão pode ser um tipo de criptograma baseado em dados de cartão específicos, algoritmo e chaves. O número (isto é, a assinatura) que é usado no processo de listagem 20 negativa pode ser projetado tal que se assemelharia a um número de conta de pagamento e não seria aceito em qualquer ambiente de pagamento.
Ambientes off-line de exemplo incluem coleta de tarifa de trânsito, pagamento de tarifa de táxis, pagamentos de distribuidores automáticos, acesso de jurisdição, medidores ou máquinas de estacionamento, 25 e outras aplicações que podem não ter conectividade ou o tempo necessário requerido a fim de entrar on-line ao emissor do dispositivo de pagamento oferecido pelo consumidor (por exemplo; o titular de cartão) para pagamento.
Implementações facilitam o pagamento e coleta de transações. O valor de transação de cada transação pode não ser conhecido na hora que um consumidor na transação recebe de um estabelecimento comercial um ou mais bens ou serviços associados com a transação. Mecanismos são providos para restringir fraude pelo uso de uma ou mais listas mantidas pelo estabelecimento comercial. Estas listas podem incluir todos os possíveis 5 números de conta (por exemplo, uma lista branca) ou só aqueles números de conta que não são válidos (por exemplo, um sistema de lista negativa, às vezes chamada "lista negra" ou "lista quente"). As implementações, porém, mudam cada tais números de contas em uma procuração disso usando uma assinatura de titular de cartão de forma que o número de conta não possa ser 10 conhecido.
Transações usam uma dispositivo de pagamento portátil de instituição financeira (FIPPD). Como usado aqui, um FIPPD é pretendido ser entendido amplamente como sendo um dispositivo de pagamento portátil associado com uma conta dentro de um sistema de pagamento. A conta pode 15 ser uma conta de crédito, uma conta de débito, uma conta de valor armazenado (por exemplo, uma conta pré-paga, uma conta acessível com um cartão de presente, uma conta acessível com um cartão recarregável). Como tal, o FIPPD pode ser um dispositivo (segurado à mão) tal como um telefone celular, um tocador de MP3, Assistente Digital Pessoal (PDA), um chaveiro, 20 um míni-cartão, um dispositivo de chaveiro (tal como o Speedpass™ comercialmente disponível de ExxonMobil Corp.), um dispositivo de pagamento sem contato de proximidade tal como um que se conforma à Organização Internacional para Padronização (ISO) 14443, um substrato portando uma região de dados opticamente escaneável, um cartão inteligente, 25 ou elementos integrais e/ou equipados efetuando as mesmas funções equivalentes e a um cartão de banco sem contato associado com um sistema de pagamento. Um dispositivo de pagamento sem contato é um dispositivo que incorpora um meio de se comunicar com um leitor ou terminal de dispositivo de pagamento portátil sem a necessidade por contato direto. Assim, podem tais dispositivos de pagamento portáteis podem efetivamente serem apresentados na proximidade de um leitor ou terminal de dispositivo de pagamento portátil. Uma chip inteligente é um dispositivo de semicondutor que é capaz de executar a maioria, se não todas as funções de um cartão 5 inteligente, mas pode ser embutido em outro dispositivo. Tais dispositivos sem contato se comunicam tipicamente com o leitor ou terminal de dispositivo de pagamento portátil usando tecnologia de RF (radiofreqüência), em que proximidade a uma antena causa transferência de dados entre o dispositivo de pagamento portátil e o leitor ou terminal.
Tipicamente, uma transação de pagamento eletrônica é
autenticada se o consumidor conduzindo a transação estiver autorizado corretamente e tiver fundos ou créditos suficientes para conduzir a transação. Reciprocamente, se houver fundos ou créditos insuficientes na conta do consumidor, ou se o dispositivo de pagamento portátil do consumidor for informado como perdido ou roubado, então uma transação de pagamento eletrônica pode não ser autorizada. Na descrição seguinte, um "adquirente" é tipicamente uma entidade empresarial (por exemplo, um banco comercial) que tem uma relação empresarial com um estabelecimento comercial particular. Um "emissor" é tipicamente uma entidade empresarial (por exemplo, um banco) que emite um dispositivo de pagamento portátil tal como um cartão de crédito, débito ou de valor armazenado a um consumidor. Algumas entidades podem executar ambas as funções de emissor e adquirente. O titular de cartão pode oferecer ao estabelecimento comercial um cartão de chip, com contato ou sem contato, tal como um cartão de Radiofreqüência (RF) como tipicamente achado no ambiente de trânsito.
Antes de discutir adicionalmente o uso do FIPPD que é capaz de funções de pagamento e trânsito combinadas, e o possível cenário de um emissor atuando como um intermediário ou terceiro confiado, uma breve descrição da operação de pagamento eletrônica padrão será apresentada. Tipicamente, uma transação de pagamento eletrônica é autorizada se o consumidor conduzindo a transação estiver autenticado corretamente e tiver fundos ou créditos suficientes para conduzir a transação. Reciprocamente, se houver fundos ou créditos insuficientes na conta do consumidor, ou se o 5 dispositivo de pagamento portátil do consumidor estiver em uma lista negativa (por exemplo, é indicado como possivelmente roubado), então uma transação de pagamento eletrônica pode não ser autorizada. Na descrição seguinte, um "adquirente" é tipicamente uma entidade empresarial (por exemplo, um banco comercial) que tem uma relação empresarial com um 10 estabelecimento comercial particular. Um "emissor" é tipicamente uma entidade empresarial (por exemplo, um banco) que emite um dispositivo de pagamento portátil tal como um cartão de crédito, débito, ou de valor armazenado a um consumidor. Algumas entidades podem executar ambas as funções de emissor e adquirente.
Em operação padrão, uma mensagem de pedido de autorização
é criada durante uma compra de consumidor de um bem ou serviço a um ponto de venda (POS) usando um dispositivo de pagamento portátil. Uma mensagem de pedido de validação de emissor pode ser enviada do terminal de POS localizado a um estabelecimento comercial para o adquirente do 20 estabelecimento comercial, para um sistema de processamento de pagamento, e então para um emissor. A "mensagem de pedido de validação de emissor" pode incluir um pedido para validação de emissor para conduzir uma transação de pagamento eletrônica. Pode incluir um ou mais do número de conta de pagamento de um titular de conta, código de moeda corrente, quantia 25 de venda, selo de transação de estabelecimento comercial, cidade de aceitante, estado/país de aceitante, etc. Uma mensagem de pedido de validação de emissor pode ser protegida usando um método de criptografia segura (por exemplo, SSL de 128 bits ou equivalente) a fim de prevenir dados de serem comprometidos. Se referindo à Figura 1, uma implementação de um sistema de pagamento 100 compatível com um FIPPD é ilustrado. O sistema de pagamento 100 inclui uma pluralidade de estabelecimentos comerciais 140 associados com um ou mais adquirentes 150, e emissores 170. Cada 5 estabelecimento comercial 140 pode ter um ou mais locais de estabelecimento comercial 140(a), 140(b) com adquirentes 150(a) e 150(b) associados com esses locais de estabelecimento comercial, onde 'a' pode ser um valor de 1 para 'A' e 'b' pode ser um valor de 1 para 'B'. Os locais de estabelecimento comercial diferentes 140(a), 140(b) podem ser afiliados com um único 10 estabelecimento comercial. Um consumidor 120 pode comprar um bem ou serviço nos locais de estabelecimento comercial 140(a), 140(b) usando um FIPPD 130. Os adquirentes 150(a), 150(b) podem se comunicar com um emissor 170 por um processador de pagamento 160.
O FIPPD 130 pode estar em muitas formas adequadas. Como 15 previamente declarado, o FIPPD 130 pode ser um dispositivo móvel que incorpora um elemento sem contato tal como um chip para armazenar dados de pagamento (por exemplo, um número de BIN, número de conta, etc.) e um elemento de transferência de dados sem fio (por exemplo, transmissão) tal como uma antena, um diodo emissor de luz, um laser, um componente de 20 comunicação de campo próximo, etc. O FIPPD 130 também pode ser usado para executar funções de débito (por exemplo, um cartão de débito), funções de crédito (por exemplo, um cartão de crédito), ou funções de valor armazenado (por exemplo, um cartão de valor armazenado).
O processador de pagamento 160 pode incluir subsistemas de 25 processamento de dados, redes, e outros meios de implementar operações usadas para suportar e entregar serviços de validação de emissor, serviços de arquivo de exceção, e serviços de compensação e liquidação para transações de pagamento. O adquirente 150, processador de pagamento 160, e o emissor 170 compõem um sistema de processamento de pagamento 180. O processador de pagamento 160 pode incluir um computador de servidor. Um computador de servidor é tipicamente um computador poderoso ou agrupamento de computadores. Por exemplo, o computador de servidor pode ser um mainframe grande, um agrupamento de 5 minicomputadores, ou um grupo de servidores funcionando como uma unidade. Em um exemplo, o computador de servidor pode ser um servidor de banco de dados acoplado a um servidor da web. O processador de pagamento 160 pode usar qualquer rede por fios ou sem fio adequada, incluindo a Internet.
O estabelecimento comercial 140 tipicamente tem um terminal
de ponto de venda (POS) (não mostrado), que pode interagir com o FIPPD 130. Qualquer terminal de ponto de venda adequado pode ser usado, incluindo leitores de dispositivo (por exemplo, cartão). Os leitores de dispositivo podem incluir qualquer modo de operação por contato ou sem 15 contato adequado. Por exemplo, leitores de cartão exemplares podem incluir antenas de RF (radiofreqüência), leitores de faixa magnética, etc., para interagir com o FIPPD 130.
Como notado, um elemento desejável do sistema de transação de pagamento eletrônico padrão é a entidade responsável pelas funções de 20 administração de conta envolvidas na transação. Tal entidade pode ser responsável por assegurar que um usuário seja autorizado para conduzir a transação (por uma validação de emissor on-line por emissor 170 tal como autenticação de emissor 170), confirmar a identidade de uma parte para uma transação (por recibo de um número de identificação pessoal), confirmar uma 25 linha de saldo ou de crédito suficiente para permitir uma compra, e reconciliar a quantia de compra com a conta do usuário (por entrada em um registro da quantia de transação, data, etc.). Também, tal entidade pode executar certos serviços relacionados a trânsito além dos serviços de transação padrão.
Por exemplo, a entidade de processamento de transação de pagamento pode ser responsável por se comunicar com um ou mais sistemas de computador de agência de trânsito para prover dados de autenticação (gerando e/ou distribuindo chaves) para controle de acesso a sistemas de trânsito, dados de processo obtidos do dispositivo móvel de um usuário de 5 trânsito para associar dados de identificação de usuário de sistema de trânsito com uma conta usada para pagar pelas despesas de trânsito, gerar registros de faturamento para atividades de trânsito, etc. Note que um terceiro confiado também pode executar algumas ou todas estas funções, e dessa maneira atuar como uma câmara de compensação para processamento de dados de controle 10 de acesso e/ou dados de atividade de trânsito.
Se referindo agora à Figura 2, coleta de tarifa de trânsito é tipicamente realizada em um sistema de processamento de trânsito fechado 200 - o dispositivo de pagamento portátil de trânsito 210 sendo emitido pelo sistema de trânsito e a tarifa sendo calculada no POS de trânsito 240. O POS 15 de trânsito 240 pode ser uma caixa de tarifa ou um torniquete com um leitor de sistema de trânsito 220, tal como um leitor de cartão sem contato. O POS de trânsito 240 coleta e armazena dados tais como o número de identificação de cartão, história de transação de cartão, informação de validade de cartão, etc. O POS de trânsito 240 e o dispositivo de pagamento portátil de trânsito 20 210 validam um ao outro, tipicamente utilizando algoritmos e chaves de criptografia. O POS de trânsito 240 então pede os dados do dispositivo de pagamento portátil de trânsito 210. O leitor de trânsito 220 e POS de trânsito 240 processam os dados do leitor de trânsito 220 e aplicam as regras de política de tarifa para a agência de trânsito. Processamento das regras de tarifa 25 resultará em uma determinação de um valor de tarifa, seguido pela diminuição do dispositivo de pagamento portátil de trânsito 210 de valor ou número de viagens, ou aplicação de um passe (como um passe mensal). O dispositivo de pagamento portátil de trânsito 210 é atualizado escrevendo informação de volta ao dispositivo de pagamento portátil de trânsito 210 como necessário para documentar a transação no dispositivo de pagamento portátil de trânsito 210.
Se uma transação tiver um impacto no custo da próxima transação, como no caso de uma transferência descontada quando o freguês 5 transfere ao próximo trecho da viagem, a história de dispositivo de pagamento portátil de trânsito 210 apropriada está disponível na hora da transação de transferência. A informação armazenada no dispositivo de pagamento portátil de trânsito 210 está disponível para fazer determinação do custo da tarifa no momento da transação. Não há nenhuma necessidade para examinar qualquer 10 outro computador ou servidores para completar a transação no dispositivo de tarifa e o passageiro é permitido entrar na instalação de acesso.
Depois que a transação está completa, a informação de transação de tarifa é tipicamente transferida para computador central de trânsito 270 pela rede privada de trânsito 260 para propósitos de 15 contabilidade, informação e determinação de fraude. O dispositivo de pagamento portátil de trânsito 210 é identificado exclusivamente por um número de conta de trânsito, e é rastreado para valores fora de saldo, velocidade, ou regras de uso. Se as regras de fraude forem quebradas e o dispositivo sem contato portátil de trânsito 210 for determinado ter fraude 20 associada, o número de dispositivo de pagamento portátil de trânsito 210 pode ser colocado em uma lista negativa ou positiva, que pode ser mantida em um armazenamento que é acessível ao computador central de trânsito, tal como é visto na Figura 3 a número de referência 305 e descrito abaixo. A lista quente pode ser enviada para cada POS de trânsito 240 para uso como um 25 componente de validação na hora da transação. Por exemplo, se o número de identificação de dispositivo de pagamento portátil de trânsito 210 for achado na lista quente, o dispositivo de pagamento portátil de trânsito 210 pode ser negado para entrada no sistema de trânsito.
Se referindo agora à Figura 3, um FIPPD 130 pode ser usado em um esquema para conduzir uma transação dentro de um sistema de acesso aberto 300. Implementação de um aplicativo de tarifa de acesso não permite a oportunidade para a transação de pagamento entrar on-line ao emissor 170 para uma validação de emissor (por exemplo, autorização) na hora da 5 transação como ocorreria com o estabelecimento comercial 140, tal como um estabelecimento comercial de varejo. Isto é devido em parte à necessidade para processar uma transação em menos de um segundo, tipicamente dentro de cerca de 300 ms - um padrão de indústria de sistema de trânsito, para permitir 30 a 45 fregueses por minuto na instalação de trânsito (daqui em w 10 diante chamado o "período de acesso"). A habilidade para entrar on-line no ambiente de trânsito também pode ser problemática por causa da falta de comunicação em tempo real e sistemas de rede. Por exemplo, ônibus estão na estrada e podem não ter sistemas de comunicação sem fio ou outros para permitir diálogo em tempo real com quaisquer outros sistemas fora do ônibus. 15 Conseqüentemente, uma implementação combina um esquema de processos para conduzir uma transação de tarifa, tal como foi ilustrado na Figura 3.
Por exemplo, um passageiro pode apresentar o FIPPD 130 no POS de trânsito tendo o leitor de trânsito 220. O leitor de trânsito 220 pode capturar do FIPPD 130 informação de conta de instituição financeira, tais 20 como Dados de Faixa Magnética (MSD), em um modo off-line (por exemplo, sem se comunicar com o sistema de processamento de pagamento 180). O leitor de trânsito 220 pode Ier tudo de dados de trilha, ou só parte dos dados de trilha tal como um número de conta primário (PAN) associado com o FIPPD 130. Os dados de trilha, junto com outra informação de transação, tal 25 como a hora e o local do POS de trânsito 240, podem ser transmitidos ao computador central de trânsito 270 pela rede privada de trânsito 260. Neste momento, porém, o valor de tarifa não pode ser conhecido. Não obstante, ao consumidor é dado acesso à instalação de trânsito.
A informação de transação pode ser armazenada e analisada no computador central de trânsito 320. O computador central de trânsito 320 pode ter um banco de dados contendo história de transação de trânsito para todos os passageiros que usam o sistema de trânsito. A história de transação de trânsito pode ser atualizada com cada uso de FIPPD 130 no POS de trânsito 240 ou pode ser atualizada em uma base de lote.
A história de transação de trânsito pode ser acessada para calcular o valor de uma tarifa off-line. Por exemplo, um conjunto da história de transação de trânsito dentro do banco de dados pode ser acessado baseado no PAN lido do FIPPD 130 a cada evento de trânsito (por exemplo, entrada, 10 transferência, ou saída) usando o FIPPD 130; a história de transação de trânsito pode ser então posta em uma ordem cronológica de eventos de trânsito; e a tarifa de trânsito pode ser derivada usando a cronologia de eventos de trânsito na base de regras e políticas de agência de trânsito predeterminadas.
Uma vez que o valor de tarifa seja derivado, a transação pode
ser processada em comunicação com o sistema de processamento de pagamento 180 como seria uma transação de varejo on-line padrão com o estabelecimento comercial 140. O valor de tarifa pode ser transmitido ao sistema de processamento de pagamento 180 pela rede on-line 310. Uma vez 20 transmitido, o valor de tarifa pode ser autorizado, compensado e liquidado - como descrito para o sistema de pagamento 100 - com o estabelecimento comercial 140.
Se referindo à Figura 4, um fluxograma é usado para ilustrar um processo exemplar 400 pelo qual o FIPPD 130 pode ser usado no sistema 25 de trânsito aberto 300. Processo 400 começa na etapa 402, onde dados da região de armazenamento de dados do FIPPD 130 associado com uma conta dentro do sistema de pagamento 100 são lidos. Os dados podem incluir todos os dados de trilha ou subcomponente disso. Por exemplo, os dados podem incluir uma identificação para o FIPPD associado com a conta tal como o P AN. Os dados podem ser lidos pelo leitor de trânsito 220 tal como um leitor sem contato lendo um cartão de pagamento sem contato que foi emitido por um emissor em um sistema de processamento de pagamento. Os dados de transação podem incluir os dados lidos no leitor de trânsito 220 junto com 5 outra informação de transação tal como a data, a hora, um código de identificação de estabelecimento comercial, o local do POS de trânsito 240, etc.
Na etapa 420, o pedido de validação opcional pode ser conduzido no POS de trânsito 240 incluindo verificações rudimentares sobre i. 10 o estado do FIPPD 130 ou variações de validação de emissor on-line (por exemplo, autorização) com o sistema de processamento de pagamento 180. Por exemplo, uma validação de trânsito pode ser pedida. A validação de trânsito poderia envolver a data de expiração do FIPPD 130 sendo verificada no POS de trânsito 240. Também, uma análise de Módulo 10, tal como um algoritmo de Luhn, poderia ser feita no POS de trânsito 240, em que uma fórmula de soma de verificação é usada para validar um número de identificação tal como o PAN. Além disso, um exame de saldo pode ser formado em uma comunicação dirigida ao emissor 170. Um exame de saldo pode executar a função de iniciar uma verificação rápida no saldo associado com um PAN no sistema de processamento de pagamento 180 associado com
o FIPPD 130. O exame de saldo poderia não incluir uma análise de risco que às vezes é feita durante o componente de autenticação de uma transação convencional. Conseqüentemente, a verificação de saldo poderia ser completada dentro do período de acesso.
25 Alternativamente, ou em combinação, a etapa de validação
420 pode incluir uma verificação contra a lista branca ou lista negra da agência de trânsito mantida tanto no POS de trânsito 240 ou no computador central de trânsito 270 para determinar se ao passageiro deveria ser permitido acesso na instalação de trânsito. A lista branca pode ser uma lista de dados tal como um PAN reeditado associado com uma conta elegível que pode ser usada para ganhar acesso à instalação de trânsito. Semelhantemente, a lista negra pode ser uma lista de dados associados com uma conta inelegível, tal como uma assinatura reeditada que não pode ser usada para ganhar acesso à 5 instalação de trânsito. Portanto, a lista branca ou lista negra pode consistir em identificadores para dispositivos de pagamento portáteis, tal como o PAN associado ao FIPPD 130 ou uma procuração disso. A agência de trânsito pode colocar um dispositivo de pagamento portátil em uma tal lista (por exemplo, branca ou negra) baseado em vários parâmetros. Por exemplo, o dispositivo
i 10 de pagamento portátil pode ter sido informado roubado por um consumidor, o dispositivo de pagamento portátil pode ter sido um cartão de valor armazenado que esvaziou seu valor, ou o dispositivo de pagamento portátil pode ter sido usado de uma maneira repetida através de um curso de um dia tal que fraude pode ser suspeitada. Declarado caso contrário, a "velocidade" 15 com a qual o dispositivo de pagamento portátil é detectado como tendo sido usado pode indicar que fraude está sendo usada para ganhar acesso a uma instalação de trânsito; uma agência de trânsito pode ter um hospedeiro de políticas e regras que, quando transgredidas, colocam um dispositivo de pagamento portátil na lista negativa. Cada tal lista pode ser mantida no banco 20 de dados 305 em comunicação com o computador central de trânsito 270 ou no POS de trânsito 240.
A agência de trânsito também pode colocar um dispositivo de consumidor em uma lista branca ou lista negra baseado em uma transmissão se originando do sistema de processamento de pagamento 180, tal como uma 25 resposta a um pedido de validação de emissor. Por exemplo, a transmissão pode ter incluído uma notificação do emissor 170 que houve uma transação recusada envolvendo o FIPPD 130 no passado ou que a avaliação de risco do sistema de processamento de pagamento 180 no FIPPD 130, o sistema de trânsito pode usar comparado à avaliação de risco a um limiar de tolerância de trânsito para risco tal que a agência de trânsito possa desejar colocar o FIPPD 130 na lista negativa se o limiar for transgredido. Outras respostas ao pedido de validação de emissor pode ser uma resposta de verificação de saldo, uma resposta de contagem de crédito, uma resposta de autorização, ou uma 5 combinação disso.
A lista branca ou lista negra pode ser hospedada no POS de trânsito 240 ou no banco de dados 305 em comunicação com o computador central de trânsito 270, enquanto ainda estando em comunicação com o POS de trânsito 240. Quando da lista é hospedada no banco de dados 305, a lista *. 10 branca ou lista negra pode ser atualizada sem ter que fazer mudanças a cada POS de trânsito 240. O computador central de trânsito 270 não precisa ser um único computador. Em lugar disso, o computador central de trânsito 270 pode ser uma rede de computadores tal como uma rede com nós para um conjunto de leitores de trânsito 220. Os nós podem ser conectados um ao outro, tanto 15 lateralmente e/ou hierarquicamente.
Na etapa 430, os dados de transação podem ser transmitidos ao computador central de trânsito 270 para armazenamento e análise. O computador central de trânsito 270 pode usar o banco de dados 305 para conter história de transação de trânsito para passageiros que usam o sistema 20 de trânsito com o passar do tempo. A história de transação de trânsito pode incluir informação de transação tal como a data e hora de um evento de trânsito, uma identificação do POS de trânsito 240, uma identificação da agência de trânsito, e pelo menos alguns dos dados lidos da região de armazenamento de dados do FIPPD 130. A história de transação de trânsito 25 pode ser atualizada com cada evento de FIPPD 130 no leitor de trânsito 220 ou em uma base de lote.
Na etapa 440, ao passageiro é dado acesso à instalação de trânsito. A instalação de trânsito pode ser um metrô, um ônibus, uma balsa, um bonde, um 'hovercraft', um trem, e outras formas de transporte como são achadas tipicamente dentro de um sistema de trânsito. Etapas 410 a 440 podem ocorrer off-line dentro de um período de tempo curto tal como menos de cerca de um segundo ou através de um período de tempo não excedendo o período de acesso (por exemplo, 300 ms). Etapas 410 por 440 se repetem 5 quando passageiros respectivos interagem com o POS de trânsito 240.
Na etapa 450, a história de transação de trânsito armazenada na etapa 430 pode ser acessada para calcular off-line (por exemplo, não em tempo real) o valor de uma tarifa usando os dados de transação armazenados e as políticas de agência de trânsito. Por exemplo, um conjunto das transações t 10 de trânsito pode ser acessado baseado na informação de identificação de FIPPD 130, tal como o PAN do FIPPD 130; o conjunto de transações de trânsito pode então ser ordenado cronologicamente por eventos de trânsito (por exemplo, entrada, transferência, ou saída); e a tarifa de trânsito pode ser derivada usando a cronologia de eventos de trânsito baseado em regras e 15 políticas de agência de trânsito predeterminadas. Por exemplo, uma agência de trânsito pode cobrar uma taxa de trânsito baseada em políticas de tarifa predeterminadas, tal como uma taxa plana de $2,00 (EUA) para entrada no sistema. Outros exemplos de políticas de tarifa predeterminadas incluem avaliar o valor de tarifa baseado em: uma entrada na instalação do sistema de 20 trânsito; uma saída da instalação do sistema de trânsito; uma distância para uma entrada e uma saída correspondente; uma transferência de uma instalação do sistema de trânsito para outra instalação do sistema de trânsito; o número seqüencial de cada transferência em um período de tempo predeterminado; uma direção de viagem no sistema de trânsito; uma classificação do 25 passageiro correspondendo ao FIPPD 130 (por exemplo, concessões baseadas em idade, estado de estudante, ou viajante freqüente); períodos de tempo de viagem de pico e fora de pico; um período de tempo de viagem de feriado; e combinações do antecedente. Aqueles na técnica estão familiarizados com as regras e políticas potenciais que podem aplicar em calcular uma tarifa de trânsito.
Λ
As vezes vários FIPPDs 130 podem ter o mesmo PAN. Por exemplo, um marido e esposa podem cada um ter seus FIPPDs 130 respectivos ligados a sua conta corrente conjunta. Alternativamente, vários 5 empregados do mesmo empregador podem cada um ter FIPPDs 130 respectivos, todos estando associados com uma única conta (por exemplo, PAN) dentro do sistema de processamento de pagamento 180. Como tal, os cálculos de tarifa respectivos para esses empregados usando seus FIPPDs 130 respectivos para viajar durante a mesma hora dentro do sistema de trânsito
l 10 precisarão levar em conta qual cartão está sendo usado por cada empregado dentro do mesmo PAN.
Na etapa 460, a agência de trânsito pode transmitir um ou mais valores de tarifa calculados ao sistema de processamento de pagamento 180 para coleta baseado em vários modelos de pagamento. Por exemplo, o modelo 15 usado pela agência de trânsito para pedir pagamento para os valores de tarifa calculados do sistema de processamento de pagamento 180 pode ser um modelo de pagamento por cada uso, um modelo de agregação de múltiplos valores de tarifa calculados, ou um modelo pré-pago.
No modelo de pagamento por cada de uso, quando a tarifa de 20 trânsito é determinada, a tarifa é transmitida ao sistema de processamento de pagamento 180 para coleta. Portanto, a tarifa de trânsito pode ser enviada diretamente ao sistema de processamento de pagamento 180. Alternativamente, a tarifa de trânsito calculada pode ser agrupada com outras tarifas de trânsito calculadas para uma pluralidade de FIPPDs 130 através de 25 um período de tempo e então enviada em uma base intermitente ao sistema de processamento de pagamento 180 para coleta.
Uma vez que a tarifa de trânsito seja enviada ao sistema de processamento de pagamento 180, ela pode ser processada de acordo com protocolo típico para estabelecimentos comerciais 140. Por exemplo, cada tarifa de trânsito de $2,00 pode ser autorizada, paga e compensada pelo sistema de processamento de pagamento 180, a agência de trânsito pode ser paga, e o consumidor pode receber as tarifas de trânsito taxadas em uma declaração mensal correspondendo a seu PAN.
5 No modelo de agregação, a tarifa de trânsito envolvendo
FIPPD 130 pode ser acumulada baseado em um algoritmo predeterminado antes de enviar a tarifa de trânsito ao sistema de processamento de pagamento 180. As tarifas de trânsito cumuladas podem ser com o passar do tempo, através de valor de trânsito, ou através de quantidade. Por exemplo, a agência . 10 de trânsito pode acumular tarifas de trânsito envolvendo o FIPPD 130 que ocorrem através de um período de semana antes de transmitir o conjunto agregado de tarifas ao sistema de processamento de pagamento 180. Alternativamente, a agência de trânsito pode acumular valores de tarifa de trânsito baseado em um valor de limiar. Por exemplo, uma vez que o valor de 15 tarifa de trânsito acumulado alcance $20,00 (dólares norte-americanos), a agência de trânsito pode transmitir o conjunto agregado de tarifas ao sistema de processamento de pagamento 180. Em outro exemplo, a agência de trânsito pode acumular os valores de tarifa de trânsito baseado na quantidade de tarifas de trânsito - tal como quando um passageiro completou cinco (5) 20 viagens envolvendo o mesmo FIPPD 130, onde cada viagem tinha seu próprio valor de tarifa (por exemplo, $4,00, $0,50, $1,00, e $5,00 dólares norte- americanos), e então acumular as tarifas e transmitir o valor total disso ao sistema de processamento de pagamento 180.
No modelo de valor armazenado, a conta associada com o 25 FIPPD 130 é acessada pelo sistema de processamento de pagamento 180 no sistema de trânsito. Por exemplo, o passageiro pode perguntar ao agente de trânsito em uma barraca de pagamento para deduzir a quantia do cartão de crédito do passageiro associado com o sistema de processamento de pagamento 180 antes do passageiro ir a um torniquete buscar entrada em um metrô do sistema de trânsito. O agente de trânsito pode então conduzir uma transação on-line com o sistema de processamento de pagamento 180 assim para cobrar um valor contra a conta, por exemplo $50,00 (dólares norte- americanos). O sistema de trânsito pode então manter uma conta de trânsito 5 associada com o FIPPD 130, por exemplo, tal que a conta de trânsito possa ser mantida no computador central de trânsito 270. Quando o passageiro deseja pegar o metrô, o passageiro pode ir ao torniquete, expor o FIPPD 130 em proximidade ao leitor de trânsito 220 em uma operação de leitura sem contato. O POS de trânsito 240, neste caso o torniquete, pode transmitir o
* 10 evento de trânsito ao computador central de trânsito 270 pela rede privada de trânsito 260. Uma vez que uma pluralidade de tais eventos de trânsito seja completada para o PAN associado com FIPPF 130 (tal como ambas uma entrada e uma saída ao sistema de metrô para o passageiro), a tarifa de trânsito pode ser calculada e deduzida da conta de trânsito no computador 15 central de trânsito 270. Neste caso, a transação on-line para registrar o evento de trânsito ocorre antes da transação off-line do computador central de trânsito 270 para coletar o conjunto agregado de tarifas do sistema de pagamento 180.
O passageiro pode estabelecer a conta de trânsito tal que a 20 conta seja "limitada" a intervalos predeterminados - tal como quando o fim do mês chega ou quando a conta de trânsito alcançou um valor mais baixo de limiar tal como $5,00 (dólares norte-americanos), por meio de que uma quantia predeterminada é cobrada à conta que está associada com o FIPPD 130 no sistema de processamento de pagamento 180. Portanto, o sistema de 25 trânsito pode conduzir uma transação on-line, por exemplo para $50,00 (dólares norte-americanos) com o sistema de processamento de pagamento 180 uma vez que o intervalo predeterminado seja alcançado.
Se referindo à Figura 5, um fluxograma é usado para ilustrar um processo exemplar 500 por qual uso um passageiro pode ganhar acesso à instalação de acesso usando o FIPPD 130. Na etapa 510, os dados da região de armazenamento de dados do FIPPD 130 são lidos no leitor de trânsito 220. Os dados podem ser associados com uma conta particular dentro do sistema de processamento de pagamento 180. Os dados podem ser estáticos ou 5 dinâmicos. Dados estáticos são dados que não mudam com cada uso do FIPPD 130, tal como o PAN. Por outro lado, dados dinâmicos são dados que podem mudar com o uso do FIPPD 130, tal como um contador que está armazenado em um cartão inteligente, onde cada uso do cartão inteligente decrementa ou incrementa o contador. Os dados podem ser, por exemplo, os
- 10 dados de trilha completa ou porções disso para o FIPPD 130. Também, os dados podem estar em um formato de dados de faixa magnética (MSD).
Opcionalmente, como impedimento a fraude por roubo de informação de sistema de trânsito e pagamento, os dados podem ser obscurecidos, por exemplo convertendo-os a um número de procuração, 15 reeditando os dados em um algoritmo executado tanto remotamente ou no POS de trânsito 240. Além disso, os dados reeditados podem ser truncados. Os dados, junto com outros dados sobre o pedido do passageiro para acesso à instalação de trânsito, podem ser armazenados como dados de transação de trânsito. Estes dados de transação de trânsito podem incluir informação tal 20 como a data, a hora da transação de trânsito, e/ou uma identificação do POS de trânsito 240. Estes dados de transação de trânsito podem ser armazenados no POS de trânsito 240 e podem ser transmitidos ao computador central de trânsito 270 pela rede privada de trânsito 260 para armazenamento, processamento ou análise adicional.
25 Na etapa 520, uma comunicação é formada que é endereçada
ao computador central de trânsito 270. Esta comunicação é transmitida através da rede privada de trânsito 260. O endereço pode estar na forma de um endereço de Protocolo de Internet para transmissão de rede ou outra forma de um endereço que identificará exclusivamente um recipiente. A comunicação também pode incluir os dados lidos, uma procuração disso, e/ou os dados de transação de trânsito completos. Um propósito desta comunicação pode ser pedir uma resposta do computador central de trânsito 270 sobre se ou não uma validação de trânsito deveria ser dada no POS de trânsito 240 para o 5 passageiro usar seu FIPPD 130 para ganhar acesso a uma instalação no sistema de trânsito. A validação de trânsito pedida pode ser, por exemplo, baseada em uma verificação dos dados lidos contra uma lista branca ou lista negra contendo identificadores de contas elegíveis e inelegíveis, respectivamente, que podem ser mantidos, por exemplo, no banco de dados 10 305 em comunicação elétrica com o computador central de trânsito 270. Além disso, a validação de trânsito pedida pode ser baseada em um módulo 10 ou verificação de data de expiração. Por exemplo, o processo de validação de trânsito pode resultar em uma negação para acesso na instalação de acesso porque o FIPPD 130 tem uma data de expiração que passou. Como 15 previamente declarado, a lista branca ou lista negra pode ser criada baseada nas políticas de sistema de trânsito para validação de trânsito e/ou nas respostas do sistema de processamento de pagamento 180 ao pedido de validação de emissor.
Na etapa 530, o POS de trânsito 240 recebe de volta a resposta 20 à validação de trânsito pedida do computador central de trânsito 270 em uma transmissão através da rede privada de trânsito 260. A resposta pode incluir informação em várias formas. Por exemplo, a informação pode estar em uma forma que inclui uma mensagem que o POS de trânsito 240 (por exemplo, um torniquete) deveria recusar acesso ao passageiro buscando entrar na instalação 25 de trânsito; a informação pode estar em uma forma para incluir uma mensagem indicando que ao passageiro é permitido acesso à instalação de trânsito; a informação pode estar em uma forma para incluir uma mensagem que o passageiro é para ser taxado uma tarifa descontada na base do estado do passageiro (por exemplo, um estado de passageiro estudante, um estado de passageiro idoso, etc.). Também, a resposta à validação de trânsito pedida pode incluir combinações da informação precedente em uma ou mais outras formas.
Na etapa 540, uma pergunta é executada na resposta à 5 validação de trânsito pedida. Se a resposta indicar que o passageiro pode entrar na instalação de trânsito, o processo 500 se move à etapa 550, à qual etapa o passageiro é permitido acessar a instalação de trânsito. Alternativamente, se a pergunta determinar que ao passageiro é recusado tal acesso, o passageiro pode ter uma opção adicional para apresentar um FIPPD .10 130 diferente para consideração subseqüente e nova do acesso do passageiro para entrar na instalação de trânsito.
Alternativamente, a validação de trânsito na etapa 540 pode ser condicional. Por exemplo, se a resposta à validação de trânsito pedida indicar que o FIPPD 130 só está autorizado para uma tarifa descontada 15 baseada no estado do passageiro, tal como um desconto de tarifa dado só a passageiros idosos, então um agente de trânsito localizado no POS de trânsito 240 pode recusar a entrada do passageiro na instalação de trânsito se o agente de trânsito observar que o passageiro não cumpre os critérios para a tarifa descontada. Por meio de ilustração, se um avô emprestar seu FIPPD 130 ao 20 seu neto para uso do sistema de trânsito por um dia, uma observação pelo agente de trânsito do neto pode resultar no agente de trânsito negar o acesso de neto à instalação de trânsito na tarifa descontada de estado de passageiro idoso.
Processo 500 repete as etapas 510 por 550 para cada 25 passageiro apresentando o FIPPD 130 a um leitor de trânsito 220. Preferivelmente, estas etapas, incluindo a etapa de receber de volta a resposta à validação de trânsito pedida do computador central de trânsito 270, ocorrerão em um período curto de tempo, mais preferivelmente em menos que cerca de um segundo, e mais preferivelmente em um período de acesso de cerca de 300 ms.
Se referindo à Figura 6, um fluxograma de um processo 600 ilustra uma implementação para validar um FIPPD 130 no sistema de trânsito para acesso por um passageiro à instalação de trânsito. Processo 600, para 5 cada passageiro, começa na etapa 610, onde o leitor de trânsito 220 lê dados do FIPPD 130 que podem incluir os dados que serão validados mais tarde. Outros dados para os dados de transação de trânsito pedidos também podem ser obtidos, tal como a hora e data do acesso. Processo 600 então se move à etapa 620.
- 10 Na etapa 620, uma validação de trânsito é determinada para os
dados (por exemplo, o PAN da conta dentro do sistema de processamento de pagamento 180 lido do FIPPD 130) para determinar se o FIPPD 130 pode ser usado para ganhar acesso no sistema de acesso (por exemplo, sistema de trânsito). Uma lista branca, uma lista negativa, ou uma combinação disso 15 pode ser usada para determinar tal validação de trânsito. Por exemplo, o computador central de trânsito 270 pode ter um banco de dados 305 contendo o estado de uma pluralidade dos FIPPDs 130 associados com passageiros respectivos. Estes dados podem ser catalogados baseado nos dados de trilha do FIPPD 130, dados de assinatura do FIPPD 130, a conta (por exemplo o 20 PAN), ou procurações disso.
Em uma implementação, um indicador associado com o FEPPD 130 pode ser usado a fim de colocar o FIPPD 130 em uma lista negativa. Uma avaliação do indicador, por exemplo, pode ser baseada em política de sistema de trânsito. Estes indicadores podem ser derivados pelo 25 sistema de trânsito internamente, eles podem ser recebidos em uma comunicação do sistema de processamento de pagamento 180, ou ambos. Por exemplo, o indicador pode ser uma velocidade de indicador de uso correspondendo a um grau de uso do FIPPD 130 dentro de um período de tempo predeterminado (descrito acima), um indicador de cartão perdido, um indicador de cartão roubado, um indicador de data de expiração, um indicador de saldo de cartão de valor armazenado esvaziado, e combinações disso. Por meio de ilustração, um passageiro oferecendo o FIPPD 130 para acesso a uma instalação de trânsito onde o FIPPD 130 tem uma data de expiração antes da 5 data de oferecer o FIPPD 130, pode fazer o POS de trânsito 240 fixar um indicador para a conta correspondente tal que ao passageiro será negado acesso à instalação de trânsito. Opcionalmente, o POS de trânsito 240 pode então enviar uma transmissão que inclui o indicador e a conta correspondente ao computador central de trânsito 270 para armazenamento no banco de dados -10 305 na lista negativa mantida aí, por exemplo na etapa 630.
Também na etapa 630 de processo 600, os dados de transação de trânsito obtidos na etapa 610 podem ser armazenados no banco de dados 305 e/ou no POS de trânsito 240. Os dados de transação de trânsito armazenados podem mais tarde ser submetidos a processamento de lote pelo 15 computador central de trânsito 270, onde tal processamento de lote também pode incluir análise dos dados de transação de trânsito armazenados tal como para tendências de viagem, taxação de tarifa e coleta de tarifas.
Na etapa 640, o computador central de trânsito 270 executa um ou mais procedimentos de manutenção em uma ou mais listas armazenadas no 20 banco de dados 305. Para estes procedimentos de manutenção, a agência de trânsito pode ter várias políticas que requerem uma conta, indicadores disso, e similar serem adicionados ou remover de tais listas. Por exemplo, uma tal lista pode incluir uma pluralidade de indicadores parar contas que incluem tudo ou uma porção do PAN associado com a conta. Uma tal lista pode ser uma lista 25 negativa e outra tal lista pode ser uma lista branca. Razões para manutenção de lista são compreendidas prontamente por aqueles de habilidade nas técnicas pertinentes e podem ser como são mencionadas acima, tais como razões derivadas internamente pelo sistema de trânsito como também razões baseadas em informação recebida pelo sistema de trânsito em comunicações do sistema de processamento de pagamento 180. Por exemplo, o emissor 170 de um cartão de banco pode comunicar ao sistema de trânsito informação para o efeito que o cartão de banco é para ser negado qualquer e todo uso transacional. Esta informação então seria usada pelo sistema de trânsito para 5 adicionar a conta do cartão de banco à lista negativa armazenada no banco de dados 305. Por meio de outra ilustração, o emissor 170 pode ter recusado uso do FIPPD 130 a um supermercado o dia prévio porque a conta de débito associada com o FIPPD 130 foi exagerada. O sistema de processamento de pagamento 180 pode transmitir uma comunicação da negação ao computador . 10 central de trânsito 270 indicando que o FIPPD 130 não deveria ser validado para uso. Subseqüentemente, o computador central de trânsito 270 pode adicionar a conta para o FIPPD 130 à lista negativa que é mantida no banco de dados 305. Da mesma maneira, o sistema de processamento de pagamento 180 pode enviar uma análise de risco sobre o FIPPD 130 que o computador 15 central de trânsito 270, baseado em um programa de política, pode julgar estar acima de uma exposição ou risco de limiar tolerada, resultando no computador central de trânsito 270 adicionar o FIPPD 130 à lista negativa.
Opcionalmente, na etapa 650, a tarifa de trânsito para a transação de acesso pode ser calculada baseado em história de transação de 20 trânsito e política de sistema de trânsito por uso de dados de transação relacionados obtidos para o FIPPD 130 de um passageiro a cada etapa 610. Como previamente declarado, uma tarifa de trânsito pode ser determinada aplicando regras de trânsito a eventos de trânsito envolvendo FIPPD 130 durante um período de tempo. Aqui, o cálculo pode ocorrer no computador 25 central de trânsito 270 por execução de um programa de política de tarifa.
Na etapa 660, o computador central de trânsito 270 dirige uma comunicação ao POS de trânsito 240. A comunicação, que inclui geralmente uma validação de trânsito ou negação disso para o acesso do passageiro a uma instalação de trânsito, pode incluir, por exemplo, o resultado da verificação de lista negativa assim para indicar se ao passageiro pode ser permitido acesso à instalação de trânsito devido à validação de trânsito contida na comunicação. A comunicação também pode indicar que o passageiro será taxado uma tarifa descontada baseado no estado do passageiro (por exemplo; uma tarifa de passageiro idoso ou menor) ou uma tarifa não descontada.
Processo 600 repete as etapas 610 por 660 para cada passageiro apresentando o FIPPD 130 no leitor de trânsito 220. Preferivelmente, estas etapas, incluindo a etapa de conduzir a verificação de validação de trânsito, ocorrerão em um período curto de tempo, mais preferivelmente em menos que cerca de um segundo, e mais preferivelmente em um período de acesso de cerca de 300 ms.
Seguindo o processo 600 para uma pluralidade de passageiros e suas transações de trânsito respectivas, tarifas para tais passageiros podem ser submetidas pelo sistema de trânsito para coleta do sistema de processamento de pagamento 180 como visto na Figura 4 nas etapas 450-460. Criação de Assinatura e Uso em Transação Off-Line
Dada a discussão precedente de várias implementações de listas em geral, incluindo listas brancas e negativas e seus usos respectivos, a discussão seguinte pertence a implementações particulares de tais listas tal que, se qualquer tal lista fosse para ser roubada ou comprometida, os números armazenados não seriam uma conta de pagamento válida tal como o Número de Conta Primário (PAN), e tal que os números armazenados não seriam usáveis como números de pagamento para conduzir transações dentro ou fora da organização do estabelecimento comercial aplicável (por exemplo, um sistema de trânsito). Além disso, tomando tais listas em uma lista de números de conta de não pagamento (por exemplo, tal como um identificador de cartão único) poderia prover ainda outro nível de segurança além daquele já provido ao emissor ou seu sistema de processamento de pagamento correspondente. Por exemplo, alguns sistemas de processamento de pagamento requerem que quaisquer dados armazenados de titular de cartão, tal como PAN, sejam codificados. As listas negativas, sendo feitas de dados de PAN, necessariamente seriam codificadas de acordo com estas exigências. O processo de decodificar uma tal lista na hora de uma consulta de lista negativa 5 pode levar tempo demais para o padrão de temporização de '300 milissegundos' de ambiente de trânsito. Usando números de conta de não pagamento (por exemplo, identificadores de cartão únicos), a lista negativa seria feita de assinaturas de cartão de não PAN que não requerem descriptografação na hora da transação. Como tal, tempos de transação são . 10 mais rápidos, tal como é requerido no ambiente de transporte público.
Em resumo, a implementação de várias listas, incluindo listas brancas e negativas, desligam o número de conta de pagamento para pagamentos financeiros do valor ou número usado para listagem negativa. Como tal, há uma separação do número de pagamento de titular possuído pelo 15 emissor do cartão ou dispositivo de pagamento do número de lista negativa administrado por um estabelecimento comercial.
Se referindo agora à Figura 7, um fluxograma de um processo 700 ilustra uma implementação que obscurece e separa um número de pagamento de titular possuído por um emissor do dispositivo ou cartão de 20 pagamento de um número de lista negativa administrado por um estabelecimento comercial, onde um consumidor usa o dispositivo ou cartão de pagamento para conduzir uma transação para um bem ou serviço com o estabelecimento comercial, e onde o estabelecimento comercial verifica a versão obscurecida do número de pagamento de titular contra uma lista 25 negativa em uma operação off-line.
Processo 700 inclui a etapa 702, na qual um cálculo de uma assinatura é executado pelo uso de uma chave ou chaves de criptografia comuns como também um algoritmo predeterminado. O algoritmo pode ser usado para criar um valor criptográfico que é armazenado dentro de dados de chip de um cartão de pagamento por contato ou sem contato. O algoritmo pode utilizar uma ou mais chaves de criptografia que podem ser tanto de um tipo simétrico (isto é, DES ou 3 DES) ou um tipo assimétrico (isto é, infra- estrutura de chave pública). A equação matemática ou algoritmo pode 5 produzir um sinal numérico, certificado, ou assinatura utilizando dados de dispositivo de pagamento ou de cartão de pagamento que são únicos àquele dispositivo de pagamento ou cartão de pagamento. Algumas das variáveis usadas no algoritmo podem incluir, mas não precisam estar limitadas ao nome do titular de cartão, um número de conta parcial, dados de expiração, código .10 de serviço, etc. Estas variáveis podem ter sua base nos campos de dados de Trilha 1 e/ou trilha 2 originais do dispositivo/cartão de pagamento de acordo com uma configuração de dados de faixa magnética (MSD).
Nas etapas 704a e 704b, as chaves e algoritmo podem ser transmitidos aos dispositivos no emissor do dispositivo de pagamento ou 15 cartão de pagamento (por exemplo, o banco emissor), que personalizará a assinatura sobre o dispositivo/cartão de pagamento, e para os Terminais de Ponto de Serviço (POS) ou dispositivo que lerá e validará o código de assinatura de cartão durante o processamento de lista negativa na hora da transação.
20 Na etapa 706 de processo 700, uma personalização de
dispositivo/cartão de pagamento pode acontecer em um local que é administrado pelo emissor do dispositivo/cartão de pagamento. Como visto na etapa 708, um sistema de personalização de banco pode carregar o código de assinatura de cartão apropriado em um cartão inteligente (isto é, em chip ou 25 outro dispositivo de armazenamento de semicondutor) baseado em algoritmo e chaves personalizadas, junto com quaisquer outros dados que são pretendidos serem personalizados nesse momento. Estes valores podem ser incluídos em etiquetas de dados adicionais que são lidas do armazenamento do cartão inteligente na hora da transação no terminal de POS. Como tal, na etapa 710, o dispositivo/cartão de pagamento (por exemplo, um cartão inteligente) contém quaisquer dados de aplicativo e outra informação para uma transação de pagamento off-line incluindo a assinatura personalizada.
Processo 700 então se move à etapa 712. Na etapa 712, o dispositivo/cartão de pagamento pode ser dado a um titular de conta pelo emissor. O emissor pretende que o titular de conta usará o dispositivo/cartão de pagamento em uma ou mais transações, algumas que são prováveis serem transação off-line a um estabelecimento comercial que usa uma lista negativa para verificar a validade de dispositivos/cartões de pagamento. Por exemplo, o emissor poderia remeter o dispositivo/cartão de pagamento a um titular de cartão de crédito. Uma vez recebido e ativado pelo titular de cartão, o cartão pode ser usado a qualquer estabelecimento comercial.
Na etapa 714, para cada consumidor, um terminal de POS lê dados do dispositivo/cartão de pagamento quando é oferecido pelo consumidor a um estabelecimento comercial para a compra de bens e/ou serviços. Por meio de exemplo de processo 700, para cada passageiro de um sistema de trânsito buscando acesso a uma instalação do sistema de trânsito, um leitor de trânsito 220 lê dados do FIPPD 130. Outros dados para os dados de transação de trânsito pedidos também podem ser obtidos.
No terminal de POS, na etapa 716, o dispositivo/cartão de pagamento pode ser lido por um leitor de cartão de chip (isto é, um leitor por contato ou sem contato). Aqui, o dados de pagamento são lidos do dispositivo/cartão de pagamento para ordenar a transação de pagamento, e o terminal de POS também lê os dados de assinatura de dispositivo/cartão de pagamento. A assinatura, assim lida, pode ser então usada no processo de listagem negativa tal como foi descrito acima, incluindo na descrição de processo 600 na Figura 6. Em tal processo, a lista, branca, negativa, ou outra, é assim obscurecida aos dados de pagamento no dispositivo/cartão de pagamento de forma que seja provida segurança para titular de conta e estabelecimento comercial como a minimização de transações fraudulentas.
Deveria ser entendido que a presente invenção pode ser implementada na forma de lógica de controle, de uma maneira modular ou integrada, usando software, hardware ou uma combinação de ambos. Baseado 5 na exposição e ensinamentos providos aqui, uma pessoa de habilidade ordinária na técnica apreciará outros modos e/ou métodos para implementar a presente invenção.
r
E compreendido que os exemplos e concretizações descritas aqui são para propósitos ilustrativos somente e que várias modificações ou . 10 mudanças em vista disso serão sugeridas às pessoas qualificadas na técnica e são para serem incluídas dentro do espírito e esfera deste pedido e extensão das reivindicações anexas.

Claims (44)

1. Método, caracterizado pelo fato de compreender: Ier dados a um terminal de ponto de serviço (POS) a um estabelecimento comercial, em que: um dispositivo de pagamento é apresentado ao terminal de POS por um consumidor buscando conduzir uma transação para um bem ou serviço do estabelecimento comercial; o dispositivo de pagamento inclui um Número de Conta Primário (PAN) emitido por um emissor; e os dados lidos do dispositivo de pagamento incluem uma assinatura de não PAN que corresponde ao PAN; verificar uma lista de assinaturas de não PAN mantida pelo terminal de POS para determinar se a assinatura de não PAN lida dos dados no dispositivo de pagamento está na lista; e permitir, na base se a assinatura de não PAN está na lista, ao consumidor completar a transação com o estabelecimento comercial.
2. Método de acordo com a reivindicação 1, caracterizado pelo fato de que a assinatura de não PAN é criada pelo emissor usando pelo menos um de: uma ou mais chaves de criptografia; e um algoritmo predeterminado.
3. Método de acordo com a reivindicação 2, caracterizado pelo fato de que pelo menos uma dita chave de criptografia é um tipo selecionado do grupo consistindo em um tipo simétrico e um tipo assimétrico.
4. Método de acordo com a reivindicação 3, caracterizado pelo fato de que o tipo assimétrico é uma infra-estrutura de chave pública.
5. Método de acordo com a reivindicação 2, caracterizado pelo fato de que o algoritmo predeterminado produz um resultado selecionado do grupo consistindo em um sinal numérico, um certificado, uma assinatura utilizando dados armazenados no dispositivo de pagamento que são únicos àquele dispositivo de pagamento.
6. Método de acordo com a reivindicação 2, caracterizado pelo fato de que o algoritmo predeterminado inclui uma ou mais variáveis cada uma das quais é selecionada do grupo consistindo no nome de um titular de conta correspondendo ao dispositivo de pagamento, uma PAN parcial, dados de expiração do dispositivo de pagamento, e um código de serviço do sistema de processamento de pagamento que corresponde ao PAN do dispositivo de pagamento.
7. Método de acordo com a reivindicação 6, caracterizado pelo fato de que a uma ou mais variáveis são armazenadas no dispositivo de pagamento em campos de dados de Trilha 1 e/ou Trilha 2 de acordo com uma configuração de dados de faixa magnética (MSD).
8. Método de acordo com a reivindicação 1, caracterizado pelo fato de que a assinatura de não PAN é estática no dispositivo de pagamento.
9. Método de acordo com a reivindicação 1, caracterizado pelo fato de que Ier dados adicionalmente inclui armazenar informação para cada dita transação.
10. Método de acordo com a reivindicação 9, caracterizado pelo fato de que a informação armazenada para cada dita transação inclui a data e hora disso, uma identificação do terminal de POS do estabelecimento comercial, e pelo menos alguns dos dados lidos de uma região de armazenamento de dados do dispositivo de pagamento.
11. Método de acordo com a reivindicação 10, caracterizado pelo fato de que os dados lidos da região de armazenamento de dados do dispositivo de pagamento são armazenados em um formato selecionado do grupo consistindo em: tanto campos de dados de Trilha 1 ou Trilha 2 do dispositivo de pagamento de acordo com uma configuração de dados de faixa magnética (MSD); e uma trilha de dados que é compatível com o sistema de processamento de pagamento que processa dados de acordo com uma configuração de dados de faixa magnética (MSD).
12. Método de acordo com a reivindicação 10, caracterizado pelo fato de que os dados lidos da região de armazenamento de dados do dispositivo de pagamento são lidos sem contato.
13. Método de acordo com a reivindicação 1, caracterizado pelo fato de que o dispositivo de pagamento é selecionado do grupo consistindo em um cartão de crédito, um cartão de débito, um cartão de valor armazenado, um dispositivo de pagamento sem contato, e combinações disso.
14. Método de acordo com a reivindicação 1, caracterizado pelo fato de que o dispositivo de pagamento está dentro de um dispositivo móvel selecionado do grupo consistindo em um assistente digital pessoal, um telefone sem fio, e um sistema inteligente incluindo um substrato tendo embutido nele um elemento sem contato incluindo um chip capaz de uso como um mecanismo de pagamento de transação para cada dita transação de acesso.
15. Método de acordo com a reivindicação 1, caracterizado pelo fato de que a leitura, a verificação, e a permissão são todos executados dentro de um período de tempo não excedendo um (1) segundo.
16. Meio legível por computador, caracterizado pelo fato de incluir instruções que, quando executadas por um computador, executa o método como definido na reivindicação 1.
17. Método, caracterizado pelo fato de compreender: Ier dados a um leitor de sistema de trânsito em um sistema de trânsito, em que: um dispositivo de pagamento é apresentado ao leitor de sistema de trânsito por um passageiro buscando conduzir uma transação de acesso para acesso a uma instalação do sistema de trânsito; e o dispositivo de pagamento inclui um Número de Conta Primário (PAN) emitido por um emissor em um sistema de processamento de pagamento; e os dados lidos do dispositivo de pagamento incluem código de criptografia; e sem descriptografar o código de criptografia: verificar, no leitor de sistema de trânsito, uma lista de outros ditos códigos de criptografia para determinar se o código de criptografia está na lista; e permitir, na base se o código de criptografia está na lista, o acesso de passageiro à instalação do sistema de trânsito.
18. Método de acordo com a reivindicação 17, caracterizado pelo fato de que o código de criptografia que corresponde exclusivamente ao dispositivo de pagamento é criado pelo emissor usando: uma ou mais chaves de criptografia; e um algoritmo predeterminado.
19. Método de acordo com a reivindicação 18, caracterizado pelo fato de que pelo menos uma dita chave de criptografia é um tipo selecionado do grupo consistindo em um tipo simétrico e um tipo assimétrico.
20. Método de acordo com a reivindicação 19, caracterizado pelo fato de que o tipo assimétrico é uma infra-estrutura de chave pública.
21. Método de acordo com a reivindicação 18, caracterizado pelo fato de que o algoritmo predeterminado produz um resultado selecionado do grupo consistindo em um sinal numérico, um certificado, uma assinatura utilizando dados armazenados no dispositivo de pagamento que são únicos àquele dispositivo de pagamento.
22. Método de acordo com a reivindicação 18, caracterizado pelo fato de que o algoritmo predeterminado inclui uma ou mais variáveis cada uma das quais é selecionada do grupo consistindo no nome de um titular de cartão correspondendo ao dispositivo de pagamento, um PAN parcial, dados de expiração do dispositivo de pagamento, e um código de serviço do dispositivo de pagamento.
23. Método de acordo com a reivindicação 22, caracterizado pelo fato de que a uma ou mais variáveis são armazenadas no dispositivo de pagamento em campos de dados de Trilha 1 e/ou Trilha 2 do dispositivo de pagamento de acordo com uma configuração de dados de faixa magnética (MSD).
24. Método de acordo com a reivindicação 17, caracterizado pelo fato de que o código de criptografia lido do dispositivo de pagamento é estático no dispositivo de pagamento.
25. Método de acordo com a reivindicação 17, caracterizado pelo fato de que Ier dados adicionalmente inclui armazenar informação para cada dita transação de acesso.
26. Método de acordo com a reivindicação 25, caracterizado pelo fato de que a informação armazenada para cada dita transação de acesso inclui a data e hora disso, uma identificação do terminal de POS no sistema de trânsito, e pelo menos alguns dos dados lidos de uma região de armazenamento de dados do dispositivo de pagamento.
27. Método de acordo com a reivindicação 17, caracterizado pelo fato de que os dados lidos do dispositivo de pagamento são armazenados em um formato selecionado do grupo consistindo em: tanto campos de dados de Trilha 1 ou Trilha 2 do dispositivo de pagamento de acordo com uma configuração de dados de faixa magnética (MSD); e uma trilha de dados que é compatível com o sistema de processamento de pagamento que processa dados de acordo com uma configuração de dados de faixa magnética (MSD).
28. Método de acordo com a reivindicação 17, caracterizado pelo fato de que os dados são lidos sem contato de uma região de armazenamento de dados do dispositivo de pagamento.
29. Método de acordo com a reivindicação 17, caracterizado pelo fato de que o dispositivo de pagamento é selecionado do grupo consistindo em um cartão de crédito, um cartão de débito, um cartão de valor armazenado, um dispositivo de pagamento sem contato, e combinações disso.
30. Método de acordo com a reivindicação 17, caracterizado pelo fato de que o dispositivo de pagamento está dentro de um dispositivo móvel selecionado do grupo consistindo em um assistente digital pessoal, um telefone sem fio, e um sistema inteligente incluindo um substrato tendo embutido nele um elemento sem contato incluindo um chip capaz de uso como um mecanismo de pagamento de transação para cada dita transação de acesso.
31. Método de acordo com a reivindicação 17, caracterizado pelo fato de que a leitura, a verificação, e a permissão são todos executados dentro de um período de tempo não excedendo um (1) segundo.
32. Meio legível por computador, caracterizado pelo fato de incluir instruções que, quando executadas por um computador, executa o método como definido na reivindicação 17.
33. Método, caracterizado pelo fato de compreender: Ier dados a um leitor de trânsito em um sistema de trânsito, em que: um dispositivo de pagamento é apresentado ao leitor de sistema de trânsito por um passageiro buscando conduzir uma transação de acesso para acesso a uma instalação do sistema de trânsito; os dados estão nos campos de dados de Trilha 1 e/ou Trilha 2 de acordo com uma configuração de Dados de Faixa Magnética (MSD); o dispositivo de pagamento inclui um Número de Conta Primário (PAN) emitido por um emissor em um sistema de processamento de pagamento; e os dados lidos do dispositivo de pagamento incluem código de criptografia que: corresponde exclusivamente ao dispositivo de pagamento; é criado pelo emissor usando pelo menos uma de: uma ou mais chaves de criptografia; e um algoritmo predeterminado; verificar, no leitor de sistema de trânsito, uma lista de outros . IO ditos códigos de criptografia para determinar se o código de criptografia está na lista; e permitir, sem descriptografar o código de criptografia, o acesso de passageiro à instalação do sistema de trânsito na base se o código de criptografia está na lista.
34. Método de acordo com a reivindicação 33, caracterizado pelo fato de que pelo menos uma dita chave de criptografia é um tipo selecionado do grupo consistindo em um tipo simétrico e um tipo assimétrico.
35. Método de acordo com a reivindicação 34, caracterizado pelo fato de que o tipo assimétrico é uma infra-estrutura de chave pública.
36. Método de acordo com a reivindicação 33, caracterizado pelo fato de que o algoritmo predeterminado produz um resultado selecionado do grupo consistindo em um sinal numérico, um certificado, uma assinatura utilizando dados armazenados no dispositivo de pagamento que são únicos àquele dispositivo de pagamento.
37. Método de acordo com a reivindicação 33, caracterizado pelo fato de que o algoritmo predeterminado inclui uma ou mais variáveis cada uma das quais é selecionada do grupo consistindo no nome de um titular de cartão correspondendo ao dispositivo de pagamento, um PAN parcial, dados de expiração do dispositivo de pagamento, e um código de serviço do dispositivo de pagamento.
38. Método de acordo com a reivindicação 33, caracterizado pelo fato de que Ier dados adicionalmente inclui armazenar informação para cada dita transação de acesso.
39. Método de acordo com a reivindicação 38, caracterizado pelo fato de que a informação armazenada para cada dita transação de acesso inclui a data e hora disso, uma identificação do terminal de POS no sistema de trânsito, e pelo menos alguns dos dados lidos de uma região de armazenamento de dados do dispositivo de pagamento.
40. Método de acordo com a reivindicação 33, caracterizado pelo fato de que os dados são lidos sem contato de uma região de armazenamento de dados do dispositivo de pagamento.
41. Método de acordo com a reivindicação 33, caracterizado pelo fato de que o dispositivo de pagamento é selecionado do grupo consistindo em um cartão de crédito, um cartão de débito, um cartão de valor armazenado, um dispositivo de pagamento sem contato, e combinações disso.
42. Método de acordo com a reivindicação 33, caracterizado pelo fato de que o dispositivo de pagamento está dentro de um dispositivo móvel selecionado do grupo consistindo em assistente digital pessoal, um telefone sem fio, e um sistema inteligente incluindo um substrato tendo embutido nele um elemento sem contato incluindo um chip capaz de uso como um mecanismo de pagamento de transação para cada dita transação de acesso.
43. Método de acordo com a reivindicação 33, caracterizado pelo fato de que a leitura, a verificação, e a permissão são todos executados dentro de um período de tempo não excedendo um (1) segundo.
44. Meio legível por computador, caracterizado pelo fato de incluir instruções que, quando executadas por um computador, executa o método como definido na reivindicação 33.
BRPI0721200-3A2A 2007-01-30 2007-10-29 Método, e, meio legível por computador BRPI0721200A2 (pt)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US88730707P 2007-01-30 2007-01-30
US60/887307 2007-01-30
US11/713,307 US7809652B2 (en) 2007-01-30 2007-03-01 Signature based negative list for off line payment device validation
US11/713307 2007-03-01
PCT/US2007/082903 WO2008094328A2 (en) 2007-01-30 2007-10-29 Signature based negative list for off line payment device validation

Publications (1)

Publication Number Publication Date
BRPI0721200A2 true BRPI0721200A2 (pt) 2014-03-18

Family

ID=39666820

Family Applications (3)

Application Number Title Priority Date Filing Date
BRPI0721132-5A2A BRPI0721132A2 (pt) 2007-01-30 2007-10-29 Método, e, meio legível por computador.
BRPI0721202-0A2A BRPI0721202A2 (pt) 2007-01-30 2007-10-29 Método
BRPI0721200-3A2A BRPI0721200A2 (pt) 2007-01-30 2007-10-29 Método, e, meio legível por computador

Family Applications Before (2)

Application Number Title Priority Date Filing Date
BRPI0721132-5A2A BRPI0721132A2 (pt) 2007-01-30 2007-10-29 Método, e, meio legível por computador.
BRPI0721202-0A2A BRPI0721202A2 (pt) 2007-01-30 2007-10-29 Método

Country Status (7)

Country Link
US (11) US7809652B2 (pt)
EP (2) EP2108178A1 (pt)
KR (3) KR20090119868A (pt)
AU (3) AU2007345585B2 (pt)
BR (3) BRPI0721132A2 (pt)
CA (3) CA2676619A1 (pt)
WO (5) WO2008094327A1 (pt)

Families Citing this family (183)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7333955B2 (en) 2001-09-24 2008-02-19 E2Interactive, Inc. System and method for securing communication service
US20060167720A1 (en) * 2004-11-19 2006-07-27 American Express Travel Related Services Company, Inc. Incentive Programs for Healthcare Cards
US20070011088A1 (en) * 2005-07-08 2007-01-11 American Express Company Assured Payments for Health Care Plans
US7922083B2 (en) * 2003-11-19 2011-04-12 Harrison Sarah E Payment programs for healthcare plans
US7905399B2 (en) * 2004-11-19 2011-03-15 Barnes Brian T Linking transaction cards with spending accounts
US20070194108A1 (en) * 2004-11-19 2007-08-23 American Express Travel Related Services Company, Inc. Assured Payments For Health Care Plans
US20100070409A1 (en) * 2004-11-19 2010-03-18 Harrison Sarah E Healthcare Card Incentive Program for Multiple Users
US7970626B2 (en) * 2005-07-08 2011-06-28 Oltine Acquistitions NY LLC Facilitating payments to health care providers
US8284929B2 (en) * 2006-09-14 2012-10-09 Uniloc Luxembourg S.A. System of dependant keys across multiple pieces of related scrambled information
US8881971B2 (en) * 2008-10-10 2014-11-11 Visa U.S.A. Inc. Transit agency as an issuer and/or program manager of prepaid products
US8763902B2 (en) * 2006-12-07 2014-07-01 Smart Systems Innovations, Llc Mass transit fare processing system
US8281990B2 (en) 2006-12-07 2012-10-09 Smart Systems Innovations, Llc Public transit system fare processor for transfers
US7809652B2 (en) 2007-01-30 2010-10-05 Visa U.S.A. Inc. Signature based negative list for off line payment device validation
US7949543B2 (en) 2007-02-13 2011-05-24 Oltine Acquisitions NY LLC Methods, systems, and computer program products for promoting healthcare information technologies to card members
US9846866B2 (en) * 2007-02-22 2017-12-19 First Data Corporation Processing of financial transactions using debit networks
US9292850B2 (en) * 2007-09-10 2016-03-22 Visa U.S.A. Inc. Host capture
US20090090770A1 (en) * 2007-10-08 2009-04-09 Sudipta Chakrabarti Combine identity token
US20090112767A1 (en) 2007-10-25 2009-04-30 Ayman Hammad Escrow system and method
US20090112766A1 (en) * 2007-10-25 2009-04-30 Ayman Hammad Device including multiple payment applications
US7567920B2 (en) * 2007-11-01 2009-07-28 Visa U.S.A. Inc. On-line authorization in access environment
US20090127332A1 (en) * 2007-11-16 2009-05-21 Kyung Yang Park System for processing payment employing off-line transaction approval mode of mobile card and method thereof
EP2232764A1 (en) * 2007-12-05 2010-09-29 Uniloc Usa, Inc. System and method for device bound public key infrastructure
US10296874B1 (en) * 2007-12-17 2019-05-21 American Express Travel Related Services Company, Inc. System and method for preventing unauthorized access to financial accounts
JP2009163595A (ja) * 2008-01-09 2009-07-23 Sony Corp 情報処理システム、情報処理装置、および情報処理方法、並びにコンピュータ・プログラム
US20090202081A1 (en) * 2008-02-08 2009-08-13 Ayman Hammad Key delivery system and method
US20090204525A1 (en) * 2008-02-13 2009-08-13 Simon Phillips Payment device to issuer communication via authorization request
US9596359B2 (en) * 2008-06-26 2017-03-14 Visa International Service Association Mobile communication device configured for transit application
US20090327135A1 (en) * 2008-06-26 2009-12-31 Loc Duc Nguyen Credit card paired with location identifiable device for point of service fraud detection
US8707319B2 (en) * 2008-06-26 2014-04-22 Visa International Service Association Resource location verification by comparing and updating resource location with a location of a consumer device after a threshold of location mismatches is exceeded
US8090650B2 (en) * 2008-07-24 2012-01-03 At&T Intellectual Property I, L.P. Secure payment service and system for interactive voice response (IVR) systems
US20100030670A1 (en) * 2008-08-04 2010-02-04 Mastercard International, Inc. Method of monitoring different debit card transactions associated with a single funding source
US8583495B2 (en) * 2008-10-09 2013-11-12 Invenstar, Llc Method and system for crediting multiple merchant accounts on a single bill
EP2469476A3 (en) * 2008-10-31 2014-08-20 Accenture Global Services Limited System for controlling user access to a service
US20100114723A1 (en) * 2008-11-05 2010-05-06 Appsware Wireless, Llc Method and system for providing a point of sale network within a lan
US20100115127A1 (en) * 2008-11-05 2010-05-06 Appsware Wireless, Llc Method and system for securing data from a non-point of sale device over a lan
US20100115599A1 (en) * 2008-11-05 2010-05-06 Appsware Wireless, Llc Method and system for securing data from a point of sale device over an external network
US8966610B2 (en) * 2008-11-05 2015-02-24 Apriva, Llc Method and system for securing data from a non-point of sale device over an external network
US20100115624A1 (en) * 2008-11-05 2010-05-06 Appsware Wireless, Llc Method and system for securing data from a point of sale device over a lan
US8732813B2 (en) * 2008-11-05 2014-05-20 Apriva, Llc Method and system for securing data from an external network to a non point of sale device
US20100115600A1 (en) * 2008-11-05 2010-05-06 Appsware Wireless, Llc Method and system for securing data from an external network to a point of sale device
US20100063945A1 (en) * 2008-11-12 2010-03-11 Cowan Jr William Curtis Systems and Methods Involving Processing of Payments Using Handheld Devices
EP2221733A1 (en) * 2009-02-17 2010-08-25 AMADEUS sas Method allowing validation in a production database of new entered data prior to their release
US20100214058A1 (en) * 2009-02-24 2010-08-26 Visa U.S.A. Inc. Security access method and system
US20100332400A1 (en) * 2009-06-24 2010-12-30 Craig Stephen Etchegoyen Use of Fingerprint with an On-Line or Networked Payment Authorization System
US10068282B2 (en) 2009-06-24 2018-09-04 Uniloc 2017 Llc System and method for preventing multiple online purchases
US9075958B2 (en) * 2009-06-24 2015-07-07 Uniloc Luxembourg S.A. Use of fingerprint with an on-line or networked auction
US20110166936A1 (en) * 2009-07-09 2011-07-07 Cubic Corporation Predictive techniques in transit alerting
US20110166914A1 (en) * 2009-07-09 2011-07-07 Cubic Corporation Reloadable prepaid card distribution, reload, and registration in transit
AU2010271243A1 (en) * 2009-07-09 2012-03-01 Cubic Corporation Proxy-based payment system
EP2452313B1 (en) 2009-07-09 2016-12-21 Cubic Corporation Transit account management with mobile device messaging
CN101989213B (zh) 2009-08-07 2016-06-29 阿里巴巴集团控股有限公司 账户并发处理方法及账户并发处理系统
WO2011031768A2 (en) * 2009-09-08 2011-03-17 Cubic Corporation Association of contactless payment card primary account number
US20120143763A1 (en) * 2009-10-28 2012-06-07 Alan Karp Using a financial institution based account for ultra-low latency transactions
US8655732B1 (en) * 2009-10-28 2014-02-18 Mark Edward Wilinski Liquid dispensation
US9240005B2 (en) * 2009-11-06 2016-01-19 Mastercard International, Incorporated Methods for risk management in payment-enabled mobile device
US20110137804A1 (en) 2009-12-03 2011-06-09 Recursion Software, Inc. System and method for approving transactions
GB2476233B (en) 2009-12-14 2018-05-23 Visa Europe Ltd Payment device
WO2011084648A2 (en) 2009-12-16 2011-07-14 Giftango Corporation Systems and methods for generating a virtual value item for a promotional campaign
CN101789946A (zh) * 2010-02-10 2010-07-28 福建三元达软件有限公司 一种支付终端通信线路的堵截方法
US9245267B2 (en) 2010-03-03 2016-01-26 Visa International Service Association Portable account number for consumer payment account
US10579995B2 (en) * 2010-03-30 2020-03-03 Visa International Service Association Event access with data field encryption for validation and access control
US20110288881A1 (en) * 2010-05-21 2011-11-24 Diversinet Corp. Method and System for Processing Healthcare Payments
US20120036076A1 (en) * 2010-08-06 2012-02-09 Jennifer Vanderwall Prepaid distribution application and device
AU2011293272B2 (en) * 2010-08-25 2015-02-19 Cubic Corporation Advanced decision logic for transit acceptance
US9031869B2 (en) 2010-10-13 2015-05-12 Gift Card Impressions, LLC Method and system for generating a teaser video associated with a personalized gift
US9483786B2 (en) 2011-10-13 2016-11-01 Gift Card Impressions, LLC Gift card ordering system and method
US8856024B2 (en) * 2010-10-26 2014-10-07 Cubic Corporation Determining companion and joint cards in transit
WO2012082795A1 (en) * 2010-12-13 2012-06-21 Magtek, Inc. Systems and methods for conducting contactless payments using a mobile and a magstripe payment card
US11978031B2 (en) 2010-12-14 2024-05-07 E2Interactive, Inc. Systems and methods that create a pseudo prescription from transaction data generated during a point of sale purchase at a front of a store
CA2726781A1 (en) * 2010-12-29 2012-06-29 Evgeny Lishak Methods of offline fare collection for open-loop and hybrid card systems
US10534931B2 (en) 2011-03-17 2020-01-14 Attachmate Corporation Systems, devices and methods for automatic detection and masking of private data
US8392259B2 (en) 2011-03-17 2013-03-05 Research In Motion Limited Methods and apparatus to obtain transaction confirmation
US8447693B2 (en) * 2011-04-13 2013-05-21 Citicorp Credit Services, Inc. Methods and systems for routing payment transactions
SG10201602608WA (en) * 2011-10-03 2016-05-30 Ezetap Mobile Solutions Private Ltd System and method for secure electronic transaction
US9544759B2 (en) 2011-11-01 2017-01-10 Google Inc. Systems, methods, and computer program products for managing states
CA2854276C (en) 2011-11-01 2019-01-29 Jvl Ventures, Llc Systems, methods, and computer program products for interfacing multiple service provider trusted service managers and secure elements
US8842840B2 (en) 2011-11-03 2014-09-23 Arvind Gidwani Demand based encryption and key generation and distribution systems and methods
US20130151318A1 (en) * 2011-12-13 2013-06-13 Boku, Inc. Transit billing network
US9111301B2 (en) 2011-12-13 2015-08-18 Boku, Inc. Activating an account based on an SMS message
US8630954B2 (en) 2011-12-15 2014-01-14 Visa International Service Association System and method of using load network to associate product or service with a consumer token
US9053481B2 (en) 2011-12-21 2015-06-09 Mastercard International Incorporated Methods and systems for providing a payment account with adaptive interchange
US10417677B2 (en) 2012-01-30 2019-09-17 Gift Card Impressions, LLC Group video generating system
US8630904B2 (en) 2012-02-14 2014-01-14 Boku, Inc. Transaction authentication with a variable-type user-stored account identifier
CN103003831B (zh) * 2012-02-14 2015-07-08 张龙其 一种智能卡支付系统
WO2013169926A1 (en) * 2012-05-08 2013-11-14 Visa International Service Association, Inc. System and method for authentication using payment protocol
US20140012704A1 (en) 2012-07-05 2014-01-09 Google Inc. Selecting a preferred payment instrument based on a merchant category
US10496977B2 (en) 2012-07-16 2019-12-03 Square, Inc. Storing and forwarding payment transactions
US11507950B2 (en) * 2012-07-31 2022-11-22 Worldpay, Llc Systems and methods for secure normative intermediation of payments processing peripherals
US8676709B2 (en) 2012-07-31 2014-03-18 Google Inc. Merchant category codes in a proxy card transaction
US11055686B2 (en) * 2012-08-08 2021-07-06 E2Interactive, Inc. S/M for providing, reloading, and redeeming stored value cards used in transit applications
US9569769B2 (en) 2012-09-17 2017-02-14 E2Interactive, Inc. Composite activation indicia substrate
JP6072907B2 (ja) 2012-09-18 2017-02-01 グーグル インコーポレイテッド 複数のサービスプロバイダのトラステッドサービスマネジャーとセキュアエレメントとをインターフェース接続するためのシステム、方法、およびコンピュータプログラム製品
CA2799055A1 (en) * 2012-12-14 2014-06-14 Caledon Computer Systems Inc. Apparatus configured to facilitate secure financial transactions
KR101438199B1 (ko) * 2013-01-09 2014-09-11 주식회사 엘지씨엔에스 교통 요금 관리 방법, 이를 수행하는 교통 요금 관리 서버 및 이를 수행하는 교통 요금 관리 시스템
DE102013201027A1 (de) * 2013-01-23 2014-07-24 Bundesdruckerei Gmbh Verfahren zur Authentisierung eines Nutzers gegenüber einem Automat
US11219288B2 (en) 2013-02-15 2022-01-11 E2Interactive, Inc. Gift card box with slanted tray and slit
US9565911B2 (en) 2013-02-15 2017-02-14 Gift Card Impressions, LLC Gift card presentation devices
US9092767B1 (en) 2013-03-04 2015-07-28 Google Inc. Selecting a preferred payment instrument
US9911110B2 (en) 2013-03-05 2018-03-06 Square, Inc. Predicting approval of transactions
WO2014152419A1 (en) * 2013-03-15 2014-09-25 Mastercard International Incorporated Transaction-history driven counterfeit fraud risk management solution
US20140289023A1 (en) * 2013-03-21 2014-09-25 Cubic Corporation Local fare processing
US10217107B2 (en) 2013-05-02 2019-02-26 Gift Card Impressions, LLC Stored value card kiosk system and method
CN105163650B (zh) * 2013-05-03 2018-12-07 飞利浦照明控股有限公司 具有经适配的光谱输出的光源
EP2819082A1 (en) * 2013-06-26 2014-12-31 Entersekt (Pty) Ltd Batch transaction authorisation
US11138605B2 (en) * 2013-07-02 2021-10-05 Visa International Service Association Online authentication in access transactions
US9972013B2 (en) * 2013-08-15 2018-05-15 Mastercard International Incorporated Internet site authentication with payments authorization data
CN105493112A (zh) * 2013-08-20 2016-04-13 慧与发展有限责任合伙企业 利用支付联合服务的销售点设备
US20150058134A1 (en) * 2013-08-23 2015-02-26 Capital One Financial Corporation Systems, methods, and articles of manufacture for targeted marketing via improved card embossing
KR101536580B1 (ko) * 2013-08-27 2015-07-15 삼성에스디에스 주식회사 요금 지불 방법 및 그 장치
KR20150029180A (ko) * 2013-09-09 2015-03-18 주식회사 엘지씨엔에스 개방형 운임 처리 방법 및 시스템
US11120462B2 (en) 2013-11-04 2021-09-14 E2Interactive, Inc. Systems and methods for using indicia of membership as a partial authorization in a transaction
US20150142515A1 (en) * 2013-11-20 2015-05-21 Mastercard International Incorporated Methods, systems and computer readable media for determining a relational strength index associated with a plurality of merchant entities
US10002388B2 (en) * 2013-12-31 2018-06-19 Nyse Group, Inc. Risk mitigation in an electronic trading system
CN104765999B (zh) * 2014-01-07 2020-06-30 腾讯科技（深圳）有限公司 一种对用户资源信息进行处理的方法、终端及服务器
AU2015210796A1 (en) * 2014-01-31 2016-08-04 Cubic Corporation Passenger behaviour rating for improved risk management in transit systems
US9858572B2 (en) 2014-02-06 2018-01-02 Google Llc Dynamic alteration of track data
KR101909361B1 (ko) * 2014-02-24 2018-10-17 소니 주식회사 주의력 레벨 및 작업부하 감지를 갖춘 스마트 착용형 디바이스들 및 방법들
US9065824B1 (en) * 2014-03-17 2015-06-23 Google Inc. Remote authorization of access to account data
GB2524282A (en) * 2014-03-19 2015-09-23 Mastercard International Inc Automatic data transfer
GB2524283A (en) 2014-03-19 2015-09-23 Mastercard International Inc Transport system user inspection
US10262346B2 (en) 2014-04-30 2019-04-16 Gift Card Impressions, Inc. System and method for a merchant onsite personalization gifting platform
WO2015191587A2 (en) * 2014-06-09 2015-12-17 Cubic Corporation Customer authentication based on action the user has done within a transit system
US20160012426A1 (en) * 2014-07-11 2016-01-14 Google Inc. Hands-free transactions with a challenge and response
EP2975581A1 (en) * 2014-07-16 2016-01-20 SPX Corporation Transit authority fare administration and management system
GB2530304A (en) * 2014-09-18 2016-03-23 Mastercard International Inc Trust management in transaction systems
US10262316B2 (en) 2014-09-23 2019-04-16 Sony Corporation Automatic notification of transaction by bank card to customer device
US9378502B2 (en) 2014-09-23 2016-06-28 Sony Corporation Using biometrics to recover password in customer mobile device
US9317847B2 (en) 2014-09-23 2016-04-19 Sony Corporation E-card transaction authorization based on geographic location
US9292875B1 (en) 2014-09-23 2016-03-22 Sony Corporation Using CE device record of E-card transactions to reconcile bank record
US9646307B2 (en) 2014-09-23 2017-05-09 Sony Corporation Receiving fingerprints through touch screen of CE device
US9953323B2 (en) 2014-09-23 2018-04-24 Sony Corporation Limiting e-card transactions based on lack of proximity to associated CE device
US9558488B2 (en) 2014-09-23 2017-01-31 Sony Corporation Customer's CE device interrogating customer's e-card for transaction information
US9367845B2 (en) 2014-09-23 2016-06-14 Sony Corporation Messaging customer mobile device when electronic bank card used
US9355424B2 (en) * 2014-09-23 2016-05-31 Sony Corporation Analyzing hack attempts of E-cards
CA2966553A1 (en) * 2014-12-04 2016-06-09 Cubic Corporation Credit and debit fraud card usage monitoring for transit
US10496974B2 (en) * 2015-03-25 2019-12-03 Intel Corporation Secure transactions with connected peripherals
US10152714B2 (en) * 2015-04-29 2018-12-11 Capital One Services, LLP System to automatically restore payment purchasing power
MA42077B1 (fr) * 2015-09-09 2019-10-31 Cpg Technologies Llc Dispositifs médicaux internes électriques avec ondes de surface guidée
US10453059B2 (en) 2015-09-30 2019-10-22 Bank Of America Corporation Non-intrusive geo-location determination associated with transaction authorization
US10607215B2 (en) 2015-09-30 2020-03-31 Bank Of America Corporation Account tokenization for virtual currency resources
SG10201508641VA (en) * 2015-10-19 2017-05-30 Mastercard Asia Pacific Pte Ltd Method And System For Managing Payment Transactions
SE540544C2 (sv) * 2015-10-30 2018-09-25 Id Loop Ab Förfarande för betalning med kontantkort
CN106910063B (zh) * 2015-12-22 2020-10-27 卓望数码技术（深圳）有限公司 一种线下支付方法及系统
US20170200149A1 (en) * 2016-01-08 2017-07-13 Mastercard International Incorporated Authenticating payment credentials in closed loop transaction processing
CN106997530B (zh) * 2016-01-25 2022-10-14 创新先进技术有限公司 基于移动终端卡模拟的信用支付方法及装置
CN106997527A (zh) 2016-01-25 2017-08-01 阿里巴巴集团控股有限公司 基于移动终端p2p的信用支付方法及装置
US10127557B2 (en) 2016-03-25 2018-11-13 Accenture Global Solutions Limited Dynamic offline card authorization
US10410204B2 (en) * 2016-03-25 2019-09-10 Accenture Global Solutions Limited Dynamic offline card authorization
CN109416790A (zh) * 2016-06-29 2019-03-01 维萨国际服务协会 用于过境处理的方法和系统
US10366378B1 (en) 2016-06-30 2019-07-30 Square, Inc. Processing transactions in offline mode
CN106327186A (zh) * 2016-08-31 2017-01-11 中城智慧科技有限公司 一种基于nfc的离线支付方法
US11144928B2 (en) * 2016-09-19 2021-10-12 Early Warning Services, Llc Authentication and fraud prevention in provisioning a mobile wallet
US10671983B2 (en) 2016-11-02 2020-06-02 Mastercard International Incorporated Computer message routing and processing system and method
US10971010B2 (en) * 2016-11-15 2021-04-06 Mastercard International Incorporated Tracking system, method and medium for enhancing the use of select transit
CN107038562A (zh) * 2017-03-13 2017-08-11 阿里巴巴集团控股有限公司 交通分段计费的支付方法、计费系统和支付系统
CN106911473A (zh) * 2017-03-13 2017-06-30 成都育芽科技有限公司 一种基于云数据处理平台的金融移动支付密码发型器
CN107133792B (zh) * 2017-04-20 2020-11-06 王�华 一种利用移动终端支付的地铁支付系统及支付方法
US20190065999A1 (en) * 2017-08-30 2019-02-28 Cubic Corporation Pre-processing of transit transactions using virtual access to machine functionality
US10650382B2 (en) * 2017-09-05 2020-05-12 Nsure.Ai Payment Assurance Ltd. Systems and methods for detecting fraudulent use of a serial code for accessing an associated value stored on a network
CN107730253B (zh) * 2017-09-15 2020-08-07 飞天诚信科技股份有限公司 一种脱机交易时效管理方法及装置
CN107944857A (zh) 2017-10-31 2018-04-20 阿里巴巴集团控股有限公司 一种支付乘车费的方法及装置
US10954049B2 (en) 2017-12-12 2021-03-23 E2Interactive, Inc. Viscous liquid vessel for gifting
US11227318B2 (en) * 2018-02-01 2022-01-18 Capital One Services, Llc Systems and methods for authenticated delivery by unmanned vehicle (UV)
CN110119942A (zh) * 2018-02-07 2019-08-13 上海复旦微电子集团股份有限公司 公交ic卡联机交易方法及装置、计算机可读存储介质
US11119989B1 (en) 2018-06-14 2021-09-14 Amazon Technologies, Inc. Data aggregation with schema enforcement
US11410153B1 (en) * 2018-07-31 2022-08-09 Block, Inc. Enrolling mobile-payment customers after online transactions
CN109919607A (zh) * 2018-11-23 2019-06-21 阿里巴巴集团控股有限公司 基于离线乘车码的换乘优惠方法及装置和电子设备
CN110245940B (zh) * 2019-03-08 2021-07-06 腾讯科技（深圳）有限公司 数字资产凭证继承转移中的信息处理方法、和相关装置
CN109978033B (zh) * 2019-03-15 2020-08-04 第四范式（北京）技术有限公司 同操作人识别模型的构建与同操作人识别的方法和装置
US11544706B2 (en) * 2019-04-26 2023-01-03 Discover Financial Services Multi-token provisioning, online purchase transaction processing, and card life cycle management systems and methods
SG11202112238VA (en) * 2019-05-09 2021-12-30 Tendyron Corp Electronic currency offline payment method and payment collection method
US11348108B2 (en) * 2019-05-29 2022-05-31 Advanced New Technologies Co., Ltd. Payment proof generation method and system, and device
EP3983987A4 (en) * 2019-06-13 2023-06-21 Baker Hughes Oilfield Operations LLC ORDERING COMPONENTS OF AN OPERATION BY MEANS OF A PROCESSING SYSTEM
US11308498B2 (en) * 2019-07-15 2022-04-19 Visa International Service Association Real-time risk based payment decision service for transit system
CN115136172A (zh) * 2019-12-09 2022-09-30 维萨国际服务协会 用于使用虚拟卡实时确定商家位置的计算机实施的方法
US20220294639A1 (en) * 2021-03-15 2022-09-15 Synamedia Limited Home context-aware authentication
US20220374896A1 (en) * 2021-05-18 2022-11-24 Mastercard Asia/Pacific Pte Ltd. Identity, Payment and Access Control System
US20220391882A1 (en) * 2021-06-08 2022-12-08 Phillip Graves Systems and methods for providing, reloading, and redeeming stored value cards used in transit applications
US20230059546A1 (en) * 2021-08-17 2023-02-23 Mastercard Asia/Pacific Pte. Ltd. Access Control System
WO2023034437A1 (en) * 2021-09-03 2023-03-09 Worldpay, Llc Systems and methods for data aggregation for transaction settlements
US20230070215A1 (en) * 2021-09-03 2023-03-09 Worldpay, Llc Systems and methods for managing payment transactions between registered users and merchants
US20230073140A1 (en) * 2021-09-03 2023-03-09 Worldpay, Llc Systems and methods for data aggregation for transaction settlement
US11934892B2 (en) * 2022-06-07 2024-03-19 Synchrony Bank Global account identifier translation

Family Cites Families (75)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5043561A (en) * 1988-09-28 1991-08-27 Kabushiki Kaisha Toshiba Fare collection system using a boarding ticket and additional money card
TW226464B (pt) * 1992-12-29 1994-07-11 Ibm
US5801943A (en) * 1993-07-23 1998-09-01 Condition Monitoring Systems Traffic surveillance and simulation apparatus
US5485520A (en) 1993-10-07 1996-01-16 Amtech Corporation Automatic real-time highway toll collection from moving vehicles
US6097292A (en) * 1997-04-01 2000-08-01 Cubic Corporation Contactless proximity automated data collection system and method
US5897621A (en) * 1996-06-14 1999-04-27 Cybercash, Inc. System and method for multi-currency transactions
JPH1018808A (ja) 1996-07-03 1998-01-20 Hitachi Ltd 再熱蒸気タービンの加熱蒸気制御装置
US5991749A (en) * 1996-09-11 1999-11-23 Morrill, Jr.; Paul H. Wireless telephony for collecting tolls, conducting financial transactions, and authorizing other activities
JP3805847B2 (ja) 1996-12-26 2006-08-09 株式会社東芝 料金後払いシステムおよび料金後払いシステムの運賃処理方法
US6078888A (en) * 1997-07-16 2000-06-20 Gilbarco Inc. Cryptography security for remote dispenser transactions
FR2783336B1 (fr) 1998-09-11 2001-10-12 Schlumberger Ind Sa Procede de transmission de donnees et carte pour une telle transmission
US6648222B2 (en) 1999-06-02 2003-11-18 Mcdonald Ian Internet-based zero intrinsic value smart card with value data accessed in real time from remote database
US6577229B1 (en) * 1999-06-10 2003-06-10 Cubic Corporation Multiple protocol smart card communication device
US6792536B1 (en) * 1999-10-20 2004-09-14 Timecertain Llc Smart card system and methods for proving dates in digital files
US7213755B2 (en) * 1999-10-21 2007-05-08 Cubic Corporation System for rapidly dispensing and adding value to fare cards
US20060178986A1 (en) * 2000-02-17 2006-08-10 Giordano Joseph A System and method for processing financial transactions using multi-payment preferences
KR100645232B1 (ko) 2000-03-29 2006-11-13 조인호 교통 및 통신 요금 통합 청구시스템
US20020046173A1 (en) * 2000-05-19 2002-04-18 Kelly Stephen J. Method, apparatus and system to facilitate delivery of goods and services to secure locations
US6609655B1 (en) * 2000-06-26 2003-08-26 Martha F. Harrell Smart card system for providing financial, travel, and entertainment-related services
JP3468744B2 (ja) * 2000-09-06 2003-11-17 株式会社鷹山 交通料金自動精算システム
HU224093B1 (hu) * 2000-11-20 2005-05-30 András Vilmos Eljárás eladó és vevő közötti üzletkötés pénzügyi teljesítésének megbízható előkészítésére és végrehajtására
US6993507B2 (en) * 2000-12-14 2006-01-31 Pacific Payment Systems, Inc. Bar coded bill payment system and method
US20020078152A1 (en) * 2000-12-19 2002-06-20 Barry Boone Method and apparatus for providing predefined feedback
US6629591B1 (en) 2001-01-12 2003-10-07 Igt Smart token
US6871784B2 (en) * 2001-02-07 2005-03-29 Trijay Technologies International Corporation Security in mag-stripe card transactions
US7124118B2 (en) * 2001-02-20 2006-10-17 Cubic Corporation Transit best fare system and method
US6655587B2 (en) 2001-03-21 2003-12-02 Cubic Corporation Customer administered autoload
US7117183B2 (en) 2001-03-31 2006-10-03 First Data Coroporation Airline ticket payment and reservation system and methods
IL159028A0 (en) 2001-05-25 2004-05-12 Gerald R Black Security access system
RO123631B1 (ro) 2001-06-29 2015-03-30 Upaid Systems Ltd. Metodă şi sistem de furnizare de servicii de comerţ mobil printr-o multitudine de comunicaţii convergente
JP2003058919A (ja) 2001-08-03 2003-02-28 J Sukina James 運賃請求システム
US20030036997A1 (en) * 2001-08-14 2003-02-20 Internet Billing Company, Ltd. System and method for fraud prevention in automated electronic payment processing
US20030156740A1 (en) * 2001-10-31 2003-08-21 Cross Match Technologies, Inc. Personal identification device using bi-directional authorization for access control
US7061383B2 (en) * 2001-11-15 2006-06-13 United Air Lines, Inc. Radio frequency check-in
AU2002351573A1 (en) * 2001-12-12 2003-07-09 Paradata Systems Inc. Global integrated payment system
US7653927B1 (en) * 2001-12-21 2010-01-26 Keen Personal Media, Inc. System and method for selecting a pay per view program to be transmitted to a program receiver
US20040210498A1 (en) * 2002-03-29 2004-10-21 Bank One, National Association Method and system for performing purchase and other transactions using tokens with multiple chips
EP2290730B1 (en) * 2002-04-24 2013-08-21 SK Planet Co., Ltd. Battery pack for a mobile terminal
DE10224209B4 (de) 2002-05-31 2004-09-23 Infineon Technologies Ag Autorisierungseinrichtung-Sicherheitsmodul-Terminal-System
US7587756B2 (en) * 2002-07-09 2009-09-08 American Express Travel Related Services Company, Inc. Methods and apparatus for a secure proximity integrated circuit card transactions
JP3957062B2 (ja) 2002-07-09 2007-08-08 株式会社リコー 旅行支援システム
US7069244B2 (en) * 2002-09-17 2006-06-27 First Data Corporation Method and system for merchant processing of purchase card transactions with expanded card type acceptance
US20040103057A1 (en) * 2002-11-26 2004-05-27 Worldpass Corporation System and method for processing a long distance communication using a debit account
US7092697B1 (en) * 2003-01-06 2006-08-15 Cellco Partnership Method and system for reduced-latency prepaid mobile messaging
US20040193460A1 (en) * 2003-03-28 2004-09-30 Jean-Francois Ducholet System and method for structuring contract performance terms
US7689483B2 (en) * 2003-05-20 2010-03-30 Amegy Bank of Texas System to facilitate payments for a customer through a foreign bank, software, business methods, and other related methods
WO2005004069A1 (es) * 2003-07-02 2005-01-13 Mobipay International, S.A. Sistema de transacciones y pagos mediante teléfono móvil digital
US7273168B2 (en) * 2003-10-10 2007-09-25 Xilidev, Inc. Point-of-sale billing via hand-held devices
US7661586B2 (en) * 2003-10-30 2010-02-16 Datapath, Inc. System and method for providing a credit card with back-end payment filtering
US20050192815A1 (en) 2004-02-27 2005-09-01 Clyde Stuart M. Display rights management system
US8407097B2 (en) * 2004-04-15 2013-03-26 Hand Held Products, Inc. Proximity transaction apparatus and methods of use thereof
JP4610240B2 (ja) 2004-06-24 2011-01-12 富士通株式会社 分析プログラム、分析方法及び分析装置
US7124937B2 (en) * 2005-01-21 2006-10-24 Visa U.S.A. Inc. Wireless payment methods and systems
US7367494B2 (en) * 2005-03-08 2008-05-06 Cubic Corporation Automatic integrated sensing and access control
US7562304B2 (en) * 2005-05-03 2009-07-14 Mcafee, Inc. Indicating website reputations during website manipulation of user information
CA2608707A1 (en) * 2005-05-16 2006-11-23 Mastercard International Incorporated Method and system for using contactless payment cards in a transit system
WO2006135779A2 (en) * 2005-06-10 2006-12-21 American Express Travel Related Services Company, Inc. System and method for mass transit merchant payment
US7374082B2 (en) * 2005-07-13 2008-05-20 Mastercard International Incorporated Apparatus and method for integrated payment and electronic merchandise transfer
JP2007052720A (ja) * 2005-08-19 2007-03-01 Fujitsu Ltd 生体認証による情報アクセス方法及び生体認証による情報処理システム
JP4876516B2 (ja) * 2005-09-30 2012-02-15 富士ゼロックス株式会社 入退室管理システム、及びその制御方法
FR2891639B1 (fr) * 2005-10-04 2007-11-30 Atmel Corp Moyen pour desactiver un dispositif sans contact.
US7657486B2 (en) * 2005-12-09 2010-02-02 Mastercard International Incorporated Techniques for co-existence of multiple stored value applications on a single payment device managing a shared balance
US8019365B2 (en) * 2005-12-31 2011-09-13 Michelle Fisher Conducting a payment using a secure element and SMS
US7996271B2 (en) * 2006-01-27 2011-08-09 International Business Machines Corporation Blocking orders during order processing
US8249965B2 (en) * 2006-03-30 2012-08-21 Obopay, Inc. Member-supported mobile payment system
US7617977B2 (en) * 2006-06-13 2009-11-17 Taxi 2000 Corporation Ticketing system for personal rapid transit
US9177314B2 (en) 2006-08-14 2015-11-03 Chijioke Chukwuemeka UZO Method of making secure electronic payments using communications devices and biometric data
US7527208B2 (en) 2006-12-04 2009-05-05 Visa U.S.A. Inc. Bank issued contactless payment card used in transit fare collection
US7566003B2 (en) * 2006-12-07 2009-07-28 Specialty Acquirer Llc Learning fare collection system for mass transit
US8281990B2 (en) * 2006-12-07 2012-10-09 Smart Systems Innovations, Llc Public transit system fare processor for transfers
US7568617B2 (en) * 2006-12-07 2009-08-04 Specialty Acquirer Llc Learning fare collection system for mass transit
US7809652B2 (en) 2007-01-30 2010-10-05 Visa U.S.A. Inc. Signature based negative list for off line payment device validation
US8762211B2 (en) * 2007-10-03 2014-06-24 Mastercard International Incorporated System for personalized payments via mobile devices
US7567920B2 (en) * 2007-11-01 2009-07-28 Visa U.S.A. Inc. On-line authorization in access environment
US9569912B2 (en) * 2008-06-26 2017-02-14 Shopatm Bv (Sarl) Article storage and retrieval apparatus and vending machine

Also Published As

Publication number Publication date
US20180349907A1 (en) 2018-12-06
WO2008094326A1 (en) 2008-08-07
AU2007345580A1 (en) 2008-08-07
CA2676619A1 (en) 2008-08-07
KR20090104907A (ko) 2009-10-06
AU2007345580B2 (en) 2013-07-25
US20150154602A1 (en) 2015-06-04
WO2008094324A1 (en) 2008-08-07
US8746556B2 (en) 2014-06-10
US9256875B2 (en) 2016-02-09
WO2008094328A2 (en) 2008-08-07
CA2676637A1 (en) 2008-08-07
US10055735B2 (en) 2018-08-21
US20080183565A1 (en) 2008-07-31
AU2007345583B2 (en) 2013-05-09
EP2108173A1 (en) 2009-10-14
US9311643B2 (en) 2016-04-12
US20130275245A1 (en) 2013-10-17
US8407082B2 (en) 2013-03-26
US8412640B2 (en) 2013-04-02
KR20090104906A (ko) 2009-10-06
US10810594B2 (en) 2020-10-20
US20120296710A1 (en) 2012-11-22
KR20090119868A (ko) 2009-11-20
US20080183589A1 (en) 2008-07-31
US8256666B2 (en) 2012-09-04
AU2007345585A1 (en) 2008-08-07
WO2008094328A3 (en) 2008-11-06
BRPI0721132A2 (pt) 2014-04-01
KR101511801B1 (ko) 2015-04-13
US8448852B2 (en) 2013-05-28
WO2008094328B1 (en) 2008-12-24
AU2007345585B2 (en) 2011-12-15
WO2008094325A1 (en) 2008-08-07
US7809652B2 (en) 2010-10-05
US20110016054A1 (en) 2011-01-20
WO2008094327A1 (en) 2008-08-07
US20080183622A1 (en) 2008-07-31
US20080179395A1 (en) 2008-07-31
AU2007345583A1 (en) 2008-08-07
US8973818B2 (en) 2015-03-10
CA2676396A1 (en) 2008-08-07
US20080179394A1 (en) 2008-07-31
BRPI0721202A2 (pt) 2014-03-18
KR101570038B1 (ko) 2015-11-18
US20130339243A1 (en) 2013-12-19
EP2108178A1 (en) 2009-10-14

Similar Documents

Publication Publication Date Title
US10810594B2 (en) Delayed transit fare assessment
US8387873B2 (en) System and method for mass transit merchant payment
AU2013213725A1 (en) Processing transactions of different payment devices of the same issuer account

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 8A 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 2330 DE 01-09-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.