BR112012024646B1 - Método implementado por computador para verificar a autorização de uma transação eletrônica. - Google Patents

Abstract

métodos e sistemas para verificar transações. a presente invenção refere-se a um método implantado por computador para verificar a autorização de uma transação. o métood compreende as etapas de: receber uma solicitação para processar uma transação eletrônica para uma quantia de dinheiro predeterminada (215); dividir a quantia predeterminada em uma pluralidade de despesas (225); proporcionar a pluralidade de despesas para facilitar o débito de um instrumento financeiro em cada uma dentre a pluralidade de despesas (235); receber informações relacionadas à pluralidade de despesas de um usuário do instrumento financeiro após o débito das despesas (245); e verificar a transação apenas se as informações estiverem corretas (255).

Description

Campo Técnico

[0001] A presente invenção refere-se de uma forma geral a transações de pagamento e mais particularmente a verificação de autorização de transações de pagamento e/ou instrumentos financeiros eletrônicos usados para realizar tais transações.

Antecedentes

[0002] A disponibilidade e o uso difundidos de sistemas de computador e da Internet resultaram em transações financeiras eletrônicas que se tornaram comuns. O uso de instrumentos financeiros tais como cartões de crédito, cartões de débito e contas bancárias para comprar produtos ou serviços de comerciantes ou vendedores online é extremamente conveniente. No entanto, o número de transações fraudulentas aumentou substancialmente. Os comerciantes têm pouca proteção contra as transações de crédito ou débito fraudulentas, particularmente em circunstâncias "sem apresentação de cartão" (CNP) (isto é, em que a boa fé dos titulares de cartão não pode ser verificada pelo uso da comparação de assinatura convencional ou pelas verificações de identificação no ponto de venda), e podem ser responsáveis pelos custos de tais transações e custos de transporte em relação aos produtos. Para piorar as coisas, os comerciantes podem adicionalmente ser responsáveis pelas taxas de desonra intrabancárias.

[0003] Durante uma transação de pagamento usando um cartãode pagamento (por exemplo, um cartão de crédito, débito, ou com valor armazenado), é benéfico verificar uma titularidade do cartão do comprador (titular do cartão) ou uma conta associada ao cartão para evitar uma variedade de problemas potenciais, tais como uso não autorizado, uso contestado, ou uma mudança de opinião posterior por parte do comprador (também conhecida como fraude "amigável" ou "eu não cometi" fraude). A autenticação do comprador é o processo de verificação de uma titularidade de uma conta do titular do cartão. Um método comum de autenticação de uma titularidade de uma conta do comprador ocorre rotineiramente em um ponto de venda durante o que é chamado de uma transação "com apresentação de cartão". Uma transação com apresentação de cartão envolve uma representativida- de do comerciante que passa o cartão através de um terminal de pagamento do cartão para verificar a situação da conta e a disponibilidade da linha de crédito, e então verifica que a assinatura no verso no cartão corresponde à assinatura do comprador. Isso pode ser acompanhado pela verificação de um documento de identificação fotográfico tal como a carteira de motorista do comprador. Esse processo tanto identifica o comprador como serve para fornecer a autorização especí-fica para a transação específica. Desde que o comerciante siga as diretrizes específicas para tais transações, o comerciante geralmente estará garantido do pagamento da quantia autorizada menos o desconto e taxas.

[0004] Em transações CNP tais como aquelas que ocorrem online,através do correio, ou através do telefone, os pagamentos não são geralmente garantidos ao comerciante. A razão principal para as transações CNP não serem garantidas é que os compradores (titulares de cartão) não são autenticados em situações em que o comerciante e o comprador não estão fisicamente juntos com o cartão no momento do processamento da transação. Isso aumenta os riscos financeiros associados à transação, que são geralmente suportados pelo comerciante. Tais riscos incluem: estornos de transações de pagamento para comerciantes online (por exemplo, transações de uso "contestado"), fraude para ambos os comerciantes e titulares de cartão (por exemplo, uso não autorizado de informações da conta roubada para comprar produtos e serviços online), e despesas crescentes para instituições financeiras (que são frequentemente passadas a diante para o comerciante em qualquer caso). Isso infelizmente também leva a uma percepção do público crescente que comprar produtos e serviços online é inseguro e não garantido, o que evita que alguns consumidores comprem online.

[0005] As transações de uso contestado ocorrem quando umcomprador que é o titular autorizado do cartão contesta que uma transação ocorreu, mesmo se eles conscientemente iniciaram tal transação, mas podem ter mudado sua opinião posteriormente. Embora mais raro do que o uso não autorizado ou as transações fraudulentas, as transações contestadas, entretanto, representam um risco para os comerciantes, pois eles estão sujeitos a potenciais estornos. Os comerciantes frequentemente confiam nos serviços de entrega com "assinatura na entrega" como o principal meio para combater esse tipo de fraude, no entanto, isso pode ser frequentemente ineficaz, pois as faturas podem ser assinadas por terceiros, a assinatura pode ser ilegível ou diferir da assinatura normal do titular do cartão, ou a fatura enviada para os endereços que diferem do endereço de cobrança. Tudo isso têm o potencial para criar um cenário para a possível contestação pelo titular do cartão e são suscetíveis a um estorno.

[0006] Tendo em conta o crescimento contínuo do comércio eletrônico, é desejável proporcionar métodos capazes de autenticar compradores como os titulares de cartão e/ou transações individuais autorizadas em um caso a caso. Isso beneficiará potencialmente todos os participantes do sistema de pagamento legítimo incluindo os compra- dores/titulares de cartão, comerciantes, esquemas de cartão, e instituições financeiras.

[0007] Ao autenticar um comprador como sendo o titular autorizado do cartão (ou uma pessoa autorizada pelo titular do cartão) e ligan- do uma autorização a cada transação (apenas em transações com a apresentação do cartão) durante as transações de compra online reduzirá os níveis de fraude, contestações, recuperações e estornos, que consequentemente reduzirão os custos associados a cada um desses eventos. Ao autenticar o comprador como sendo o titular autorizado do cartão (ou uma pessoa autorizada pelo titular do cartão) também endereça ao consumidor preocupações de segurança e pro-vavelmente levarão a vendas online crescentes. Face ao exposto, um sistema para autenticação tanto da identidade do comprador quanto de sua autorização em relação à transação online específica em um caso a caso seria desejável durante as transações com a não apresentação do cartão (CNP). Esse sistema de autenticação deve ser, de preferência, relativamente fácil de implantar e usar, requer um investimento de recursos mínimo, e proporciona um alto nível de confiança em torno da autorização da transação. Esse sistema de autenticação, preferencialmente, deve também satisfazer as transações de moeda cruzada, em que uma moeda de emissão do cartão do comprador é diferente da moeda de transação do vendedor ou comerciante.

[0008] Várias verificações são atualmente usadas para identificar edescartar as transações fraudulentas. Por exemplo, as portas de entrada de cartão de crédito geralmente recomendam as verificações do Serviço de Verificação do Endereço (AVS) e Valor de Verificação do Cartão (CVV). A falta de uma verificação do AVS sugere que o comprador como o originador da transação possa não ser o titular do cartão. A falta de uma verificação de CVV sugere que o originador da transação possa não estar de posse do cartão efetivo.

[0009] No entanto, essas verificações não são infalíveis, pois osfraudadores geralmente são capazes de obter as informações necessárias com suficiente esforço. Essas verificações, mesmo se proporcionadas no momento da transação, nem sempre protegem o comerci- ante dos 'estornos' em que o titular autorizado do cartão pode contestar que a transação foi autorizada e alegar que foi iniciada por um terceiro não autorizado.

[00010] Outra verificação é consultar um endereço de IP do comprador com um provedor de serviço de geolocalização que também detecte representantes anônimos. Na maior parte dos casos, a localização geográfica geral do endereço de IP deve corresponder tanto ao endereço de cobrança do comprador quanto ao endereço de envio. Os pedidos de representantes anônimos são geralmente considerados a representar um alto risco porque os fraudadores frequentemente usam representantes anônimos para esconder seus endereços de IP verdadeiros.

[00011] Outra verificação é comparar a localização geográfica do endereço de IP do comprador com uma lista de países ou territórios de alto risco.

[00012] Outra verificação é determinar se os produtos serão enviados para uma empresa de remessa de correio quando os endereços de envio e cobrança são diferentes. Esses pedidos poderiam ser arriscados, pois os produtos podem ser enviados para o exterior.

[00013] Outra verificação é determinar se o código de endereçamento postal ou código postal fornecido pelo comprador corresponde à cidade e estado para ambos os endereços de cobrança e envio. A verificação de AVS referida acima apenas verifica o código de endereçamento postal e a parte numérica do endereço de rua. Os fraudado- res podem nem sempre estar de posse do endereço completo e podem ser muito lentos para fazer uma consulta inversa do código de endereçamento postal para informações de endereço adicionais.

[00014] Outra verificação é solicitar que o comprador envie um formulário de autorização assinado com cópias da frente e verso do cartão por fax. No entanto, isso é inconveniente e é, portanto, geralmente apenas solicitado sob circunstâncias suspeitas. Além disso, os frauda- dores se tornaram conhecidos por criar as imagens de cartão de crédito usando o software de design gráfico.

[00015] Outra verificação é solicitar que o comprador forneça o nome do banco e o número de telefone do serviço de atendimento ao cliente conforme mencionado no cartão. O serviço de atendimento ao cliente pode então ser chamado para determinar se as informações fornecidas correspondem aos registros bancários do titular do cartão. Essa verificação é geralmente efetiva, mas é demorada e inconveniente.

[00016] Outra verificação é fornecer ao comprador um número de identificação pessoal (PIN) antecipadamente a quaisquer transações para uso em cada transação. Isso é considerado efetivo, mas os compradores geralmente precisam pedir separadamente e antecipadamente por um PIN para as transações CNP, e podem frequentemente perder ou confundir os PINs.

[00017] Existe uma necessidade por métodos e sistemas aperfeiçoados que proporcionem comprovar ou verificar que uma conta ou titular de cartão autorizou uma transação ou pagamento específico de uma conta ou cartão específico, sem apresentar atrasos indevidos e/ou transações ou operações adicionais desnecessárias.

Sumário

[00018] Um aspecto da presente invenção proporciona um método implementado por computador para verificar a autorização de uma transação. O método compreende as etapas de: receber uma solicitação para processar uma transação eletrônica para uma quantia de dinheiro predeterminada, a solicitação que compreende identificar dados de um instrumento financeiro particular; dividir a quantia predeterminada em uma pluralidade de despesas; que faça com que o instrumento financeiro seja debitado em cada despesa dentre a pluralidade de despesas; receber informações relacionadas à pluralidade de despe- sas do originador da solicitação; e verificar a transação apenas se as informações estiverem corretas.

