BRPI0709074A2

BRPI0709074A2 - transações financeiras usando um dispositivo de comunicação

Info

Publication number: BRPI0709074A2
Application number: BRPI0709074-9A
Authority: BR
Inventors: Howard J Gerson
Original assignee: Phone1 Inc; Howard J Gerson
Priority date: 2006-03-21
Filing date: 2007-03-16
Publication date: 2011-06-28
Also published as: WO2007109559A2; WO2007109559A3; CA2647074A1; EP1999713A2; US20100235283A1

Abstract

TRANSAçõES FINANCEIRAS USANDO UM DISPOSITIVO DE COMUNICAçãO. A presente invenção refere-se a um sistema implementado em computador que provê um método para conduzir uma transação financeira. O método começa quando o sistema atribui um designador de um valor usando uma pré-autorização por um pagador. O sistema associa o pagador com um identificador de telefone de pagador autorizado. Quando o sistema recebe uma chamada telefónica com o identificador do telefone do pagador autorizado em um número de telefone de discagem interna direta (DID) especificado associado com um tipo de transação, o sistema responde enviando pelo menos um código de transação para o pagador. Quando o sistema recebe o código de transação do recebedor, o designador do valor é novamente atribuído do pagador para o recebedor. O sistema permite que o código de transação seja entregue diretamente do pagador para o recebedor ou enviado automaticamente para o recebedor. Cada número de telefone DID representa tipos diferentes de transação tais como caixa eletrónico (ATM), pessoa a pessoa (P2P), transações comerciais, transações de vendas e outros tipos de transações.

Description

Relatório Descritivo da Patente de Invenção para "TRANSA-ÇÕES FINANCEIRAS USANDO UM DISPOSITIVO DE COMUNICAÇÃO".

Campo da Invenção

A presente invenção refere-se, de forma geral, ao campo de te-lecomunicações, e mais particularmente ao uso de um telefone ou outro apa-relho telefônico sem fio para conduzir transações financeiras.Antecedentes da Invenção

Existem vários processos usados para conduzir uma transaçãofinanceira para o pagamento de bens e serviços entre um pagador e um re-cebedor, também conhecido como um beneficiário. Mecanismos de paga-mento disponíveis incluem dinheiro e equivalentes de dinheiro, transferên-cias eletrônicas, transferências ACH, cupons, cartões de crédito e débito,cartões de valor armazenado e cartões de presente.

O e-comércio se desenvolveu rapidamente com a Internet e aadoção do e-mail. Vários sistemas com base em conta, tal como esses dis-poníveis de PayPaI e Google, deixam qualquer um com acesso à rede e umendereço de e-mail enviar e receber seguramente pagamentos em linha u-sando seu cartão de crédito ou conta bancária. Sistemas em linha se torna-ram um método barato para comerciantes aceitarem cartões de crédito nassuas frentes de loja em linha ao invés de usar um caminho de pagamentotradicional.

Esforços para estender esses sistemas de pagamento não tradi-cionais incluem transformar um telefone celular em uma carteira eletrônica.Um exemplo de uma carteira eletrônica para transferir fundos pelo telefonecelular é o PayPaI Mobile. Esses sistemas de pagamento possibilitam queconsumidores enviem pagamentos através do telefone via mensagem detexto ou chamando um sistema de serviço de consumidor automático e u-sando comandos de voz.

Embora vários esforços para estender o uso de um telefone ce-lular como uma carteira eletrônica para transações financeiras tenham sidomuito úteis, existem inconvenientes e problemas conhecidos. Um inconveni-ente com muitos sistemas atuais para conduzir o pagamento com telefonecelular é que eles exigem modificações de hardware e/ou de software pararecuperar e algumas vezes criptografar os dados. Modificações de hardwarepara esses tipos de soluções incluem leitoras sem contato tais como leitorasde RFID, BIueTooth e código de barras. Outros sistemas atualmente dispo-níveis são com base em cartões chave e memory sticks removíveis para ar-mazenar a informação da conta e mecanismos de segurança. Modificaçõesde software incluem aplicações de cliente especializadas e acionadores es-pecializados. A exigência de hardware e/ou software especializados significaque muitos dos milhões de telefones celulares atuais em uso atualmente nãofuncionarão. Dessa maneira, existe uma necessidade de superar esse pro-blema.

Um outro inconveniente com muitos dos sistemas atuais paraconduzir pagamento com telefones celulares é que eles comprometem aprivacidade do recebedor. Muitos sistemas disponíveis atualmente exigemque o recebedor proveja informação pessoalmente identificável. Para evitaresse problema, os recebedores freqüentemente insistem em serem pagosem dinheiro para permanecerem anônimos e para evitar serem associadoscom uma dada transação. O anonimato do recebedor é desejável nas situa-ções onde estar associado com um dado tipo de transação seria embaraço-so. Por exemplo, a compra de produtos de perda de peso, fraldas para adul-tos e semelhantes. Dessa maneira, existe uma necessidade de superar esseproblema.

Ainda um outro inconveniente com muitos sistemas atuais paraconduzir pagamento com telefones celulares é que não existe mecanismopara prover o pagamento para um recebedor em um caixa eletrônico (ATM),a menos que o recebedor tenha uma conta no sistema de pagamento. Des-sa maneira, existe uma necessidade de superar esse problema.

Ainda um outro inconveniente com muitos sistemas atuais paraconduzir o pagamento com telefones celulares é manter a segurança da in-formação da transação tais como códigos de transação e PlNs. Embora vá-rias técnicas de criptografia de máquina estejam sendo usadas, essas exi-gem hardware especial ou modificações no telefone celular do usuário. Des-sa maneira, existe uma necessidade de superar esse problema.

Ainda um outro inconveniente com muitos sistemas atuais paraconduzir o pagamento com telefones celulares é a incapacidade de transferirdinheiro em moedas nacionais diferentes. Embora serviços tal como Wes-tern Union permitam que o dinheiro seja transferido entre filiais da WesternUnion em vários países e em moedas nacionais diferentes, atualmente, nãoexiste mecanismo para permitir que tal transferência ocorra entre um paga-dor usando um telefone e um recebedor em um ATM.

Dessa maneira, o que é necessário é um sistema implementado em computador para superar os problemas encontrados na técnica anteriore para prover um método de condução de uma transação financeira usandoum aparelho telefônico sem fio ou telefone celular.Sumário da Invenção

É revelado um sistema de pagamento eletrônico implementado em computador que prove um método para conduzir uma transação financei-ra. O processo começa quando o sistema de pagamento eletrônico atribuium designador de um valor, tal como uma quantia em dólar, usando umapré-autorização por um pagador. O sistema de pagamento eletrônico asso-cia o pagador com um identificador de telefone do pagador autorizado ou identificador do dispositivo. Quando o sistema de pagamento eletrônico re-cebe uma chamada telefônica com o identificador de telefone do pagadorautorizado em um número de telefone de discagem interna direta (DID) es-pecificado associado com um tipo de transação, o sistema de pagamentoeletrônico responde criando pelo menos um código de transação. Quando o sistema de pagamento eletrônico recebe o código de transação e/ou a con-firmação do recebedor, o designador do valor é novamente atribuído do pa-gador para o recebedor. A presente invenção permite que o código de tran-sação seja entregue diretamente do pagador para o recebedor fora do sis-tema de pagamento eletrônico ou enviado automaticamente pelo sistema depagamento eletrônico para o recebedor. Em uma modalidade, cada númerode telefone DID representa tipos diferentes de transação, tais como caixaeletrônico (ATM), pessoa para pessoa (P2P), transações comerciais, transa-ções de vendas e outros tipos de transações. Em uma outra modalidade, osvários tipos de transações podem ser selecionados de um número de telefo-ne DID único.

Em uma outra modalidade, o sistema de pagamento eletrônicoimplementado em computador provê conversão de moeda entre uma primei-ra moeda nacional e uma segunda moeda, tal como dólares americanos pa-ra euros.

Em uma outra modalidade, o sistema de pagamento eletrônicoimplementado em computador provê uma cifra de transposição para o paga-dor e/ou o recebedor. A cifra de transposição é selecionada de um grupo decifras de transposição consistindo em cifra de rota, cifra de transposição co-lunar, cifra de transposição dupla, cifra de substituição e cifra de adição, pormeio do que o código de transação deve ser decriptografado pelo usuárioantes do uso sem qualquer hardware especializado.