[00019] Outro aspecto da presente invenção proporciona um sistema de computador para verificar a autorização de uma transação. O sistema de computador compreende: uma memória para armazenar dados e instruções do programa; e pelo menos um processador acoplado à memória. O pelo menos um processador é programado para: receber uma solicitação para processar uma transação eletrônica para uma quantia de dinheiro predeterminada, a solicitação que compreende identificar dados de um instrumento financeiro particular; dividir a quantia predeterminada em uma pluralidade de despesas; fazer com que o instrumento financeiro seja debitado em cada despesa dentre a pluralidade de despesas; receber informações relacionadas à pluralidade de despesas do originador da solicitação; e verificar a transação apenas se as informações estiverem corretas.

[00020] Outro aspecto da presente invenção proporciona um produto de programa de computador que compreende um meio legível por computador que compreende um programa de computador gravado no mesmo para verificar a autorização de uma transação. O produto de programa de computador compreende: os meios de código de programa de computador para receber uma solicitação para processar uma transação eletrônica para uma quantia de dinheiro predeterminada, a solicitação que compreende identificar dados de um instrumento financeiro particular; os meios de código de programa de computador para dividir a quantia predeterminada em uma pluralidade de despesas; os meios de código de programa de computador para fazer com que o instrumento financeiro seja debitado em cada despesa dentre a pluralidade de despesas; os meios de código de programa de computador para receber as informações relacionadas à pluralidade de despesas do originador da solicitação; e os meios de código de programa de computador para verificar a transação apenas se as informações estiverem corretas.

[00021] Outro aspecto da presente invenção proporciona um método implementado por computador para verificar transações. O método compreende as etapas de: receber uma solicitação para verificar uma transação eletrônica para uma quantia de dinheiro predeterminada; dividir a quantia predeterminada em uma pluralidade de despesas; proporcionar a pluralidade de despesas para facilitar o débito do instrumento financeiro em cada despesa dentre da pluralidade de despesas; receber informações relacionadas à pluralidade de despesas, as informações originárias de um usuário do instrumento financeiro após a pluralidade de despesas que foram debitadas para o instrumento financeiro; e verificar a transação apenas se as informações recebidas estiverem corretas.

[00022] Outro aspecto da presente invenção proporciona um sistema de computador para verificar transações. O sistema de computador compreende: uma memória para armazenar dados e instruções do programa; e pelo menos um processador acoplado à memória. O pelo menos um processador é programado para: receber uma solicitação para verificar uma transação eletrônica para uma quantia de dinheiro predeterminada; dividir a quantia predeterminada em uma pluralidade de despesas; proporcionar a pluralidade de despesas para facilitar o débito do instrumento financeiro em cada despensa dentre a pluralidade de despesas; receber informações relacionadas à pluralidade de despesas, as informações originárias de um usuário do instrumento financeiro após a pluralidade de despesas terem sido debitadas para o instrumento financeiro; e verificar a transação apenas se as informa-ções recebidas estiverem corretas.

[00023] Outro aspecto da presente invenção proporciona um produto de programa de computador que compreende um meio legível por computador que compreende um programa de computador gravado no mesmo para verificar transações. O produto de programa de computador compreende: os meios de código de programa de computador para receber uma solicitação para verificar uma transação eletrônica para uma quantia de dinheiro predeterminada; os meios de código de programa de computador para dividir a quantia predeterminada em uma pluralidade de despesas; os meios de código de programa de computador para proporcionar a pluralidade de despesas para facilitar o débito do instrumento financeiro em cada despesa dentre a pluralidade de despesas; os meios de código de programa de computador para receber as informações relacionadas à pluralidade de despesas, as informa-ções originárias de um usuário do instrumento financeiro após a pluralidade de despesas terem sido debitadas para o instrumento financeiro; e os meios de código de programa de computador para verificar a transação apenas se as informações recebidas estiverem corretas.

[00024] Em certas modalidades, a pluralidade de despesas compreende duas despesas.

[00025] Em certas modalidades, as informações relacionadas à pluralidade de despesas podem ser armazenadas e comparadas às informações recebidas, quando subsequentemente recebidas, para determinar se as informações recebidas estiveram corretas.

[00026] O instrumento financeiro pode, por exemplo, compreender: uma conta bancária, um cartão de crédito, um cartão de débito, um cartão de despesa, um cartão de armazenagem, e uma facilidade de conta de débito direta.

[00027] As informações relacionadas à pluralidade de despesas podem compreender: a quantia de cada despesa dentre a pluralidade de despesas ou o número de pluralidade de despesas.

[00028] Em certas modalidades, uma taxa de câmbio de moeda associada à transação pode ser armazenada.

Breve Descrição dos Desenhos

[00029] Um pequeno número de modalidades da presente invenção será descrito a seguir com referência aos seguintes desenhos, nos quais:

[00030] A figura 1A é um diagrama de bloco esquemático de um sistema para verificar transações ou a autorização de transações de acordo com uma modalidade da presente invenção;

[00031] A figura 1B é um diagrama de bloco esquemático de um sistema para verificar transações ou a autorização de transações de acordo com outra modalidade da presente invenção;

[00032] A figura 1C é um diagrama de bloco esquemático de um sistema para verificar transações ou a autorização de transações de acordo com outra modalidade da presente invenção;

[00033] A figura 1D é um diagrama de bloco esquemático de um sistema para verificar transações ou a autorização de transações de acordo com outra modalidade da presente invenção;

[00034] A figura 1E é um diagrama de bloco esquemático de um sistema para verificar transações ou a autorização de transações de acordo com outra modalidade da presente invenção;

[00035] A figura 1F é um diagrama de bloco esquemático de um sistema para verificar transações ou a autorização de transações de acordo com outra modalidade da presente invenção;

[00036] A figura 2A é um fluxograma de um método para verificar transações ou a autorização de transações de acordo com uma modalidade da presente invenção;

[00037] A figura 2B é um fluxograma de um método para verificar transações ou a autorização de transações de acordo com outra modalidade da presente invenção;

[00038] A figura 2C é um fluxograma de um método para verificar transações de moeda cruzada ou a autorização de transações de mo- eda cruzada de acordo com outra modalidade da presente invenção;

[00039] A figura 2D é um fluxograma de um método para verificar transações de moeda cruzada ou a autorização de transações de moeda cruzada de acordo com outra modalidade da presente invenção; e

[00040] As figuras 3A e 3B são diagramas de bloco esquemáticos de um sistema de computador com o qual as modalidades da presente invenção podem ser executadas.

[00041] Os indicadores de referência idênticos nas diferentes figuras são destinados a denotar itens similares substancialmente ou idênticos exceto se indicado o contrário.

Descrição Detalhada

[00042] As modalidades de métodos e sistemas para verificar a autorização de transações são descritas a seguir. Os métodos e sistemas descritos a seguir podem ser usados para verificar a legitimidade do originador de uma transação com Cartão Não Apresentado (CNP) para utilizar o instrumento financeiro e subsequentemente, a autorização de uma transação.

[00043] Por conveniência, as modalidades são descritas de uma forma geral usando cartões de crédito ou cartões de débito como um instrumento financeiro. No entanto, não é pretendido que o escopo da invenção seja limitado dessa maneira, pois a invenção tem aplicação ampla a outros instrumentos financeiros incluindo, mas não limitado a, contas bancárias e outros cartões com valor armazenado.

[00044] Também por conveniência, as modalidades são descritas de uma forma geral com referência ao comprador, que pode alternativamente ser referido como o titular do cartão ou o originador da transação.

[00045] Também por conveniência, as modalidades são descritas de uma forma geral com referência à compra online de um item de um comerciante (por exemplo, um vendedor de produtos físicos ou virtuais, ou um provedor de serviços) por um comprador que origina uma transação CNP online. No entanto, não é pretendido que o escopo da invenção seja limitado dessa maneira, pois a invenção tem aplicação ampla a outras transações com Cartão Não Apresentado (CNP), incluindo Encomenda por Correio e Encomendas por Televendas ("MOTO"), bem como a ligação de detalhes secundários tais como endereços de email ou Serviço de Mensagem Curta (SMS), Serviço de Mensagem Multimídia (MMS) ou telefones habilitados para dados para a transação verificada, então também verificando, além da ligação, aqueles detalhes secundários para a transação e o pagante (comprador).

[00046] Os métodos e sistemas de verificação descritos a seguir confirmam que o comprador (como originador de uma transação CNP) tem acesso a uma conta associada ao instrumento financeiro, e é muito provavelmente o titular autorizado do cartão ou uma pessoa autorizada pelo titular do cartão.

[00047] As modalidades descritas a seguir podem ser executadas independentemente ou em conjunto com os vários métodos e verificações referidos na seção de fundamentos supracitada.

[00048] A figura 1A é um diagrama de bloco esquemático de um sistema para verificar transações eletrônicas ou a autorização de transações eletrônicas.

[00049] Referindo-se à figura 1A, um comprador (ou originador) 110, um comerciante 120, uma porta de entrada de pagamento 130 e a instituição financeira do comprador (isto é, como provedor do instrumento financeiro) 140 são tipicamente representados ou incorporados por sistemas de computador tais como o sistema de computador 300 descrito a seguir com referência às figuras 3A e 3B. A porta de entrada de pagamento 130 pode compreender um intermediário independente tal como uma câmara de compensação ou pode alternativamente ser fornecida pela instituição financeira do comprador ou pela instituição financeira do comerciante. Os sistemas de computador do comprador 110, o comerciante 120, a porta de entrada de pagamento 130, e a instituição financeira do comerciante 140 são comunicativamente acoplados através de uma rede de comunicações (não mostrada) tal como uma Rede de Área Local (LAN) ou uma Rede de Área Ampla (WAN). Tais redes podem compreender redes privadas, redes públicas, redes com fio ou redes sem fio, ou qualquer combinação das supracitadas. Em particular, os sistemas de computador supracitados podem ser acoplados através da Internet (não mostrados na figura 1A).

[00050] Na operação, o comprador (ou originador) 110 envia uma solicitação 112 ao comerciante 120 para processar uma transação eletrônica para uma quantia de dinheiro predeterminada. A solicitação 112 pode, por exemplo, resultar do comprador 110 navegando em um website do comerciante 120 (por exemplo, um comerciante online) e escolhendo comprar um item oferecido para venda no website do comerciante. Nesse exemplo, a quantia de dinheiro predeterminada pode corresponder ao preço anunciado ou preço de tabela do item. A solicitação 112 inclui tipicamente os detalhes de identificação de um instrumento financeiro particular (por exemplo, cartão de crédito, cartão de débito, conta bancária ou outra conta, etc.) que o comprador 110 deseja usar para pagar pelo item.

[00051] Após receber a solicitação 112, o comerciante 120 envia uma solicitação 122 para a porta de entrada de pagamento 130 para processar uma transação eletrônica para a quantia de dinheiro predeterminada usando o instrumento financeiro nomeado pelo comprador (de acordo com as exigências do processo da Rede de Esquema de Cartão e/ou da Instituição Financeira).

[00052] Após receber a solicitação 122, a porta de entrada de pagamento 130 procede à despesa (ou seja, débito) o instrumento financeiro nomeado pelo comprador 110 com duas ou mais despesas 132, 134 que se somam à quantia de dinheiro predeterminada. A porta de entrada de pagamento 130 divide a quantia de dinheiro predeterminada em múltiplas (ou seja, duas ou mais) despesas, preferencialmente de uma maneira aleatória (por exemplo, usando um aplicativo de software de computador que inclui um gerador de número aleatório).

[00053] Em uma modalidade alternativa, a quantia de dinheiro predeterminada pode ser dividida em múltiplas despesas pelo comerciante 120 e as múltiplas despesas podem ser comunicadas à porta de entrada de pagamento 130 na solicitação 122.

[00054] Após debitar com sucesso o instrumento financeiro do comprador identificado nas solicitações 112 e 122, o comprador 110 é avisado (através do comerciante nas comunicações 124 e 114) que o instrumento financeiro do comprador foi debitado. O comprador 110 é também solicitado a fornecer informações relacionadas ao número de despesas feitas ao instrumento financeiro do comprador e/ou a quantia de cada despesa. Em outra modalidade, a porta de entrada de pagamento 130 pode se comunicar diretamente com o comprador 110 nesse sentido.

[00055] O comprador 110 então verifica 116 sua conta relacionada ao instrumento financeiro e determina ou obtém 142 o número de despesas (ou seja, débitos) e/ou as quantias individuais das múltiplas despesas debitadas pela porta de entrada de pagamento 130 em nome do comerciante 120.

[00056] O comprador 110 então avisa ou confirma 118 as quantias individuais das múltiplas despesas ao comerciante 120. Tal aviso ou confirmação do comprador 110 pode, por exemplo, ser através da transferência de dados eletrônica, correio eletrônico (email), serviço de mensagem curta (SMS) através do telefone celular, do preenchimento de um formulário eletrônico/tela de entrada disponível online, ou qualquer outro meio adequado disponível, incluindo verbalmente (através do telefone). Em modalidades alternativas, o comprador 110 pode fornecer o aviso ou confirmação para ou através de outra parte, tal como a porta de entrada de pagamento ou a instituição financeira do comerciante 130.

[00057] Ao receber a confirmação do número de despesas e as quantias individuais das múltiplas despesas, o comerciante 120 verifica a autorização da transação. A verificação com sucesso pode, por exemplo, referir-se a uma exigência interna do comerciante 120 antes da liberação ou envio do(s) item/s relevante(s) ao comprador 110.

[00058] Em uma modalidade alternativa, é incumbente ao comprador 110 verificar a conta relacionada ao seu instrumento financeiro após fazer a solicitação 112 para determinar o número de despesas feitas e/ou a quantia de cada despesa (isto é, espontaneamente) e avisar ao comerciante 120 ou à porta de entrada de pagamento ou a instituição financeira do comerciante 130 de acordo.

[00059] Em outras modalidades, a instituição financeira do comerciante 130 ou a instituição financeira do comprador 140 pode verificar a transação ou a autorização da transação para o comerciante 120, diretamente ou através da porta de entrada de pagamento. A verificação pode, por exemplo, referir-se a um aviso de autorização, à compensação ou liquidação atual de fundos para o comerciante 120, seguindo os mesmos o comerciante 120 pode liberar ou enviar o(s) item/s rele- vante(s) ao comprador 110.

[00060] Em outras modalidades, uma Rede de Esquema de Cartão à qual o relevante instrumento financeiro é relacionado (por exemplo, Visa, MasterCard®, American Express®, JCB etc.) pode verificar a transação, tanto diretamente quanto através da instituição financeira do comerciante ou da porta de entrada de pagamento 130, para o comerciante 120. Isso pode ser contratado em conjunto com os processos de autorização empregados pelas instituições financeiras relevan- tes. A verificação pode, por exemplo, referir-se a um aviso da Rede de Esquema de Cartão através da instituição financeira do comerciante ou da porta de entrada de pagamento 130 de verificação e/ou autorização, ou a verificação e início da compensação ou liquidação atual de fundos para o comerciante 120, seguindo os mesmos o comerciante 120 pode liberar ou enviar o(s) item/s relevante(s) ao comprador 110.

[00061] A divisão da quantia de dinheiro predeterminada em múltiplas despesas pode ser realizada por um agente de verificação, que compreende tipicamente um aplicativo de software de computador. O agente de verificação pode, por exemplo, ser residente e/ou executar no:• sistema ou rede de computador do comerciante;• sistema ou rede de computador da porta de entrada de pagamento;• em um sistema ou rede de computador da instituição financeira do comerciante; ou em um sistema de computador independente (por exemplo, um servidor de computador accessível através da Internet pelos comerciantes, as portas de entrada de pagamento e/ou as instituições financeiras do comerciante);• um sistema ou rede de computador associada a um esquema de cartão de crédito ou de cartão de despesa tal como Visa, MasterCard®, American Express®, etc.; ou• uma combinação de qualquer um dos supracitados.

[00062] Ao seguir uma solicitação para verificar uma transação para uma quantia predeterminada ou a autorização de uma transação, o agente de verificação determina o número de despesas nas quais a quantia predeterminada deve ser dividida e os valores associados a cada uma das despesas. Conforme descrito mais acima, o número de despesas e/ou a quantia de cada despesa são preferencialmente determinadas de maneira aleatória (por exemplo, usando um aplicativo de software de computador implementado no gerador de número alea- tório). As informações (isto é, o número de despesas e/ou a quantia de cada despesa) são armazenadas e enviadas a uma porta de entrada de pagamento ou à instituição financeira para a cobrança efetiva (débito) em uma conta associada ao instrumento financeiro do comprador.

[00063] As informações subsequentemente recebidas do comprador (isto é, o número de despesas e/ou a quantia de cada despesa) são comparadas às informações armazenadas para determinar se o comprador forneceu a versão correta das informações. Se estiver correta, a autorização da transação é verificada.

[00064] A comparação de informações armazenadas com as informações recebidas do comprador é preferencialmente realizada pelo agente de verificação, se estão implantadas no sistema de computador da porta de entrada de pagamento, no sistema de computador do comerciante, no sistema de computador da instituição financeira do comerciante, no sistema de computador da Rede de Esquema de Cartão relevante, ou em um sistema de computador independente.

[00065] A comunicação entre o comprador e o agente de verificação pode ser direta ou indireta (por exemplo, através da porta de entrada de pagamento, do comerciante, da instituição financeira do comerciante, ou da Rede de Esquema de Cartão). Tal comunicação pode, por exemplo, ser através da transferência de dados eletrônica, direta ou revezada pelo correio eletrônico (email), direta ou revezada pelo serviço de mensagem curta (SMS) através do telefone celular, pelo preenchimento de um formulário eletrônico/tela de entrada disponível na rede mundial ou qualquer outro meio adequado disponível, incluindo verbalmente (através do telefone) para um operador que introduza os dados apropriados. Em casos em que a comunicação é ele-trônica, o endereço e os detalhes do dispositivo relacionados ao comprador podem ser associados ao comprador ou à transação e armazenados para identificação do comprador em transações subsequentes. Quando as informações são recebidas como parte do processo de verificação através de endereços roteáveis eletronicamente tal como endereços de email, telefones móveis habilitados para sms, endereços de protocolo de IP, etc., então esses endereços roteáveis eletronicamente podem ser associados ao comprador ou à transação seguindo a verificação e armazenados para identificação subsequente do comprador.

[00066] Nos casos em que o instrumento financeiro do comprador e o comerciante operam com o uso de moedas diferentes, a(s) taxa/s de câmbio da moeda associada(s) à transação pode ser solicitada da instituição financeira e armazenada em uma transação por transação para possibilitar a conversão e a resposta subsequente do comprador direta ou indireta ao agente de verificação em ambas as moedas.

[00067] A figura 1B é um diagrama de bloco esquemático de outro sistema para verificar transações ou a autorização de transações.

[00068] Referindo-se à figura 1B, um comprador 210, um comerciante 220, uma porta de entrada de pagamento 230, a instituição financeira do comerciante 240, e a instituição financeira do comprador (como provedor do instrumento financeiro) 250 são tipicamente representados ou incorporados pelos sistemas de computador tal como o sistema de computador 300 descrito a seguir com referência às figuras 3A e 3B. Os sistemas de computador supracitados são tipicamente comunicativamente acoplados através de uma ou mais rede/s de comunicação (não mostrada(s)). Tais redes podem, por exemplo, compreender as redes privadas, redes públicas, redes com fio, redes sem fio, Redes de Área Local (LANs), Redes de Área Ampla (WANs), e qualquer combinação das supracitadas. Em particular, os sistemas de computador supracitados podem ser acoplados através da Internet (não mostrados na figura 1B).

[00069] Um agente de verificação 260 opera em conjunto com o sistema de computador do comerciante 220. O agente de verificação 260 pode, for exemplo, compreender um aplicativo de software de computador residente em e executado pelo sistema de computador do comerciante 220. Alternativamente, o agente de verificação 260 pode compreender um servidor de computador separado acoplado ao sistema de computador do comerciante 220 (por exemplo, através da Internet ou de uma rede de área local (LAN)).

[00070] Na operação, o comprador (ou originador) 210 envia uma solicitação 212 ao comerciante 220 para processar uma transação eletrônica para uma quantia de dinheiro predeterminada. A solicitação pode, por exemplo, resultar do comprador 210 que navega em um website do comerciante 220 (por exemplo, um comerciante online) e escolher comprar um item oferecido para venda no website do comerciante. Nesse exemplo, a quantia de dinheiro predeterminada pode corresponder ao preço anunciado ou preço de tabela do item. A solicitação 212 tipicamente inclui os detalhes de identificação do instrumento financeiro particular (por exemplo, o cartão de crédito/cartão de débito, conta bancária ou outra conta, etc.) que o comprador 210 deseje usar para pagar pelo item.

[00071] Após receber a solicitação 212, o comerciante 210 envia a solicitação 222 ao agente de verificação 260.