Em uma outra modalidade, uma mensagem particular opcionaldo pagador para o recebedor é enviada junto com o código de transação.

Em uma outra modalidade, uma transação financeira é proces-sada em um ATM. O método começa quando um usuário do ATM desejareceber uma quantidade de uma mercadoria negociável, tal como dinheiro,de um ATM designado. O sistema de pagamento eletrônico usando uma pla-taforma de voz através de IP (VoIP) recebe uma chamada de um usuário emuma discagem interna direta (DID) especificada do número de telefone dosistema de pagamento eletrônico associado com a transação do ATM. A se-guir, em resposta ao sistema de pagamento eletrônico receber um sinal queum dado código de transação foi inserido pelo usuário do ATM, uma mensa-gem de notificação é enviada através de uma rede para o ATM fornecer aquantidade da mercadoria negociável em resposta à recepção do sinal.

Uma vantagem das modalidades precedentes da presente in-venção é que uma transação financeira segura é provida usando um telefo-ne celular sem a exigência que o recebedor proveja informação pessoalmen-te identificável para o sistema de pagamento eletrônico. A presente invençãonão exige modificações de software e/ou hardware, então ela funciona bemcom qualquer telefone celular ou aparelho telefônico sem fio ou dispositivode comunicação.

A presente invenção é também vantajosa porque ela é muitoescalável e funciona com uma variedade de transações financeiras, incluin- do ATMs, pessoa a pessoa (P2P), transações comerciais, transações devendas e outros tipos de transações. Um pagador pode escolher que o ser-vidor de transação financeira envie o código de transação diretamente parao recebedor ou pode controlar o código de transação entregando para o re-cebedor fora da rede de transação. A presente invenção funciona com qual-quer tipo de mercadoria negociável, especialmente essas com um meio tan-gível resgatável com valor inerente imediato tais como dinheiro, cupons,comprovantes, selos, bilhetes, sinais e pontos.

O precedente e outros aspectos e vantagens da presente inven-ção serão evidentes a partir da descrição mais particular seguinte das moda-Iidades preferidas da invenção, como ilustrado nos desenhos acompanhan-tes.

Breve Descrição dos Desenhos

A matéria exposta, que é considerada como a invenção, é parti-cularmente evidenciada e distintamente reivindicada nas reivindicações na conclusão do relatório descritivo. O precedente e outros aspectos e vanta-gens da invenção serão evidentes a partir da descrição detalhada seguintetomada em conjunto com os desenhos acompanhantes nos quais:

A figura 1 é um diagrama de blocos funcional de um sistema depagamento eletrônico, incluindo um servidor, de acordo com a presente in-venção.

A figura 2 é uma visão generalizada do diagrama de fluxo dopagador, de acordo com a presente invenção.

A figura 3 é um diagrama de fluxo generalizado do recebedor, deacordo com a presente invenção.

A figura 4 é um diagrama de fluxo de uma verificação do identifi-cador de telefone do pagador e/ou recebedor, de acordo com a presenteinvenção.A figura 5 é um diagrama de fluxo de uma verificação do PIN dopagador e/ou recebedor, de acordo com a presente invenção.

A figura 6 é um diagrama de fluxo dos tipos de financiamento dopagador, de acordo com a presente invenção.

A figura 7 é um diagrama de fluxo de uma criptografia do códigode transação do pagador e/ou recebedor, de acordo com a presente invenção.

A figura 8 é um diagrama de fluxo de uma seleção do tipo decódigo de transação do pagador, de acordo com a presente invenção.

A figura 9 é um diagrama de fluxo da entrega do código de tran-sação de um pagador e/ou recebedor, de acordo com a presente invenção.

A figura 10 é um diagrama de fluxo da entrega do código detransação de um pagador e/ou recebedor, de acordo com a presente invenção.

A figura 11 é um diagrama de fluxo de uma transação financeirano ATM, de acordo com a presente invenção.

Descrição das Modalidades Preferidas

Como requerido, modalidades detalhadas da presente invençãosão reveladas aqui, entretanto, é para ser entendido que as modalidadesreveladas são meramente exemplares da invenção, que pode ser personifi-cada em várias formas. Portanto, detalhes estruturais e funcionais específi-cos revelados aqui não devem ser interpretados como limitando, mas mera-mente como uma base para as reivindicações e como uma base representa-tiva para ensinar alguém versado na técnica a utilizar de maneira variada apresente invenção em virtualmente qualquer estrutura apropriadamente de-talhada. Além do que, os termos e frases usados aqui não são planejadospara serem limitadores, mas preferivelmente, para prover uma descriçãointeligível da invenção.

Os termos "um", "uma", "uns", "umas", como usados aqui, sãodefinidos como um ou mais do que um. O termo pluralidade, como usadoaqui, é definido como dois ou mais do que dois. O termo um outro, comousado aqui, é definido como pelo menos um segundo ou mais. Os termosincluindo e/ou tendo, como usados aqui, são definidos como compreenden-do (isto é, linguagem aberta). O termo acoplado, como usado aqui, é defini-do como conectado, embora não necessariamente de forma direta e nãonecessariamente de forma mecânica. Os termos programa, aplicação de software e assim por diante como usados aqui são definidos como uma se-qüência de instruções projetadas para execução em um sistema de compu-tador. Um programa, programa de computador ou aplicação de software po-de incluir uma subrotina, uma função, um procedimento, um método de obje-to, uma implementação de objeto, uma aplicação executável, um miniaplica-tivo, um "servlet", um código fonte, um código do objeto, uma bibliotecacompartilhada/biblioteca de carga dinâmica e/ou outra seqüência de instru-ções projetada para execução em um sistema de computador.

Um método para autorizar o pagamento para um recebedor a-través de uso de um telefone, e um sistema de pagamento eletrônico para implementar o método, são descritos como segue. Um pagador, usando umtelefone ou outro dispositivo de comunicação, chama um número de telefonepredeterminado ou endereço IP predeterminado para acessar um sistema depagamento eletrônico. O pagador chama um número de telefone geral dosistema de pagamento eletrônico ou um número de telefone que é especifi-camente associado com um recebedor ou pagador.Sistema de Pagamento Eletrônico Geral

A figura 1 é um diagrama de blocos funcional de um sistema depagamento eletrônico 100, de acordo com a invenção. O sistema de paga-mento eletrônico tem um aparelho telefônico sem fio ou telefone celular de clientes diferentes 102, terminal de ponto de vendas (POS) 104, computador106 e assistente digital pessoal (PDA) 108 que se comunica com a série deporta 120. As comunicações com a série de porta são através de qualquerrede de comunicação incluindo o protocolo SS7 sobre terrestre, satélite, porfiação, sem fiação em uma maneira conhecida para aqueles versados na técnica. A série de porta 120 inclui interfaces de comunicação para o IP (pro-tocolo da Internet) 122, voz 124, conexão de dados tais como T1 126, pro-vedor do serviço da Internet (ISP) 128 e Wireless Fidelity (WiFi) 129 e ou-tros. A porta de comunicação 120 se comunica usando uma variedade deprotocolos TCP, HTTP, UDP com uma barreira de proteção 132 no servidorde transação financeira 150. Logicamente, o servidor de transação financeira150 é dividido em duas metades: uma série de apresentação 130 e série decontrole 140, que se comunicam através de protocolos ligados por fiação esem fio, por exemplo, VoIP 131, VXML 134, WiFi 136 e HTTP 138. Tambémincluído na série de apresentação 130 está o agente de DID (discagem in-terna direta) 135 e identificador do telefone do pagador tal como o agenteANI (identificador de número automático) 137 ou agente OLI (identificador dalinha de origem) ou componente de sinalização SS7 ou identificador de dis-positivo tal como endereço IP ou identificador do pagador tal como identifi-cador biométrico tal como reconhecimento de voz.

A série do controlador 140 tem módulos diferentes de controledo consumidor que interagem com várias infra-estruturas de negócios nasérie de negócios 160. Da mesma forma, a série do controlador inclui várioscontroladores de serviço para vendas 144, ponto de vendas (POS) 146, ser-viços da web 148 que se comunicam com vários objetos de negócios: obje-tos de venda 164, objetos P2P 166, objetos de POS 168 e objetos de serviçodesacompanhados 169 tal como um objeto de ATM. Uma camada de acessoseguro 170 com um banco de dados 172 é acoplada na série de negócios160 para uso pelo sistema de pagamento eletrônico 100.