[00072] No recebimento, o agente de verificação 260 divide a quantia de dinheiro predeterminada em duas ou mais despesas, preferencialmente de uma maneira aleatória (por exemplo, usando um aplicativo de software de computador que inclui um gerador de número aleatório), e retorna as múltiplas quantias de despesa 262 ao comerciante 220. As múltiplas quantias de despesa se somam à quantia de dinheiro predeterminada. Então, o comerciante 220 solicita 224, 232 à instituição financeira do comerciante 240 através da porta de entrada de pagamento 230 debitar o instrumento financeiro do comprador identifi- cado nas solicitações 212, 224 com duas ou mais despesas que se somem à quantia de dinheiro predeterminada.

[00073] A instituição financeira do comerciante 240 debita 242 a conta relacionada ao instrumento financeiro do comprador (na instituição financeira do comprador 250) com as múltiplas despesas.

[00074] Após o instrumento financeiro do comprador ter sido debitado com as múltiplas despesas, o comprador 210 é avisado 244, 234, 226 que seu instrumento financeiro foi debitado pela instituição financeira do comerciante 240 através da porta de entrada de pagamento 230 e pelo comerciante 220.

[00075] O comprador 210 verifica 214 sua conta relacionada ao instrumento financeiro na instituição financeira do comprador 250 e obtém 252 o número de despesas (ou seja, os débitos) e as quantias individuais de cada uma das múltiplas despesas debitadas pela instituição financeira do comerciante 240.

[00076] O comprador 210 então avisa ou confirma 216 as quantias individuais de cada uma das múltiplas despesas ao comerciante 220 e ou ao agente de verificação 260. Em uma modalidade alternativa que é mostrada na figura 1B, o comprador 210 pode avisar ou confirmar as quantias individuais de cada uma das múltiplas despesas diretamente ao agente de verificação 260 (ou seja, não através do comerciante 220). Tal aviso ou confirmação podem, por exemplo, ser através da transferência de dados eletrônica, correio eletrônico (email), serviço de mensagem curta (SMS) através do telefone celular, ou pelo preenchimento de um formulário eletrônico/tela de entrada disponível online, ou qualquer outro meio adequado disponível, incluindo verbalmente (através do telefone). A confirmação do número de despesas e/ou as quantias individuais das múltiplas despesas servem para confirmar a autorização da transação, que pode por sua vez servir com uma autorização ou provocador ao comerciante 220 para liberar ou enviar o item/s rele- vante ao comprador 210.

[00077] Em uma modalidade alternativa, é incumbente ao comprador 210 verificar a conta relacionada ao seu instrumento financeiro após fazer a solicitação 212 para determinar o número de despesas feitas e/ou a quantia de cada despesa (isto é, espontaneamente).

[00078] A figura 1C é um diagrama de bloco esquemático de outro sistema para verificar transações ou a autorização de transações.

[00079] O sistema da figura 1C é substancialmente similar ao sistema da figura 1B. No entanto, o agente de verificação 260 é acoplado à porta de entrada de pagamento 230 ao invés do comerciante 220. Ou seja, as comunicações 222 e 262 na figura 1B são substituídas pelas comunicações 236 e 264, respectivamente, na figura 1C. Os outros elementos do sistema da figura 1C são idênticos ou substancialmente similares aos elementos correspondentes do sistema da figura 1B. Especificamente, os elementos que têm os mesmos designadores de referência nas figuras 1B e 1C têm funcionalidade idêntica, equivalente, ou similar. Em uma modalidade alternativa que é mostrada na figura 1C, o comprador 210 pode avisar ou confirmar as quantias individuais de cada uma das múltiplas despesas diretamente ao agente de verificação 260 (isto é, não através do comerciante 220 e/ou pela porta de entrada de pagamento 230).

[00080] Ainda em outra modalidade, o agente de verificação 260 pode ser acoplado à instituição financeira do comerciante 240 ao invés da porta de entrada de pagamento 230 ou do comerciante 220.

[00081] Ainda em outra modalidade, o agente de verificação 260 pode ser executado como um servidor de computador independente acessível aos sistemas de computador de qualquer comerciante 220, à porta de entrada de pagamento 230, ou à instituição financeira do comerciante 240 através da Internet.

[00082] A figura 1D é um diagrama de bloco esquemático de outro sistema para verificar transações ou a autorização de transações.

[00083] O sistema da figura 1D é substancialmente similar ao sistema da figura 1C, mas também mostra uma Rede de Esquema de Cartão 270 (por exemplo, Visa, MasterCard®, American Express®, etc.) comunicativamente acoplado ao agente de verificação 260, à instituição financeira do comerciante 240 e à instituição financeira do comprador 250. O agente de verificação 260 facilita o débito das múltiplas quantias de despesa através das comunicações 266, 276 com a Rede de Esquema de Cartão 270, que processa a transferência de fundos através das comunicações bidirecionais 244 e 254 com a instituição financeira do comerciante 240 e com a instituição financeira do comprador 250, respectivamente. Os elementos que têm os mesmos designadores de referência nas figuras 1B, 1C e 1D têm funcionalidade idêntica, equivalente, ou similar.

[00084] Ainda em outra modalidade, o agente de verificação 260 pode ser acoplado à instituição financeira do comerciante 240 ou à Rede de Esquema de Cartão 270 ao invés da porta de entrada de pagamento 230 ou do comerciante 220.

[00085] Ainda em outra modalidade, o agente de verificação 260 pode ser executado como um servidor de computador independente acessível aos sistemas de computador de qualquer comerciante 220, à porta de entrada de pagamento 230, à instituição financeira do comerciante 240, ou à Rede de Esquema de Cartão 270 através da Internet.

[00086] A figura 1E é um diagrama de bloco esquemático de outro sistema para verificar transações ou a autorização de transações.

[00087] A figura 1E inclui um agente de verificação independente 260 comunicativamente acoplado aos sistemas 270 e 280, que corresponde aos sistemas das figuras 1B e 1C, respectivamente. O agente de verificação 260 na figura 1E compreende tipicamente um aplicativo de software de computador residente e executa em um servidor de computador que é independente dos sistemas de computador dos compradores, dos comerciantes, da porta de entrada de pagamentos, e das instituições financeiras do comprador e/ou comerciante.

[00088] A figura 1F é um diagrama de bloco esquemático de outro sistema para verificar transações ou a autorização de transações.

[00089] O sistema da figura 1F é substancialmente similar ao sistema da figura 1E. O sistema da figura 1F também inclui um agente de verificação independente 260 comunicativamente acoplado ao sistema 290, que é similar aos sistemas 270 e 280 das figuras 1B e 1C, respectivamente. No entanto, uma Rede de Esquema de Cartão 295 (por exemplo, Visa, MasterCard®, American Express®, JCB etc.) é mostrada interposta entre a instituição financeira do comerciante e o agente de verificação 260. Como na figura 1E, o agente de verificação 260 na figura 1F compreende tipicamente um aplicativo de software de computador residente e executa em um servidor de computador que é independente dos sistemas de computador dos compradores, dos comerciantes, das portas de entrada de pagamento, das instituições financeiras do comprador e/ou comerciante, e da Rede de Esquema de Cartão.

[00090] Nota-se que a porta de entrada de pagamento e a instituição financeira do comerciante podem ser as mesmas ou diferentes organizações. No entanto, quando representadas em várias figuras a seguir, a porta de entrada de pagamento e/ou a instituição financeira do comerciante representam a(s) organização(ões) denominada(s) pelo comerciante para fins de processamento eletrônico de transações usando os instrumentos financeiros do comprador. Nota-se adicionalmente que esse documento não descreve completamente as intercomunicações entre as várias câmaras de compensação, portas de entrada de pagamento, Redes de Esquema de Cartão e instituições financeiras, pois isso pode variar de acordo com o local e é conhecido por aqueles versados nas técnicas relevantes.

[00091] O agente de verificação não necessariamente fornece os serviços de processamento de pagamento e geralmente opera em conjunto com as portas de entrada de pagamento de terceiros, instituições financeiras, Redes de Esquema de Cartão e/ou câmaras de compensação. Além disso, os detalhes do instrumento financeiro efetivo usado para processar uma transação (por exemplo, número de cartão, nome do titular do cartão, etc.) não são necessários para serem conhecidos pelo agente de verificação, pois cada transação pode ser processada em um caso a caso com referência apenas à própria transação, sem restrição do tipo ou fonte de instrumento financeiro.

[00092] A integração opcional de um agente de verificação de acordo com as modalidades da presente invenção em autorização existente, compensação, e processos de liquidação das instituições financeiras e/ou da Rede de Esquema de Cartão que vantajosamente tem o potencial para reduzir os custos associados ao processamento de transações de cartão de crédito. As Redes de Esquema de Cartão e as instituições financeiras geralmente implantam um processo com três etapas para os pagamentos de cartão de crédito, a saber: 1) autorização, 2) compensação, e 3) liquidação. As modalidades da presente invenção podem vantajosamente ser integradas nas etapas de autorização e compensação, portanto, reduzindo os custos de processamento totais. Portanto, as transações não são liquidadas entre as instituições financeiras do comerciante e do titular do cartão se a verificação não for alcançada. Isso resulta vantajosamente em processamento interbancário reduzido e menos estornos (processo usado para recuperar os fundos transferidos interbancariamente).

[00093] As informações que podem ser transmitidas e/ou armazenadas pelo agente de verificação em uma base por transação podem, opcionalmente, incluir, mas não são limitadas ao seguinte: • Data e hora da transação original;• Identificador do comerciante;• Identificador da porta de entrada;• Identificador da instituição financeira do comprador;• Identificador da transação (alocado pelo comerciante, porta de entrada, ou agente de verificação);• Quantia da despesa predeterminada;• Identificador da rede de esquema de cartão (por exemplo, Visa, MasterCard®, American Express®, etc.);• Identificador do comprador único (alocado independentemente dos detalhes da conta do instrumento financeiro pelo agente de verificação, comerciante, ou porta de entrada);• País de emissão do instrumento financeiro;• Moeda do instrumento financeiro;• Taxa de câmbio aplicada à transação;• Endereço de IP do comprador durante a transação, como revezado pelo comerciante ou porta de entrada;• Endereço de email do comprador;• Número de telefone do comprador, sendo um telefone habilitado para SMS ou MMS;• Quantias das múltiplas despesas fornecidas pelo compra-dor;• Data e hora das múltiplas quantias de despesa fornecidas pelo comprador;• Endereço de IP do comprador e/ou endereço de email e/ou endereço de mensagem instantânea ou outros endereços roteáveis eletronicamente usados durante o fornecimento das múltiplas quantias de despesa do comprador;• Detalhes de contato do telefone do comprador, sendo um telefone habilitado para mensagem de SMS ou MMS ou similar usado ou indicado pelo comprador no fornecimento das quantias das múltiplas despesas;• O endereço de MAC, IMEI, ESN, número de série adquirido ou outros dados codificados permanentemente fixados a um dispositivo usado pelo comprador no fornecimento das quantias das múltiplas despesas;• O Número de Identificação Pessoal (PIN) do comprador indicado no fornecimento das quantias das múltiplas despesas.