No sistema de pagamento eletrônico 100, um subsistema dacamada de suporte de transação 190 provê acesso de contabilidade, finan-ceiro, relatório e administrativo através dos clientes da web 182. Módulostais como POS 194, inventário 196 e associação 198 junto com seus contro-ladores auxiliares 197 são mostrados. Um banco de dados de diretório 195 étambém acoplado no sistema de pagamento eletrônico 100. É importanteobservar que dispositivos de armazenamento diferentes dos bancos de da-dos 172 e 195 podem ser usados para conexões em dispositivos de arma-zenamento de massa, que podem ser usados para armazenar e ler os da-dos.

Embora o sistema de pagamento eletrônico 100 seja ilustradocomo subsistemas separados com múltiplas CPUs, um único sistema podeser usado igualmente de maneira efetiva. Embora as modalidades exempla-res da presente invenção sejam descritas no contexto de um sistema decomputador totalmente funcional, aqueles versados na técnica verificarãoque as modalidades podem ser distribuídas como um produto de programaatravés de disco flexível, por exemplo, CD-ROM, ou outra forma de mídiagravável, ou através de qualquer tipo de mecanismo de transmissão eletrô-nica.

Visão Generalizada do Processo

O sistema de pagamento eletrônico 100 inclui um servidor pro-gramado para executar etapas de acordo com a invenção. Um pagador, u-sando um telefone, chama um número de telefone específico para acessarum sistema de pagamento eletrônico. O pagador chama um número de tele-fone genérico para o sistema de pagamento eletrônico ou um número detelefone especial que é associado com o recebedor a ser pago e/ou com opagador. O número de telefone especializado, tal como um número de dis-cagem interna direta (DID) pode ser atribuído para um recebedor específicotal como uma cadeia de bancos, lojas ou restaurantes. O número de telefoneespecializado pode ser atribuído para um pagador e/ou recebedor específicocom base em certas afiliações tais como milhas aéreas, associações emorganizações específicas ou a freqüência de uso do sistema de pagamentoeletrônico 100.

O sistema de pagamento eletrônico identifica o pagador pelonúmero do telefone do telefone que chama, como identificado por um identi-ficador de telefone do pagador autorizado tipicamente gerado por um trans-portador tal como identificação de número automático ("ANI" ou "ID do cha-mador") e OLI (identificador da linha de origem). O pagador, em resposta alembretes de voz, insere o seu número de identificação pessoal (PIN) e umaquantia de pagamento usando o teclado do telefone. O sistema de paga-mento eletrônico valida o PIN do pagador e verifica se fundos suficientesestão na conta do pagador para cobrir a quantia do pagamento. O sistemade pagamento eletrônico então autoriza o pagamento para o recebedor.O recebedor é identificado pelo número de telefone especial queé chamado pelo pagador para selecionar o pagamento para esse recebedor,como descrito acima, ou pelo pagador chamando o número de telefone ge-nérico para o sistema de pagamento eletrônico e inserindo um identificador do recebedor, tal como o número de telefone do recebedor ou outro númerode identificação, a partir do seu teclado de telefone em resposta a um lem-brete de voz.

O pagamento para o recebedor pode então ser concluído imedi-atamente depois da entrada dos dados pelo pagador ou depois que umasolicitação de pagamento é feita pelo recebedor. Em algumas modalidades,o sistema de pagamento eletrônico provê ao pagador um código de transa-ção, ou códigos, tal como uma seqüência alfanumérica de transação que éassociada com o pagamento. Esse código de transação de múltiplos dígitosé fornecido durante a chamada telefônica através de mensagem de texto, mensagem de voz, mensagem de e-mail, fax, telegrama e carta postal, tipi-camente depois que o pagamento é autorizado. Em uma modalidade, o có-digo de transação é válido somente para um uso e é somente válido por umperíodo de tempo especificado. A fim de completar a transação na modali-dade onde o sistema de pagamento eletrônico provê um tal código para o pagador, o pagador fornece para o recebedor o código de transação e o re-cebedor submete uma quantia de fatura e o código de transação para o sis-tema de pagamento eletrônico. Depois que o sistema de pagamento eletrô-nico recebe esse código de transação e a quantia da fatura, os fundos sãotransferidos da conta do pagador para a conta do recebedor. Uma variação desse sistema de pagamento eletrônico permite que o pagador obtenha umcódigo de transação para uma quantia de pagamento máxima para um rece-bedor especificado, tal como um comerciante particular. Esse código detransação é válido por um período de tempo especificado, permitindo que opagador compre nesse comerciante e apresente o código no caixa a fim de efetuar o pagamento para as compras.

Além de prover o pagamento para um recebedor, o sistema depagamento eletrônico da presente invenção é usado para fazer com que umcaixa eletrônico (ATM) distribua dinheiro para o usuário do telefone. Em talsistema de pagamento eletrônico, o usuário chama um número de telefoneassociado com um ATM particular e/ou um número genérico associado comuma dada rede do ATM, insere uma quantia de dinheiro e o seu PIN através do telefone e o ATM fornecerá a quantia especificada de dinheiro com a veri-ficação do PIN e do saldo da conta para a conta associada com o número detelefone do telefone que faz a chamada. É importante observar que o rece-bedor ou receptor do dinheiro ou outra mercadoria negociável em uma mo-dalidade não tem que inserir informação no teclado no ATM. Em uma outra modalidade, o recebedor insere informação no teclado no ATM, tais como onúmero de telefone do recebedor, PIN ou o código de transação.

O sistema de pagamento eletrônico financeiro 100 possibilita ociclo completo de uma transação de pagamento entre duas partes. As duaspartes podem incluir: Consumidor para ComercianteComerciante para consumidorConsumidor para consumidorFirma para fornecedorFornecedor para firmaConsumidor para terceiros

A finalidade dessa transação pode ser para qualquer uma dasrazões seguintes:Pagamento por bensPagamento por serviçosCrédito por bensCrédito por serviçosPresente

Transferência de conta para contaValor armazenadoLançamento de linha de crédito

Transferência de fundos domésticosTransferência de fundos internacionaisTroca de moeda

Os diagramas de fluxo seguintes ilustram três exemplos diferen-tes:

1) Pagamento com um telefone sem fio: pessoa para pessoa(P2P) usando um telefone sem fio.

2) Pagamento/retirada com um telefone sem fio: para retirar di-nheiro de um ATM.

3) Amortização/pagamento/retirada com um telefone sem fio:terminal de pontos de vendas (POS) do comerciante.

4) Pagamento com um telefone sem fio: serviço, por exemplo,

restaurante (REST).Visão Geral do Pagador

O fluxo seguinte é quase idêntico para os tipos diferentes deserviços de pagamento disponíveis do sistema de pagamento eletrônico 100,isto é, P2P, ATM, restaurante e POS.

A figura 2 é uma visão generalizada do diagrama de fluxo dopagador, de acordo com a presente invenção. O processo começa 202 eprossegue diretamente para a etapa 204 com um pagador iniciando umachamada para o sistema de pagamento eletrônico 100. A DID chamada em uma modalidade define o tipo de transação que será tratada, por exemplo,P2P, ATM, POS e RES. É importante observar que de acordo com o tipo detransação financeira, por exemplo, P2P, ATM, POS e RES, em algumas mo-dalidades são providos tipos diferentes de autorizações para financiamento.Por exemplo, em uma transação de ATM ou P2P, a quantia exata da transa- ção é conhecida pelo pagador quando iniciando o financiamento ou transfe-rência. Entretanto, em algumas transações de RES e transação de POS, aquantia exata pode não ser conhecida até que o pagador tenha calculadouma gorjeta de serviço ou até depois que todos os itens para a compra te-nham sido examinados e o total apresentado para o pagador na loja. Dessamaneira, nos tipos de transação de RES e POS, uma pré-autorização esti-mada ou uma quantia de financiamento a não exceder para a transação écapturada para esse tipo de transação financeira em oposição a uma quantiaexata.

Além do que, dependendo do tipo de transação, o sistema depagamento eletrônico 100 capturará o número do telefone ou outro identifi-cador do recebedor. Por exemplo, em um tipo de transação P2P, o pagadorinseriria o número de telefone do recebedor. Enquanto que para POS, ven-das ou outros tipos de transações financeiras associadas com uma DID es-pecífica, não existe necessidade de identificar o recebedor porque a DID éassociada com o recebedor.

Opcional: Identificador do Telefone do Pagador e PIN

Opcionalmente, o sistema de pagamento eletrônico 100 na eta-

pa 206 recebe o identificador do telefone do pagador autorizado. Em umamodalidade, um PIN (número de identificação pessoal) do pagador é tam-bém recebido na etapa 208. Dependendo do tipo de transação financeira oudas preferências estabelecidas pelo pagador individual, lembrete de voz dosistema e massagens 210 são reproduzidas tais como saldo atual, últimaatividade, nova configuração de conta e outras mensagens de gerenciamen-to de conta.

Opcional: Financiamento do Pagador

Na etapa 212, tipos diferentes opcionais de financiamento são induzidos tais como conta financeira em um banco, uma conta de amortiza-ção, uma conta de valor armazenado, uma conta de cartão de crédito, umaconta de cartão de presente, uma conta de telefone pré-pago e uma contade cartão de débito. Uma verificação de saldo ou mensagem opcional é for-necida para notificar o pagador dos fundos disponíveis.

Receber Quantia do Pagador

Na etapa 214, o sistema de pagamento eletrônico 100 incita opagador por um designador de valor tal como um número ou código numéri-co representando a quantia de dinheiro, pontos, cupons, bilhetes, sinais eoutro meio tangível resgatável com valor inerente imediato. A verificação dodesignador numérico é concluída e os fundos disponíveis dependendo daetapa do tipo de financiamento opcional 212 são verificados. É importanteobservar que os fundos podem ser transferidos de uma conta financeira,14conta de amortização, uma conta de valor armazenado, uma conta de cartãode presente, uma conta de cartão de crédito, uma conta de cartão de débitoe qualquer outro mecanismo de financiamento que possa ser associado comum pagador. Em uma modalidade onde existem fundos insuficientes dispo- níveis, uma mensagem de falha é reproduzida tal como "A quantidade solici-tada excede o limite na conta" ou "Sua transação excede o valor permissívelpara esse tipo de transação". O sistema em uma modalidade limita a quantiade mercadoria negociável que pode ser transferida dependendo de tais fato-res como tipo da transação financeira. Por exemplo, um limite pode ser apli-cado para POS e um outro limite aplicado para as transações de ATM. Ou-tros fatores tal como a história de uso com o sistema do pagador e/ou rece-bedor do sistema.

Gerar código de transação e criptografia opcional

Um código de transação é criado que é associado com o paga-dor, o tipo de financiamento, a quantia do financiamento e o recebedor. Ocódigo de transação é qualquer código aleatório de qualquer comprimentoque pode incluir dígitos alfanuméricos. Na etapa 216, dependendo do perfildo pagador e/ou recebedor, a criptografia do código de transação acontece.A criptografia é do tipo que pode ser mentalmente decriptografada pelo re-cebedor sem a necessidade de usar hardware ou software. Uma cifra detransposição muda um caractere de um código de transação de texto sim-ples para um outro. Para decriptografar, o inverso é feito. Por exemplo, se ocódigo de transação original é 459220, a criptografia pode ser trocar doisdígitos como os últimos dois dígitos tornando 459202. Ou a criptografia podeser adicionar o número 100 em qualquer código de transação onde o códigode transação original é 459220 e o código criptografado é 459320. Nova-mente, embora o processo de criptografia seja executado automaticamentecomo estabelecido pelas preferências opcionais do pagador e/ou recebedor,o processo de decriptografia é feito mentalmente para evitar a necessidadede hardware e software especializados. Qualquer cifra de transposição podeser usada incluindo essas selecionadas de um grupo de cifras de transposi-ção consistindo em cifra de transposição de rota, cifra de transposição colu-nar, cifra de transposição dupla, cifra de substituição e cifra de adição, pormeio do que antes do uso pelo recebedor, o código de transação deve serdecriptografado. Para informação adicionai sobre a cifra de transposição fa-zer referência a