[00094] A figura 2A é um fluxograma de um método implementado por computador para verificar transações ou a autorização de transações.

[00095] Referindo-se à figura 2A, uma solicitação para processar uma transação eletrônica para uma quantia de dinheiro predeterminada é recebida na etapa 410. A solicitação compreende identificar dados de um instrumento financeiro particular indicado pelo originador da solicitação.

[00096] Na etapa 420, a quantia predeterminada é dividida em uma pluralidade de despesas tal que a soma das quantias individuais da pluralidade de despesas é igual à quantia de dinheiro predeterminada (isto é, a quantia de transação total). O número de despesas individuais e as quantias relevantes são preferencialmente determinadas ou selecionadas em uma base aleatória (por exemplo, por meio de um programa de software de computador que emprega um gerador pseu- doaleatório). O número de despesas individuais e as quantias relevantes são armazenados para posterior recuperação.

[00097] Na etapa 430, o instrumento financeiro indicado é separadamente debitado em cada uma dentre a pluralidade de despesas.

[00098] Na etapa 440, a confirmação da pluralidade de despesas (isto é, o número de despesas separadas e/ou as respectivas quanti- as) é recebida do originador da solicitação. Ou seja, o originador obtém o número de despesas separadas e/ou as respectivas quantias ao acessar sua conta relacionada ao instrumento financeiro e envia essas informações para verificação. Contanto que a confirmação das informações recebida na etapa 440 esteja correta, a transação é verificada na etapa 450. Ao determinar se as informações recebidas na etapa 440 estão corretas, o número de despesas individuais e/ou as respectivas quantias conforme recebidas do comprador é/são comparadas ao número de despesas e/ou às respectivas quantias conforme determinadas na etapa 420.

[00099] A figura 2B é um fluxograma de um método implementado por computador para verificar transações.

[000100] Referindo-se à figura 2B, uma solicitação para verificar uma transação eletrônica para uma quantia de dinheiro predeterminada é recebida na etapa 415.

[000101] Na etapa 425, a quantia predeterminada é dividida em uma pluralidade de despesas tal que a soma das quantias individuais da pluralidade de despesas é igual à quantia de dinheiro predeterminada (isto é, a quantia de transação total). O número de despesas individuais e as quantias relevantes são preferencialmente determinadas ou selecionadas em uma base aleatória (por exemplo, por meio de um programa de software de computador que emprega um gerador pseu- doaleatório). O número de despesas individuais e as quantias relevantes são armazenados para posterior recuperação.

[000102] Na etapa 435, as múltiplas despesas (por exemplo, as quantias) são fornecidas para uma entidade para facilitar o débito de um instrumento financeiro.

[000103] Na etapa 445, a confirmação da pluralidade de despesas (isto é, o número de despesas separadas e/ou as respectivas quantias) é recebida. Essas informações se originam do usuário do instru- mento financeiro e são tipicamente obtidas pelo usuário que acessa sua conta relacionada ao instrumento financeiro.

[000104] Desde que as informações de confirmação recebidas na etapa 445 estejam corretas, a transação é verificada na etapa 455. Ao determinar se as informações recebidas na etapa 445 estão corretas, o número de despesas individuais e/ou as respectivas quantias conforme recebidas do usuário do instrumento financeiro é/são comparadas ao número de despesas e/ou às respectivas quantias conforme determinadas na etapa 425.

[000105] Os métodos e sistemas descritos anteriormente com referência às figuras 2A e 2B podem vantajosamente ser executados para transações de moeda cruzada (isto é, transações em que a moeda de emissão ou a operação de um instrumento financeiro particular (por exemplo, cartão de crédito, cartão de débito, despesa, cartão, conta bancária, etc.) é diferente da moeda da transação (conforme processada pelo comerciante)). Uma desvantagem específica das transações convencionais de moeda cruzada, que tipicamente apenas liquidam vários dias após a ocorrência da transação efetiva, é que a taxa de câmbio aplicada não é simultaneamente conhecida pelo comprador (por exemplo, um titular do cartão) e pelo comerciante.

[000106] A pluralidade de despesas que se somam à quantia da transação predeterminada é armazenada pelo agente de verificação e são posteriormente comparadas aos valores fornecidos pelo comprador para fins de autenticação. A pluralidade de despesas são preferencialmente armazenadas como razões de despesa relativas à quantia predeterminada (isto é, a quantia da transação total) para posterior equiparação aos valores fornecidos pelo comprador. Os valores recebidos pelo agente de verificação do comprador são modificados pela taxa de câmbio entre a moeda do instrumento financeiro (isto é, a moeda do comprador) e a moeda do comerciante (isto é, a moeda do preço do item ou produto anunciado). Cada um dos valores fornecidos pelo comprador (por exemplo, do seu extrato bancário) é convertido pelo agente de verificação nas razões de valor pela divisão de cada um dentre a pluralidade de valores recebidos, respectivamente, pela soma da pluralidade dos valores recebidos. As razões de valor são comparadas às razões de despesa armazenada e a transação é autenticada ou verificada se cada uma das razões de valor corresponde a uma respectiva razão de despesa armazenada dentro de uma margem predefinida de erro ou tolerância de erro (isto é, devido ao arredondamento).

[000107] Cada uma dentre a pluralidade de despesas é convertida para uma razão e armazenada como uma razão de valor de despesa armazenada (SV) como se segue:SV1 = Valor1/(Quantia predeterminada)SV2 = Valor2/(Quantia predeterminada)....SVN = ValorN/(Quantia predeterminada)em que:

[000108] Valor1, Valor2...ValorN são a pluralidade de despesas;

[000109] A quantia predeterminada é a quantia total da transação; e

[000110] A soma(∑) [Valori, Valor2...ValorN] é igual à quantia predeterminada, conforme armazenada na moeda da transação original (ou seja, na moeda do comerciante).A soma das razões armazenadas, Soma(∑) [SVi SV2... SVN ] = 1.

[000111] A resposta do comprador compreende uma pluralidade de valores de resposta (RV) que correspondem à pluralidade de despesas, mas modificados pela taxa de câmbio relevante do dia (isto é, a taxa de câmbio atual entre a moeda do instrumento financeiro usado e a moeda da transação (β)). Note que a taxa de câmbio (β) não precisa ser conhecida e não é geralmente conhecida como parte do processo, e o processo matematicamente elimina a necessidade de saber (β) a fim de comparar os valores recebidos versus os valores armazenados.

[000112] Ao receber a resposta do comprador, a pluralidade de valores de resposta é convertida para razões de resposta do comprador (PR) como se segue:PRi = RVi/ ∑ (RVi, RV2...RVN)PR2 = RV2/ ∑ (RVi, RV2...RVN)PRN = RVN/ ∑ (RVi, RV2...RVN)em que:

[000113] RVi, RV2...RVN são a pluralidade de valores de resposta recebidos do comprador e são relacionados à pluralidade de despesas

[000114] Valori, Valor2...ValorN pelo fator (β)

[000115] PRi, PR2... PRN são a pluralidade de razões de resposta docomprador; e

[000116] Soma(∑) [PRi, PR2... PRN] ~ i sujeita a uma tolerância deerro (ε).

[000117] Agora, se SVi é igual, dentro de uma tolerância de erro predefinida (ε), para qualquer um do PRi ao PRN então isso é considerado ser uma resposta correta para o Valori predeterminado para fins de verificação. Um processo similar é realizado para todas as razões armazenadas remanescentes pela comparação e equiparação do SV2 através do SVN para uma razão de resposta similar correspondente a PR2 através da PRN sujeita à tolerância de erro (ε).

[000118] Cada valor armazenado (SV) precisa ser atribuído a um valor de PR correspondente até todos estarem esgotados. Em caso de existir uma incompatibilidade em valores ou no número efetivo de SV's a PR's, então o processo de autenticação resultará em uma falha.

[000119] Além disso, a taxa de câmbio aplicada à transação pode ser calculada dentro de uma tolerância de erro razoável (ε) ao dividir a quantia predeterminada pela soma das respostas do comprador.

[000120] Vantajosamente, a comparação de razões armazenadas, calculadas usando a pluralidade de despesas como numeradores e a quantia predeterminada como o denominador, com as razões de resposta calculadas ao usar os valores de resposta como numeradores e a soma do total dos valores de resposta como o denominador, matematicamente elimina a necessidade de saber o fator da taxa de câmbio (β) antecipadamente ou como parte do processo.

EXEMPLO

[000121] Um comerciante oferece um produto para venda por US$ 105. Um comprador concorda em comprar o produto por US$ 105 e entra com os detalhes do seu instrumento financeiro (dados) no website do comerciante. O dado é passado para o agente de verificação, que divide os US$105 (isto é, a quantia predeterminada) em duas despesas separadas usando um gerador de número aleatório, por exemplo, US$59,99 e US$45,01. A soma das duas despesas separadas é igual a US$ 105 (isto é, a quantia predeterminada). O agente de verificação armazena as duas despesas separadas como quantias e como razões: US$59,99/US$105 = 0,571333333 e US$40,01/US$105 = 0,381047619.

[000122] O instrumento financeiro do comprador, entretanto, está em outra moeda de modo que as quantias efetivas mostradas no extrato bancário do comprador serão modificadas pela taxa de câmbio do dia (β) para aquela moeda: $59,99β e $40,01β, respectivamente. A quantia predeterminada será também modificada pela taxa de câmbio. O comprador então responderá ao agente de verificação com duas quantias numéricas que diferem em valor numérico absoluto, mas que têm a mesma razão relativa à quantia predeterminada, a saber $59,99β e $45,01β.

[000123] O agente de verificação então calcula as seguintes razões relativas à quantia predeterminada modificada:$59,99β / ($59,99β + $45,01β) = 0,571333333; e $45,01β / ($59,99β + $45,01β) = 0,381047619.

[000124] Como se pode notar, o β variável é matematicamente fato- rado para fora (ou seja, removido), deixando as razões relativas apenas, sujeitas a erros de arredondamento computacionais. Para ilustrar adicionalmente, se a moeda do comerciante é a mesma moeda do comprador, então β será igual à unidade (1), pois os valores de PR se igualarão exatamente aos valores de SV.

[000125] A figura 2C é um fluxograma de um método implementado por computador para verificar transações de moeda cruzada ou autorização de transações de moeda cruzada. O método da figura 2C é similar ao método da figura 2A, à parte da adição das etapas 422, 442, e 444, que se referem especificamente ao aspecto da moeda cruzada. Na etapa 422, a pluralidade de despesas é convertida para razões de despesa pela divisão de cada uma dentre a pluralidade de despesas pela quantia predeterminada e armazenada. Na etapa 444, as razões de despesa armazenada são comparadas às informações recebidas do originador da solicitação (isto é, o comprador) para realização da verificação da transação. As informações recebidas do originador da solicitação compreendem uma pluralidade de valores que correspondem à pluralidade de despesas, cada uma modificada por uma taxa de câmbio (ou seja, a taxa de câmbio entre a moeda do comprador e a moeda do comerciante). A pluralidade de valores é tipicamente obtida do extrato bancário do originador e transmitida ao agente de verificação para autenticação ou verificação. Antes de realizar a comparação, a pluralidade de valores é primeiro convertida para as respectivas razões pela divisão de cada um dentre a pluralidade de valores pela soma da pluralidade de valores. A transação é verificada ou autenticada se cada uma das razões de valor corresponder a uma respectiva razão de despesa armazenada dentro de uma margem predefinida de erro. A etapa 442 é uma etapa opcional, em que o dado de identificação é capturado (por exemplo, o endereço de IP, os números de série, o endereço MAC, o endereço IMEI, etc.) e vinculado à transação e autenticação do pagante (comprador).

[000126] A figura 2D é um fluxograma de um método implementado por computador para verificar transações de moeda cruzada. O método da figura 2D é similar ao método da figura 2B, à parte da adição das etapas 427, 447, e 449, que se referem especificamente ao aspecto da moeda cruzada. Na etapa 427, a pluralidade de despesas é convertida para razões de despesa pela divisão de cada uma dentre a pluralidade de despesas pela quantia predeterminada e armazenada. Na etapa 449, as razões de despesa armazenada são comparadas às informações recebidas do originador da solicitação (ou seja, o comprador) para realização da verificação da transação. As informações recebidas do originador da solicitação compreendem uma pluralidade de valores que correspondem à pluralidade de despesas, cada uma modificada por uma taxa de câmbio (isto é, a taxa de câmbio entre a moeda do comprador e a moeda do comerciante). A pluralidade de valores é tipicamente obtida do extrato bancário do originador e transmitida ao agente de verificação para autenticação ou verificação. Antes de realizar a comparação, a pluralidade de valores são primeiro convertidos às respectivas razões pela divisão de cada um dentre a pluralidade de valores pela soma da pluralidade de valores. A transação é verificada e autenticada se cada uma das razões de valor corresponder a uma respectiva razão de despesa armazenada dentro de uma margem de erro predefinida. A etapa 447 é uma etapa opcional, em que o dado de identificação é capturado (por exemplo, endereço de IP, números de série, endereço MAC, endereço IMEI, etc.) e vinculado à transação e autenticação do pagante (comprador).

[000127] Os métodos descritos anteriormente com referência às figuras 2A, 2B, 2C e 2D são tipicamente realizados por um agente de verificação, também conforme descrito anteriormente.

[000128] As figuras 3A e 3B representam um sistema de computador 300 para fins gerais, com o qual as várias disposições descritas no presente documento podem ser executadas.

[000129] Conforme visto na figura 3A, o sistema de computador 300 inclui: um módulo do computador 301; os dispositivos de entrada tais como um teclado 302, um dispositivo indicador de mouse 303, um scanner 326, uma câmera 327, e um microfone 380; e os dispositivos de saída incluindo uma impressora 315, um dispositivo de visualização 314 e alto-falantes 317. Um dispositivo transceptor Modulador- Demodulador externo (Modem) 316 pode ser usado pelo módulo do computador 301 para se comunicar com e partir de uma rede de comunicações 320 através de uma conexão 321. A rede de comunicações 320 pode ser uma rede de área ampla (WAN), tal como a Internet, uma rede de telecomunicações de celular, ou uma WAN privada.

[000130] Quando a conexão 321 é uma linha de telefone, o modem 316 pode ser um modem "de acesso discado" tradicional. Alternativamente, onde a conexão 321 for uma conexão de alta capacidade (por exemplo, cabo), o modem 316 pode ser um modem de banda larga. Um modem sem fio pode também ser usado para a conexão sem fio à rede de comunicações 320.

[000131] O módulo do computador 301 tipicamente inclui pelo menos uma unidade de processador 305, e uma unidade de memória 306. Por exemplo, a unidade de memória 306 pode ter a memória de acesso aleatório semicondutora (RAM) e a memória apenas para leitura semicondutora (ROM). O módulo do computador 301 também inclui um número de interfaces de entrada/saída (I/O) que incluem: uma interface de áudio-vídeo 307 que se acopla à tela de vídeo 314, aos alto- falantes 317 e ao microfone 380; uma interface de I/O 313 que se acopla ao teclado 302, ao mouse 303, ao scanner 326, à câmera 327 e opcionalmente a um joystick ou outro dispositivo de interface humana (não ilustrado); e a uma interface 308 para o modem externo 316 e à impressora 315. Em algumas implantações, o modem 316 pode ser incorporado dentro do módulo do computador 301, por exemplo dentro da interface 308. O módulo do computador 301 também tem uma interface de rede local 311, que permite acoplar o sistema de computador 300 através de uma conexão 323 para uma rede de comunicações de área local 322, conhecida como uma Rede de Área Local (LAN). Conforme ilustrado na figura 3A, a rede local de comunicações 322 pode também se acoplar à rede ampla 320 através de uma conexão 324, que incluiria tipicamente um chamado dispositivo de "firewall" ou dispositivo de funcionalidade similar. A interface de rede local 311 pode compreender um cartão de circuito de Ethernet®, uma disposição sem fio de Bluetooth™ ou uma disposição sem fio de IEEE 802.11; entretanto, outros tipos numerosos de interfaces podem ser executados para a interface 311.

[000132] As interfaces de I/O 308 e 313 podem proporcionar uma ou ambas da conectividade serial e paralela, a anterior tipicamente sendo implantada de acordo com os padrões de Barramento Serial Universal (USB) e tendo os conectores de USB correspondentes (não ilustrados). Os dispositivos de armazenagem 309 são proporcionados e tipicamente incluem um drive de disco rígido (HDD) 310. Outros dispositivos de armazenagem tais como um drive de disquete e um drive de fita magnética (não ilustrado) podem também ser usados. Um drive de disco ótico 312 é tipicamente proporcionado para agir como uma fonte de dados não volátil. Os dispositivos de memória portáteis, como discos óticos (por exemplo, CD-ROM, DVD, Disco de Blu-ray®), USB- RAM, drives rígidos externos, portáteis, e disquetes, por exemplo, po- dem ser usados como fontes de dados apropriadas ao sistema 300.

[000133] Os componentes 305 a 313 do módulo do computador 301 tipicamente se comunicam através de um barramento interconectado 304 e em uma maneira que resulte em um modo de operação convencional do sistema de computador 300 conhecido por aqueles na técnica relevante. Por exemplo, o processador 305 é acoplado ao barra- mento do sistema 304 usando uma conexão 318. Do mesmo modo, a memória 306 e o drive de disco ótico 312 são acoplados ao barramen- to do sistema 304 pelas conexões 319. Os exemplos de computadores nos quais as disposições descritas podem ser executadas incluem IBM-PC's e compatíveis, Sun Sparcstations, Apple Mac® ou sistemas de computador similares.

[000134] O método de verificação da autorização de uma transação conforme descrito anteriormente pode ser implementado usando o sistema de computador 300 em que os processos das figuras 1 e 2 podem ser implementados como um ou mais programas de aplicativo de software 333 executáveis dentro do sistema de computador 300. Em particular, as etapas do método de verificação de uma transação eletrônica são efetuadas pelas instruções 331 (ver a figura 3B) no software 333 que são realizadas dentro do sistema de computador 300. As instruções de software 331 podem ser formadas por um ou mais módulos de código, cada um para realizar uma ou mais tarefas específicas. O software pode também ser dividido em duas partes separadas, em que uma primeira parte e os módulos de código correspondentes realizam os métodos de verificação da transação e uma segunda parte e os módulos de código correspondentes gerenciam uma interface de usuário entre a primeira parte e o usuário.

[000135] O software pode ser armazenado em um meio legível por computador, incluindo os dispositivos de armazenagem descritos abaixo, por exemplo. O software é carregado no sistema de computador 300 a partir do meio legível por computador, e então executado pelo sistema de computador 300. Um meio legível por computador que tenha tal software ou programa de computador gravado no meio legível por computador é um produto de programa de computador. O uso do produto de programa de computador no sistema de computador 300 preferencialmente produz um aparelho vantajoso para verificar transações eletrônicas.

[000136] O software 333 é tipicamente armazenado no HDD 310 ou na memória 306. O software é carregado no sistema de computador 300 a partir de um meio legível por computador, e executado pelo sistema de computador 300. Dessa maneira, por exemplo, o software 333 pode ser armazenado em um meio de armazenagem de disco legível oticamente (por exemplo, CD-ROM) 325 que é lido pelo drive de disco ótico 312. Um meio legível por computador que tenha tal software ou programa de computador gravado em é um produto de programa de computador. O uso do produto de programa de computador no sistema de computador 300 preferencialmente produz um aparelho para verificar transações eletrônicas.

[000137] Em alguns exemplos, os programas de aplicativo 333 podem ser fornecidos ao usuário codificados em um ou mais CD-ROMs 325 e lidos através do drive correspondente 312, ou alternativamente podem ser lidos pelo usuário a partir das redes 320 ou 322. Ainda adicionalmente, o software pode também ser carregado no sistema de computador 300 a partir de outro meio legível por computador. O meio de armazenagem legível por computador refere-se a qualquer meio de armazenagem que forneça instruções gravadas e/ou dados para o sistema de computador 300 para realização e/ou processamento. Os exemplos de tal meio de armazenagem incluem disquetes, fita magnética, CD-ROM, DVD, Disco de Blu-ray, um drive de disco rígido, uma ROM ou circuito integrado, memória USB, um disco magneto-ótico, ou um cartão legível por computador tal como um cartão PCMCIA e o similar, se tais dispositivos são ou não internos ou externos do módulo do computador 301. Os exemplos de meios de transmissão legíveis por computador que podem também participar no fornecimento de software, programas de aplicativo, instruções e/ou dados para o módulo do computador 301 incluem canais de transmissão por rádio ou transmissão por infravermelho bem como uma conexão de rede para outro computador ou dispositivo ligado em rede, e a Internet ou Intranets que incluem transmissões de e-mail e informações gravadas em websites e similares.