(http://en.wikipedia.org/wiki/Transposition cipher#Route cipher)que é aqui incorporado por referência na sua integridade.Opcional: Tipos de código de transação

Na etapa opcional 218, o código de transação pode ter condi-ções associadas com ele, por exemplo, para segurança adicional, o códigode transação pode ser ligado a somente um dado tipo de recebedor, por e-xemplo, RES, ATM, POS ou um dado tipo de loja, comerciante, classe debens, por exemplo, comestíveis, eletrônica do consumidor, roupas e outrascategorias de gastos. Em uma outra modalidade, o código de transação éválido por um período de tempo antes de expirar. Além do que, o código detransação pode ser para uma quantia estabelecida, isto é, uma quantia pré-autorizada, por exemplo, ATM, P2P ou uma quantia a não exceder, RES,POS. O uso de códigos de transação de quantia a não exceder permite quedespesas adicionais tais como gorjetas de serviço e gratuidade sejam adi-cionadas.

Associar código de transação com financiamento do pagador

Na etapa 220, o código de transação é associada com o financi-amento do pagador estabelecido na etapa 212, por exemplo, conta financei-ra em um banco, uma conta de amortização, uma conta de valor armazena-do, uma conta de cartão de crédito, uma conta de cartão de presente e uma conta de cartão de débito.

Código de transação de rota opcional

A seguir na etapa 222, o código de transação é encaminhadopara o pagador e/ou recebedor dependendo das preferências do pagadore/ou recebedor junto com o tipo de transação financeira. Por exemplo, umamensagem de texto, mensagem de voz, mensagem de e-mail, fax, telegra-ma e carta postal é encaminhada para o pagador e/ou recebedor. Por exem-plo, em um P2P, o sistema em uma modalidade não provê um código detransação para qualquer um do pagador ou recebedor. Entretanto, em outrostipos de transação financeira tais como RES1 POS1 o sistema provê um có-digo de transação para o pagador e/ou recebedor.Opcional: modalidade de conversão de moeda

Na modalidade para o ATM ou P2P, pode existir uma conversãode moeda intermediária de uma moeda nacional para uma segunda moedanacional, tal como de dólares americanos para pesos mexicanos. O sistemade pagamento eletrônico 100 sugere o tipo de moeda que é para ser com-prada. Alternadamente, o tipo de moeda em uma modalidade é com base no tipo da conta de financiamento, isto é, o pagador sempre paga em dólaresamericanos de uma conta de banco e esse recebedor particular recebe dóla-res canadenses. Em ainda uma outra modalidade, o número de telefone dopagador e/ou recebedor pode ser usado para determinar a moeda nacional.O sistema de pagamento eletrônico então usaria as conversões de moeda internacionais, tal como essas disponíveis na maior parte dos bancos, paracalcular corretamente a taxa de câmbio.Opcional: modalidade de prêmio de fidelidade

Em uma modalidade opcional não mostrada, o sistema de pa-gamento eletrônico 100 reúne dados dé transação e comerciais. Esses da- dos são então usados para prover incentivos de fidelidade para o consumi-dor. O comerciante determinará os prêmios de fidelidade. Os parâmetrospara determinar os prêmios podem ser freqüência, a quantia gasta duranteum certo período, compras específicas do produto, seleção aleatória ou es-pecífica do concurso.

Visão Geral do Recebedor

A figura 3 é um diagrama de fluxo generalizado do recebedor, deacordo com a presente invenção. Não mostrado, mas entendido para aque-les versados na técnica, no caso onde o recebedor não é registrado com osistema de pagamento eletrônico 100, lembretes são reproduzidos para re- gistrar o recebedor e para capturar a informação do recebedor e para confi-gurar uma conta e PIN.

O processo começa na etapa 302 e prossegue imediatamentepara uma etapa opcional 304 onde o sistema de pagamento eletrônico 100chama o recebedor.

Opcional: sistema contata o recebedor

Essa etapa opcional em uma modalidade é para os tipos detransações financeiras tais como P2P e ATM, enquanto que tipicamente pa-ra os tipos de transação financeira de POS e RES1 o sistema de pagamentoeletrônico se comunica através de uma ligação de dados tal como a Internet.Ter o sistema de pagamento eletrônico 100 chamando um número de telefo-ne predeterminado de um recebedor provê maior segurança de extremidadea extremidade e reduz a possibilidade de fraude. Por exemplo, opcionalmen-te, o sistema de pagamento eletrônico 100 inicia uma chamada para o tele-fone do recebedor anunciando que o dinheiro está disponível para o recebe-dor.

Opcional: recebedor contata o sistema

O processo continua com uma etapa opcional 306 onde o rece-bedor contata o sistema de pagamento eletrônico 100. Tipos de transaçõesfinanceiras tais como RES e POS tipicamente iniciariam a comunicação como sistema de pagamento eletrônico 100.

Opcional: identificador do telefone do pagador e PIN

Junto com essa etapa opcional 306, o sistema de pagamentoeletrônico verifica o identificador de telefone do recebedor tais como ANI1OLI ou outro identificador de telefone tipicamente gerado pelo portador. Naetapa 310, um PIN opcional do recebedor é capturado.

Código de Transação Recebido

A seguir, o recebedor insere o código de transação e/ou confir-mação tal como uma entrada do teclado. É importante observar que o rece-bedor em uma modalidade recebe o código de transação diretamente dosistema de pagamento eletrônico 100, tal como através de mensagem detexto, mensagem de voz, mensagem de e-mail, fax, telegrama e carta postal.Em uma outra modalidade, o pagador envia para o recebedor o código detransação fora do sistema de pagamento eletrônico 100.

Nova Atribuição do Desiqnador de ValorA seguir, o sistema de pagamento eletrônico 100, em resposta àrecepção do código de transação correto, o sistema de pagamento eletrôni-co atribui novamente o designador de valor tal como uma quantia de dinheiropara as contas do recebedor. Em uma modalidade de POS ou RES, o de-signador de valor é transferido para a loja ou restaurante. É importante ob-servar que em uma modalidade para a transação financeira de POS ou RES,que a identidade do pagador é anônima para a loja ou restaurante desdeque somente o código de transação é provido do pagador para o recebedor.Nenhuma informação pessoalmente identificável é fornecida para o comerci-ante ou restaurante.

Na modalidade para o ATM ou P2P, pode existir uma conversãode moeda intermediária de uma moeda nacional para uma outra, tal como dedólares americanos para pesos mexicanos. Além do que, na transação fi-nanceira do ATM, o dinheiro pode ser imediatamente fornecido da máquinado ATM. A nova atribuição do designador de valor é da conta do pagadordiretamente para a rede do ATM.

A despeito do tipo de transação financeira, um banco de dadosatualizando a nova atribuição do designador de valor, tal como uma quantiade dinheiro, pontos, cupons, comprovantes, selos, bilhetes, sinais, pontos ououtro meio tangível resgatável com valor inerente imediato é gravado nobanco de dados 172.

Opcional: verificação do identificador de telefone do pagador/recebedor

A figura 4 é um diagrama de fluxo de uma verificação do identifi-cador de telefone do pagador e/ou recebedor, de acordo com a presenteinvenção. Esse fluxo de processo provê uma modalidade para as etapas ouações 206 da figura 2 e 308 da figura 3. O processo começa na etapa 402 eprossegue imediatamente para a etapa 404 onde uma determinação é feitase o identificador do telefone do pagador e/ou do recebedor foi capturadocom sucesso. No caso onde o identificador de telefone não foi capturadocom sucesso, um código de autorização adicional pode ser solicitado paraidentificar apropriadamente o pagador. Em alguns sistemas de telefone na-cionais, dígitos adicionais, enchimento ou tradução podem ser necessáriospara prover a autorização correta para o sistema e identificar o município deorigem. Ou em uma outra modalidade, um lembrete é reproduzido para a-cionar o id do chamador ou para desbloquear o id do chamador do telefonena etapa 406 e o processo termina na etapa 412. No caso em que o identifi- cador do telefone é capturado, uma verificação é feita para ver se o identifi-cador do telefone está autorizado em um banco de dados. Dependendo dese o identificador do telefone está em um banco de dados, uma ou maismensagens personalizadas são reproduzidas para o chamador tal como"Bem-vindo ao sistema de pagamento Phonel", na etapa 414 e o processo termina na etapa 412. No caso onde o identificador do telefone não está nobanco de dados, uma mensagem personalizada diferente na etapa 410 éreproduzida tal como "Não registrado com o sistema" e o processo terminana etapa 412.

Opcional: verificação do PIN do pagador/recebedor

A figura 5 é um diagrama de fluxo de uma verificação de PIN deum pagador e/ou recebedor, de acordo com a presente invenção. Esse fluxode processo provê uma modalidade para as etapas ou ações 208 da figura 2e 310 da figura 3. O processo começa na etapa 502 e prossegue imediata-mente para a etapa 504 onde um lembrete é reproduzido para inserir o PIN (número identificador pessoal). Uma determinação é feita se o PIN do paga-dor e/ou do recebedor foi capturado com sucesso na etapa 506. No casoonde o PIN não foi capturado com sucesso, um teste é feito na etapa 508para determinar se um número predeterminado de tentativas falhas ocorreu.Se o número de tentativas está abaixo do número predeterminado, um Iem- brete para tentar novamente é reproduzido na etapa 510 e o fluxo retornapara a etapa 506. É importante observar que depois de um número prede-terminado de tentativas falhas, o fluxo reproduz uma mensagem opcional talcomo "Por razões de segurança essa conta foi bloqueada. Por favor, entreem contato com o serviço do consumidor" e a conta é bloqueada (não mos-trado) antes que o fluxo termine na etapa 516. Na eventualidade em que oPIN capturado iguale um valor armazenado para o usuário, o sistema de pa-gamento eletrônico 100 reproduz mensagens opcionais 516 tal como "Bem-vindo ao sistema de pagamento Phonel" e o processo termina na etapa516.

Opcional: tipos de financiamento

A figura 6 é um diagrama de fluxo dos tipos de financiamento do5uma modalidade para a etapa ou ação 212 da figura 2. O processo começana etapa 602 e prossegue imediatamente para a etapa 604 onde uma de-terminação é feita se a preferência de financiamento do pagador está esta-belecida. No caso onde a transação de financiamento não está estabelecida, um lembrete é reproduzido para selecionar um tipo de preferência de finan-ciamento de fontes de financiamento disponíveis tais como uma conta ban-cária, uma conta de amortização, uma conta de valor armazenado, uma con-ta de cartão de crédito, uma conta de cartão de presente e uma conta decartão de débito, na etapa 606. A preferência é recebida na etapa 608 e atransação é associada com um tipo de conta na etapa 610. No caso onde apreferência do financiamento já está estabelecida, o processo flui diretamen-te da etapa 604 para a etapa 610. Mensagens personalizadas opcionais sãoreproduzidas na etapa 612 e o processo termina na etapa 614.Opcional: criptografia do código de transação

A figura 7 é um diagrama de fluxo da criptografia do código detransação de um pagador e/ou recebedor, de acordo com a presente inven-ção. Esse fluxo de processo provê uma modalidade para a etapa ou ação216 da figura 2. O processo começa na etapa 702 e prossegue imediata-mente para a etapa 704 onde uma determinação é feita se a preferência de financiamento de criptografia do código de transação do pagador e/ou recep-tor está estabelecida. No caso onde o código de criptografia não está esta-belecido, um lembrete é reproduzido para selecionar um tipo de preferênciade criptografia na etapa 706 e a preferência é recebida na etapa 708 e pros-segue para criptografar o código de transação na etapa 710 antes do envio. No caso onde a preferência da criptografia já está estabelecida, o processocontinua para a etapa 710 para criptografar o código de transação de acordocom as preferências estabelecidas. A seguir, na etapa 712, uma ou maismensagens opcionais são reproduzidas confirmando a cifra de criptografiausada e o processo termina na etapa 714.

Opcional: tipo do código de transação

A figura 8 é um diagrama de fluxo da seleção do tipo de códigode transação do pagador, de acordo com a presente invenção. Esse fluxo deprocesso provê uma modalidade para a etapa ou ação 218 da figura 2. Oprocesso começa na etapa 802 e prossegue imediatamente para a etapa804 onde o tipo do código de transação tal como a expiração, o uso por so-mente um dado bem, serviço, loja, banco é estabelecido dependendo do tipode transação financeira e preferências do pagador e/ou recebedor na etapa806. O sistema provê um lembrete opcional na etapa 806 para permitir que opagador estabeleça parâmetros adicionais, condições e limitações associa-das com o código de transação. Por exemplo, o código de transação podeser limitado a uma certa quantia em dólar ou um período de expiração defi-nível pelo usuário. Na etapa 808, os parâmetros do código de transação sãoestabelecidos no sistema com base em uma combinação dos tipos de tran-sação financeira da etapa 804 e das preferências do usuário capturadas naetapa 808. Mensagens personalizadas opcionais são reproduzidas para ousuário confirmando o tipo do código de transação que foi estabelecido. Oprocesso termina na etapa 812.

Opcional: código de transação de.rota

A figura 9 é um diagrama de fluxo da entrega do código de tran-sação do pagador e/ou recebedor, de acordo com a presente invenção. Essefluxo de processo provê uma modalidade para a etapa ou ação 222 da figura2. O processo começa na etapa 902 e prossegue imediatamente para a eta-pa 904 onde uma determinação é feita se a preferência de rota do pagadore/ou recebedor para a transação está estabelecida. No caso onde a prefe-rência de rota não está estabelecida, um lembrete é reproduzido para sele-cionar um tipo de rota ou uma predefinição é usada na etapa 906 e a prefe-rência é recebida na etapa 908 e o processo prossegue para capturar amensagem opcional do pagador na etapa 910. Preferências de rota incluemmensagem de texto, mensagem de voz, mensagem de e-mail, fax, telegra-ma e carta postal. Em uma modalidade, o pagador pode cancelar qualqueropção de preferência do recebedor. No caso onde a preferência de rota estáestabelecida, o fluxo continua diretamente para a etapa 910 onde a mensa-gem do pagador opcional é capturada. Isso pode ser uma mensagem de vozgravada, por exemplo, "Jim, seu pagamento foi liberado. Por favor, vá aqualquer ATM de banco". O pagador pode gravar novamente a mensagemou salvá-la e verificar a mensagem antes de sair. Nesse momento, um de-signador de valor para o pagador específico e um número telefônico de umrecebedor é gravado nesse banco de dados 172. O código de transação éentregue de acordo com as preferências estabelecidas para o pagador e/ouo recebedor. É importante observar que o pagador pode decidir prover o có-digo de transação diretamente para o recebedor fora do sistema de paga-mento eletrônico 100. Em uma outra modalidade, além de enviar o código detransação para o pagador, o sistema de pagamento eletrônico envia o códi-go de transação para o recebedor em uma maneira especificada, por exem-plo, mensagem de texto, mensagem de voz, mensagem de e-mail, fax, tele-grama e carta postal junto com qualquer mensagem opcional. O processocontinua com quaisquer mensagens de sistemas opcionais 914 sendo re-produzidas, e o processo termina na etapa 916. Deve ser entendido que como uso de uma transação P2P na presente invenção, um comerciante comoum recebedor seria capaz de receber o pagamento com apenas um telefonee sem a necessidade de qualquer plataforma de POS.

Exemplo de Transação P2P

Agora com referência às figuras acima, é descrita uma modali-dade onde um pagador deseja enviar uma mercadoria negociável para umrecebedor. O pagador inicia uma chamada telefônica para um número detelefone DID predeterminado para uma transação financeira P2P. Depoisque o sistema de pagamento eletrônico verifica o identificador do telefone eo PIN do pagador, lembretes opcionais tal como "Por favor, insira o númerode telefone dos receptores incluindo o código de área". Uma verificação éfeita para determinar se o recebedor/receptor é previamente registrado como sistema de pagamento eletrônico e um aviso reproduzido se o recebedornão foi previamente instituído. O pagador seleciona um tipo de financiamen-to tal como um banco e insere um valor numérico para uma mercadoria ne-gociável tal como dinheiro. O sistema de pagamento eletrônico provê umcódigo de transação para o pagador e o sistema de pagamento eletrônico oatualiza e grava que uma transação está pendente. O pagador nesse exem-plo decide fornecer o código de transação diretamente para o recebedor semusar o sistema de pagamento eletrônico para enviar automaticamente o có-digo. O recebedor recebe o código de transação do pagador. O sistema depagamento eletrônico chama o recebedor no número de telefone armazena-do. Quando o recebedor responde a chamada do sistema de pagamentoeletrônico, em uma modalidade, o recebedor insere um PIN e um código detransação. Em uma outra modalidade, o recebedor pode não precisar inseriro PIN e/ou o código de transação ou ambos, o recebedor precisa somenteconfirmar com uma resposta de teclado que ele recebeu a chamada. Essetipo de retorno resguarda que o sistema entregou a mensagem e o recebe-dor confirmou o recebimento da informação. O sistema de pagamento ele-trônico move a quantia de mercadoria negociável da conta de financiamentodo pagador para a conta do recebedor.

Exemplo de Terminal de Ponto de Venda (POS)

Continuando com referência às figuras acima, é descrita umamodalidade onde um pagador deseja pagar por uma venda em um POS.Isso provê pagamento seguro e anônimo em uma localização varejista. Ocomerciante necessita de uma plataforma de POS existente. O POS do co-merciante deve estar conectado em uma linha de telefone ou uma conexãoda Internet. Para qualquer comerciante que aceita cartões de crédito atual-mente, essas exigências já estão satisfeitas.

A exigência final para a implementação é que uma interface deprotocolo de aplicação (API) de software de acordo com a invenção precisaser carregada para o terminal do POS. A API possibilita que o comerciantefeche a transação e provê as decisões e os relatórios necessários. A API épequena e totalmente compatível com o sistema existente do comerciante.

O pagador/consumidor usa um telefone sem fio/PDA para seconectar no sistema de pagamento eletrônico antes da compra ou na loja. Osistema de pagamento eletrônico autentica e valida o pagador e a quantia defundos disponível. O sistema de pagamento eletrônico emite um código detransação de múltiplos dígitos para o pagador/consumidor. O consumidorcompra na localização varejista. No fim de um período de compras, o con-sumidor prossegue para o caixa. O comerciante totaliza os itens comprados.

O pagador/consumidor então informa ao comerciante o código de transaçãopara essa transação ou insere diretamente o código no próprio POS. O POSenvia o código de transação e o pedido total para o sistema de pagamentoeletrônico para autorização. O sistema de pagamento eletrônico recebe atransação e valida a disponibilidade de fundos para o pedido total e valida ocódigo de transação. O sistema de pagamento eletrônico retorna para oPOS do comerciante um estado de aprovação. A transação está agora com-pleta. Nesse exemplo, o tipo do código de transação é somente bom parauma única transação em uma loja específica e não pode ser reutilizado du-rante as próximas setenta e duas (72) horas. Também é importante observarque, embora o exemplo tenha sido descrito para compra de um bem usandoum POS, a compra de serviços, tal como conserto de automóveis, está den-tro do escopo verdadeiro e espírito da presente invenção.

Exemplo da máquina de vendas (VEND)

Continuando com referência às figuras acima, é descrita umamodalidade onde um pagador deseja pagar por uma venda em uma máqui-na de vendas, tais como uma máquina de refrigerante, máquina de doces,carrinho de bagagem de aeroporto, máquina de lavar, parquímetro, garagemde estacionamento, elevador e qualquer outro mecanismo independente quefornece um bem ou executa um serviço ou provê acesso a um bem e/ou ser-viço. Isso provê pagamento seguro e anônimo para transações de vendas. Amáquina de vendas deve estar conectada em uma linha telefônica ou umaconexão da Internet. Para qualquer máquina de vendas que aceita cartõesde crédito atualmente, essas exigências já estão satisfeitas.

O pagador/consumidor usa um telefone sem fio/PDA para seconectar no sistema de pagamento eletrônico usando um número associadocom uma máquina de vendas específica ou companhia de vendas. O siste-ma de pagamento eletrônico autentica e valida o pagador e a quantia defundos disponível. O pagador insere o item desejado e opcionalmente aquantia para o item ou serviço. O sistema de pagamento eletrônico emite umpacote seguro para a máquina de vendas fornecer o item ou serviço selecio-nado. O sistema de pagamento financeiro reconcilia a contabilidade com ossistemas da máquina de vendas. A transação está agora completa. Nesseexemplo, o código de transação gerado pelo sistema de transação financeirapara finalidades de contabilidade interna pode ser somente bom para uma única transação em uma loja específica ou máquina de vendas e não podeser reutilizado durante o próximo período de tempo.Exemplo de Restaurante (RES)

Agora com referência às figuras acima, é descrita uma modali-dade onde um pagador deseja enviar uma mercadoria negociável para umrestaurante (RES). Como o tipo de transação do POS, o pagamento seguroe anônimo em um restaurante é realizado. O restaurante precisa de um sis-tema existente que aceite pagamentos sem dinheiro, tal como cartões decrédito. O sistema do restaurante deve estar conectado em uma linha detelefone ou uma conexão da Internet. A exigência final para a implementa-ção é que uma interface de protocolo de aplicação (API) de software de a-cordo com a invenção precisa ser carregada na plataforma do restaurante. AAPI possibilita que o restaurante feche a transação e provê as decisões e osrelatórios necessários. A API é pequena e totalmente compatível com o sis-tema existente do restaurante.

Quando uma nota ou conta é apresentada para o consumidor,em uma modalidade, a nota inclui um número de telefone ou DID para o pa-gador/consumidor usar quando fazendo o pagamento usando a presenteinvenção. Com referência agora à figura 10, é mostrado um diagrama defluxo de uma entrega de código de transação de pagador e/ou recebedor, de acordo com a presente invenção. O processo começa na etapa 1002 e pros-segue imediatamente para a etapa 1004 quando o pagador/consumidor usaum telefone sem fio/PDA para se conectar no sistema de pagamento eletrô-nico 100. Como explicado nas figuras acima, o sistema de pagamento ele-trônico 100 na etapa 1006 autentica e valida o pagador e a quantia de fun-dos disponível. Em uma modalidade, o número do telefone chamado foi pre-viamente associado com o restaurante. Em uma outra modalidade, o paga-dor/consumidor deve selecionar o restaurante de um menu de voz interativo.Depois que o restaurante é selecionado, a quantia da fatura, nota ou conta éenviada para o sistema de pagamento eletrônico na etapa 1008.

Em uma modalidade, o sistema de pagamento eletrônico usandoas preferências previamente armazenadas para o pagador/recebedor calculauma gorjeta na etapa 1010. A aplicação de calculadora de gorjeta funcionausando uma entrada preestabelecida no banco de dados e ainda permitecancelamento total pelo pagador/consumidor. O pagador/consumidor tem aopção de estabelecer um perfil com o sistema de pagamento eletrônico. Operfil reduz o tempo e faz sugestões para o consumidor durante o uso dosistema de pagamento eletrônico pelo consumidor. Por exemplo, o consumi-dor pode ter preestabelecido que o consumidor preferiria deixar uma gorjetade 18% por predefinição. A entrada de 18% é feita em um campo do bancode dados de percentual de gorjeta. A aplicação de calculadora de gorjetaprocura no campo de percentual de gorjeta antes de fazer o cálculo de gorje-ta na etapa 1012. Em uma modalidade, se nenhuma entrada é feita no cam-po de percentual de gorjeta, uma predefinição tal como 15% é usada, masoutras predefinições podem ser definidas na etapa 1014. Em qualquer caso,o pagador/consumidor tem a oportunidade de cancelar a quantia sugerida einserir uma quantia diferente. Em uma outra modalidade, o sistema de res-posta de voz interativo sugere uma gratificação ou gorjeta.

Um pagamento total que inclui a gorjeta opcional é verificadopelo pagador/recebedor na etapa 1016 e um código de transação é enviadopara o pagador/consumidor na etapa 1018. O pagador/consumidor entãoinforma para o restaurante o código de transação para essa transação. Emuma modalidade, um pagamento total é também provido para o restaurantejunto com o código de transação para ajudar o restaurante a identificar aquantia de gratificação. O sistema do restaurante envia o código de transa-ção e o total para o sistema de pagamento eletrônico para autorização. Osistema de pagamento eletrônico recebe a transação e valida a disponibili-dade de fundos para o total e valida o código de transação. O sistema depagamento eletrônico retorna para o restaurante um estado de aprovação. Atransação está agora completa na etapa 1020.

Exemplo da Transação no ATM

Novamente com referência às figuras acima, é descrita uma mo-dalidade de uma transação no ATM sem cartão onde um pagador envia umamercadoria negociável para um recebedor usando um ATM com um exem- pio de conversão de moeda. A figura 11 é um diagrama de fluxo de umatransação financeira no ATM para esse exemplo. O processo começa naetapa 1102 e prossegue imediatamente para a etapa 1104. Depois que opagador é autenticado e validado na etapa 1104, o pagador insere a quantiada mercadoria negociável na etapa 1106. Em uma etapa de conversão de moeda opcional 1108, o sistema de pagamento eletrônico determina se aconta do pagador e o ATM estão no mesmo país. O sistema de pagamentoeletrônico converte os fundos solicitados da conta do pagador na moeda doATM. Por exemplo, uma conta de banco dos E.U.A. sendo usada na Europaforneceria euros. É importante observar que, nesse exemplo, o pagador e o recebedor são a mesma pessoa. Entretanto, em outras modalidades, o pa-gador e o recebedor são donos de conta diferentes.

A seguir, mensagens opcionais 1110 são reproduzidas. O siste-ma de pagamento eletrônico gera um código de transação e o encaminhapara o pagador através de qualquer uma ou mais rotas de uma mensagem de texto, uma mensagem de voz, uma mensagem de e-mail, um fax, um te-legrama e uma carta postal. O pagador ou se a informação de transação éfornecida para um recebedor, o recebedor, parado em frente da máquina doATM, os fundos ou mercadoria negociável é entregue. Em uma modalidade,o dinheiro é imediatamente entregue no ATM sem o recebedor inserir qual- quer coisa no teclado do ATM ou usar qualquer cartão com o ATM. Em umaoutra modalidade, um PIN e/ou código de transação é inserido no teclado noATM sem usar um cartão de banco. O sistema de pagamento eletrônico re-cebe uma mensagem do processador do ATM que uma chave ou chavesforam inseridas no ATM na etapa 1114. As chaves inseridas podem incluir ocódigo de transação. Na etapa 1116, o sistema de pagamento eletrônicoenvia uma mensagem de notificação para o processador do ATM para for-necer os fundos ou mercadoria negociável na máquina do ATM e o processotermina na etapa 1118. O sistema de pagamento eletrônico relaciona os i-tens e registra a transação no banco de dados.

Exemplos não Limitadores

Embora o consumidor citado aqui seja tipicamente uma pessoanatural que é um consumidor de varejo, deve ser entendido que o escopodas reivindicações não é limitado a uma pessoa natural que é um consumi-dor de varejo, ao contrário, o consumidor pode ser qualquer tipo de entidadeou usuário.

Embora o comerciante citado aqui seja tipicamente um comércioque é um varejista que vende bens ou serviços, deve ser entendido que oescopo das reivindicações não é limitado a um comércio que é um varejistaque vende bens ou serviços, ao contrário, o comerciante pode ser qualquertipo de entidade ou usuário.

Embora uma modalidade específica da invenção tenha sido re-velada, será entendido por aqueles versados na técnica que mudanças po-dem ser feitas nessa modalidade específica sem se afastar do espírito-e doescopo da invenção. O escopo da invenção não é para ser restrito, portanto,à modalidade específica e é planejado que as reivindicações anexas abran-jam qualquer e todas tais aplicações, modificações e modalidades dentro doescopo da presente invenção.

Claims

1. Método implementado em computador para conduzir umatransação financeira, o método em um servidor de transação financeiracompreendendo:atribuir, usando uma pré-autorização por um pagador associadocom um identificador de telefone de pagador autorizado, um designador deum volume para uma transação subseqüente entre o pagador e pelo menosum recebedor,receber, em um número de telefone de discagem interna direta(DID) especificado associado com um tipo de transação, uma chamada tele-fônica com o identificador do telefone do pagador autorizado,em resposta à recepção da chamada telefônica, enviar pelo me-nos um código de transação para o pagador, receber do recebedor o códigode transação eem resposta à recepção do código de transação, atribuir nova-mente o designador do valor para o recebedor.

2. Método implementado em computador, de acordo com a rei-vindicação 1, em que receber o código de transação de recebedor inclui re-ceber o código de transação que foi transferido diretamente do pagador parao recebedor sem usar o servidor de transação financeira.

3. Método implementado em computador, de acordo com a rei-vindicação 1, ainda compreendendo:automaticamente enviar o código de transação para o recebedoratravés de pelo menos um de:uma mensagem de texto,uma mensagem de voz,uma mensagem de e-mail,um fax,um telegrama euma carta postal.

4. Método implementado em computador, de acordo com a rei-vindicação 1, em que o designador do valor a ser novamente atribuído dopagador para o recebedor é associado com pelo menos uma de:uma conta financeira,uma conta de amortização,uma conta de valor armazenado,uma conta de cartão de presente,uma conta de cartão de crédito,uma conta de cartão de débito euma conta de telefone pré-pago.

5. Método implementado em computador, de acordo com a rei-vindicação 4, em que o número do telefone DID especificado é associadocom uma transação de caixa eletrônico (ATM) e o recebedor é um usuáriodo ATM.

6. Método implementado em computador, de acordo com a rei-vindicação 1, em que o recebedor não é identificado.

7. Método implementado em computador, de acordo com a rei-vindicação 1, ainda compreendendo:enviar um número de referência de transação para um endereçode rede específico do recebedor.

8. Método implementado em computador, de acordo com a rei-vindicação 1, em que o número de telefone DID especificado é associadocom uma transação de pessoa a pessoa e o recebedor é uma pessoa dife-rente do pagador.

9. Método implementado em computador, de acordo com a rei-vindicação 1, em que o número de telefone DID especificado é associadocom uma transação comercial e o recebedor é um comerciante.

10. Método implementado em computador, de acordo com a rei-vindicação 1, em que o número de telefone DID especificado é associadocom uma transação para uma máquina de vender e o recebedor é um ope-rador da máquina de vender.

11. Método implementado em computador, de acordo com a rei-vindicação 1, em que o número de telefone DID especificado é associadocom uma transação para um terminal de ponto-de-venda (POS) e o recebe-dor é um operador do terminal POS.

12. Método implementado em computador, de acordo com a rei-vindicação 1, em que o código de transação é válido somente por um perío-do especificado.

13. Método implementado em computador, de acordo com a rei-vindicação 11, em que o período especificado em que o código de transaçãoé válido é estabelecido por pelo menos um do pagador e do servidor detransação financeira.

14. Método implementado em computador, de acordo com a rei-vindicação 1, em que o designador do valor é um de dinheiro, cupons, com-provantes, sinais, pontos, selos e mercadoria negociável.

15. Método implementado em computador, de acordo com a rei-vindicação 1, em que o designador do valor está em uma primeira moedanacional e o método ainda compreende:converter a primeira moeda nacional para uma segunda moedanacional; ea nova atribuição do designador do valor para o recebedor inclu-indo o valor na segunda moeda nacional.

16. Método implementado em computador, de acordo com a rei-vindicação 2, em que o código de transação é provido para o recebedor comuma cifra de transposição selecionada de um grupo de cifras de transposi-ção consistindo em cifra de rota, cifra de transposição colunar, cifra detransposição dupla, cifra de substituição e cifra de adição, por meio do queantes do uso pelo recebedor, o código de transação deve ser decriptografado.

17. Método implementado em computador, de acordo com a rei-vindicação 3, em que o código de transação é provido para o recebedor comuma cifra de transposição selecionada de um grupo de cifras de transposi-ção consistindo em cifra de transposição de rota, cifra de transposição colu-nar, cifra de transposição dupla, cifra de substituição e cifra de adição, pormeio disso antes do uso pelo recebedor, o código de transação deve serdecriptografado.

18. Método implementado em computador, de acordo com a rei-vindicação 2, ainda compreendendo:receber uma mensagem do pagador para o recebedor,enviar pelo menos um código de transação para o recebedorcom a mensagem do pagador.

19. Método implementado em computador, da reivindicação 3,também compreendendo:receber uma mensagem do pagador para o recebedor,enviar o pelo menos um código de transação para o recebedorcom a mensagem do pagador.

20. Método implementado em computador para conduzir umatransação financeira, o método em um servidor de transação financeiracompreendendo:receber usando uma plataforma de voz através de IP (VoIP) emum número de telefone de discagem interna direta (DID) especificado asso-ciado com uma transação de caixa eletrônico (ATM) a partir de uma chama-da telefônica de um usuário que deseja receber uma quantidade de merca-doria negociável de um ATM designado,receber um sinal que um dado código de transação é inseridopelo usuário do ATM eenviar uma mensagem de notificação através de uma rede parao ATM dispensar a quantidade da mercadoria negociável em resposta à re-cepção do sinal.

21. Método implementado em computador, de acordo com a rei-vindicação 20, em que a mercadoria negociável é pelo menos uma de:dinheiro;um cupom;um comprovante;um selo;um bilhete;um sinal;um ponto; eum meio tangível resgatável com valor inerente imediato.

22. Método implementado em computador, de acordo com a rei-vindicação 20, em que a recepção de um sinal que o dado código de transa-ção é inserido pelo usuário no ATM inclui verificar se o identificador de nú-mero automático de um aparelho telefônico sem fio para o usuário chaman-do o número de telefone DID é autorizado.

23. Método implementado em computador, de acordo com a rei-vindicação 20, em que o número de telefone de discagem interna direta(DID) especificado é associado somente com o ATM designado.

24. Método implementado em computador, de acordo com a rei-vindicação 20, em que o número de telefone de discagem interna direta(DID) especificado é associado somente com a rede para o ATM.

25. Método implementado em computador, de acordo com a rei-vindicação 20, em que a quantidade de mercadoria negociável é dispensadaem resposta a um código de transação sendo inserido no ATM pelo usuário.

26. Método implementado em computador, de acordo com a rei-vindicação 25, em que a quantidade de mercadoria negociável é dispensadano ATM em resposta ao código de transação e um número de telefone doaparelho telefônico sem fio sendo inserido no ATM.

27. Método implementado em computador, de acordo com a rei-vindicação 25, em que o usuário do ATM recebe o código de-transação deum pagador de terceiros da quantidade de mercadoria negociável por meioseparado do ATM e da rede do ATM.

28. Método implementado em computador, de acordo com a rei-vindicação 27, em que o usuário do ATM recebe o código de transação deum pagador de terceiros da quantidade da mercadoria negociável através depelo menos um de:uma mensagem de texto;uma mensagem de voz;uma mensagem de e-mail;um fax;um telegrama; euma carta postal.

29. Método implementado em computador, de acordo com a rei-vindicação 20, em que o envio da mensagem de notificação através de umarede para o ATM usando um protocolo de voz através de IP (VoIP) inclui en-viar uma notificação para um processador de pagamento que está associadocom a rede do ATM.

30. Método implementado em computador, de acordo com a rei-vindicação 20, em que o envio da mensagem de notificação através de umarede para o ATM usando um protocolo de voz através de IP (VoIP) inclui se-lecionar um de uma pluralidade de processadores de pagamento (por exem-plo, primeiros dados, HSBC) com base em uma remuneração cobrada peloprocessador de pagamento.

31. Método implementado em computador, de acordo com a rei-vindicação 21, em que a remuneração cobrada pelo processador de paga-mento é um de uma taxa de câmbio, uma taxa de intercâmbio e um tipo deautenticação provido pelo usuário.

32. Método implementado em computador, de acordo com a rei-vindicação 20, em que o envio da mensagem de notificação através de umarede para o ATM usando um protocolo de voz através de IP (VoIP) inclui se-lecionar um de uma pluralidade de operadores de ATM (por exemplo, primei-ros dados, HSBC) com base em uma remuneração cobrada pelo processa-dor de pagamento.

33. Método implementado em computador, de acordo com a rei-vindicação 20, em que a quantidade de uma mercadoria negociável do ATMdesignado está em uma moeda nacional que é diferente de uma moeda na-cional usada para financiar originalmente a quantidade de mercadoria negociável.

34. Método implementado em computador, de acordo com a rei-vindicação 20, em que o usuário do ATM é diferente de uma pessoa quefinanciou originalmente a quantidade de mercadoria negociável.

35. Método implementado em computador para conduzir umatransação financeira, o método em um servidor de transação financeiracompreendendo:atribuir, usando uma pré-autorização por um pagador associadocom um identificador de telefone de pagador autorizado, um designador deum valor para uma transação subseqüente entre o pagador e pelo menosum recebedor;receber, em um número de telefone de discagem interna direta(DID) especificado associado com um tipo de transação, uma chamada tele-fônica com o identificador do telefone do pagador autorizado;em resposta à recepção da chamada telefônica, atribuir nova-mente o designador do valor para um recebedor, automaticamente chamar orecebedor para entregar a informação relacionada com a nova atribuição dodesignador do valor; ereceber uma resposta do recebedor que a informação foi recebi-