[000138] A segunda parte dos programas de aplicativos 333 e dos módulos de código correspondentes mencionados acima pode ser executada para implantar uma ou mais interfaces gráficas de usuário (GUIs) para serem apresentadas ou senão representadas na tela 314. Através da manipulação de tipicamente o teclado 302 e o mouse 303, um usuário do sistema de computador 300 e o aplicativo podem manipular a interface em uma maneira adaptável de funcionalidade para proporcionar comandos de controle e/ou entrada para os aplicativos associados às GUI(s). Outras formas de funcionalidade adaptável às interfaces do usuário podem também ser implantadas, tal como uma interface de áudio que utilize a saída de lembretes de fala através dos alto-falantes 317 e a entrada de comandos de voz do usuário através do microfone 380. A figura 3B é um diagrama de bloco esquemático detalhado do processador 305 e uma "memória" 334. A memória 334 representa uma agregação lógica de todos os módulos de memória (incluindo o HDD 309 e a memória semicondutora 306) que podem ser acessados pelo módulo do computador 301 na figura 3A.

[000139] Quando o módulo do computador 301 é inicialmente acionado, um programa de autoteste de incialização (POST) 350 executa. O programa POST 350 é tipicamente armazenado em uma ROM 349 da memória semicondutora 306 da figura 3A. Um dispositivo de hardware tal como o ROM 349 que armazena o software é algumas vezes referido como firmware. O programa POST 350 examina o hardware dentro do módulo do computador 301 para assegurar o funcionamento apropriado e tipicamente verifica o processador 305, a memória 334 (309, 306), e um módulo básico de software de sistemas de entrada-saída (BlOS) 351, também tipicamente armazenado na ROM 349, para a correta operação. Uma vez que o programa POST 350 tenha rodado com sucesso, o BIOS 351 ativa o drive de disco rígi-do 310 da figura 3A. A ativação do drive de disco rígido 310 desencadeia um programa de carregamento de inicialização 352 que é residente no drive disco rígido 310 para executar através do processador 305. Essas cargas no sistema de operação 353 na memória RAM 306, após o qual o sistema de operação 353 começa a operação. O sistema de operação 353 é um aplicativo de nível do sistema, executável pelo processador 305, para cumprir várias funções de alto nível, incluindo o gerenciamento do processador, o gerenciamento da memória, o gerenciamento do dispositivo, o gerenciamento da armazenagem, a interface de aplicativo de software, e interface genérica de usuário.

[000140] O sistema de operação 353 gerencia a memória 334 (309, 306) para assegurar que cada processo ou aplicativo que rode no módulo do computador 301 tenha memória suficiente no mesmo para executar sem colidir com a memória alocada para outro processo. Além disso, os diferentes tipos de memória disponíveis no sistema 300 da figura 3A precisam ser usados adequadamente de modo que cada processo possa rodar efetivamente. Portanto, a memória agregada 334 não é destinada a ilustrar como os segmentos particulares de memória são alocados (exceto se determinado o contrário), mas sim para fornecer uma visão geral da memória acessível pelo sistema de computador 300 e como tal é usado.

[000141] Conforme mostrado na figura 3B, o processador 305 inclui um número de módulos funcionais que incluem uma unidade de controle 339, uma unidade lógica aritmética (ALU) 340, e uma memória interna ou local 348, algumas vezes chamada de memória cache. A memória cache 348 tipicamente inclui um número de registros de armazenagem 344 a 346 em uma seção de registro. Um ou mais barra- mentos internos 341 funcionalmente se interconectam a esses módulos funcionais. O processador 305 tipicamente também tem uma ou mais interfaces 342 para comunicação com dispositivos externos através do barramento do sistema 304, usando uma conexão 318. A memória 334 é acoplada ao barramento 304 usando uma conexão 319.

[000142] O programa de aplicativo 333 inclui uma sequência de instruções 331 que podem incluir ramificações condicionais e instruções de circuito elétrico. O programa 333 pode também incluir o dado 332 que é usado na execução do programa 333. As instruções 331 e o dado 332 são armazenadas nos lugares da memória 328, 329, 330 e 335, 336, 337, respectivamente. Dependendo do tamanho relativo das instruções 331 e dos lugares da memória 328 a 330, uma instrução específica pode ser armazenada em um único lugar de memória como representado pela instrução mostrada no lugar de memória 330. Alter-nativamente, uma instrução pode ser segmentada em um número de partes e cada qual é armazenada em um lugar de memória separado, conforme representado pelos segmentos da instrução mostrados nos lugares de memória 328 e 329.

[000143] Em geral, ao processador 305 é dado um conjunto de instruções que são executadas no mesmo.

[000144] O processador 305 espera por uma entrada subsequente, à qual o processador 305 reage pela execução de outro conjunto de instruções. Cada entrada pode ser fornecida por um ou mais de um número de fontes, incluindo os dados gerados por um ou mais dos dis- positivos de entrada 302, 303, os dados recebidos de uma fonte externa através de uma das redes 320, 302, os dados recuperados de um dos dispositivos de armazenagem 306, 309 ou os dados recuperados de um meio de armazenagem 325 inseridos na leitora correspondente 312, todos representados na figura 3A. A execução de um conjunto de instruções pode em alguns casos resultar na saída de dados. A execução pode também envolver a armazenagem de dados ou variáveis para a memória 334.

[000145] As disposições de verificação da transação revelada usam variáveis de entrada 354, que são armazenadas na memória 334 nos lugares de memória correspondentes 355, 356, 357. As disposições de verificação da transação produzem variáveis de saída 361, que são armazenadas na memória 334 nos lugares de memória correspondentes 362, 363, 364. As variáveis intermediárias 358 podem ser armazenadas nos lugares de memória 359, 360, 366 e 367.

[000146] Referindo-se ao processador 305 da figura 3B, os registros 344, 345, 346, a unidade lógica aritmética (ALU) 340, e a unidade de controle 339 trabalham juntos para realizar as sequências de micro- operações necessárias para realizar ciclos de "busca, decodificação, e execução" para cada instrução no conjunto de instrução que constitui o programa 333. Cada ciclo de busca, decodificação, e execução compreende:

[000147] uma operação de busca, que busca ou lê uma instrução 331 de um lugar de memória 328, 329, 330;

[000148] uma operação de decodificação na qual a unidade de controle 339 determina que instrução foi buscada; e

[000149] uma operação de execução em que a unidade de controle 339 e/ou a ALU 340 executa a instrução.

[000150] Consequentemente, um ciclo adicional de busca, decodifi- cação e execução para a próxima instrução pode ser executado. Simi- larmente, um ciclo de armazenagem pode ser realizado através do qual a unidade de controle 339 armazena ou escreve um valor para um lugar de memória 332.

[000151] Cada etapa ou subprocesso nos processos das figuras 1 e 2 está associada a um ou mais segmentos do programa 333 e é realizada pela seção de registro 344, 345, 347, e pela ALU 340, e pela unidade de controle 339 no processador 305 que trabalham juntas para realizar os ciclos de busca, decodificação, e execução para cada instrução no conjunto de instrução para os segmentos mencionados do programa 333.

[000152] Os processos de autenticação do pagante descritos anteriormente podem também formar parte de um processo maior envolvendo uma assinatura eletrônica para execução de contratos ou registros, por meio da qual o processo de autenticação é anexado a ou logicamente associado a um contrato ou outro registro executado ou adotado por uma pessoa com a intenção de assinar o registro. A soma predeterminada pode, por exemplo: (i) formar parte da consideração monetária associada ao contrato, (ii) ser um pagamento associado à execução ou apresentação de um contrato ou registro, ou iii) ser uma taxa cobrada individualmente a qualquer um, a algumas ou todas as partes em um contrato de um provedor de serviço (terceiro) que age como provedor de autenticação independente de assinaturas eletrônicas. Em cada caso, a aplicação com sucesso do processo serve como um processo anexo ou associado para autenticação de cada assinatura eletrônica da parte em relação ao contrato ou registro.

[000153] A geração da pluralidade de despesas (cujo total é a quantia predeterminada) também age como um sistema para gerar dinamicamente chaves exclusivas que precisam ser fornecidas pelo titular do cartão como uma resposta a um desafio emitido pelo agente de verificação a fim de autenticar aquela transação específica. Para acessar o valor das chaves dinâmicas, o titular do cartão tipicamente precisa acessar seus sistemas bancários de internet ou telefone existentes e procurar e retornar o valor das chaves.

[000154] Os métodos e sistemas descritos anteriormente podem vantajosamente ser executados em uma base por transação. Diferentemente de outros sistemas existentes, o pré-registro de usuários (por exemplo, clientes ou compradores) não é necessário, o que substancialmente aumenta a conveniência para os usuários. Além disso, o instrumento financeiro e/ou os detalhes do usuário não são necessários serem armazenados por um intermediário, o que vantajosamente contribui para a segurança.

[000155] As modalidades descritas anteriormente envolvem o débito em oposição ao crédito de um instrumento financeiro. Isso é vantajoso naqueles instrumentos financeiros tais como cartões de crédito e débito que são debitados substancialmente instantaneamente. O crédito de tais instrumentos financeiros, por outro lado, geralmente envolve prazos mais longos devido às verificações de liberação, etc., e é então muito lento e nem flexível ou conveniente. De acordo com as modalidades descritas anteriormente, a verificação pode vantajosamente ser proporcionada substancialmente instantaneamente após o recebimento de uma solicitação do usuário ou comprador.

[000156] As modalidades descritas anteriormente envolvem transações de pagamento efetivas de um comerciante para produto ou serviços ao invés da simulação inicial, as transações de pré-autorização. Tais transações fantasmas podem impactar um desejo do comprador de subsequentemente revisitar o comerciante e concluir uma transação, e podem também ser limitações em termos de fraude atenuante. Por exemplo, um instrumento financeiro pode ser pré-autorizado pelo uso de uma transação fantasma, subsequentemente perdida ou roubada, porém ainda aparece como autorizada para uso até ser retirada pela instituição financeira relevante. O período entre a perda e retirada é tipicamente o período que a fraude ocorre, o que faz a pré- autorização menos desejável do que se não tivesse se confiado.

[000157] As modalidades descritas anteriormente vantajosamente usam dados ou informações relacionadas a ou contidas na transação para verificar a autenticidade da transação. Esses dados ou informações são conhecidos apenas pelo titular autorizado do instrumento financeiro relevante e pela instituição financeira do titular do instrumento financeiro.

[000158] Em certas modalidades, os métodos e sistemas descritos no presente documento podem ser implementados para cada e toda transação iniciada caso a caso ou por comerciante por comerciante.

[000159] Em certas modalidades, os métodos e sistemas descritos no presente documento podem ser implementados seguindo um conjunto de critérios de risco que são identificados, independentemente de se o método ou sistema foi previamente implementado para o instrumento financeiro particular. O critério de risco pode, por exemplo, ser determinado pelo comerciante e/ou pela porta de entrada de pagamento. Tal critério pode, por exemplo, incluir: o(s) produto/s ou servi- ço/s que é(são) comprado(s) como parte de uma transação identificada como sendo de alto risco, o(s) produto/s ou serviço/s sendo com- prado(s) estando acima de um valor de limiar monetário, e a solicitação do comprador originária de um Endereço de IP fora do limite nor-malmente associado ao instrumento financeiro ou de um instrumento financeiro que foi usado para efetuar uma alta frequência de compras recentemente, ou caso contrário.

[000160] Algumas vantagens de uma ou mais modalidades descritas anteriormente incluem:(i) Os detalhes completos do próprio instrumento financeiro (por exemplo, número de cartão de crédito e/ou detalhes do compra dor) não precisam ser passados ao agente de verificação, pois o agente de verificação verifica cada transação única em um caso a caso (isto é, a transação é atribuída a um identificador único que não necessariamente corresponde a quaisquer detalhes relativos ao instrumento financeiro, à porta de entrada de pagamento, ou ao comerciante). O conhecimento dos detalhes do instrumento financeiro efetivo não é necessário para realizar a verificação.(ii) O agente de verificação não é suscetível à perda dos dados sensíveis se raqueados, pois o instrumento financeiro completo e/ou detalhes do usuário não são armazenados pelo agente de verificação.(iii) Em certas modalidades, a transferência de fundos do instrumento financeiro do comprador para o comerciante é iniciada imediatamente e a verificação da autorização pode ser realizada quase instantaneamente ou logo após a transferência de fundos ser solicitada.(iv) Em certas modalidades em que a verificação é através de uma instituição financeira ou Rede de Esquema de Cartão usando um agente de verificação, o comerciante recebe a autorização para a transação que foi sujeita à verificação a partir da porta de entrada de pagamento. O agente de verificação é então transparente para o comerciante, pois os processos existentes continuam a ser utilizados. O início da compensação e liquidação de fundos pelas instituições financeiras pode ser diferido até tal momento que a autenticação do comprador esteja completa, assim fornecendo vantagens para a instituição financeira. Isso também tem o benefício de alterações mínimas, se houverem, para intercomunicações entre o comerciante e a porta de entrada de pagamento para fins de processamento de transações.(v) O comprador não tem que completar, antes de uma transação efetiva, quaisquer processos de inicialização, criação de conta/inscrição de terceiro ou intermediário, autorização antecipada ou outros processos não associados diretamente com a compra.(vi) Dependendo da implantação escolhida, o comerciante não tem que completar nenhuma criação de conta/inscrição de terceiro ou intermediário, ou negociar com quaisquer instituições financeiras, portas de entrada de pagamento, e/ou Redes de Esquema de Cartão a não ser com aqueles que já negocia.(vii) A verificação de autorização pode ser realizada em um caso a caso, incluindo e até o caso de cada e toda transação.(viii) Onde um cartão ou outro instrumento financeiro opera em uma moeda que difere da moeda usada por um comerciante, não existe a necessidade de saber a taxa de câmbio atual entre a moeda do instrumento financeiro e a moeda do comerciante.(ix) A soma das quantias individuais de dinheiro cobradas ao instrumento financeiro designadas pelo comprador equivale ao total da transação efetiva como iniciada pelo comprador sem a necessidade de transações separadas para fornecer os créditos ou despesas de 'balanço'.(x) A confirmação da pluralidade de despesas e quantias aleatórias cobradas (a soma das mesmas equivale à quantia predeterminada) proporciona um alto nível de confiança contra fraude.(xi) Os dispositivos, endereços roteáveis eletronicamente ou arquivos eletrônicos usados ou submetidos como parte do processo de verificação podem também ser vinculados à autenticação com sucesso do comprador e usados para identificar o cliente para subsequentes aplicações ou vincular cada combinação do nome no mundo real do cliente, o identificador do cliente, o número de série do dispositivo, os endereços roteáveis eletronicamente, os arquivos, o instrumento financeiro e a transação uns aos outros.(xii) Os dispositivos, endereços roteáveis eletronicamente, números de série, endereços MAC, números IMEI, etc., podem ser capturados para uso posterior como prova em situações de contestação do estorno em uma base transacional e podem ser opcionalmente vinculados ao pagante para referência futura.(xiii) Diferentemente dos códigos de PIN estáticos pré- atribuídos logicamente anexados a um instrumento financeiro, tal como Visa's 3D Secure® ou Mastercard's SecureCode®, a geração da pluralidade de despesas age como o código exclusivo gerado dinamicamente associado à transação específica apenas. Isso é vantajoso, pois um PIN estático não é armazenado centralmente, com tal PIN estático sujeito ao raqueamento e uso não autorizado, e, em virtude da pluralidade de despesas agindo como códigos exclusivos, cada transação tem sua própria característica única de autorização. Isso propicia segurança de diversas ordens de magnitude mais difícil de quebrar por métodos de raqueamento do que o raqueamento de um PIN convencional. Isso também não está sujeito a preocupações de segurança associadas à armazenagem de detalhes do cartão junto a um PIN em sistemas de servidor, e às consequências catastróficas do número do cartão e PIN sendo usados por partes não autorizadas.(xiv) O prazo e opcionalmente o Endereço de IP do cliente que acessa a pluralidade de despesas através dos seus bancos existentes na internet pode ser registrado pela instituição financeira, e, comparados ao prazo e opcionalmente ao Endereço de IP da resposta para o agente de verificação, e fornecer prova adicional da autorização pelo titular do cartão.Aplicação Industrial

[000161] As disposições descritas são aplicáveis às indústrias de informática e processamento de dados e particularmente para o processamento e verificação de transações eletrônicas. A descrição supracitada proporciona modalidades exemplificativas apenas, e não é desti- nada a limitar o escopo, a aplicabilidade ou configurações da presente invenção. Preferencialmente, a descrição das modalidades exemplifi- cativas proporciona àqueles versados na técnica a possibilitar as descrições para implantar as modalidades da invenção. Várias alterações podem ser feitas na função e disposição dos elementos sem se afastar da essência e escopo da invenção conforme apresentado nas reivindicações a seguir.

[000162] Onde características, elementos e etapas específicos aqui referidos têm equivalências na técnica à qual a invenção se refere, tais equivalências conhecidas são consideradas como sendo incorporadas no presente documento como se apresentadas individualmente. Além disso, as características, elementos e etapas referidos a ou descritos em relação a uma modalidade particular da invenção pode formar parte de quaisquer das outras modalidades exceto se determinado o contrário.

[000163] (Apenas Austrália) No contexto deste relatório descritivo, a palavra "que compreende" significa "que inclui principalmente, mas não necessariamente de maneira exclusiva" ou "que tem" ou "que inclui", e não "que consiste apenas em". As variações da palavra "que compreende", tal como "compreendem" e "compreende" têm significados variados correspondentes.

Claims (7)

1. Método implementado por computador para verificar a autorização de uma transação eletrônica caracterizado pelo fato de compreender:receber uma solicitação para processar uma transação eletrônica para uma quantia predeterminada, a dita solicitação compreendendo dados que identificam um instrumento financeiro particular;dividir a quantia predeterminada em uma pluralidade de despesas em uma base aleatória;determinar informações relacionadas com a dita pluralidade de despesas compreendendo um ou mais do grupo que consiste de: uma quantia de cada uma da dita pluralidade de despesas; e um número da dita pluralidade de despesas;fazer com que o instrumento financeiro seja debitado com cada uma dentre a pluralidade de despesas;receber informações relacionadas à pluralidade de despesas de um originador da solicitação;comparar as informações recebidas do originador da solicitação com as ditas informações determinadas relativas à pluralidade de despesas para determinar se as informações recebidas do originador da solicitação estão corretas; everificar a transação somente se a informação recebida estiver correta.

2. Método implementado por computador de acordo com a reivindicação 1, caracterizado pelo fato de que a informação recebida do originador da solicitação inclui uma pluralidade de valores relacionados à pluralidade de despesas, em que cada um da pluralidade de valores é uma despesa correspondente modificada por um fator predeterminado, e em que o método compreende as etapas adicionais de: determinar uma representação de verificação para cada uma dentre as despesas, a representação de verificação para cada despesa sendo determinada em relação à quantia predeterminada;armazenar a representação de verificação para cada um das despesas; edeterminar uma representação de verificação para cada um dos valores, cada representação de verificação para cada valor sendo determinada em relação à soma dos valores,em que comparar as informações recebidas do originador da solicitação com as informações armazenadas relativas à pluralidade de despesas compreende comparar as representações de verificação dos valores com as representações de verificação das despesas, eem que a informação recebida é correta se cada uma das representações de verificação da pluralidade de valores corresponder, dentro de uma quantidade de erro predefinida, a uma respectiva representação de verificação armazenada da pluralidade de despesas.

3. Método implementado por computador de acordo com a reivindicação 1 ou 2, caracterizado pelo fato de que:a solicitação para processar a transação eletrônica dinheiro é recebida através de um sistema de computador de porta de entrada de pagamento, um sistema de computador de instituição financeira comercial, e um sistema de computador de rede de esquema de cartão; efazer com que o instrumento financeiro seja debitado com cada uma dentre a pluralidade de despesas inclui comunicar com o sistema de computador de rede de esquema de cartões, para fazer com que o sistema de computador de rede de esquema de cartões processe uma transferência de fundos por comunicação bidirecional com o sistema de computador da instituição financeira comercial e um sistema de computador da instituição financeira originadora.

4. Método implementado por computador, de acordo com qualquer uma das reivindicações anteriores, caracterizado pelo fato de que a soma da pluralidade de despesas é igual à dita quantia predeterminada.

5. Método implementado por computador, de acordo com qualquer uma das reivindicações anteriores, caracterizado pelo fato de que a pluralidade de despesas age como um código gerado dinamicamente uma vez que é exclusivo para transação.

6. Método implementado por computador, de acordo com qualquer uma das reivindicações anteriores, caracterizado pelo fato de que a quantia predeterminada é dividida na pluralidade de despesas em uma base aleatória usando um gerador de números aleatórios.

7. Método implementado por computador, de acordo com qualquer uma das reivindicações anteriores, caracterizado pelo fato de que o método é aplicado a transações individuais.

Images