BRPI0710089A2 - sistema de pagamento individualizado móvel - Google Patents

sistema de pagamento individualizado móvel Download PDF

Info

Publication number
BRPI0710089A2
BRPI0710089A2 BRPI0710089-2A BRPI0710089A BRPI0710089A2 BR PI0710089 A2 BRPI0710089 A2 BR PI0710089A2 BR PI0710089 A BRPI0710089 A BR PI0710089A BR PI0710089 A2 BRPI0710089 A2 BR PI0710089A2
Authority
BR
Brazil
Prior art keywords
user
account
payment
transaction
mobile
Prior art date
Application number
BRPI0710089-2A
Other languages
English (en)
Inventor
John Tumminaro
Carol Realini
Pete Hosokawa
David Schwartz
Hesham Shawki
Nirav Shah
Original Assignee
Obopay Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Obopay Inc filed Critical Obopay Inc
Publication of BRPI0710089A2 publication Critical patent/BRPI0710089A2/pt

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/223—Payment schemes or models based on the use of peer-to-peer networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3221—Access to banking information through M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3223—Realising banking transactions through M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3227—Aspects of commerce using mobile devices [M-devices] using secure elements embedded in M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3229—Use of the SIM of a M-device as secure element
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
    • G06Q20/3255—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks using mobile network messaging services for payment, e.g. SMS
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/326—Payment applications installed on the mobile devices
    • G06Q20/3263—Payment applications installed on the mobile devices characterised by activation or deactivation of payment capabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3274—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being displayed on the M-device
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3278—RFID or NFC payments by means of M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/386—Payment protocols; Details thereof using messaging services or messaging apps
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • G06Q20/425—Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0207—Discounts or incentives, e.g. coupons or rebates
    • G06Q30/0226—Incentive systems for frequent usage, e.g. frequent flyer miles programs or point systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/16—Automatic or semi-automatic exchanges with lock-out or secrecy provision in party-line systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/068—Authentication using credential vaults, e.g. password manager applications or one time password [OTP] applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor

Abstract

SISTEMA DE PAGAMENTO INDIVIDUALIZADO MóVEL. Uma plataforma e serviço de pagamento móvel provêem uma maneira rápida, fácil para fazer pagamentos por usuários de dispositivos móveis. A plataforma também faz interface com canais e dispositivos não móveis tais como e-mail, mensageiro instantâneo e Web. Em uma implementação, fundos são acessados de um dispositivo móvel do dono da conta tais como um telefone móvel ou um assistente digital pessoal para fazer ou receber pagamentos. Transações financeiras podem ser conduzidas em uma base de pessoa para pessoa (P2P) ou pessoa para comerciante (P2M) onde cada parte é identificada por um indicador único, tal como um número de telefone ou código de barras. As transações podem ser solicitadas através de qualquer número de recursos incluindo troca de mensagens SMS, Web, e-mail, mensageiro instantâneo, uma aplicação de cliente móvel, uma aplicação de arquivo complementar ("plug.-in") de troca de mensagens instantânea ou "widget". A aplicação do cliente móvel, residente no dispositivo móvel, simplifica o acesso e executa as transações financeiras em uma maneira rápida, segura.

Description

Relatório Descritivo da Patente de Invenção para "SISTEMA DEPAGAMENTO INDIVIDUALIZADO MÓVEL".
Descrição
Uma porção da revelação desse documento de patente contémmaterial que está sujeito à proteção de direitos autorais. O dono dos direitosautorais não tem objeção à reprodução por fac-símile por qualquer um dodocumento de patente ou da revelação de patente, como ela aparece nosarquivos ou registros de patentes do Escritório de Patentes e Marcas dosE.U., mas de outra forma se reserva todos os direitos dos direitos autorais.
Referência cruzada com pedidos relacionados
Esse pedido de patente reivindica o benefício dos pedidos depatente U.S. 60/744.013, depositado em 30 de março de 2006, 60/744.930,depositado em 15 de abril de 2006 e 60/870.484, depositado em 18 de de-zembro de 2006, que são incorporados por referência junto com todas asoutras referências citadas nesse pedido.
Antecedentes da invenção
Modalidades da presente invenção se referem a sistemas e téc-nicas para efetuar transações financeiras através de dispositivos móveis, taiscomo telefones móveis ou celulares, e mais particularmente a uma infra-estrutura de transferência de pagamento individualizada móvel e métodopara transferir o pagamento. Além do que, modalidades da presente inven-ção se referem a um sistema de transação financeira e mais particularmentea um sistema de transação financeira de circuito fechado para transações depessoa para pessoa e consumidor para comerciante e métodos para uso dosistema de transação financeira.
Historicamente, um dono de conta que desejava concluir umatransação financeira para comprar um item contava com vários instrumentosfinanceiros tais como dinheiro, cheques, cartões de crédito ou cartões dedébito. Infelizmente, esses tipos de instrumentos financeiros têm certas pre-ocupações de segurança e a prevenção de fraude é uma exigência significa-tiva na utilidade da indústria do pagamento. Quando o dinheiro é perdido ouroubado, geralmente não existe recurso a não ser aceitar a perda. Com ou-tros instrumentos financeiros, a perda não é uma preocupação principal, masa fraude causa perdas significativas para a indústria de pagamento. Na rea-lidade, a fraude do cartão de crédito, cartão de débito e do cheque tem sidoe continua como um problema principal para a indústria.
Uma razão pela qual a fraude do cheque é tão comum surgedevido à necessidade de apresentar fisicamente um cheque para o banco dopagador. Assim, quando um cheque é aceito em uma transação financeira, ocheque não tem a garantia dos fundos. Mais propriamente, o cheque é me-ramente um pedaço de papel onde a validade do banco de onde ele é saca-do deve ser verificada junto com a conta que é usada e a assinatura usadapara autorizar o pagamento. Com um cartão de crédito ou débito, o usuáriopode não ser autorizado, mas pode extorquir despesas consideráveis antesque o emissor possa desativar a conta.
Claramente, o que é necessário é um sistema de pagamentoonde o receptor dos fundos em uma transação financeira é capaz de facil-mente verificar a validade da entidade que controla os fundos, a conta e osaldo e a identidade da pessoa com o telefone. Além do que, o que é neces-sário é uma maneira mais segura para acessar cartões de crédito e débitopara concluir as transações financeiras. Embora cada um dos instrumentos financeiros acima listadostenha funcionado bem no passado, é evidente que os consumidores dese-jam um método seguro, simples, para concluir as transações financeiras. Ouso crescente de cartões de crédito provê ampla evidência que os consumi-dores preferem usar sistemas de pagamento eletrônico ao invés de transpor-tar grandes quantias de dinheiro ou sofrer a chatice de escrever múltiploscheques para pequenas compras. Mesmo com a adoção difundida dos sis-temas de pagamento eletrônico, é evidente que existe uma necessidadecrescente por sistemas de pagamento eletrônico mais rápidos, mais baratose mais convenientes para completar as transações financeiras. Além do que,existe uma necessidade de um sistema de pagamento eletrônico que sejamais individualizado tal que as transações financeiras sejam facilmente con-cluídas em uma maneira similar às transações em dinheiro.A despeito do uso progressivo de cartões de crédito, existe ain-da uma grande população global de pessoas que conta primariamente comtransações em dinheiro e que ainda precisa de um sistema de pagamentoeletrônico conveniente e de custo efetivo para enviar e receber dinheiro. Es-sa necessidade levou ao uso crescente de cartões de débito pré-pagos. Infe-lizmente, cartões de débito são primariamente projetados de modo que umconsumidor pode pagar no cartão de débito em um comerciante que investiuem um terminal de transação de ponto de vendas. É difícil para um indivíduotransferir uma porção da quantia armazenada em um cartão de débito pré-pago para um outro indivíduo sem envolver uma ida inconveniente a umbanco ou um comerciante com um terminal de POS. O que é necessário éum sistema de pagamento eletrônico que possibilite que as transações fi-nanceiras sejam concluídas entre indivíduos e sem a necessidade de envol-ver diretamente uma instituição financeira de terceiros ou uma instituiçãofinanceira externa.
Embora muitas pessoas não tenham acesso aos terminais dePOS, a maior parte tem acesso a um dispositivo de comunicações sem fioportátil, freqüentemente citado como dispositivos celulares (ou celular) oumóveis. Na realidade, as pessoas agora tiram vantagem rotineiramente deaspectos adicionais providos por um telefone móvel típico tais como troca demensagens de texto, fotografia e escuta de música já que os dispositivosmóveis evoluíram para incluir PDA integrado, MP3, paginação, reprodutor ecapacidades de e-mail.
Existiu um crescimento explosivo nos dispositivos de telefoniamóvel e outros dispositivos portáteis que tratam das comunicações tantoatravés da voz, e-mail, troca de mensagens de texto SMS, troca de mensa-gens instantânea e a Internet. As pessoas freqüentemente se lembrarão detransportar os seus telefones móveis ou celulares com eles, mesmo se elesesquecem de transportar sua carteira ou chaves do carro. Os telefones mó-veis são ubíquos nos E.U. e em muitos países ao redor do mundo. Em 2005,foi estimado 2,14 bilhões de assinantes de telefone móvel. Cerca de 80 porcento da população mundial tem cobertura de telefone móvel. Portanto, exis-te uma grande necessidade de um sistema para permitir que os telefonesmóveis enviem e recebam pagamento, semelhante a dinheiro, e provejamoutras transações bancárias financeiras e móveis.
Tentativas para criar um sistema de pagamento móvel usandodispositivos celulares encontraram sucesso variado primariamente porque otelefone celular deve ter um dispositivo de circuito adicional (ou "circuito in-tegrado") que é usado para armazenar saldos de conta e informação de con-ta. Quando a pessoa que controla o telefone deseja transferir fundos, osfundos são deduzidos no ponto de vendas do circuito integrado e transferidopara a instituição financeira em um momento posterior a ser gravado pelainstituição financeira. Claramente, esse atraso entre o tempo que a venda éfeita e o tempo que a venda é gravada é ineficiente e arrisca a perda davenda caso o equipamento de POS do comerciante falhe antes que a vendaseja registrada. Além do que, se o telefone é perdido, o saldo da conta podeser usado por qualquer pessoa que controle o telefone. Embora esse siste-ma proveja melhor proteção contra a perda de fundos e seja superior paratransportar dinheiro, o sistema carece de segurança adequada para protegero dono da conta do uso impróprio por outros.
Além do que, um cartão de crédito indica que o dono tem con-cessão de uma linha de crédito de um banco ou outro emissor e isso possibi-lita que o dono faça compras ou retire dinheiro até uma quantia preestabele-cida. Uma participação é cobrada com base nos termos do acordo do cartãode crédito e o dono é, algumas vezes, cobrado com uma anuidade. Tradicio-nalmente, um cartão plástico que transporta um número de conta é atribuídopara o dono.
As transações de cartão de crédito utilizam redes proprietáriasque são pagas pelos comerciantes para quitar as transações. Por causa danatureza proprietária do sistema de pagamento, tais custos de sistema sãoaltos. Também, porque múltiplas partes estão envolvidas em uma transaçãode cartão de crédito, tais sistemas são freqüentemente citados como siste-mas financeiros de "circuito aberto".
A figura 34 mostra um exemplo de uma rede proprietária queinclui um terminal de ponto de vendas (POS) 3401 para iniciar as transaçõesna localização de um comerciante e um processador de pagamento 3402conectado com o terminal de POS 3401 por uma rede proprietária 3403. Emalguns casos, a rede proprietária não é nada mais do que uma conexão coma Internet. O processador de pagamento 3402, por sua vez, é conectado poruma rede proprietária 3404 em um intercâmbio de cartão de crédito 3408.
Para iniciar a transação, um consumidor apresentaria um cartãode crédito 3406 ou alternativamente um berloque de chave RFID 3407 noterminal do POS. Um berloque de chave é um tipo de prova de segurança:um pequeno dispositivo de hardware com mecanismo de armazenamentoincorporado. Ambos o cartão de crédito 3406 e o berloque de chave 3407incluem informação codificada que o terminal do POS detecta e envia para oprocessador de transação 3402 através da rede proprietária 3403. Infeliz-mente, ambos o cartão de crédito e o berloque de chave são incapazes defuncionar sem acesso ao terminal do POS por proximidade ou através dotelefone.
O processador de transação 3402 submete a transação para ointercâmbio do cartão de crédito (uma rede de entidades financeiras que secomunica para controlar o processamento, compensação e quitação dastransações do cartão de crédito) através da rede privada 3404. O intercâm-bio do cartão de crédito guia a transação para o emissor do cartão de créditodo consumidor. O emissor identifica o consumidor com base no número deconta detectada e determina o limite de crédito disponível antes de aprovarou declinar a transação. Se a transação é aprovada, a quantia é enviadapara o processador do banco do comerciante 3405 através do intercâmbiodo cartão de crédito com a quantia sendo adicionada na conta de créditomantida pelo banco para o comerciante.
Desde que a informação para a transação é transportada emredes proprietárias, os comerciantes pagam uma despesa de serviço mensalexagerada pelo privilégio de aceitar cartões de crédito e para acessar essasredes proprietárias. Os comerciantes também pagam uma despesa por tran-sação substancial para cada transação. Por exemplo, para tratar de umasimples transação para compra de uma garrafa de água em uma loja deconveniências por US$1, o comerciante pode incorrer em uma despesa portransação de aproximadamente $0,25 e 3 por cento da quantia da transação,embora despesas muito mais altas sejam típicas se o comerciante incorre em uma grande quantidade de devolução de despesa. Depois de contabili-zar suas despesas gerais, a despesa por transação pode ser uma partesubstancial das despesas gerais e, em alguns casos, pode ser mais do quea margem de lucro em um item particular. Infelizmente, para muitos peque-nos comerciantes, a combinação da despesa do serviço mensal e da despe- sa de intercâmbio por transação pode exceder seu lucro total em vendas decartão de crédito para o mês. Para comerciantes maiores, a taxa de inter-câmbio é um obstáculo menos significativo na rentabilidade, mas ainda umaerosão importuna nas suas margens de lucro.
Não somente os cartões de créditos é um item de dispêndio de "alto custo" para a maior parte dos comerciantes, eles também são sujeitos afraude e abuso substanciais. Por exemplo, se um cartão de crédito é rouba-do, ele pode ser usado em um terminal do POS por qualquer um, mesmo seeles não são os donos. Para impedir tal uso, muitos terminais de POS agoraincluem uma solicitação que o consumidor insira o código postal onde a nota do cartão de crédito é enviada, para autenticar o consumidor como o dono.Infelizmente, a informação postal está facilmente disponível na Internet, en-tão o ladrão ativo não é detido pela solicitação de informação adicional paracompletar a transação. O dono, entretanto, é incomodado por ter que inserirtal informação supérflua.
Finalmente, o sistema de cartão de crédito de circuito abertosimplesmente não é adaptável para transações de pessoa a pessoa ondeuma parte não é um comerciante. Por exemplo, se dois estudantes desejamcompartilhar as despesas para um par de ingressos de cinema, um estudan-te pode desejar transferir eletronicamente os fundos para o outro estudante.Entretanto, a taxa de intercâmbio sozinha tornaria a transação suficiente-mente cara para desencorajar o uso. Além do que, é improvável que qual-quer estudante concorde em pagar a taxa mensal e outras despesas associ-adas com a conta de um comerciante a fim de acessar o intercâmbio do car-tão de crédito. Dessa maneira, o sistema de circuito fechado desenvolvido eoperado pelos emissores de cartão de crédito é totalmente inadequado paratransações financeiras de pessoa para pessoa.
Portanto, o que é necessário é um sistema de pagamento móvelde custo efetivo que possibilite a um dono de conta a flexibilidade para con-duzir suas transações financeiras a qualquer momento em qualquer lugar. Oque é também necessário é uma "carteira móvel" que as pessoas possamtransportar como uma fonte de dinheiro que fique acessível a partir de um telefone móvel. Além do que, o que é necessário é uma aplicação de softwa-re e serviços gerenciados para pagamentos móveis do consumidor que ope-re como uma carteira móvel em uma plataforma de telefone móvel. Essacarteira móvel deve ser segura, fácil de usar e fácil de adquirir de modo quea capacidade de fazer pagamentos móveis fique disponível para qualquer dono de conta móvel. Além do mais, o que é necessário é um sistema detransação financeira de circuito fechado que facilite os pagamentos sem asdespesas de pagamento substanciais associadas com os sistemas financei-ros de circuito fechado e tenha um alto nível de segurança para o dono, ocomerciante e outros envolvidos nas transações financeiras. Dessa maneira, as modalidades seguintes e as descrições exemplares das invenções sãoreveladas.
Sumário da invenção
Uma plataforma e serviço de pagamento móvel proveem umamaneira rápida, fácil, de fazer pagamentos por usuários dos dispositivos mó- veis. A plataforma também faz interface com canais não móveis e dispositi-vos tais como e-mail, mensageiro instantâneo e Web. Em uma implementa-ção, os fundos são acessados a partir do dispositivo móvel do dono de umaconta tal como um telefone móvel ou um assistente digital pessoal para fazerou receber pagamentos. As transações financeiras podem ser conduzidasem uma base de pessoa para pessoa (P2P) ou pessoa para comerciante(P2M) onde cada parte é identificada por um indicador único, tal como umnúmero de telefone ou código de barras. As transações podem ser solicita-das através de qualquer número de recursos incluindo troca de mensagensSMS, Web, e-mail, mensageiro instantâneo, uma aplicação de cliente móvel,uma aplicação de arquivo complementar de troca de mensagem instantâneaou "widget". A aplicação do cliente móvel, residente no dispositivo móvel,simplifica o acesso e executa as transações financeiras em uma maneirarápida, segura.
A invenção provê um sistema de pagamento móvel (MPS) ousistema de pagamento móvel de pessoa para pessoa que permite transa-ções em dinheiro rápidas e fáceis. O telefone móvel está se tornando cadavez mais ubíquo ao redor do mundo. Muitas pessoas transportam um telefo-ne móvel ou dispositivo de comunicações portátil similar, mesmo se eles nãotransportam uma carteira junto com eles quando eles ocupam-se das suasvidas diárias. Através do sistema de pagamento móvel e seus telefones, osusuários serão capazes de fazer o que eles podem com uma carteira normale muito, muito mais. Os usuários serão capazes de enviar e receber dinhei-ro, pagar por serviços, pagar as contas, pagar por ingressos de cinema, pa-gar armazéns, pagar uma babá, pagar por café e um jornal, instantaneamen-te pagar de volta um amigo, dividir uma conta de jantar, enviar dinheiro paraas crianças, obter dinheiro dos pais, obter dinheiro rápido ou de emergência,enviar dinheiro de emergência, pagar integralmente ou coletar uma apostaamigável, pagar por futebol de fantasia, pagar por serviços de jardinagem,pagar por quotas de associação, rastrear compras, verificar o saldo e mais.Como pode ser verificado, o sistema da invenção provê muitos benefícios.
Os problemas e necessidades que a invenção trata incluem: di-nheiro pode ser roubado e transações em dinheiro não podem ser rastrea-das: necessidade de encorajar que o dinheiro permaneça nos bancos aoinvés de nos bolsos do consumidor. Necessidade por armazenamento dedinheiro de baixo custo ou pequeno depósito. Necessidade por pagamentoseletrônicos de baixo custo. Necessidade que os pagamentos eletrônicos es-tejam disponíveis para qualquer um, em qualquer lugar, a qualquer tempo eem tempo quase real. Necessidade que os pagamentos eletrônicos resultemem uma forma instantaneamente utilizável (cartão de débito pré-pago dacompanhia, por exemplo, ou através de uma ligação em tempo real na contade depósitos sob demanda (DDA) do usuário em um banco). Necessidadeque os pagamentos eletrônicos fiquem acessíveis para consumidores quetenham conta bancária e não tenham. Necessidade que os pagamentos eie-trônicos possam ser ligados em instrumentos financeiros existentes tais co-mo crédito, débito, pré-pago, folha de pagamento e outros. Necessidade depoder carregar e descarregar de instrumentos financeiros existentes emtempo real ou em tempo quase real. Necessidade que os pagamentos ele-trônicos funcionem através dos bancos. Necessidade que os pagamentoseletrônicos sejam acessíveis via dispositivos móveis. Necessidade que ospagamentos eletrônicos fiquem acessíveis via dispositivos de mídia do con-sumidor tais como PCs, terminais de pagamento de POS, conversores defreqüência de TV, gravadores de vídeo digital (DVRs), conversores de satéli-te e outros. Necessidade que os pagamentos eletrônicos fiquem acessíveisvia dispositivos de pessoa para máquina tais como máquinas de vendas,parquímetros, quiosques e outros. Necessidade que os pagamentos eletrô-nicos funcionem através de redes eletrônicas tais como portadoras móveis,portadoras a cabo, portadoras via satélite e outros.
Alguns dos benefícios da invenção incluem que os pagamentoseletrônicos MPS encorajam que o dinheiro permaneça no banco (ao invés denos bolsos do consumidor). Pagamentos eletrônicos MPS são seguros epodem ser rastreados. Pagamentos eletrônicos MPS ocorrem em tempoquase real. Pagamentos eletrônicos MPS ficam acessíveis para qualquerum, a qualquer tempo e em qualquer lugar. O MPS pode prover um cartãode débito pré-pago da companhia opcional ou não requerido (por exemplo,MasterCard, Visa ou outro) para a acessibilidade de fundos instantânea. Pa-gamentos eletrônicos MPS podem ser alavancados para transações de pes-soa-2-pessoa (P2P), bem como pessoa-2-comerciante (P2M). Os fundosMPS são armazenados dentro das contas bancárias de parceiros em fundocomum distribuído. Os registros "T" para os fundos do consumidor MPS sãogerenciados dentro do sistema de pagamento MPS do registro (para transfe-rência P2P e P2M de baixo custo). MPS facilita a funcionalidade de cargamanual ou automática de instrumentos financeiros existentes (por exemplo,crédito, débito, outros). MPS facilita a funcionalidade de descarga manual ouautomática para instrumentos financeiros existentes (por exemplo, crédito,débito, outros). MPS pode otimizar o processamento de carga ou descarga(isto é, executando carga ou descarga dentro do banco quando possível).MPS facilita os pagamentos eletrônicos em uma maneira de banco mútuo.MPS facilita os pagamentos eletrônicos em uma maneira de portador mútuoou rede mútua. MPS facilita os pagamentos eletrônicos em uma maneira dedispositivo mútuo ou canal mútuo (isto é, móvel, e-mail, Web, mensageiroinstantâneo). Os fundos MPS são eletrônicos, protegidos por PIN e "vivem"no banco.
Além do que, um sistema de transação financeira de circuito fe-chado baseado, em parte, no uso de um telefone celular ou um PDA parafazer ou receber pagamentos. As transações financeiras podem ser condu-zidas em uma base de pessoa para pessoa onde cada parte é identificadapor um indicador único tais como um número de telefone, endereço de e-mail, identificador de troca de mensagens instantânea ou código de barrasou em uma base de consumidor para comerciante. Estruturas de taxa sãoreveladas para facilitar a adoção difundida e liberar as pessoas de ter quetransportar dinheiro.
Em uma modalidade, a invenção é um sistema de transaçõesfinanceiras incluindo uma interface do consumidor, conectada em uma rede,incluindo: uma interface da Web para tratar de solicitações de transaçãoprovenientes de um cliente do navegador da Web, uma interface de navega-dor da Internet móvel para tratar de solicitações de transação de um nave-gador da Internet móvel em um cliente de telefone móvel, uma interface deSMS para tratar de solicitações de transação usando troca de mensagens detexto SMS e uma interface de aplicação de cliente móvel para tratar de soli-citações provenientes de uma aplicação de cliente móvel executando no cli-ente do telefone móvel.
A interface do consumidor pode incluir uma interface de respostade voz interativa para tratar de solicitações provenientes de um canal de vozde telefone. O sistema pode incluir uma conta em fundo comum para usuá-rios recentemente registrados, onde os usuários recentemente registradospodem conduzir as transações provenientes de usuários registrados imedia-tamente depois do registro. A interface de aplicação do cliente móvel podepermitir uma transação de envio de dinheiro, transação de carregamento deconta, transação de descarregamento de conta e transação de pesquisa desaldo. A interface do consumidor pode também incluir uma interface demensageiro instantâneo para tratar de solicitações provenientes de um clien-te de mensageiro instantâneo.
O sistema pode incluir: uma interface de parceiro financeiro, umainterface comercial, onde os usuários através da interface do consumidorpodem acessar o seu dinheiro em um banco conectado ao sistema atravésda interface do parceiro financeiro e transferir dinheiro para comerciantesconectados à interface comercial. O sistema pode incluir um sistema de re-gistros gerenciado pelo sistema de transação financeira, registrando a tran-sação executada através da interface do consumidor. O sistema pode incluiruma conta em fundo comum gerenciada pelo sistema de transação financei-ra, onde um número dos clientes acessando o sistema através da interfacedo consumidor tem uma conta na conta em fundo comum. Um número dosclientes pode não ter uma conta na conta em fundo comum, mas ao invésdisso, ter uma conta em uma instituição financeira, que tem acesso ao sis-tema.
Em uma modalidade, a invenção é um método incluindo: proveruma interface de programa aplicativo para conduzir as transações com umprimeiro parceiro financeiro, prover uma interface de troca de mensagensSMS para receber solicitações para conduzir transações e prover uma inter-face de aplicação de cliente móvel para receber solicitações para conduzirtransações, onde através da interface do mensageiro SMS ou da interfacedo cliente móvel, um cliente pode solicitar uma transferência de dinheiro deuma primeira conta no primeiro parceiro financeiro para uma segunda contano segundo parceiro financeiro.
O método pode também incluir prover uma interface de progra-ma aplicativo para conduzir as transações com um segundo parceiro finan-ceiro, onde através da interface do mensageiro SMS ou da interface do cli-ente móvel, um cliente pode solicitar uma transferência de dinheiro de umaconta no primeiro parceiro financeiro para uma conta no segundo parceirofinanceiro. O método pode incluir prover um sistema de registro para regis-trar transações solicitadas através das interfaces de cliente móvel e de trocade mensagens SMS.
Em uma modalidade, a invenção é um método incluindo: exibiruma primeira tela em um mostrador de um telefone móvel para mostrar umnúmero de opções incluindo uma primeira opção para pagar dinheiro paraum outro e uma segunda opção para solicitar informação de saldo, com ousuário selecionando a primeira opção, exibir uma segunda tela onde o usu-ário insere um número de telefone alvo para o qual enviar o pagamento, de-pois que o usuário insere o número do telefone alvo, exibir uma terceira telaonde o usuário insere uma quantia de transação, depois que o usuário inse-re o número do telefone, exibir uma quarta tela onde o usuário insere umcódigo PIN e depois que o usuário insere o código PIN, enviar de modo semfio a informação da transação incluindo o número do telefone alvo, a quantiada transação e o código PIN para um servidor para processamento.
O método pode incluir depois que o usuário insere o número dotelefone alvo, exibir uma quinta tela onde o usuário insere uma mensagemopcional. O método pode incluir: com o usuário selecionando a segunda op-ção, enviar de modo sem-fim uma solicitação por informação de saldo para oservidor, receber informação de saldo proveniente do servidor e exibir a in-formação de saldo em uma quinta tela. O método pode incluir onde a primei-ra tela também provê uma terceira opção para solicitar pagamento de umoutro. O método pode incluir onde a segunda tela tem uma terceira opçãoque, com a seleção pelo usuário, provê ao usuário o acesso a um livro deendereços do qual o usuário pode selecionar uma entrada para usar como onúmero de telefone alvo. A informação de transação pode incluir um númerode seqüência gerado pelo telefone móvel. Em uma implementação, os fun-dos do usuário são mantidos no servidor e não no telefone móvel.Em uma implementação, o método inclui: com a recepção deuma solicitação de solicitar pagamento no telefone móvel, exibir a quinta telaonde o usuário pode inserir uma quantia de gorjeta.
Outros objetivos, aspectos e vantagens da presente invenção setornarão evidentes com a consideração da descrição detalhada seguinte edos desenhos acompanhantes, nos quais designações de referência seme-lhantes representam aspectos semelhantes por todas as figuras.Breve Descrição dos Desenhos
A figura 1 mostra um diagrama de blocos de um sistema da in-venção.
A figura 2 mostra uma arquitetura de software para uma modali-dade específica da invenção.
A figura 3 mostra um ambiente para implementar uma modalida-de da invenção.
A figura 4 mostra uma modalidade da invenção onde serviços devalor adicionado são providos em conjunto com serviços de pagamento.
A figura 5 mostra uma topologia do sistema para pagamentosmóveis de pessoa para pessoa.
A figura 6 mostra um pagamento entre bancos de pessoa parapessoa.
A figura 7 mostra um pagamento de banco mútuo de pessoa pa-ra pessoa.
A figura 8 mostra uma carga de conta vinculada.
A figura 9 mostra uma descarga de conta vinculada.
A figura 10 mostra um sistema de pagamento e um pagamentode pessoa para pessoa de acordo com uma técnica da invenção.
A figura 11 mostra um método para executar uma transação en-tre um membro com um cartão e um usuário não registrado.
A figura 12 mostra um método para executar uma transação en-tre um membro sem um cartão e um usuário não registrado.
A figura 13 mostra um método para executar uma transação en-tre um membro sem cartão e um outro membro sem cartão.A figura 14 mostra um método para executar uma transação en-tre um membro com cartão e um outro membro com cartão.
A figura 15 mostra um método para executar uma transação en-tre um membro com cartão e um membro sem cartão.
A figura 16 mostra um método para executar uma transação en-tre um membro sem cartão e um membro com cartão.
A figura 17 mostra um método de registro para um usuário nãoregistrado.
A figura 18 mostra um método de ativação de um cartão.
A figura 19 mostra um diagrama do sistema geral de uma moda-lidade específica da invenção.
A figura 20 mostra um pagamento de pessoa para pessoa entreduas contas de cartão individuais.
A figura 21 mostra um pagamento de pessoa para pessoa entreuma conta com cartão e uma conta de não membro.
A figura 22 mostra um pagamento de pessoa para pessoa entreuma conta de cartão e uma conta sem cartão.
A figura 23 mostra um pagamento de pessoa para pessoa para aconta sem cartão para uma conta sem cartão.
A figura 24 mostra uma carga de cartão de crédito.
A figura 25 mostra o diagrama geral do sistema de uma outramodalidade específica da invenção.
A figura 26 mostra um pagamento de pessoa para pessoa entreuma conta sem cartão e uma conta sem cartão.
A figura 27 mostra um pagamento de pessoa para pessoa entreuma conta sem cartão e uma conta com cartão.
A figura 28 mostra um pagamento de pessoa para pessoa parauma transação viral para um não membro.
A figura 29 mostra o financiamento de incentivo.
A figura 30 mostra a carga do cartão de crédito.
A figura 31 mostra a carga ACH.
A figura 32 mostra a descarga ACH.A figura 33 mostra uma carga de ATM.
A figura 34 mostra um ambiente da técnica anterior para imple-mentar uma transação de cartão de crédito usando a rede de intercâmbio"fechada".
A figura 35 mostra um sistema de transação de pagamento decircuito fechado de acordo com uma modalidade da presente invenção.
A figura 36 mostra um ambiente para implementar um sistemade transação financeira de circuito fechado com baixas taxas e segurançamelhorada de acordo com uma modalidade da invenção.
A figura 37 é um diagrama de blocos de um sistema financeirode circuito fechado de acordo com uma modalidade da invenção.
A figura 38 é um diagrama de blocos da aplicação do clientemóvel (MCA) de acordo com uma modalidade da invenção.
A figura 39 mostra um sistema de transação de pagamento decircuito fechado de acordo com uma modalidade da presente invenção.
A figura 40 mostra uma estrutura de taxa exemplar para o siste-ma financeiro de circuito fechado de acordo com uma modalidade da inven-ção.
A figura 41 mostra uma operação de crédito de carga em umaimplementação do sistema de pagamento suportada por membros da inven-ção.
A figura 42 mostra um registro de consumidor no sistema de pa-gamento suportado por membros.
A figura 43 mostra operações de carga e descarga no sistemade pagamento suportado por membros.
A figura 44 mostra uma transação de compra no sistema de pa-gamento suportado por membros.
A figura 45 mostra um sistema usando uma conta em fundo co-mum virtual.
A figura 46 mostra um aspecto de compra rápida de acordo comuma modalidade da presente invenção.
A figura 47 mostra um outro aspecto de compra rápida de acor-do com uma modalidade da presente invenção.
A figura 48 é uma ilustração ao nível do sistema de uma transa-ção financeira executada por pelo menos um mecanismo de troca de men-sagens SMS de acordo com uma modalidade da presente invenção.
A figura 49 mostra um método para garantir transações financei-ras baseadas em SMS de acordo com uma modalidade da presente inven-ção.
A figura 50 mostra o uso de um servidor de agregação SMS se-guro de acordo com uma modalidade da presente invenção.
A figura 51 mostra um processo de registro para um novo donode conta de acordo com uma modalidade da presente invenção.
A figura 52 mostra um sistema de detecção de fraude em sériede acordo com uma modalidade da presente invenção.
A figura 53 mostra uma estrutura de conta em fundo comum de acordo com uma modalidade da presente invenção.
As figuras 54, 55 e 56 mostram um método para impedir a frau-de e múltiplas solicitações de transação em duplicata de acordo com moda-lidades da presente invenção.
A figura 57 mostra um exemplo da autenticação do número de seqüência.
A figura 58 mostra um outro exemplo da autenticação do númerode seqüência.
A figura 59 mostra o protocolo de transmissão de dados que es-pecifica o formato dos dados serializados passados entre dispositivos e ocentro de dados de acordo com uma modalidade da invenção.
A figura 60 mostra uma invocação bem sucedida da chamada deserviço de acordo com uma modalidade da invenção.
A figura 61 mostra uma resposta para uma chamada de serviçoonde uma exceção é gerada como um resultado da chamada de serviço de acordo com uma modalidade da invenção.
A figura 62 mostra uma invocação bem-sucedida de uma outrachamada de serviço de acordo com uma modalidade da invenção.A figura 63 mostra camadas de projeto OMAP de alto nível paraum dispositivo móvel de acordo com uma modalidade da invenção.
A figura 64 é um diagrama de estado que mostra o projeto decomunicação OMAP de acordo com uma modalidade da invenção.
A figura 65 é um diagrama de estado que mostra o projeto depersistência OMAP de acordo com uma modalidade da invenção e o dia-grama de estado que mostra o projeto de notificação do usuário OMAP deacordo com uma modalidade da invenção.
A figura 66 mostra a paleta de tela OMAP de acordo com umamodalidade da invenção.
A figura 67 é um diagrama de estado que mostra as transiçõesde tela OMAP de acordo com uma modalidade da invenção.
A figura 68 mostra o Ieiaute para o menu principal OMAP de a-cordo com uma modalidade da invenção.
A figura 69 mostra o fluxo de tela de pagamento OMAP da pers-pectiva da origem de acordo com uma modalidade da invenção.
A figura 70 mostra o fluxo de tela de pagamento OMAP da pers-pectiva do alvo de acordo com uma modalidade da invenção.
A figura 71 mostra o fluxo de tela de solicitação de pagamentoOMAP da perspectiva da origem da solicitação de acordo com uma modali-dade da invenção.
A figura 72 mostra o fluxo de tela de solicitação de pagamentoOMAP da perspectiva de aceite do alvo de acordo com uma modalidade dainvenção.
A figura 73 mostra o fluxo de tela de solicitação de pagamentoOMAP onde o alvo nega uma solicitação de acordo com uma modalidade dainvenção.
A figura 74 mostra o fluxo de tela de solicitação de pagamentoOMAP onde ambos a origem e o alvo aceitam uma solicitação de acordocom uma modalidade da invenção.
A figura 75 mostra o fluxo de tela de solicitação de pagamentoOMAP onde ambos a origem e o alvo negam uma solicitação de acordo comuma modalidade da invenção.
A figura 76 mostra o fluxo de tela de saldo OMAP de acordo comuma modalidade da invenção.
A figura 77 mostra o fluxo de tela da história OMAP de acordocom uma modalidade da invenção.
A figura 78 mostra o fluxo de tela das definições OMAP na ori-gem de acordo com uma modalidade da invenção.
A figura 79 mostra o fluxo de tela para o OMAP para um ID mó-vel desconhecido de acordo com uma modalidade da invenção.
A figura 80 mostra o fluxo de tela de exceção do sistema OMAPonde uma solicitação falha de acordo com uma modalidade da invenção.
As figuras 81 a 86 mostram telas do usuário e fluxos para umaaplicação de telefone móvel para execução de pagamentos de pessoa parapessoa.
As figuras 87 e 88 mostram uma arquitetura para prover um sis-tema de pagamento fora de linha de acordo com uma modalidade da pre-sente invenção.
A figura 89 é um diagrama de blocos dos componentes de umdispositivo móvel para conduzir ambas as transações financeiras em temporeal e fora de linha em um dispositivo móvel de acordo com uma modalidadeda presente invenção.
A figura 90 mostra a infra-estrutura de aplicação J2ME para oMCA de acordo com uma modalidade da presente invenção.
A figura 91 mostra os diagramas de seqüência de tela e de inici-alização de aplicação (MCA) de acordo com uma modalidade da presenteinvenção.
A figura 92 mostra as classes de seqüência de tela de acordocom uma modalidade da presente invenção.
A figura 93 mostra a invocação do serviço síncrono J2ME EWPde acordo com uma modalidade da presente invenção.
A figura 94 mostra uma interação assíncrona com o servidor ounotificação não solicitada de acordo com uma modalidade da presente in-venção.
A figura 95 é uma representação de um dispositivo de comuni-cações do consumidor móvel típico, um telefone celular, que opera com ummódulo de identificação.
A figura 96 é um diagrama de blocos de um arranjo de um adap-tador IM conectado a um IM e uma unidade de processamento programável,de acordo com uma modalidade da presente invenção.
A figura 97 ilustra como o adaptador IM do arranjo da figura 96pode ser ligado no soquete IM de um telefone celular,
A figura 98 ilustra como o arranjo da figura 96 é movido, de mo-do que ele pode ser armazenado dentro do telefone celular.
A figura 99 é um diagrama de blocos ilustrando as conexões elé-tricas do arranjo da figura 96 de acordo com uma modalidade da presenteinvenção.
A figura 100 é um diagrama de blocos do arranjo da figura 96com uma conexão USB para computadores Iaptop se comunicarem comuma rede de comunicações sem fio com as vantagens da presente inven-ção.
A figura 101 é uma representação de alguns dos elementos desoftware na unidade de processamento programável no arranjo da figura 96de acordo com uma modalidade da presente invenção.
A figura 102 é uma representação do diagrama de blocos dacomunicação de canal por voz entre um dispositivo de comunicações doconsumidor móvel e um servidor da rede, de acordo com uma modalidadeda presente invenção.
Descrição Detalhada da Invenção
Nessa descrição das modalidades da presente invenção, nume-rosos detalhes específicos são providos, tal como exemplos de componen-tes ou métodos, ou ambos, para prover um entendimento completo das mo-dalidades da presente invenção. O versado na técnica relevante reconhece-rá, entretanto, que uma modalidade da invenção pode ser praticada sem umou mais dos detalhes específicos, ou com outros aparelhos, sistemas, mon-tagens, métodos, componentes, partes ou semelhantes e combinações des-ses. Em outros casos, estruturas bem conhecidas, materiais ou operaçõesnão são especificamente mostrados ou descritos em detalhes para evitarobscurecer os aspectos das modalidades da presente invenção.
Em uma implementação específica, a presente invenção refere-se a uma plataforma de pagamento móvel e serviço. Uma modalidade dapresente invenção abrange uma plataforma de pagamento que provê umamaneira rápida, fácil para fazer pagamentos por indivíduos ou comerciantesusando seus dispositivos móveis para acessar uma conta tal como uma con-ta de débito. Interfaces adicionais incluem IM1 Web e widgets de aplicação.Outras contas podem incluir um DDA ou uma conta de cartão de crédito. Aconta pode também ser uma conta de valor armazenado sem um cartão as-sociado com ela. Modalidades adicionais da presente invenção abrangemuma variedade de parceiros que inclui operadores de telefone móvel, comer-ciantes nacionalmente identificados por marca e provedores de serviço fi-nanceiro junto com uma plataforma de pagamento que provê uma maneirarápida, fácil de fazer pagamentos por indivíduos usando seus dispositivosmóveis.
A figura 1 mostra um diagrama de blocos de um sistema da in-venção para conduzir transações de troca de valor incluindo em implemen-tações específicas, pagamentos e transações móveis de pessoa para pes-soa, transações de pagamento móvel de pessoa para comerciante e transa-ções bancárias móveis. Um servidor de aplicações 107 é conectado em umarede 109. Embora somente um servidor de aplicações seja mostrado, podeexistir qualquer número de servidores de aplicações em um sistema da in-venção. Tais servidores de aplicações podem estar funcionando em umamáquina de servidor única ou um número de máquinas de servidor. À medi-da que a carga em um servidor de aplicações aumenta, tipicamente maismáquinas serão usadas para lidar com e responder a maior carga.
Uma interface comercial 112 e uma interface do consumidor 116são também conectadas na rede. Essa rede pode ser qualquer rede paratransportar dados incluindo, mas não limitada a, Internet, Ethernet, linha deserviços de telefone antigo simples (POTS), rede de telefone comutada pú-blica (PSTN), ISDN1 DSL, cabo coaxial, fibra ótica, satélite, celular, por fia-ção, sem fio, linha fixa, serial, paralela e muitas outras e combinações des-sas. A interface do consumidor pode lidar com qualquer número de consu-midores tais como consumidor A, consumidor B e até o consumidor n, onden é qualquer número inteiro positivo. A interface comercial é também conec-tada no servidor de aplicações. Similar a interface do consumidor, pode exis-tir qualquer número de comerciantes que se conectam no servidor de aplica-ção.
No servidor de aplicações está um processador de pagamento119, que pode também ser conectado na interface comercial. Uma interfacede instituição financeira 123 é conectada no servidor de aplicações e pro-cessador de pagamento. Pode existir qualquer número de instituições finan-ceiras conectadas no servidor de aplicações. O servidor de aplicações podetambém incluir um banco de dados 127. Alternativamente, o banco de dadospode estar em um servidor separado do servidor de aplicações e acessívelpara o servidor de aplicações através de uma rede ou outra conexão. A insti-tuição financeira é também conectada no banco de dados. O banco de da-dos pode incluir um sistema de registro 130 e contas em fundo comum virtu-ais 134, que o servidor de aplicações pode controlar. A instituição financeirapode controlar as contas em fundo comum 138. Portanto, o sistema de regis-tro e as contas em fundo comum virtuais podem ser controlados separada-mente das contas em fundo comum na instituição financeira.
Um sistema da invenção pode incluir qualquer número dos ele-mentos mostrados na figura. O sistema pode incluir outros elementos nãomostrados. Alguns elementos podem ser divididos em blocos separados, oualguns elementos podem ser incorporados ou combinados com outros ele-mentos (por exemplo, dois blocos combinados em um único bloco). Adicio-nalmente, alguns elementos podem ser substituídos por outros elementosnão mostrados (por exemplo, substituindo um bloco por um bloco diferente).
Em operação, o sistema da invenção facilita as transações fi-nanceiras entre consumidores e entre um consumidor e um comerciante. Emuma implementação, o consumidor iniciando uma transação pode estar u-sando um dispositivo móvel, tal como um telefone móvel ou telefone inteli-gente. Também, o alvo de uma transação pode ser uma pessoa tendo umdispositivo móvel, que é capaz de acessar o sistema de pagamento móvel.
Em uma implementação, a fonte de financiamento dessas tran-sações financeiras pode ser o dono ou o operador do servidor de aplicações(que pode ser citado algumas vezes como um servidor de pagamento móvelou serviço de pagamento móvel). A seguir, consumidores (e comerciantes)serão capazes de carregar ou descarregar fundos do serviço de pagamentomóvel. Esses fundos podem ser de qualquer fonte incluindo dinheiro, che-que, dinheiro, solução de pagamento em linha, transferência de fundos porfiação, conta corrente, conta de poupança, certificados de depósito, conta dehipoteca inversa, conta de corretagem, dividendos, títulos, conta de fundo decobertura, cartão de crédito, cartão de débito ou qualquer instrumento finan-ceiro ou qualquer combinação desses.
Em outras implementações, a fonte de financiamento é uma ins-tituição financeira que fica acessível pelo usuário através do servidor de pa-gamento móvel. Os fundos podem ser transferidos entre as instituições fi-nanceiras se necessário. Por exemplo, o consumidor A pode enviar dinheiropara o consumidor B ou um comerciante, onde as partes têm dinheiro eminstituições financeiras diferentes. O sistema de pagamento móvel facilitará atransferência entre as instituições e notificará as partes apropriadamente.
A figura 2 mostra uma arquitetura de software para uma modali-dade específica da invenção. Esse diagrama de blocos mostra as camadaspara uma arquitetura específica que pode ser implementada no servidor deaplicações. As camadas incluem um recipiente de aplicação da web do con-sumidor 203, um recipiente do sistema de pagamento 206, uma camada depersistência 209 e uma camada do sistema de gerenciamento do banco dedados relacionai (RDBMS) 212.
Em uma implementação específica, o recipiente de aplicação daweb do consumidor e o recipiente do sistema de pagamento podem ser ba-seados em WebLogic por BEA Systems, Inc. A camada de persistência podeser baseada em Hibernate. O sistema de gerenciamento do banco de dadosrelacionai pode usar um banco de dados Oracle. Entretanto, em outras im-plementações específicas, outros fornecedores, abastecedores ou sistemaspodem ser usados. Por exemplo, um sistema da invenção pode incorporar ocódigo de origem aberto.
No recipiente de aplicação da web do consumidor está uma ca-mada de apresentação para tipos diferentes de clientes. Alguns exemplosdas interfaces providas incluem porta SMS, porta de aplicação de telefone,porta dos serviços da web, porta de páginas de aplicação da web e porta deestrutura de aplicação da web. O codec de troca de mensagens de telefoneconverte as solicitações que chegam ou que saem, ou ambas, tal como SMSou mensagens específicas do cliente ou de telefone para o sistema. Umaarquitetura da invenção pode incluir qualquer número dessas interfaces.
O recipiente do sistema de pagamento inclui conectores parasistemas financeiros externos ou de segurança, servidores de correio e ser-viços de troca de mensagens. Existe também uma interface lógica de negó-cios e lógica de negócios do sistema de pagamento. Os clientes do serviçopodem invocar os serviços de negócios através da porta do serviço de negó-cios. A implementação da porta poderia usar EJB ou outras tecnologias.
Um sistema da invenção pode incluir qualquer número dos ele-mentos mostrados na figura. O sistema pode incluir outros elementos nãomostrados. Alguns elementos podem ser divididos em blocos separados oualguns elementos podem ser incorporados ou combinados com outros ele-mentos (por exemplo, dois blocos combinados em um único bloco). Adicio-nalmente, alguns elementos podem ser substituídos por outros elementosnão mostrados (por exemplo, substituindo um bloco por um bloco diferente).
Infra-estrutura do sistema de pagamento - ambiente de tecnolo-gia
Um aspecto da invenção é um sistema ou serviço de pagamentomóvel. Esse pedido discute muitas modalidades específicas e implementa-ções dos componentes e elementos individuais, variações e modificaçõesdesses e combinações desses. Um sistema da invenção pode incluir qual-quer uma das variações ou implementações específicas discutidas, unica-mente ou em qualquer combinação. Nesse pedido, um exemplo de uma im-plementação específica de um sistema de pagamento móvel é provido e es-sa implementação específica é o sistema Obopay. O sistema Obopay é me-ramente um exemplo de uma implementação de um sistema de pagamentomóvel e é discutido para descrever mais facilmente vários aspectos da in-venção. A invenção abrange muitas implementações do sistema de paga-mento móvel e não é limitada às implementações específicas descritas.
A figura 3 mostra uma implementação específica da invenção. Afigura 3 mostra um ambiente de tecnologia robusto 300 de acordo com umamodalidade da presente invenção que compreende uma plataforma de ser-vidor de cliente móvel 302, um ambiente de hardware escalável 304 e a in-tegração do banco 306.
A plataforma 302 é o coração da infra-estrutura do sistema depagamento oferecendo segurança, comunicação, livro razão, moeda, fraudee relatórios e administração. Uma aplicação de cliente móvel (MCA) funcionaem um servidor de pagamento J2EE, a tecnologia favorecida por muitosbancos. As solicitações de transação que chegam e que saem são proces-sadas por HTTP ou comandos de serviços da Web. A detecção da fraude,bancos de dados transacionais e integração do banco completam o quadro.
Será verificado que em vista da natureza ubíqua da presenteinvenção, a plataforma 302 compreende muitas implementações diferentes.Por exemplo, a plataforma 302 pode compreender um sítio de servidor comuma pluralidade de servidores acoplados em uma rede de dispositivos dearmazenamento. Em outras modalidades, a plataforma pode ser implemen-tada como uma pluralidade de centros de dados para prover equilíbrio decarga e redundância.
Infra-estrutura do sistema de pagamento - ambiente de hardwareda plataforma 302
A infra-estrutura do sistema de pagamento é baseada em umambiente de hardware horizontalmente expansível, agrupado e escalávelque provê capacidade de confiabilidade robusta. O sistema operacional combase no Linux suporta aplicações de cliente magro - mais notavelmente na-vegadores tais como Microsoft® Internet Explorer, Netscape, Opera e Mozil-la Firefox. O sistema operacional também suporta aplicações de cliente gor-do. Em uma implementação, Java 2 Platform, Micro Edition (J2ME) e Micro- soft.NET são usados na plataforma do cliente móvel. A arquitetura é facil-mente configurável para permitir outras aplicações de cliente gordo quandonecessário.
Exemplos de clientes que podem fazer interface com o sistemaincluem telefones móveis, telefones inteligentes, dispositivos de assistente digital pessoal, computador portátil, computadores de mesa e muitos outros.Os clientes podem se conectar através de uma rede de comunicações nosistema. Essa rede pode ser sem fio ou ligada por fiação. Em uma imple-mentação específica, a rede é sem fio e os dispositivos do cliente são dispo-sitivos móveis.
A rede de comunicação pode ser feita de muitos sistemas decomputador interligados e ligações de comunicação. As ligações de comuni-cação podem ser ligações por hardware, ligações óticas, ligações de comu-nicações por satélite ou outras sem fio, ligações por propagação de onda ouquaisquer outros mecanismos para comunicação de informação. Vários pro- tocolos de comunicação podem ser usados para facilitar a comunicação en-tre os vários sistemas. Esses protocolos de comunicação podem incluirTCP/IP, protocolos HTTP, protocolo de aplicação sem fio (WAP), protocolosespecíficos do fornecedor, protocolos personalizados e outros. Embora emuma modalidade a rede de comunicação seja a Internet, em outras modali- dades, a rede de comunicação pode ser qualquer rede de comunicação a-dequada incluindo uma rede local (LAN), uma rede remota (WAN), uma redesem fio, uma intranet, uma rede particular, uma rede pública, uma rede co-mutada, uma rede de troca de mensagens SMS, uma rede de telefone mó-vel, uma rede de telefone celular, Ethernet e combinações desses e assim por diante.
A rede pode ser uma rede ligada por fiação (por exemplo, usan-do cobre), rede de telefone, rede de pacote, uma rede ótica (por exemplo,usando fibra ótica) ou uma rede sem fio ou qualquer combinação desses.Por exemplo, dados e outras informações podem ser passados entre o com-putador e os componentes (ou etapas) de um sistema da invenção usandouma rede sem fio usando um protocolo tal como Wi-Fi (padrões IEEE802.11, 802.11a, 802.11b, 802.11e, 802.11g, 802.11i e 802.11η, apenas pa-ra citar uns poucos exemplos).
Em uma modalidade, um usuário faz interface com o sistemaatravés de um dispositivo de computação portátil, tais como um telefone inte-ligente ou telefone móvel. Um sistema de computador pode incluir um mos-trador, gabinete, teclado e dispositivo ponteiro. Dentro do gabinete, podemexistir componentes de computador familiares tais como um processador,memória, dispositivo de armazenamento em massa e assim por diante. Podeexistir um único processador ou múltiplos processadores. O processadorpode ser um processador de núcleo múltiplo.
Alguns exemplos de dispositivos de armazenamento em massaque podem fazer interface com um dispositivo de computação incluem ar-mazenamento de memória flash e outras não voláteis, unidades flash, cartãoflash (por exemplo, cartões SD), unidades de disco de massa, discos flexí-veis, discos magnéticos, discos óticos, discos magneto-óticos, discos fixos,discos rígidos, CD-ROMs, CDs graváveis, DVDs, DVDs graváveis (por e-xemplo, DVD-R, DVD+R, DVD-RW, DVD+RW, HD-DVD ou Disco Blu-ray),memória volátil com bateria de segurança, armazenamento de fita, leitora eoutra mídia similar e combinações desses.
Em uma modalidade, a invenção é software de computador queé executado por um dispositivo de computação. O dispositivo de computa-ção pode ser um dispositivo cliente ou um dispositivo servidor, ou uma com-binação desses. Uma versão executável no computador ou implementada nocomputador da invenção pode ser personificada usando, armazenada em,ou associada com, meio legível por computador. Um meio legível por com-putador pode incluir qualquer meio que participa do fornecimento de instru-ções para um ou mais processadores para execução. Um tal meio pode ado-tar muitas formas incluindo, mas não limitado a, meios não voláteis, voláteise de transmissão. Meios não voláteis incluem, por exemplo, memória flashou discos óticos ou magnéticos. Meios voláteis incluem memória estática oudinâmica, tais como memória cache ou RAM. Meios de transmissão incluemcabos coaxiais, fio de cobre, linhas de fibra ótica e fios dispostos em um bar-ramento. Meios de transmissão podem também adotar a forma de ondaseletromagnéticas, de radiofreqüência, acústicas ou luminosas, tal como es-sas geradas durante as comunicações de dados por onda de rádio e infra-vermelho.
Por exemplo, uma versão binária executável por máquina dosoftware da presente invenção pode ser armazenada ou residir na RAM oumemória cache ou no dispositivo de armazenamento de massa. O código daorigem do software da presente invenção pode também ser armazenado ouresidir no dispositivo de armazenamento de massa (por exemplo, disco rígi-do, disco magnético, fita ou CD-ROM). Como um exemplo adicional, o códi-go da invenção pode ser transmitido via fios, ondas de rádio ou através deuma rede tal como a Internet. Por exemplo, um programa aplicativo da in-venção pode ser carregado e instalado em um telefone. Depois da instala-ção, o usuário do telefone pode executar a aplicação e enviar dinheiro paraum outro usuário.
Produtos de software de computador podem ser escritos emqualquer uma de várias linguagens de programação adequadas tais como C,C++, C#, Pascal, Fortran, Perl, SAS, SPSS, JavaScript, AJAX e Java. Oproduto de software do computador pode ser uma aplicação independentecom módulos de entrada de dados e exibição de dados. Alternativamente, osprodutos de software do computador podem ser classes que podem ser ins-tanciadas como objetos distribuídos. Os produtos de software do computa-dor podem também ser software de componente tais como Java Beans (deSun Microsystems) ou Enterprise Java Beans (EJB de Sun Microsystems).
Um sistema operacional para o sistema pode ser um da famíliade sistemas operacionais da Microsoft Windows® (por exemplo, Windows95, 98, Me, Windows NT, Windows 2000, Windows XP, Windows XP x64Edition, Windows Vista, Windows CE, Windows Mobile), Linux, HP-UX, U-NIX, Sun OS, Solaris, MAC OS X, Alpha OS, AIX, IRIX32 ou IRIX64. Outrossistemas operacionais podem ser usados. Microsoft Windows é uma marcaregistrada da Microsoft Corporation.
Em uma modalidade, com um navegador da web executando emum dispositivo, um usuário acessa um sistema na World Wide Web (WWW)através de uma rede tal como a Internet. O navegador da web é usado paracarregar páginas da web ou outro conteúdo em vários formatos incluindoHTML, XML, texto, PDF e postscript, e pode ser usado para transferir infor-mação para outras partes do sistema. O navegador da web pode usar identi-ficadores constantes de recursos (URLs) para identificar recursos na web eprotocolo de transferência de hipertexto (HTTP) na transferência dos arqui-vos na web.
A plataforma 302 compreende um servidor 308 que lida com ainteração com os donos de conta e mantém registros de transações. O ser-vidor 308 também provê a ligação para os serviços de valor adicionado pro-vidos pelos parceiros comerciais. O servidor 308 utiliza um banco de dadostransacional 309 que preferivelmente compreende uma rede de armazena-mento de dados. O servidor 308 usa informação (tais como números de con-ta, informação de saldo, etc.) obtida do banco de dados transacional 309para gerenciar um processador de pagamento 310 que se comunica com osterminais de ponto de vendas (POS) do comerciante 311. Os comerciantespodem usar os terminais do POS 311 para transações financeiras tal comoadicionar fundos em um cartão de débito para um dono de conta. Os comer-ciantes podem também estabelecer uma ligação separada para o servidorde pagamento 302 para finalidades de contabilidade.
Um mecanismo de quitação manipula as transações dentro dosistema de circuito fechado que quitará em uma base de tempo real. A contado usuário e a conta do comerciante serão atualizadas simultaneamente.Pelo fato de que a maior parte dos comerciantes pode também servir comoagentes de carga, os comerciantes transportarão um saldo na sua conta. Omecanismo de quitação será primariamente usado para vasculhar umaquantia em dólar pré-estabelecida ou uma quantia em dólar acima de ummínimo para uma conta externa do banco controlada pelo comerciante.
O mecanismo de quitação facilita as transações de pessoa parapessoa (P2P) por causa da capacidade de transferir fundos de um dono deconta inscrito para um outro dono de conta inscrito.
A plataforma 302 também compreende um sistema de detecçãode fraude 312 para acompanhar a informação destilada de cada transaçãofinanceira. Tais sistemas de detecção de fraude são conhecidos e são fre-qüentemente usados para monitorar a fraude quando os cartões de créditosão usados. O risco é controlado por um mecanismo de regras geral (verfigura 3) que aplica limites e determina a aceitabilidade das transações soli-citadas de uma perspectiva do risco.
A informação coletada para cada transação financeira pode serminerada para uso pelas aplicações de valor adicionado do consumidor ecomerciante, pelas aplicações de monitoramento de negócios, pelas aplica-ções de operações do sistema e aplicações de monitoramento de segurançacomo indicado em 313.
Para ilustrar, um mecanismo de mercadologia entrega cuponsou descontos para donos de conta provenientes dos comerciantes partici-pantes. Esse mecanismo também controla o uso de créditos de conta instan-tâneos para estimular a inscrição.
Um módulo de conversão de moeda facilita a operação estran-geira onde a medição do valor no sistema de pagamento de circuito fechadoprecisa ser convertida para outras moedas. O módulo também será usadopara controlar a exposição do câmbio estrangeiro.
O mecanismo vira! provê a capacidade de enviar fundos para umusuário não inscrito. Esse módulo permite que o dono da conta envie os fun-dos que enviará uma mensagem para o receptor que os fundos estão sendomantidos para eles contanto que eles se inscrevam.
Um aspecto de perambulação provê um ambiente de transaçãode par para comerciante onde o comerciante usará um telefone móvel parareceber os fundos onde o comerciante não tem acesso a um terminal quetipicamente seria usado para aceitação de cartão de crédito ou débito. Umavantagem da presente invenção surge da segurança de não aceitar dinheiroe fundos garantidos contra um cheque e também provê a verificação instan-tânea que não é possível com uma compra por cartão de crédito sem umterminal.
Integração do parceiro bancário
Os bancos de dados transacionais 308 integram diretamentecom uma conta de banco em fundo comum 306 mantida em um banco par-ceiro. Todos os fundos permanecem dentro dessa conta, embora os comer-ciantes tenham a opção de transferir os seus fundos de suas contas de débi-to pré-pagas para outras contas através de transferências ACH ou integra-ção DDA direta através de uma API direta com seu banco ou através da re-de de ATM. Será verificado que mais do que um banco parceiro pode serconfigurado tal que cada conta pode ser vinculada a uma conta de banco emfundo comum em mais do que um banco. Desde que a plataforma 302 sabeo saldo disponível para cada conta (a despeito do número de parceiros dobanco), não existe risco de fundos não estarem disponíveis quando as quita-ções entre bancos ocorrem.
Trabalhando com parceiros de mercadologia, incluindo operado-ras móveis, comerciantes nacionalmente identificados por marca e provedo-res de serviço financeiro, tais como os bancos principais e as uniões de cré-dito, a infra-estrutura do sistema de pagamento tira vantagem da infra-estrutura móvel existente e da tecnologia de troca de mensagens para ofe-recer serviços financeiros de baixo custo universalmente acessíveis. Emuma implementação, o sistema da invenção provê interoperabilidade entreos bancos. Também existe interoperabilidade entre contas em fundo comume quaisquer contas de dono de cartão que são mantidas como contas individuais.
Parceiros dos provedores de serviço móvel
Os provadores de serviço móvel obtêm renda incrementai, bemcomo o tráfego de dados adicional e uma vantagem competitiva, por ofere-cer aos seus assinantes uma solução de pagamento digital. Ao contrário dosoutros sistemas de pagamento, a presente invenção pode ser oferecida parauma base de consumidor inteira de um provedor, desde que ele pode usarSMS ou o serviço de Internet móvel (por exemplo, WAP) além de uma apli-cação carregável.
Além disso, os donos de conta podem pagar suas contas ou mi-nutos "top-off" através da sua conta de serviço. Isso é especialmente útil pa-ra donos de conta que não tem outros serviços financeiros disponíveis paraeles.
Parceiros comerciais
Vários comerciantes que tradicionalmente aceitam cartões de10 crédito, cartões de débito, cheques e dinheiro aceitarão a infra-estrutura detransferência de pagamento individualizada móvel por causa do seu baixocusto de adoção. Os comerciantes também têm a oportunidade de ganharcomissões para manipular transações de conta pré-paga tal como ajudandoos donos de conta a adicionar fundos nas suas contas. A maior parte doscomerciantes pode também prover pequenas quantias de dinheiro de troco,similar ao modelo de cartão de débito em uso atualmente.
Uma modalidade específica do serviço de pagamento móvel dainvenção tem extensões P2M móveis e serviços da web. Esses permitemque um comerciante aceite pagamento de um usuário de um telefone móvelou sítio da web. Eles podem também ajudar o comerciante a diminuir o seucusto de aceitação da transação e aumentar o seu alcance para seus con-sumidores.Parceiros bancários
Os bancos podem agora "mobilizar" sua base de consumidoresexistente com acesso instantâneo as suas contas e a capacidade de fazerpagamentos de dono de conta para dono de conta. As transações de bancomútuo são também possíveis. Com essa parceria, os bancos podem tam-bém alcançar consumidores previamente muito caros para servir. Ao invésde incorrer na despesa de estabelecer um banco e aderir a um regime regu-lador pesado, as contas em fundo comum nos bancos participantes, lidamcom as coberturas de frente, relatam posições líquidas para ou em nomedos seus bancos parceiros e permitem que os bancos conduzam a quitaçãofinal. Isso é para possibilitar a concordância com as regulamentações gover-namentais e permitir a coexistência ativa com o ambiente bancário.
Pelo uso de bancos parceiros e contas de banco associado, ainfra-estrutura do sistema de pagamento é projetada para aumentar as con-tas bancárias existentes dos donos de conta sempre que possível, porémagir como uma conta discreta quando necessário. Todos os fundos repre-sentados por contas de débito pré-pagas individuais serão mantidos em con-tas de banco comercial mantidas em crédito para os donos da conta. No fimde cada dia de negócios, o saldo agregado de todas as contas igualará o saldo bancário. Todas as transações criadas dentro de um período de vintee quatro horas serão quitadas dentro desse período. As contas funcionamcomo uma carteira com dinheiro onde o saldo muda imediatamente. Em ou-tras palavras, a presente invenção não funciona como um depósito por de-manda no qual os instrumentos podem ser apresentados por um terceiro.Por exemplo, os donos de conta não serão capazes de emitir instrumentospor demanda tal como cheques. Como um resultado, não existirão transa-ções pendentes que quitarão em uma data futura.
Em uma implementação específica da invenção, contas de car-tão de débito não são mantidas em uma conta em fundo comum pelo prove- dor do serviço de pagamento móvel, mas em contas de cartão de débito in-dividuais em um parceiro do banco direto. O provedor do serviço de paga-mento móvel mantém o dinheiro em uma conta em fundo comum para con-sumidores sem cartões que é mantido em crédito no banco.Método de operação
Em uma modalidade da presente invenção, um dono de contaadiciona dinheiro em uma conta de débito pré-paga antes das compras. Odinheiro pode ser adicionado em uma conta de débito pré-paga na localiza-ção de um parceiro, por meio de resposta por voz interativa (IVR) usandoseu telefone móvel ou um outro telefone, através de um sítio da web acessí- vel através da Internet ou pelo contato com um representante do serviço doconsumidor. Em uma modalidade, um usuário pode configurar a ligação dedepósito direto ou vincular uma conta a uma conta de banco via as redesACH ou ATM. 0 dinheiro pode ser transferido de uma conta existente em umparceiro do provedor do serviço financeiro (tal como uma instituição bancá-ria) ou pelo depósito de dinheiro ou um cheque na conta de débito pré-paga(em um comerciante participante ou outro terceiro). Os donos de conta entãotêm acesso a esses fundos através de seus dispositivos móveis para fazerpagamentos e eles podem receber os pagamentos para sua atividade deconta de outros. Em outras modalidades, os fundos podem ser transferidosde uma conta de cartão de crédito designada para a conta de débito pré-paga.
Em uma outra modalidade, os fundos de cada dono de contasão colocados em fundo comum em uma única instituição financeira e cadadono de conta tem uma participação na conta em fundo comum igual aosfundos depositados, menos os fundos transferidos para uma outra contamais os fundos recebidos de outros. Os donos da conta podem sacar algumou todos os seus fundos disponíveis da conta em fundo comum.
Em uma outra modalidade, cada dono de conta pode configuraruma conta de débito pré-paga em qualquer instituição financeira e acessar aconta indiretamente para transferir fundos. Assim, os donos da conta nãosão limitados a um cartão de débito com fundos mantidos na conta em fundocomum em uma instituição financeira particular. Ao contrário, os donos daconta podem acessar uma conta de cartão de débito em uma instituição fi-nanceira da sua escolha.
Em uma outra modalidade, uma conta de cartão de crédito é de-signada como a conta primária e um adiantamento de dinheiro é movido pa-ra uma conta de cartão de débito pré-paga sempre que os fundos na contade cartão de débito caem para ou abaixo de uma quantia selecionada.
Em ainda uma outra modalidade, as transações financeiras sãoconduzidas em uma base de pessoa para pessoa onde cada parte é identifi-cada por um número de telefone e uma senha (por exemplo, um número deidentificação pessoal do PIN). Alternativamente, a transação financeira podeser identificada por um nome de usuário e senha. Em outras modalidades,pelo menos uma parte para uma transação é identificada por um código debarras. O código de barras pode ser exibido em um mostrador tal como atela de um telefone móvel e detectado pela câmara que está presente namaior parte dos dispositivos móveis modernos. O código de barras pode serimpresso no dispositivo ou pode ser de outra forma preso no telefone móvel.
Em uma modalidade específica, uma aplicação de software, ci-tada como uma aplicação de cliente móvel (MCA), residente no telefone mó-vel somente requer que os donos de conta tenham um número de telefonemóvel e a conta de débito pré-paga. Opcionalmente, um cartão de crédito ouuma conta corrente pode ser acessada como uma fonte de financiamento.Vantajosamente, nenhum hardware adicional tal como um terminal do pontode vendas ou acesso à Internet requerido. Depois de registrado, o dono daconta configura um único número de identificação (PIN) de dono da contapara verificar todas as transações. Com o registro, o dono da conta insere oseu número de telefone móvel e um servidor ativa a aplicação do cliente mó-vel para o seu telefone. Depois que a aplicação do cliente móvel está insta-lada, o dono da conta pode começar a usar o telefone móvel para concluir astransações financeiras. Uma outra opção é para o usuário carregar a aplica-ção avançando para um URL específico usando o navegador de Internetmóvel do usuário (por exemplo, get.obopay.com) que começará o processode carregamento para a aplicação móvel.
Os donos de conta podem também escolher vincular a sua contaa um cartão de débito ou crédito oferecido pela instituição financeira e quepode ser usado nos milhões de localizações comerciais mundialmente. Alémdisso, ele permite que os donos da conta obtenham dinheiro da conta dedébito pré-paga usando um ATM caso a necessidade surja.
Para os donos da conta, concluir uma transação financeira éperfeitamente coerente. Simplesmente enviando uma mensagem do telefonemóvel equipado com a aplicação do cliente móvel para um servidor. O servi-dor de pagamento valida cada transação e transfere os fundos ou respondeà solicitação do dono da conta por informação da conta.Envio das solicitações de transação para o servidor
Quando um dono de conta faz uma solicitação de transação apartir do seu telefone móvel, a informação é encaminhada para o operadormóvel, tal como Cingular ou Verizon ou outro provedor de serviço de telefo-ne móvel. A informação é então encaminhada para o servidor de pagamentoatravés de uma conexão segura da Internet. Em modalidades alternativas, ainformação é encaminhada através de redes alternativas, tais como as redessem fio, POTS ou outra rede disponível. Essa redundância é importante por-que o dono da conta não está limitado a uma única trajetória de acesso paracontrolar a sua conta e conduzir as transações financeiras. Dependendo dalocalização do dono da conta ou outras circunstâncias, uma ou mais vias decomunicações podem não estar disponíveis. Entretanto, por causa da re-dundância do sistema, provavelmente existirá pelo menos uma via de comu-nicação disponível e então a transação financeira será permitida.
As solicitações de transação financeira são transmitidas em umade duas maneiras, dependendo do telefone móvel do dono da conta. Se odono da conta tem um telefone habilitado com a aplicação, que possibilitatransmitir a solicitação financeira através de uma aplicação com base naWeb (HTTP ou HTTPS) ou uma aplicação móvel, tais como J2ME, .NET,.NET CF, WAP ou SMS, ou qualquer combinação desses, a transmissãopassa diretamente para o servidor. Uma mensagem de solicitação é enviadadepois que a MCA estabelece uma conexão com o servidor de pagamento.
Desde que os dispositivos habilitados com a aplicação atualmen-te constituem uma porção relativamente pequena dos dispositivos sendousados hoje em dia, o servidor de pagamento também transmite e recebeatravés do serviço de mensagem curta, também citado como troca de men-sagens de texto SMS ou simplesmente SMS, porque quase todos os disposi-tivos suportam SMS. Nesse caso, os dados financeiros são encaminhadospara o operador móvel e a seguir para um agregador de SMS que transmiteas mensagens para o servidor de pagamento em tempo real.
Um sistema de pagamento móvel SMS evita a despesa e osproblemas associados com ter um circuito integrado adicionado no telefonecelular. Na operação do sistema SMS, a informação financeira é enviadausando troca de mensagens de texto SMS. Embora a troca de mensagensde texto SMS funcione bem com todos os tipos de dispositivos celulares ecertos outros tipos de dispositivos de comunicação móvel, tais como assis-tentes digitais portáteis ou PDAs1 SMS expõe senhas não criptografadas ounúmeros de identificação pessoal (PINs), bem como a informação de saldo ou detalhes sobre a transação mais recente. Desde que qualquer pessoaque esteja de posse do telefone pode ler o arquivo de mensagem SMS eimediatamente saber como acessar a conta de um outro, a presente inven-ção, dessa maneira, em uma modalidade, provê a iniciação da transaçãofinanceira por meio da mensagem de texto SMS. A mensagem SMS começa com uma palavra-chave que provê o tipo de transação solicitada - PAGA-MENTO, SOLICITAR PAGAMENTO, SALDO, TRANSFERÊNCIA ou AJU-DA. Em uma implementação, "PAGAMENTO" é citado como "ENVIAR" e"SOLICITAR PAGAMENTO" é citado como "OBTER".
Onde a mensagem SMS contém a palavra chave que indica o desejo de transferir fundos de um dono de conta para um outro dono de con-ta, a palavra-chave seria pagamento ou solicitar pagamento (ou enviar ouobter). Depois da palavra-chave, a quantia é inserida com ou sem um pontodecimal. Depois da quantia, o número do telefone alvo (ou código curto, en-dereço de e-mail, número de licença ou outra informação de identificação) é inserido. Essa informação pode ser obtida do diretório de telefone do dispo-sitivo móvel. Depois do número de telefone, o dono da conta pode inseriruma mensagem para exibição para a outra parte. Em algumas circunstân-cias, essa mensagem pode ser uma mensagem nula. Em algumas modali-dades, o dono da conta pode inserir uma mensagem complementar parafinalidades de manutenção de registro.
Depois que a mensagem SMS é enviada para o servidor de pa-gamento, o PIN é inserido pelo dono da conta e enviado através de uma co-nexão de canal de voz para o servidor de pagamento para verificar a men-sagem SMS. O PIN é inserido através do teclado e pode ser qualquer código alfanumérico. O PIN é então enviado para o servidor de pagamento comouma mensagem codificada em DTMF onde DTMF se refere à múltipla fre-qüência de tom duplo, o sinal que uma companhia de telefone recebe quan-do as teclas de toque de um telefone são pressionadas.
No servidor, o servidor de pagamento recebe a mensagem SMSatravés da trajetória de comunicação da mensagem de texto SMS e o PINatravés do canal de voz. A chamada para o servidor de pagamento pode serfeita pelo dono da conta ou ela pode ser iniciada como um aspecto de "cha-mada de autenticação" pelo servidor de pagamento em resposta à recepçãoda mensagem SMS. O PIN pode ser enviado como uma mensagem codifi-cada em DTMF para manter a segurança, mas em outras modalidades, oPIN pode ser falado pelo dono da conta e convertido por um módulo desoftware de reconhecimento de voz interativo operando no servidor de pa-gamento ou um outro servidor (não mostrado) dedicado ao tratamento daschamadas de voz.
Em uma modalidade, o dispositivo móvel inclui a aplicação docliente móvel. A aplicação do cliente móvel é invocada, diretamente pelo do-no da conta ou em resposta à ativação do aspecto de troca de mensagensde texto SMS no dispositivo móvel. A MCA determina o melhor método paraenviar o PIN.
Em uma modalidade alternativa, o PIN é criptografado pela apli-cação do cliente móvel e incluído em uma mensagem SMS subseqüente queé enviada para o servidor de pagamento. O servidor de pagamento correla-ciona as mensagens comparando o número de telefone e o tempo em quecada mensagem foi enviada. Se o PIN foi enviado em uma mensagem queestava distante no tempo comparado com a mensagem SMS, a transaçãopode ser rejeitada. Se somente uma das duas mensagens é recebida, atransação pode ser rejeitada. Se, entretanto, ambos a mensagem SMS comos detalhes da transação financeira (mínimo de em uma palavra-chave) e ocódigo PIN são recebidos e são verificados, então a transação financeira éconcluída.
Em uma modalidade alternativa, quando um canal de voz estádisponível, a aplicação do cliente móvel invoca um módulo para codificar oPIN na forma DTMF. O DTMF é então enviado pela aplicação do cliente mó-vel para o servidor de pagamento junto com uma conexão de canal de vozestabelecida pela aplicação do cliente móvel. O módulo pode ser uma APIJava que gera os tons apropriados com base na entrada do teclado.
Em ainda uma outra modalidade alternativa, a aplicação do cli-ente móvel provê uma interface do usuário (UI) na tela de exibição do dispo-sitivo móvel para guiar o dono da conta para concluir a transação financeira.Nessa modalidade, o dono da conta é guiado através do processo de cons-trução da mensagem de texto SMS pela inserção automática da palavra-chave, quantia, número de telefone alvo, senha e mensagens se qualquer.
Em ainda uma outra modalidade alternativa, a mensagem SMSpode incluir a palavra-chave, a quantia, o número de telefone alvo e a senha.Um inconveniente desta implementação é que a senha ficaria visível paraqualquer um controlando o dispositivo móvel. Entretanto, a presente inven-ção lida com esse problema enviando uma mensagem ou instruindo o usuá-rio através da ajuda e informação FAQ, para o dono da conta deletar a men-sagem enviada da pasta de registro de SMS. Essas instruções podem tam-bém sugerir que o dono da conta desative o registro das mensagens SMSque saem quando conduzindo as transações financeiras.
A descrição seguinte ilustra o uso da troca de mensagens detexto SMS para prover acesso dos donos de conta ao servidor de pagamen-to de qualquer telefone móvel capaz de SMS ou outro dispositivo habilitadoem SMS. A aplicação do cliente móvel não precisa ser residente no disposi-tivo móvel embora como já discutido, existam vantagens em ter a aplicaçãodo cliente móvel carregada no dispositivo móvel.
Em operação, o dono da conta envia uma mensagem de textopara o servidor de pagamento usando a capacidade de mensagem de textoexistente no seu telefone. A funcionalidade inclui pagar (ou enviar), solicitarpagamento (ou obter), saldo, história e ajuda invocados pelo uso de qual-quer um desses aspectos como uma palavra-chave. Pode também existiruma opção de referir ou convidar para permitir que o usuário convide umaoutra pessoa a se unir ao sistema. A pessoa que faz a referência ou o referi-do, ou ambos, pode obter uma bonificação de referência. O dono da containsere a palavra-chave junto com a informação adicional no corpo da men-sagem de texto para construir um comando que é então enviado para o ser-vidor de pagamento. O acesso para o servidor de pagamento pode ser pormeio de um número de telefone isento de cobrança, um código curto ou umendereço de e-mail, todos os quais identificam o servidor de pagamento parao sistema de troca de mensagens de texto SMS. Um exemplo de um códigocurto é 62729 que é usado como o número de telefone alvo para seus co-mandos de mensagem de texto para o servidor de pagamento. Um exemplode um endereço de e-mail é sms@obopay.com que é o alvo de e-mail paracomandos de mensagem de texto SMS enviados para o servidor de paga-mento.
Para enviar um pagamento para uma outra pessoa ou um co-merciante usando o método SMS, o dono da conta inseriria a seqüência decomando mostrada na tabela A.Tabela A
<table>table see original document page 40</column></row><table>
Cada item deve ter um espaço entre ele e o item prévio. Em umaimplementação, a palavra-chave não é sensível ao caso. O número móveldeve incluir o código de área mais o número móvel sem espaços presentesno número móvel. O dono da conta pode inserir um 1 na frente ou não nonúmero de telefone. Um sinal de dólar não precisa ser inserido com a quan-tia, mas deve ser permitido. O usuário deve ser capaz de incluir opcional-mente uma mensagem com o seu pagamento.
Em um exemplo alternativo, o PIN é enviado em uma segundamensagem por meio de uma chamada de voz. Para enviar um pagamentopara uma outra pessoa ou um comerciante usando o método combinado deSMS mais o canal de voz, o dono da conta inseriria a seqüência de comandomostrada na tabela B.
Tabela B
<table>table see original document page 40</column></row><table>O PIN é enviado para o servidor de pagamento através do canalde comunicação de voz - isto é, a rede de celular, a Internet ou POTS.
Quando uma solicitação para pagamento é feita para um donode conta usando o método SMS ou o método combinado de SMS mais voz,eles podem aceitar ou declinar da solicitação usando o sistema de troca demensagens de texto SMS manual.
No lado do servidor de pagamento, um ou mais centros de da-dos teriam sistemas para processar as transações financeiras. Cada centrode dados conteria uma combinação de tecnologia PBX/ACD/VRU para per-mitir múltiplos processamentos simultâneos de chamada. A tecnologia VRUpode ser usada para prover suporte DTMF que chega e que sai programá-vel. O VRU pode ser conectado em um sistema J2EE empreendedor querepresenta a lógica de negócios atual e sistema de registro para as transa-ções financeiras. O sistema J2EE pode então integrar com bancos atuaispara quitação das transações. Em uma implementação, existe uma opção desenha de uma vez para segurança SMS como uma opção. Isso funcionariacom o usuário enviando a transação sem um PIN e a seguir o sistema envia-ria ao usuário uma série de perguntas que ele responderia.
Execução de transações usando a aplicação do cliente móvel (MCA).
O envio de dinheiro para um outro dono de conta ou comercianteé rápido e simples. O presente sistema simplifica os pagamentos de massa,tal como coleta para um evento de caridade de muitos donos de conta ouenvio de múltiplas transações do mesmo dono de conta ao mesmo tempo.
Transações de dono de conta para dono de conta (pessoa para pessoa)
O envio de dinheiro de um dono de conta para um outro atravésda sala, através da cidade ou através do país é fácil, conveniente e barato.Um dono de conta de débito pré-paga pode enviar dinheiro para qualquerdono de conta com aparelho habilitado em SMS, mesmo se eles não têm aaplicação do cliente móvel instalada no seu dispositivo móvel ou uma contade débito pré-paga. Se o receptor já não é um dono de conta, o receptor re-cebe uma mensagem de texto SMS indicando que os fundos foram transfe-ridos no seu nome. Para obter acesso adequado a esses fundos, o receptorpode se registrar para sua própria conta de débito pré-paga. Essa troca demensagens viral torna fácil para os usuários sem conta se tornarem por elespróprios donos de conta registrados. Se o dispositivo móvel usado pelo usu- ário sem conta suporta um navegador WAP ou da Internet móvel, então oalistamento pode ocorrer imediatamente através do telefone. O usuário tam-bém tem a opção de se alistar no serviço usando a web, um quiosque, empessoa em um parceiro comercial ou através de um outro dispositivo.
A flexibilidade da presente invenção possibilita novos métodos de seleção e identificação de partes para uma transação. Em uma modali-dade, o pagador pode digitar um número de telefone ou outro código de i-dentificação no teclado do seu dispositivo móvel. Um código de identificaçãopode ser um "código curto" especial de três, quatro ou cinco dígitos que étransladado para uma conta específica pelo provedor de serviços móveis. Por exemplo, se um dono de conta deseja carregar um programa de televi-são disponível por uma rede de televisão, tal como a rede de televisão CBS,o dono da conta pode digitar um código curto de 227 para pagar a rede peloconteúdo desejado. O código curto pode usar qualquer caractere alfanumé-rico. Essa modalidade exige que certas partes disponham para adquirir um código curto para encorajar os usuários a acessar os seus serviços.
Em uma modalidade alternativa, o receptor dos fundos pode seridentificado por um número de telefone selecionado da função de livro deendereços no dispositivo móvel. Assim, não existe necessidade de inserirseparadamente o número de telefone. Em uma implementação, um livro de endereços hospedado é usado onde o usuário configuraria o seu livro deendereços com o serviço e a seguir esse livro de endereços ficaria disponí-vel para ele através de qualquer dispositivo que ele use. Para preencher ini-cialmente o livro de endereços hospedado, o sistema pode prover interfacespara livros de endereço de terceiros tal como Outlook, um livro de endereço do gerenciador de informação pessoal de telefone (PIM) ou serviços de ter-ceiros tal como Plaxo.
Em ainda uma outra modalidade alternativa, o pagador pode u-sar a função de câmera do dispositivo móvel para adquirir uma imagem queidentifica o recebedor. Um exemplo de uma imagem seria um código de bar-ras.
Em ainda uma outra modalidade alternativa, o pagador é identifi-cado pelo recebedor por meio de uma imagem adquirida. Uma tal imagemadquirida é um código de barras exibido em uma tela de exibição ou visivel-mente afixado em uma porção externa do dispositivo móvel.
Em ainda uma outra modalidade, o pagador ou o recebedor éidentificado por meio de um dispositivo de proximidade tais como um dispo-sitivo de identificação de radiofreqüência (RFID) ou um dispositivo de comu-nicação perto da esfera de ação (NFC).
Dono de conta para comerciante
Um dono de conta pode sacar fundos ou fazer compras em umcomerciante parceiro em múltiplas maneiras:
(1) telefone móvel para telefone móvel do comerciante,
(2) telefone móvel para aplicação da web do ponto de vendas docomerciante,
(3) cartão de débito associado pré-pago,
(4) enviando o texto do código para o serviço que identifica oproduto e comerciante que um usuário deseja comprar,
(5) selecionando uma opção para pagar com o serviço de carri-nho de compras eletrônico de um comerciante ou web ou aplicação móvelou
(6) selecionando um produto de um catálogo dentro de uma apli-cação da Web ou de telefone do serviço.
Em uma modalidade da invenção, um dispositivo móvel é asso-ciado com uma ou mais contas bancárias (conta corrente, poupança, crédito,pré-paga ou uma conta em fundo comum e assim por diante) e o dono daconta pode transferir fundos em tempo real de uma conta para uma outrasem qualquer acesso a um centro de serviços e sem qualquer acesso daInternet ou computador. Vantajosamente, o dono da conta pode selecionar aconta da qual os fundos são obtidos para fazer uma compra em tempo real.Em uma outra modalidade da invenção, os donos da conta con-tribuem para uma conta de suporte de participação mestre mantida por umparceiro do banco. Em qualquer tempo o dono da conta pode sacar a suacontribuição completa sem qualquer penalidade. O parceiro bancário geren-cia o sistema de pagamento e é compensado com a participação que ficaacumulada.
Em uma outra modalidade, NFC é usado para se comunicar en-tre dispositivos móveis para concluir as transações financeiras usando a in-fra-estrutura da presente invenção. Em ainda uma outra modalidade, NFC éusado para se comunicar de um dispositivo móvel para o terminal POS paraconcluir as transações financeiras.
Existem muitos produtos existentes, e potencialmente um gran-de número de novos produtos, que se beneficiarão da presente invenção.Por exemplo, qualquer dispositivo de telefone habilitado na Internet, tal comoum telefone VOIP pode ser usado para praticar a presente invenção mesmoembora ele possa estar afixado em uma localização específica e não sernecessariamente móvel. Em outras modalidades, endereços de e-mail sãousados além de ou no lugar dos números de telefone para identificar uma oumais partes para uma transação financeira.
Também será verificado que um ou mais dos elementos repre-sentados nos desenhos/figuras podem também ser implementados em umamaneira mais separada ou integrada, ou até mesmo removidos ou transfor-mados em inoperáveis em certos casos, como for útil de acordo com umaaplicação particular.
Operação dos modelos de renda para a infra-estrutura de trans-ferência de pagamento individualizada, móvel
A operação da infra-estrutura de transferência de pagamentoindividualizada, móvel provê a oportunidade de gerar uma seqüência de ren-da sem cobrar uma sobrecarga sobre as transações onde um comerciante éuma das partes. É reconhecido que no mundo móvel ou sem fio, os usuáriosde telefone celular estão freqüentemente desejando investir em uma peque-na taxa mensal para adquirir acesso a certos serviços. Dessa maneira, arenda é gerada cobrando uma pequena por transação para enviar dinheiro.Em uma modalidade exemplar, a taxa por transação varia de uns poucoscentavos por transações sob uma quantia selecionada tal como $25. Parailustrar mais, a taxa "por transação" pode variar de $0,05 a aproximadamen-te $0,10 por transação em modalidades alternativas. Qualquer taxa pode sercobrada de menos do que um centavo por transação a dólares por transa-ção. Por exemplo, a taxa pode ser de $0,00001 a $10 por transação.
A taxa pode ser cobrada em ambas a parte que recebe o paga-mento e a parte que envia o pagamento. Alternativamente, a taxa pode sercobrada para o dono da conta que envia o dinheiro. Em ainda outras modali-dades, uma porcentagem da quantia de transação é cobrada para concluir atransação. Nessa modalidade, a taxa é cobrada para transações de valormais alto, tal como, por meio de ilustração $25. Uma notificação de taxa, sealguma, é preferivelmente exibida na tela de aprovação antes da aprovaçãofinal do dono da conta e autorização para enviar o pagamento. Em aindaoutras modalidades, a taxa pode ser desconsiderada para pequenas quanti-as de transação. Assim, não existiria taxa "por transação" quando pequenascompras são feitas usando a infra-estrutura de transferência de pagamento.Um outro modelo de operação é cobrar em uma base de assinatura.
Ao invés de pagar uma taxa "por transação", os donos da contapodem eleger pagar uma despesa mensal fixa para enviar e receber paga-mentos. Nessa modalidade, não existem taxas "por transação". A despesamensal pode variar com comerciantes pagando uma taxa mais alta (ou maisbaixa em algumas circunstâncias) do que os usuários individuais.
Dessa maneira, a presente invenção considera três modelos di-ferentes de geração de renda. Especificamente, (1) uma taxa "por transa-ção" é tributada contra uma ou ambas as partes em uma transação financei-ra. De preferência, a quantia da taxa é nominal variando de aproximadamen-te um centavo a aproximadamente $0,15, (2) plano de preço mensal de taxafixa onde cada dono de conta pagaria uma despesa de serviço mensal, (3)taxa de transação para valor alto para transações acima de uma quantia se-lecionada, tal como por meio de ilustração, $50, a taxa desconsiderada paratodas as outras transações e (4) serviços de valor adicionado, tal como vin-culando a um serviço de contabilidade para automaticamente gravar deta-lhes da transação ou ajudar a preparar declarações de imposto de arquiva-mento. O serviço pode ser lançado para manter os fundos ou renda de pu-blicidade e esses podem ser aplicados nas taxas do comerciante (por exem-plo, intercâmbio).
A figura 4 mostra uma outra implementação de um sistema dainvenção. A figura 4 mostra uma modalidade onde o serviço de valor adicio-nado é usado entre dois donos de conta. Por meio de exemplo, se um donode conta associado com o dispositivo móvel 401 inicia uma transferênciapara o dispositivo móvel 402, a solicitação de pagamento é transferida paraa plataforma do servidor 403 como indicado pela seta de referência 404. Asolicitação de pagamento pode incluir uma descrição opcional do pagamen-to. Por exemplo, o dono da conta pode anotar o pagamento para representarque ele foi um item da conta de despesa. A descrição pode ser selecionadade um menu exibido no dispositivo móvel 401. Alternativamente, a descriçãopode ser uma mensagem de voz ou texto associada com a solicitação depagamento.
Com a recepção da solicitação de pagamento, o servidor 403transfere os fundos da conta do pagador para uma conta para o dono daconta associado com o dispositivo móvel 402. A instituição financeira quecontrola a conta em fundo comum 405 é notificada da transação como indi-cado pela seta de referência 406. Dessa maneira, o dinheiro é adicionado naconta associada com o dispositivo móvel 402 e debitado da conta associadacom o dispositivo móvel 401. A instituição financeira então envia uma con-firmação como indicado pela seta de referência 407.
A plataforma do servidor 403 também envia uma notificação dopagamento para o dispositivo móvel 402 como indicado pela seta de refe-rência 408. Uma segunda mensagem é enviada indicando que o pagamentofoi feito e enviado para o telefone móvel 401, como indicado pela seta dereferência 409. Se o usuário do dispositivo móvel 402 não é um dono deconta, uma nova conta pode ser aberta como indicado pela seta de referên-cia 410. Alternativamente, o usuário pode sacar fundos de um ATM designa-do ou outra facilidade associada com a instituição financeira que controla osfundos em fundo comum.
A plataforma do servidor 403 então documenta a transação en- viando a quantia da transação e a descrição da transação para um serviçode contabilidade e de manutenção de registro 411 como indicado pela setade referência 412. A seguir, o dono da conta pode acessar a informaçãodescrevendo as suas compras que é armazenada e organizada pelo serviçode manutenção de conta e registro 411 via o dispositivo móvel 401 ou por uma outra conexão da Internet (não mostrada).
Para mostrar também como um pagamento de conta chega nosistema recebível de contas, considere um pequeno negócio que usa umprograma de contabilidade (que pode ser armazenado em um computadorpessoal) para imprimir uma fatura em papel que ele envia para o seu con- sumidor. O consumidor deve então pagar o pequeno negócio, o que é ge-ralmente feito por cheque. Pelo fato de que a fatura em papel pode não serenviada com o cheque, o pequeno negócio precisa associar o número daconta com o cheque. Se o número da conta não está escrito no cheque,tempo é desperdiçado tentando combinar o pagamento com uma cópia da fatura. O pequeno negócio então deposita o cheque no seu banco e manu-almente insere os dados no seu programa de contabilidade recebível de con-tas. Claramente esse processo antiquado é lento e caro para suportar.
Entretanto, com a presente invenção, o pequeno negócio precisasomente selecionar uma opção de fatura que coloca a fatura do programa de contabilidade em um formato OFX, por meio de exemplo, ou outro formatode importação/exportação legível por um programa de contabilidade. Essafatura eletrônica é então enviada para a plataforma de pagamento (ver figura3). A plataforma de pagamento cria uma mensagem de "solicitação de pa-gamento" que é enviada para o consumidor. Quando o consumidor aprova o pagamento da fatura, os dados do pagamento são enviados de volta para aconta para o programa de contabilidade via OFX e coloca o dinheiro na con-ta do pequeno negócio. A mensagem OFX posta o item para o programa decontabilidade. Desde que a identificação do recebível das contas do consu-midor é seu número de telefone, a manutenção do acompanhamento e doregistro é grandemente simplificada. Deve ser observado que os fundos sãogarantidos completamente e não existem cheques devolvidos ou outros taisproblemas.
Para transações pagáveis de contas, o serviço de manutençãode contabilidade e registro 411 envia uma mensagem OFX com, por meio deilustração, um pagamento do reembolso de despesa do empregado (T&E). Odinheiro é transferido para a conta do empregado e a notificação é enviadapara o seu dispositivo móvel. Vantajosamente, a presente invenção elimina oprocesso manual de inserir cada transação no programa de contabilidade.
A figura 5 mostra uma implementação adicional do sistema parapagamentos móveis de pessoa para pessoa. Como discutido acima, umamodalidade específica da invenção permite que usuários ou clientes façaminterface com o sistema de pagamento móvel através da web (por exemplo,através de um navegador da Internet), WAP (por exemplo, através de umnavegador da Internet móvel em um telefone móvel, telefone inteligente, dis-positivo de assistente digital pessoal), SMS (por exemplo, troca de mensa-gens de texto através de um telefone móvel), IVR (por exemplo, sistema deresposta por voz interativo que entende as respostas de voz de um usuárioou tons dos apertos de teclas do telefone), WSDL (por exemplo, serviços daweb que podem ficar acessíveis através de um dispositivo móvel tal comoum telefone inteligente).
O sistema pode fazer interface com instrumento de telefonessem fio por qualquer uma das múltiplas portadoras, tais como Verizon1 Cin-gular (AT&T), Sprint, Nextel, Alltel, Virgin Mobile, Amp'd Mobile, U.S. Celluar1T-Mobile e outras. O serviço pode também fazer interface com telefones pré-pagos. Alguns benefícios para a portadora móvel incluem: um modelo decompartilhamento de renda baseado na transmissão ou com base na assina-tura. Promove a transferência/compra de aplicação. Promove o uso de redeou dados. Promove o uso do SMS. Solução de pagamento "fora da nota"que ajudará a aliviar o problema da surpresa da "grande conta".O sistema de pagamento móvel permite muitos serviços finan-ceiros diferentes para o usuário. Exemplos de alguns serviços incluem cargade cartão de crédito, carga de cartão de débito, carga de câmara de com-pensação automática (ACH)1 descarga da ACH, pagamento de pessoa parapessoa (P2P), pagamento remoto (RPAY), viral, pessoa para comerciante(P2M) e referências. Outros serviços podem incluir carga e descarga pelarede de caixa eletrônico (ATM) tal como através do sistema NYCE, PLUS ouSTAR ATM. O sistema pode também incluir integração de pagamento deconta, onde um usuário pode pagar contas tais como uma conta a cabo,conta de eletricidade, conta de serviço da Internet, conta de telefone, contado serviço de manutenção de casa e outras contas.
O carregamento de uma conta se refere à transferência de fun-dos para uma conta no sistema de pagamento móvel onde os fundos podemser negociados. Por exemplo, um usuário pode carregar fundos de uma con-ta corrente ou cartão de crédito para a conta do sistema de pagamento mó-vel do usuário, que pode ser controlada pelo parceiro financeiro ou controla-da pelo operador do sistema de pagamento móvel.
A descarga de uma conta se refere à transferência de fundos dosistema de pagamento móvel para uma outra conta. Por exemplo, um usuá-rio pode descarregar fundos da conta do sistema de pagamento móvel dousuário, que pode ser controlada pelo parceiro financeiro ou controlada pelooperador do sistema de pagamento móvel, para uma conta corrente ou car-tão de crédito.
O carregamento e o descarregamento podem ser executadosem qualquer uma das maneiras discutidas nesse pedido incluindo através deACH, ATM ou cartão de crédito ou intercâmbio. O ACH é geralmente o maisbarato, mas o ACH geralmente não é em tempo real porque os fundos sãoquitados em um modo de lote no fim do dia. Então, quando uma transferên-cia de fundos ACH é solicitada, os fundos reais não serão transferidos e fica-rão disponíveis para o sistema de pagamento móvel até tipicamente o fim dodia. Para ATM e cartões de crédito, a transferência do dinheiro é em temporeal. ATM é tipicamente mais caro do que ACH, mas mais barato para usardo que os cartões de crédito. Observe que ambos ATM e ACH podem serusados para acessar uma conta corrente de um usuário. Os cartões de cré-dito são geralmente o mais caro dos três para usar. Em uma implementação,o sistema da invenção permite carga e descarga de qualquer uma dessasredes. Em uma outra implementação, o sistema permite carga e descarga desomente uma ou mais dessas, tal como de ACH somente, ACH e ATM so-mente, cartão de crédito somente, ATM somente, ATM e cartão de créditosomente ou ACH e cartão de crédito somente.
O sistema de pagamento móvel de pessoa para pessoa tambémprovê uma plataforma para um ou mais parceiros financeiros. Esses parcei-ros podem incluir um parceiro adquirente tal como Pay by Touch (PBT), Ve-risign ou outros; banco ou outro parceiro institucional financeiro tais comoum banco da cidade de Nova Iorque, São Francisco, São José (Califórnia),Londres, Xangai, Hong Kong ou Tóquio, banco eletrônico, NYCE; parceirodireto (tal como cartões pré-pagos com marca); parceiro de processamentopré-pago e um parceiro ACH. O sistema de pagamento móvel pode tambémfazer interface com os sistemas de ponto de vendas (POS).
Pode existir qualquer número e combinação de parceiros e ser-viços discutidos. Por exemplo, um sistema pode ter somente um único par-ceiro, pode ter dois parceiros, três parceiros ou mais do que três parceiros.Um sistema pode incluir um parceiro bancário único provendo um cartão dedébito somente (isto é, sem cartão de crédito) para acesso pelos clientesmóveis. Um sistema pode incluir um único parceiro bancário provendo umcartão de débito e um cartão de crédito para acesso pelos clientes móveis.Um sistema pode incluir dois ou mais parceiros bancários, um provendo umcartão de débito e um outro provendo um cartão de débito diferente paraacesso pelos clientes móveis. Um sistema pode incluir dois ou mais parcei-ros bancários, um provendo um cartão de débito e um outro provendo umcartão de débito diferente e um cartão de crédito para acesso pelos clientesmóveis. Um sistema pode incluir um único parceiro bancário provendo umcartão de crédito somente para acesso pelos clientes móveis. Um sistemapode incluir um único parceiro bancário provendo um cartão de crédito so-mente para acesso pelos clientes móveis.
Para cada tipo de parceiro (por exemplo, cartão de débito), po-dem exigir múltiplas tais entidades de parceiro que fazem interface com osistema de pagamento móvel ou rede. Por exemplo, o sistema pode fazerinterface com dois bancos, banco A e banco B, ou qualquer número de par-ceiros bancários. O sistema pode ter qualquer combinação dos parceirosdescrita nesse pedido. Por exemplo, o sistema pode ter um parceiro direto eparceiro bancário, mas não um parceiro de processamento pré-pago. O sis-tema pode ter um parceiro de processamento pré-pago somente. O sistemapode ter um parceiro direto somente. O sistema pode ter múltiplos parceirosbancários.
Cada sistema de parceiro pode ter um esquema de interface ele-trônica diferente, e o sistema de pagamento móvel se comunicará usando ainterface do programa de aplicação (API) apropriada para cada parceiro. Umsistema da invenção permite fácil integração dos parceiros financeiros (porexemplo, parceiros bancários, parceiros de cartão) para parceiros móveis eoutros de consumidor (por exemplo, portadoras de telefone móvel).
Em uma implementação particular do sistema, o parceiro adqui-rente tem uma conta de quitação. O parceiro bancário tem contas em fundocomum e de giro. O parceiro direto tem contas em fundo comum e de giro. Oparceiro de processamento pré-pago tem contas em fundo comum e de giro.O parceiro ACH tem uma conta de quitação. O sistema de pagamento móvelpode prover um ou mais do controle da conta em fundo comum, quitação debanco mútuo e gerenciamento de caixa e integração bancária móvel.
Os fundos dos sistemas são representados pela agregação detodas as contas em fundo comum do banco parceiro. Por meio da relação denegócios com o sistema de pagamento móvel, o sistema de pagamento mó-vel facilita um processo de controle de caixa periódico tal que as contas emfundo comum do banco parceiro mantêm saldos que são representativos dasua contribuição para a base de consumidor do sistema de pagamento mó-vel mais uma porcentagem acordado de "outros" fundos do sistema de pa-gamento móvel. Uma "trajetória" de aquisição de um consumidor dita o saldoda conta em fundo comum para um dado banco parceiro (isto é, quanto maisconsumidores um banco parceiro adquire através de "suas" trajetórias, maisalto o saldo da sua conta em fundo comum associada).
Os usuários são tipicamente associados com parceiros financei-ros específicos, tal como um banco particular. No sistema de pagamentomóvel, cada usuário terá um perfil de usuário que tem definições para esseusuário. Esses parâmetros podem incluir (1) um nível de participação, (2)qual processador (por exemplo, qual parceiro financeiro), (3) definições develocidade, (4) contas vinculadas ou qualquer combinação desses. O siste-ma pode incluir qualquer número de definições de parâmetro em um perfil dousuário, mais ou menos do que descrito nesse pedido de patente.
O sistema da invenção opera qualquer número de parceiros fi-nanceiros diferentes (por exemplo, 1, 2, 3, 4, 5, 6, 7, 8, 507, 1001, 2054,3096 ou mais), cada um dos quais pode ter uma interface API diferente. Emcada perfil de usuário, a definição para qual processador indicará com qualparceiro financeiro um usuário está associado. Quando negociando paraesse usuário, o sistema então saberá onde (qual banco) direcionar as tran-sações e qual API usar de modo que as transações de troca de valor do u-suário (que são tipicamente trocas de dinheiro) sejam negociadas apropria-damente.
A definição do nível de participação será os privilégios ou nívelde serviço que o usuário terá. O nível da definição de participação pode serbaseado em uma série de fatores tal como qual informação foi providaquando o usuário fez o alistamento, quanto dinheiro o usuário tem na contado usuário, quantas referências o usuário fez, quantas transações o usuáriofez ou o total de dólares negociados. Essa definição de perfil pode ser atua-lizada periodicamente à medida que nova informação é coletada. Algunsexemplos de nomes de nível de participação para um usuário podem serníveis "bronze", "ouro", "prata" e "platina". O nível de participação pode servisível para o usuário e pode ser usado para construir a lealdade do consu-midor. Em outras modalidades da invenção, o nível de participação podeficar oculto ou de outra forma não ficar disponível para o usuário.Quando se registrando com o sistema, o sistema fornecerá aousuário uma escolha de quanta informação o usuário deseja revelar. Porexemplo, o usuário pode escolher revelar o número do telefone móvel dousuário e a seguir financiar a conta do usuário com dinheiro. Isso pode ser o mínimo requerido para abrir a conta. Ao usuário será dada a opção de pro-ver outras informações, tais como endereço de e-mail, número do cartão decrédito, número do seguro social (por exemplo, para uma verificação de cré-dito), número da conta corrente e assim por diante. Em uma implementaçãoda invenção, quanto mais informação o usuário escolhe revelar, maior o ní- vel de participação que o usuário conseguirá.
Em uma implementação, para o nível de definição de participa-ção, o usuário pode ser um de quatro estados do usuário: (1) convidado, (2)inscrito, (3) verificado e (4) avançado. Em outras implementações, podemexistir estados adicionais. Para o estado convidado, o usuário foi referido ou dinheiro viral foi enviado. Viral se refere ao envio ou recepção de dinheiroonde um dos usuários é um usuário que não estava previamente registradocom o sistema. Um usuário viral pode também ser citado como um usuárionão membro ou usuário não registrado. Viral se refere a uma característicado sistema de pagamento móvel da invenção que encoraja ou permite que usuários atuais negociem com usuários não membros. À medida que maisusuários se registram e usam o sistema, os usuários ajudarão a espalhar asnotícias e trazer usuários adicionais, um tanto similarmente a como os vírussão transmitidos. Por exemplo, a fim de que um usuário não membro recebao dinheiro, o não membro será encorajado a se alistar como um membro.
Para o estado inscrito, o usuário inseriu informação básica, talcomo um telefone confirmado. O telefone pode ser confirmado pelo sistemachamando o número de telefone provido pelo usuário no alistamento. Essachamada pode ser uma chamada automática ou do tipo IVR. Pode existir umincentivo para o usuário se alistar, tal como o usuário recebendo dinheiro (por exemplo, $5) que é colocado na conta do usuário. O incentivo pode serreferido como uma bonificação de referência e pode ser qualquer quantia. Abonificação de referência pode ser paga somente para quem fez a referên-cia, somente para o referido ou para ambos. Nesse estado, o usuário podereceber e solicitar dinheiro.
Para o estado verificado, a identidade do usuário é conhecida. Ousuário provê endereço ou outra informação de contato relacionada. Um u-suário no estado verificado pode receber, solicitar, adicionar (isto é, carre-gar) ou sacar (isto é, descarregar) dinheiro.
Para o estado avançado, o usuário forneceu o número de segurosocial do usuário. Nesse estado, por exemplo, o usuário pode se alistar emum parceiro bancário particular para receber um cartão. Esse cartão podeser um cartão de débito pré-pago. Em outras modalidades, o cartão pode serum cartão de crédito. O usuário será capaz de fazer qualquer coisa que umusuário verificado pode mais ser capaz de instantaneamente gastar dinheirosempre que o cartão for aceito. O cartão pode ser aceito ou utilizável atravésde uma ou mais redes incluindo Visa, MasterCard, American Express, NY-CE, PLUS ou STAR, ou qualquer combinação desses. Q-cartãn ρ virmuiarinà conta do usuário. Um usuário sem um cartão pode ser chamado um usuá-rio sem cartão, enquanto um usuário com um cartão pode ser chamado umusuário com cartão.
Algumas maneiras como uma pessoa pode ser verificada quan-do se alistando incluem: para informação pessoal, o sistema pode solicitar oendereço e o número da licença de motorista. Uma alternativa é solicitar oendereço e número do seguro social. A informação pode ser verificada con-tra um banco de dados da agência de relatório de crédito tal como o bancode dados Equifax. Para uma conta de banco vinculada, essas podem serverificadas usando depósitos de desafio. Por exemplo, o sistema pode fazerqualquer número de pequenos depósitos na conta do usuário. O usuário in-forma ao sistema a quantia desses depósitos para obter verificação. Alterna-tivamente, o usuário pode verificar através de uma verificação de conta ins-tantânea em linha, onde um usuário provê um nome e senha na tela em li-nha. Para adicionar cartão de crédito ou débito, esses podem também serverificados usando depósitos de desafio. Alguns cartões tais como Visa eMasterCard podem ser alternativamente verificados usando códigos de se-gurança e semelhantes.
A velocidade da participação é uma definição que estabelececertas restrições ou limites na conta. Alguns exemplos em limites de umaconta são quantas transações por dia um usuário pode executar ou a quan-tia de dinheiro que pode ser transferida em uma transação. Podem existiralguns limites rígidos e limites flexíveis. Limites rígidos não mudarão com aintervenção por um terceiro tal como a pessoa mudando o limite. Limites fle-xíveis podem mudar dependendo das ações do usuário. Por exemplo, de-pois que o usuário permaneceu um membro por seis meses, o usuário podeter automaticamente permissão de cinco transações por dia quando o limiteprévio do usuário era algum número menor do que cinco.
Tipicamente, o usuário não terá acesso ou saberá a velocidadeda definição da participação. Entretanto, em certa implementação, o usuáriopode ser fornecido com a velocidade da informação de participação, tal co-mo limites de crédito ou transação.
Contas vinculadas é um outro aspecto que pode ser armazena-do no perfil de um usuário. Entretanto, qualquer uma das definições do usuá-rio discutidas nesse pedido, ou combinação desses, pode ser mantida emlocalização separada, não necessariamente no perfil do usuário. Contas vin-culadas é um aspecto do sistema onde múltiplas identidades de um usuáriosão centralizadas ou unificadas em uma única conta. Pode existir uma ânco-ra (por exemplo, tal como um número de conta) para o usuário e múltiplasidentidades seriam associadas com essa âncora. Essas identidades podemincluir múltiplos números de telefone, endereço de e-mail, identificadores demensageiro instantâneo e assim por diante. O usuário não precisaria saber onúmero da conta ou âncora para acessar a conta. O usuário seria capaz deacessar a conta do usuário através de qualquer uma das identidades asso-ciadas.
Além do mais, em uma implementação, para adicionar identida-des a uma conta, o usuário validaria cada uma das novas identidades. Issopoderia ser feito através de uma chamada de autenticação IVR ou respon-dendo a uma mensagem SMS no caso de um número de telefone. Para ume-mail, isso pode ser feito através do envio de um e-mail com um único URLou um código de passagem que o usuário responderia na nossa página daweb. E com um ID de mensageiro instantâneo, isso poderia ser feito respon-dendo para um IM.
Outras opções disponíveis em um perfil de usuário podem incluirdefinições de preferência para certos aspectos. Tais opções podem ser es-tabelecidas ou modificadas pelo usuário a qualquer momento acessandouma tela de manutenção de conta. Também, o usuário pode ser questionadose ativar ou desativar opções durante o fluxo de registro (ver abaixo). Umaspecto é um aspecto de aceitação automática e aceitação manual. Quandoa aceitação automática está ativada, os pagamentos enviados para essemembro serão automaticamente aceitos. Quando a aceitação manual estáativada, os pagamentos enviados para esse membro precisarão ser manu-almente aceitos ou rejeitados.
Fluxos do sistema
A figura 6 mostra um pagamento entre bancos de pessoa parapessoa. Essa figura mostra um consumidor A enviando dinheiro para umoutro consumidor B, onde ambos os consumidores são membros do mesmoparceiro bancário, A. O sistema de pagamento móvel da invenção tratará datransação.
Um fluxo básico da transação é: (1) o consumidor A envia para osistema de pagamento móvel uma solicitação de pagamento. Essa solicita-ção de pagamento pode ser provida por qualquer uma das maneiras discuti-das nessa patente. (2) O sistema de pagamento móvel atualiza os registrosT ou da transação no sistema de registro (SOR) do sistema de pagamentomóvel para refletir a transação. Esses registros de transação são manipula-dos pelo sistema de pagamento móvel. (3) O sistema (por exemplo, Obopay)notifica o consumidor B sobre o pagamento. Isso pode ser por meio de umanotificação eletrônica, e-mail, mensagem instantânea, mensagem SMS ououtra notificação.
A figura 7 mostra um pagamento de pessoa para pessoa debanco mútuo. Essa figura mostra um consumidor A enviando dinheiro paraum outro consumidor B1 onde os consumidores são membros de parceirosbancários diferentes. O consumidor A tem o banco Aeo consumidor B temo parceiro bancário Β. O sistema de pagamento móvel da invenção trataráda transação.
Um fluxo básico da transação é: (1) o consumidor A envia para osistema de pagamento móvel a solicitação de pagamento. (2) O sistema depagamento móvel transfere fundos da conta em fundo comum para a contade giro. (3) O sistema de pagamento móvel transfere fundos da conta de giropara a conta em fundo comum. (4) O sistema de pagamento móvel atualizaos registros T no sistema de registro do sistema de pagamento móvel. (5) Osistema de pagamento móvel notifica o consumidor B sobre o pagamento.(6) O sistema de pagamento móvel periodicamente faz a quitação entre osbancos parceiros. Essa quitação pode ocorrer em qualquer período de tem-po periódico. Ao invés de tempo real, a quitação pode ser executada em ummodo de lote. Por exemplo, ela pode ser executada uma vez a cada 24 ho-ras. Os períodos não têm necessariamente que ser períodos de tempo i-guais, mas podem ser períodos de tempo diferentes.
A figura 8 mostra uma carga de conta vinculada. Essa figuramostra um consumidor carregando a conta do sistema de pagamento móveldo usuário com fundos de uma outra fonte. Por exemplo, um usuário podedesejar transferir alguns fundos para a conta do sistema de pagamento mó-vel do usuário de uma conta corrente ou cartão de crédito.
Um fluxo básico dessa transação é: (1) o consumidor A envia asolicitação de "carga" para o sistema de pagamento móvel indicando o ins-trumento de crédito ou débito vinculado. (2) (a/b) o sistema de pagamentomóvel submete a transação do cartão de crédito em tempo real (CC)/DDA(fundos certos). (3) O sistema de pagamento móvel transfere os fundos daconta de giro para a conta em fundo comum. (4) O sistema de pagamentomóvel atualiza os registros T no sistema de registro do sistema de pagamen-to móvel. (5) O sistema de pagamento móvel periodicamente executa o ge-renciamento de caixa. Esse gerenciamento pode ocorrer em qualquer perío-do de tempo periódico. Por exemplo, ele pode ser executado uma vez a ca-da 24 horas. Os períodos não têm necessariamente que ser períodos detempo iguais, mas podem ser períodos de tempo diferentes.
Um exemplo específico de uma carga de cartão de crédito. Daweb, um usuário insere um número de cartão de crédito para carregar $300no cartão MPS do usuário. O MPS obtém uma autorização de $300 do Pay-By-Touch (PBT) para a transação do cartão de crédito. O MPS envia umamensagem para o parceiro financeiro suportando o cartão MPS iniciando umpagamento de $300 de pessoa para pessoa da conta do cartão de créditoMPS para a conta do cartão de débito do usuário. A conta do usuário é ime-diatamente creditada com fundos. PBT quita a transação do cartão de crédi-to e envia por ACH os $300 para a conta de quitação do MPS no banco doMPS tratando da conta de quitação. O MPS envia por ACH os $300 para aconta mestre do cartão de crédito MSP para reabastecer os fundos.
A figura 9 mostra uma descarga de conta vinculada. Essa figuramostra um consumidor descarregando fundos da conta do sistema de pa-gamento móvel do usuário para uma outra conta. Por exemplo, um usuáriopode desejar transferir alguns fundos da conta do sistema de pagamentomóvel do usuário para a conta corrente do usuário, cartão de crédito ou ou-tra conta.
Um fluxo básico dessa transação é: (1) o consumidor A envia aosistema de pagamento móvel uma solicitação de carga indicando o instru-mento de crédito vinculado. (2) O sistema de pagamento móvel submete atransação DDA em tempo real (fundos certos). (3) O sistema de pagamentomóvel transfere os fundos da conta em fundo comum para a conta de giro.(4) O sistema de pagamento móvel atualiza os registros T no sistema de re-gistro do sistema de pagamento móvel. (5) O sistema periodicamente execu-ta o gerenciamento do caixa.
Em uma modalidade específica, essa invenção refere-se a umsistema de pagamento e mais especificamente, em uma modalidade especí-fica, a um sistema em linha para negociar pagamentos usando telefonesmóveis.
Existe uma necessidade por um sistema em linha que permitatroca e outras transações de dinheiro ou outro valor usando telefones mó-veis.
Em um sistema de pagamento de pessoa para pessoa, mem-bros existentes de um sistema de pagamento podem enviar fundos para nãomembros (que podem também ser citados como usuários não registrados)com a intenção que o não membro se torne um membro. Essa capacidadede um sistema de pagamento pode ser citada como "viral" porque ela esti-mula inscrições de novo membro em um modo de propagação exponencial.
Com relação a um sistema de pagamento de pessoa para pes-soa, essa invenção trata a capacidade de membros existentes de um siste-ma de pagamento enviarem fundos para não membros com a intenção que onão membro se torne um membro. Essa capacidade de um sistema de pa-gamento pode ser citada como "viral" porque ela estimula as inscrições denovo membro em um modo de propagação exponencial. Alguns elementosda capacidade viral incluem o seguinte, que não são listados em qualquerordem particular.
(1) Um sistema de pagamento permite que membros existentesenviem fundos para não membros via algum identificador único ou "id". Esseidentificador único pode estar geralmente disponível. Alguns exemplos detais identificadores incluem endereços de e-mail, números de telefone (porexemplo, linha terrestre, voz através de IP, telefone móvel, paginador oufax), números de seguro social, número de conta, número de placa da licen-ça, nome de usuário do mensageiro instantâneo e outros. O identificadorpode ser selecionado por um usuário, tal como um não membro escolhendoum número de telefone ou endereço de e-mail.
(2) O sistema de pagamento notifica o membro existente que atransação de "enviar fundos" que eles estão para executar é para um nãomembro e fornece ao membro existente a oportunidade de cancelar essatransação como um resultado.
(3) Na eventualidade que o membro existente escolha enviar osfundos para um não membro, o sistema de pagamento deve notificar o nãomembro que fundos foram enviados para ele através de vários mecanismosde comunicação geralmente disponíveis (tais como e-mail, telefone e ou-tros).
(4) O sistema de pagamento deve permitir que o não membro"convidado" aceite ou recuse os fundos que estão tentando enviar do mem-bro existente.
(5) Se o não membro convidado decide aceitar os fundos domembro existente, então o sistema de pagamento deve prover a capacidadedo não membro se registrar via mecanismos de comunicação geralmentedisponíveis (tais como e-mail, telefone e outros).
(6) A fim de completar uma transação viral, o sistema de paga-mento finalmente facilitará a transferência de fundos da conta dos membrosexistentes para a conta dos novos membros.
Abaixo estão várias modalidades das técnicas de execução datransferência de fundos viral dentro de um sistema de pagamento.
Modalidade 1A
Seguimento do lembrete de pagamento. O membro existente élembrado do pagamento com o alistamento do novo membro. Nos exemplosabaixo, Obopay é usado como um exemplo de um sistema de pagamentoespecífico, mas outros sistemas de pagamento podem ser usados. Um sis-tema de pagamento pode ser chamado ou conhecido por qualquer nome. Osítio da web obopay.com é especificamente identificado, mas qualquer sítioda web apropriado, nome de sítio da web ou endereço IP pode ser usado.Também, a invenção pode ser usada no contexto de outras infra-estruturasde rede, não apenas a Internet.
1. O membro existente usuário A decide convidar o usuário nãomembro B a se unir enviando dinheiro para B, que B tem que reivindicar seinscrevendo como um membro.
2. O usuário A envia uma transação de pagamento para B inse-rindo o número de telefone móvel de B e a quantia em dólar. O sistema nãodistingue inicialmente entre pagamentos enviados para membros e nãomembros.
3. Se o número de telefone móvel não é para um membro cor-rente, o usuário A recebe a seguinte mensagem, "Nota: o seu pagamentopara o não membro está pendente."
4. O usuário A também recebe um e-mail redigido como segue:Obrigado por sua referência. Nós contatamos o seu amigo e o convidamospara se alistar em nosso sistema."
5. O pagamento enviado para B é debitado da conta de A e émantido em suspense da inscrição pendente de B.
6. O usuário B recebe uma mensagem dizendo que A envioudinheiro para ele e que B pode obter o dinheiro fazendo a inscrição em obo-pay.com.
7. O usuário B se inscreve no sítio da web do sistema (por e-xemplo, obopay.com).
8. Depois que o usuário B se inscreve com sucesso, a conta deB é automaticamente financiada com o pagamento de A.
Modalidade 1B
A figura 10 mostra um sistema de pagamento e um pagamentode pessoa para pessoa de acordo com uma técnica como descrito para amodalidade 1B da invenção.
1. O membro existente usuário A decide convidar o usuário nãomembro B a se juntar enviando dinheiro para B, que B tem que reivindicarpela inscrição como um membro.
2. O usuário A envia uma transação de pagamento para B inse-rindo o número de telefone móvel e a quantia em dólar. O sistema não dis-tingue inicialmente entre pagamentos enviados para membros e não mem-bros.
3. Se o número do telefone móvel não é para um membro atual,o usuário A recebe a mensagem seguinte "Nota: seu pagamento foi enviadopara um usuário não membro. Gostaria que nós estendêssemos um convitepara ele se unir? Sim/não."
4. Se a resposta para a etapa 3 é sim, o usuário A também re-cebe um e-mail redigido como segue: "Obrigado por sua referência. Nóscontatamos o seu amigo e o convidamos para se alistar em nosso sistema."5. O pagamento não é debitado da conta do usuário A.
6. O usuário B recebe uma mensagem dizendo que A convidouB para se unir ao sistema de modo que A possa enviar dinheiro para B.
7. O usuário B se inscreve no sítio da web do sistema (por e-xemplo, obopay.com).
8. Depois que B se inscreve com sucesso, B é notificado que Adeseja enviar dinheiro para ele e que B pode fazer uma "solicitação de pa-gamento" pelo pagamento. Se B concorda, é mostrada para B uma transa-ção de solicitação de pagamento pré-preenchida com o número do telefonede A e a quantia de pagamento original preenchida.
9. O usuário A recebe uma "solicitação de pagamento" e con-corda com o pagamento
10. O dinheiro é debitado da conta de A e creditado na conta deΒ. B é notificado.
Modalidade 2
Fundos reservados pessoais virais - membros existentes podemseparar fundos que são reservados para pagamentos virais. Por exemplo,um usuário pode reservar um certo número de dólares na conta do usuáriopara quitar as transações virais. Esses fundos não ficarão disponíveis, deoutra forma, para o usuário para uso em transações não virais (por exemplo,gasto pelo cartão de débito). Em uma implementação, o usuário pode mudara quantia reservada através de uma função de manutenção de conta do u-suário.
Modalidade 3
Viral coloquial - O ciclo de vida viral completo ocorre em temporeal com ambas as partes sendo notificadas das outras "etapas" ao longo docaminho. A transferência de fundos final é então simplesmente uma transfe-rência entre dois membros.
Modalidade 4
Viral promissor - O membro existente promete pagar o membroconvidado se ou quando ele se registrar. Os fundos do membro existenteseriam reservados para o pagamento de seguimento depois que o membroconvidado se registra.
Modalidade 5
Fundos divididos virais - O sistema de pagamento incentivamembros existentes a fazerem pagamentos virais oferecendo uma divisãode fundos onde o sistema de pagamento iguala a quantia de pagamento viaquantias fixas ou de porcentagem.Modalidade 6
Solicitação de fundos virais - Ao invés do membro existente en-viar fundos para um não membro, o membro existente está solicitando fun- dos de um não membro.
Uma implementação da invenção pode incluir qualquer um dosaspectos descritos acima. Em um sistema da invenção, as modalidades a-cima podem ser implementadas individualmente ou em combinação comqualquer outra modalidade ou modalidades.
Uma implementação específica descreve o uso de um númerode telefone móvel como um identificador para um usuário. Entretanto, qual-quer identificador pode ser usado para cada usuário, tal como qualquer nú-mero de telefone (por exemplo, número de telefone residencial, número detelefone do trabalho, número de telefone de voz através de IP, fax ou pagi- nador), endereço de e-mail, nome de usuário do mensageiro instantâneo,número do seguro social, número de licença de motorista, número de asso-ciação, número do cartão de crédito, número do cartão de débito ou outros.
E-mail foi discutido como uma técnica para enviar mensagensentre usuários, mas outras técnicas de comunicação podem ser usadas in- cluindo correio de voz, troca de mensagens de voz automatizado, mensa-gens instantâneas ou troca de mensagens de texto. O usuário Aeo usuárioB foram discutidos meramente como representativos de dois dos numerososusuários que um sistema pode ter. Um sistema da invenção pode ter qual-quer número de usuários.
A figura 1 mostra uma visão geral em diagrama de blocos repre-sentando um sistema de pagamento móvel entre duas ou mais pessoas utili-zando a presente invenção. Em um sistema da invenção, o usuário A enviafundos para o usuário B via um identificador único ou ID. O identificador úni-co pode ser comumente disponível. Exemplos incluem números de telefone(por exemplo, linha terrestre, voz através de IP, telefone móvel, paginador oufax), endereço de e-mail, número do seguro social, número da conta, núme-ro da placa de licença, nome de usuário do mensageiro instantâneo e outros.Esse identificador pode ser usado para contatar um usuário independente-mente de passar através do sistema da invenção (por exemplo, um númerode telefone ou endereço de e-mail onde um usuário pode ser contatado dire-tamente, sem envolver o sistema).
Cada identificador único pode ser somente associado com umusuário para garantir a segurança da conta e do sistema. O usuário A podetambém prover detalhes da transação financeira, tal como a quantia a sertransferida, ou a forma do pagamento, ou combinações desses e um númeroPIN se solicitado para validar uma conta.
O sistema identifica o usuário A como um membro e pode verifi-car o número do PIN, validar a conta e verificar o saldo para a conta do usu-ário A. Na eventualidade que a conta do usuário A careça de fundos sufici-entes para a transação financeira, o sistema pode enviar uma notificaçãoeletrônica para o usuário A por fundos insuficientes. Se a conta do usuário Atem fundos suficientes para a transação, o sistema também notifica o usuá-rio B da transação pendente via tecnologia móvel. Devido às notificaçõeseletrônicas imediatas que os usuários AeB receberam, aparentaria como sea transação financeira ocorresse quase instantaneamente.
O sistema pode permitir que os usuários estabeleçam preferên-cias com relação à aceitação das transações. Se o usuário B selecionouuma definição de aceitação automática (selecionada quando um usuário seregistra no sistema) para automaticamente aceitar os pagamentos, os fun-dos são transferidos da conta do usuário A para a conta do usuário B ime-diatamente. Se o usuário B selecionou uma definição de aceitação manual,os fundos são transferidos somente depois que o usuário B aprova a transa-ção. O sistema pode também incluir uma definição para usuários ditaremque eles somente aceitarão transações de membros especificados, ou aocontrário, eles não aceitarão pagamentos de membros especificados.
Se o usuário B ainda não aprovou a transação depois de um cer-to número de dias estabelecidos pelo sistema, tal como trinta dias, o sistemapode automaticamente cancelar a transação. O sistema pode então enviarnotificações eletrônicas para ambos o usuário Aeo usuário B notificandoambos da transação cancelada. O usuário B pode também ter a opção derejeitar a transação, em cujo caso o usuário A pode ser notificado do paga-mento recusado através de notificação eletrônica.
Na eventualidade que o usuário A tenha fundos suficientes, e ousuário B aceite a transação, a quantia é debitada da conta do usuário A ecreditada na conta do usuário B. As transações podem ser retardadas devi-do aos retardos inerentes no sistema de transação financeira eletrônico.
Alguns exemplos específicos de fluxos são apresentados nessepedido. Entretanto, deve ser entendido que a invenção não é limitada ao flu-xo e etapas específicas apresentadas. Um fluxo da invenção pode ter etapasadicionais, que podem não ser necessariamente descritas nesse pedido,etapas diferentes que substituem algumas das etapas apresentadas, menosetapas ou um subconjunto das etapas apresentadas ou etapas em uma or-dem diferente do que apresentado ou qualquer combinação desses.
Além do que, as etapas em outras implementações da invençãopodem não ser exatamente as mesmas que as etapas apresentadas. Comoum exemplo específico, o identificador único ou eletrônico (ID) é descritocomo o número móvel do usuário B. Em outras modalidades da invenção, oidentificador não é limitado ao número de telefone do usuário Β. O identifica-dor pode também ser o nome de usuário do mensageiro instantâneo do usu-ário B ou endereço de e-mail em outras implementações da invenção.
Um outro exemplo de uma variação possível nos fluxos, sem seafastar do escopo da invenção, é as mensagens específicas que os usuáriosA e B recebem em várias etapas nos fluxos. Em outras modalidades da in-venção, essas mensagens podem ser diferentes dessas especificamenteidentificadas nesse pedido ou algumas mensagens podem não ser enviadase combinações desses.A figura 11 mostra um método para executar uma transação en-tre um membro com um cartão e um usuário não registrado. Esse fluxo in-clui: (1) membro A envia a solicitação de "pagamento" para o servidor doserviço de pagamento móvel com o não membro B como alvo. (2) O serviçode pagamento móvel identifica a origem como membro, valida a conta, veri-fica o saldo e verifica o PIN. (3) O serviço de pagamento móvel identifica oalvo como não membro. (4) O serviço de pagamento móvel notifica o mem-bro de origem A do pagamento. (5) O serviço de pagamento móvel notifica onão membro alvo B do pagamento. (6) (a/b) O serviço de pagamento móveldebita a conta de cartão do membro e credita a conta em fundo comum viral.(7) (a/b) O serviço de pagamento móvel registra a transação de débito domembro de origem e registra a transação de crédito viral do alvo. As etapas6 e 7 podem ser encadeamentos secundários assíncronos do servidor. Issosignifica que essas ações em uma modalidade ocorrem de maneira assín-crona. O servidor solicita as ações, mas elas não são necessariamente exe-cutadas pelo próprio servidor, então a conclusão das ações é independenteda chamada do procedimento do servidor.
A figura 12 mostra um método para executar uma transação en-tre um membro sem um cartão e um usuário não registrado. O fluxo inclui:(1) membro A envia a solicitação de "pagamento" para o servidor do serviçode pagamento móvel com o não membro B como alvo. (2) O serviço de pa-gamento móvel identifica a fonte como membro, valida a conta, verifica osaldo e verifica o PIN. (3) O serviço de pagamento móvel identifica o alvocomo não membro. (4) O serviço de pagamento móvel notifica o membro deorigem A do pagamento. (5) O serviço de pagamento móvel notifica o nãomembro alvo B do pagamento. (6) (a/b) O serviço de pagamento móvel debi-ta a conta em fundo comum do membro e credita a conta em fundo comumviral. (7) (a/b) O serviço de pagamento móvel registra a transação de débitodo membro de origem e registra a transação de crédito viral do alvo. As eta-pas 6 e 7 podem ser encadeamentos secundários assíncronos do servidor.
A figura 13 mostra um método para executar uma transação en-tre um membro sem cartão e um outro membro sem cartão. O fluxo inclui:(1) membro A envia a solicitação de "pagamento" para o membro B. (2) Oserviço de pagamento móvel identifica a origem A como membro, valida aconta, verifica o saldo e verifica o PIN. (3) O serviço de pagamento móvelidentifica o alvo B como membro e valida a conta. (4) O serviço de pagamen-to móvel notifica o membro de origem A do pagamento. (5) O serviço de pa-gamento móvel notifica o membro alvo B do pagamento. (6) (a/b) O serviçode pagamento móvel registra a transação de débito do membro A e registraa transação de crédito do membro Β. A etapa 6 pode ocorrer usando um en-cadeamento secundário de servidor assíncrono.
A figura 14 mostra um método para executar uma transação en-tre um membro com cartão e um outro membro com cartão. O fluxo inclui:(1) membro A envia a solicitação de "pagamento" para o servidor do serviçode pagamento móvel com o membro B como alvo. (2) O serviço de paga-mento móvel identifica a origem A como membro, valida a conta, verifica osaldo e verifica o PIN. (3) O serviço de pagamento móvel identifica o alvo Bcomo membro e valida a conta. (4) O serviço de pagamento móvel notifica omembro de origem A do pagamento. (5) O serviço de pagamento móvel noti-fica o membro alvo B do pagamento. (6) (a/b) O serviço de pagamento mó-vel debita a conta de cartão do membro A e credita a conta de cartão domembro B. (7) (a/b) O serviço de pagamento móvel registra a transação dedébito do membro A e registra a transação de crédito do membro B. As eta-pas 6 e 7 podem ser encadeamentos secundários assíncronos do servidor.
A figura 15 mostra um método para executar uma transação en-tre um membro com cartão e um membro sem cartão. O fluxo inclui: (1)membro A envia a solicitação de "pagamento" para o servidor do serviço depagamento móvel com o membro B como alvo. (2) O serviço de pagamentomóvel identifica a origem A como membro, valida a conta, verifica o saldo everifica o PIN. (3) O serviço de pagamento móvel identifica o alvo B comomembro e valida a conta. (4) O serviço de pagamento móvel notifica o mem-bro de origem A do pagamento. (5) O serviço de pagamento móvel notifica omembro alvo B do pagamento. (6) (a/b) O serviço de pagamento móvel debi-ta a conta de cartão do membro A e credita a conta em fundo comum domembro. (7) (a/b) O serviço de pagamento móvel registra a transação dedébito do membro A e registra a transação de crédito do membro B. As eta-pas 6 e 7 podem ser encadeamentos secundários assíncronos do servidor.
A figura 16 mostra um método para executar uma transação en-tre um membro sem cartão e um membro com cartão. O fluxo inclui: (1)membro A envia a solicitação de "pagamento" para o servidor do serviço depagamento móvel com o membro B como alvo. (2) O serviço de pagamentomóvel identifica a origem A como membro, valida a conta, verifica o saldo everifica o PIN. (3) O serviço de pagamento móvel identifica o alvo B comomembro e valida a conta. (4) O serviço de pagamento móvel notifica o mem-bro de origem A do pagamento. (5) O serviço de pagamento móvel notifica omembro alvo B do pagamento. (6) (a/b) O serviço de pagamento móvel debi-ta a conta em fundo comum do membro e credita a conta de cartão domembro B. (7) (a/b) O serviço de pagamento móvel registra a transação dedébito do membro A e registra a transação de crédito do membro B. As eta-pas 6 e 7 podem ser encadeamentos secundários assíncronos do servidor.
A figura 17 mostra um método de registro para um usuário nãoregistrado. O fluxo inclui: (1) o membro a ser A submete a solicitação de re-gistro. (2) A conta do novo membro é criada. (3) Os controles de risco deidentidade são verificados para o novo membro e a conta é atualizada deacordo. (4) Verificação de registros virais associados com o novo membro.(5) (a/b) O serviço de pagamento móvel debita a conta em fundo comumviral e credita a conta em fundo comum do membro. (6) (a/b) O serviço depagamento móvel registra o débito viral da origem e registra o crédito domembro alvo. (7) Verificação por incentivos aplicáveis ao novo membro. (8)(a/b) O serviço de pagamento móvel debita a conta de incentivo e credita aconta em fundo comum do membro. (9) O serviço de pagamento móvel re-gistra o crédito de incentivo do novo membro. As etapas 5, 6 e 7 podem serencadeamentos secundários assíncronos do servidor.
A figura 18 mostra um método de ativação de um cartão. O fluxoinclui: (1) o membro A recebe o cartão no correio e chama o serviço de pa-gamento móvel IVR para ativar. (2) Durante a interação IVR, o serviço depagamento móvel fecha a conta sem cartão. (3) (a/b) O serviço de pagamen-to móvel debita a conta em fundo comum do membro e credita a conta decartão individual do novo membro A. (4) (a/b) O serviço de pagamento móvelregistra a transação de débito em conta comum do membro e registra atransação de crédito do membro A. (5) O sistema de serviço de pagamentomóvel envia a declaração de fechamento da atividade sem cartão para omembro A. As etapas 3 e 4 podem ser encadeamentos secundários assín-cronos do servidor.
Em uma implementação, o sistema manipula pagamentos ele-irônicos em proximidade, tal como através do uso de NFC, Bluetooth, RFID,feixe de infravermelho, feixe de LED ou outras tecnologias em proximidade.Uma situação pode ser que os membros AeB estão fisicamente perto umdo outro e eles desejam executar um pagamento eletrônico. Esse poderiaser um cenário de consumidor para consumidor ou consumidor para comer-ciante. Isso poderia ser um envio de fundos, obtenção de fundos ou qualqueroutro cenário de transferência de dinheiro.
Um fluxo básico de uma tal transação é: (1) A e B concordamcom uma transação de pagamento eletrônico em proximidade. (2) B selecio-na "dicar pronto para recepção em proximidade". Dispositivo questiona PIN1B insere PIN1 dispositivo ativa o modo de recepção. (3) A seleciona "ficarpronto para envio em proximidade." O dispositivo questiona o PIN, A inserePIN, dispositivo ativa o modo de envio. (4) A e B colocam os dispositivosdentro da faixa de proximidade adequada. AeB tem permissão de uma du-ração limitada de tempo para executar essa etapa, de outra forma os dispo-sitivos desativarão. (5) os dispositivos A e B se reconhecem e transmitem ainformação de pagamento um para o outro. (6) A e B revisam o diálogo deconfirmação nos dispositivos e selecionam "confirmar". (7) A transação depagamento começa.
O sistema permite transações de múltiplos canais e canal cruza-do. Em particular, os pagamentos podem ser solicitados de qualquer um doscanais disponíveis (por exemplo, telefone móvel, mensageiro instantâneo, e-mail, Web, cartão de débito, WAP, mensagem SMS ou aplicação de telefonemóvel dedicado) e a transação pode ser direcionada para qualquer um doscanais disponíveis, em qualquer combinação. Por exemplo, alguém podesolicitar o pagamento do mensageiro instantâneo para o telefone móvel, daweb para o telefone móvel, do telefone móvel para o mensageiro instantâ-neo, do WAP para o mensageiro instantâneo, do mensageiro instantâneopara o e-mail, do e-mail para o telefone móvel, do e-mail para o mensageiroinstantâneo, da Web para SMS, do SMS para o e-mail ou qualquer outracombinação. O sistema pode também ser usado para pagar através de ter-minais de pagamento, sítios da web interativos, pagamento por serviços ouconteúdo de mídia através da televisão (por exemplo, pagamento para filmessob demanda por um provedor a cabo ou satélite), telefones pré-pagos emuitos outros. Por exemplo, um usuário pode pagar um comerciante via omensageiro instantâneo. O sistema pode suportar o pagamento para ou a-través de máquinas de venda, parquímetros, quiosques, telefones de paga-mento, quiosques de passagem aérea e muitos outros.
O fluxo A abaixo mostra uma implementação da execução datransação entre um membro usuário registrado (usuário A) e um usuário nãoregistrado (usuário B).Fluxo A
<table>table see original document page 70</column></row><table><table>table see original document page 71</column></row><table><table>table see original document page 72</column></row><table>Na etapa 3, o sistema de pagamento móvel notifica o usuário Asobre os fundos insuficientes via troca de mensagens SMS. Em uma outramodalidade da invenção, o usuário A pode receber essa mensagem em ou-tras formas, tais como e-mail, troca de mensagens SMS ou outras formas decomunicação móvel. Em algumas modalidades da invenção, o usuário podenão receber essa mensagem absolutamente, tal como o caso quando o usu-ário A decidiu e indicou para o sistema não receber tais mensagens. O fluxopode também ser aplicado no sistema de pagamento por e-mail ou outrossistemas de pagamento, móveis, não móveis (isto é, onde um telefone móvelnão está envolvido na transação) ou de outra forma.
Na etapa 4, o sistema de pagamento móvel determina que o u-suário B não é registrado e notifica o usuário A disso. Em uma outra modali-dade da invenção, o sistema pode permitir que o usuário A envie o paga-mento para o usuário B a despeito do estado não registrado do usuário B eassim pode pular essa etapa.
Na etapa 5, o sistema de pagamento móvel coloca um controlena conta de A para a quantia da transação. A quantia da transação não édebitada da conta de A até que a quantia da transação é debitada na etapa- 15.
Na etapa 6, o usuário não registrado B recebe uma mensagempelo sistema de pagamento móvel solicitando o registro do usuário B com osistema. Essa mensagem pode ser enviada para o telefone móvel do usuárioB via troca de mensagens SMS, e-mail, troca de mensagens MMS, troca demensagens instantânea ou outras formas de comunicação móvel.
Na etapa 7, é provida para o usuário A a opção de ser capaz decancelar o pagamento antes que o usuário B o aceite. O pagamento podetambém ser automaticamente anulado se mais do que 30 dias decorreramdepois que o usuário A envia o pagamento e antes que o usuário B aceite opagamento. O número de dias depois dos quais uma transação é automati-camente cancelada pode variar. Por exemplo, o número de dias pode serqualquer número tal como 5, 10, 14, 15, 16, 21 ou mais ou menos dias doque 30. Também, os usuários AeB podem não receber uma mensagem osnotificando da transação cancelada.
Na etapa 8, o sistema cria uma conta para o usuário B com oregistro do usuário B. Em uma outra modalidade da invenção, o sistema po-de não requerer que o usuário B se registre com o sistema e pode ao invésdisso automaticamente vincular o sistema a uma das contas bancárias dousuário B.
Na etapa 9, o usuário B somente recebe uma mensagem comrelação a solicitação do usuário A para enviar pagamento somente depoisque o usuário B se registra com o sistema. Em uma outra modalidade dainvenção, o usuário B pode receber a mensagem com relação ao pagamentodo usuário A sem ter que se registrar com o sistema.
Na etapa 10 da modalidade atual, o usuário A recebe uma men-sagem SMS com relação ao cancelamento pelo usuário B da transação. Emuma outra modalidade da invenção, o sistema pode enviar ao usuário A umamensagem diferente e pode enviá-la em outras formas de comunicação mó-vel.
Na etapa 11, B pode ter opções para mudar ou modificar a tran-sação em alguma forma. O usuário B pode ser provido com um botão sim,um botão não e um botão de solicitar mudança. Alternativamente, o botão desolicitar mudança pode ser citado como um botão de negociação, porque édada a B a oportunidade para negociar com A. B pode ter a oportunidade demudar qualquer termo da transação. Alguns termos da transação que B po-de mudar incluem a quantia, selecionar para qual conta o dinheiro será cre-ditado ou outros.
Na etapa 12, se o usuário B solicita uma mudança na transação,é enviada para o usuário A uma notificação com relação à mudança propos-ta. É dada ao usuário A a capacidade de aceitar ou rejeitar a mudança pro-posta pelo usuário B. Em uma modalidade da invenção, o usuário A pode terescolhido rejeitar automaticamente as mudanças propostas na sua configu-ração inicial com o sistema. A seguir, o usuário B pode receber uma mensa-gem da rejeição automática da mudança pelo usuário A. Se o usuário A re-jeita a mudança, quer manual ou automaticamente, pode ser dada ao usuá-rio B a opção de enviar uma outra mudança proposta para o usuário A. Oupode ser dada para B a oportunidade de aceitar a transação original.
Na etapa 13, o sistema de pagamento móvel notifica o usuário Asobre os fundos insuficientes através de troca de mensagens SMS. Em umaoutra modalidade da invenção, o usuário A pode receber essa mensagemem outras formas, tais como e-mail, troca de mensagens MMS ou outrasformas de comunicação móvel ou pode não receber essa mensagem absolu-tamente.
Na etapa 14, o usuário A recebe uma notificação por SMS simi-lar a uma recepção notificando-o que a transação foi concluída. Em uma ou-tra modalidade, o usuário A pode receber uma notificação em outras formas,tal como através de e-mail, mensageiro instantâneo, troca de mensagensMMS ou outras formas de comunicação móvel. O sistema pode também en-viar para o usuário B uma notificação que a transação foi concluída. O sis-tema pode também não enviar para os usuários A ou B quaisquer mensa-gens com relação à conclusão da transação.
Na etapa 15, a transação do dinheiro acontece. Em uma imple-mentação, as transações de crédito e débito não ocorrem em tempo real. Astransações podem levar aproximadamente sessenta segundos ou mais paracompletar depois que um processo é iniciado devido aos retardos inerentesnos sistemas de financiamento eletrônico.
Qualquer número das etapas no fluxo A, em qualquer combina-ção, pode ser combinado com qualquer outro fluxo do sistema de pagamen-to móvel incluindo os outros fluxos discutidos nesse pedido.
O fluxo B abaixo mostra uma outra implementação da execuçãoda transação entre um membro usuário registrado (usuário A) e um usuárionão registrado (usuário B).Fluxo B
<table>table see original document page 76</column></row><table><table>table see original document page 77</column></row><table>
A implementação no fluxo B é similar ao fluxo A acima. Entretan-to, ao contrário do fluxo A, o fluxo B não coloca um controle na quantia detransação na conta de A (etapa 5 do fluxo A). Na etapa 4 do fluxo B, desdeque não existe controle na conta Aea conta de A não é debitada, o dinheirofica disponível para o usuário A gastar pelo pagamento móvel ou pagamentopor cartão de débito até que a quantia da transação é debitada com sucessoda conta do usuário A na etapa 6.
Na etapa 5, o usuário B recebe uma mensagem com relação àtransação e é questionado para se registrar com o sistema.
Na etapa 6, o dinheiro é negociado. Tais transações podem serencadeamentos assíncronos que duram aproximadamente sessenta segun-dos ou mais para completar depois que um processo é iniciado devido aosretardos inerentes nos sistemas de financiamento eletrônico. A duração doretardo é indeterminada desde que vários fatores influenciam o retardo. Deforma geral, o retardo é de cerca de 60 segundos, mas se a grade de potên-cia cai, por exemplo, o retardo será muito maior.
Em particular, o processamento de pagamento de um sistemapode não ser executado em uma maneira síncrona. Uma certa duração devalidação de solicitação positiva é feita. As notificações enviadas para oconsumidor podem indicar que a solicitação foi aceita e será processada embreve. O encadeamento secundário assíncrono do servidor é iniciado pararealmente processar a solicitação de pagamento. Em uma implementação, oencadeamento assíncrono é executado depois que as notificações são envi-adas para o usuário. Isso proporciona ao usuário resposta mais rápida comrelação à transação. É possível que a parte assíncrona do processamentode pagamento possa falhar. Por exemplo, isso pode ser por causa dos fun-dos insuficientes devido ao uso do cartão simultâneo. Na eventualidade defalha de processamento do pagamento assíncrono, o usuário é notificado.
Em uma implementação, existem dois tipos de contas em fundocomum, (i) uma conta em fundo comum de usuário não registrado e (ii) umaconta em fundo comum sem cartão. Todos os fundos dos usuários não re-gistrados serão mantidos juntos na conta em fundo comum do usuário nãoregistrado. Se o usuário A é um usuário sem cartão que não tem ainda umaconta individual, A terá o dinheiro mantido, em vez disso, na conta em fundocomum sem cartão. Em uma outra implementação da invenção, pode existiruma conta em fundo comum única para ambas as contas em fundo comumde usuário não registrado e em fundo comum sem cartão. Em uma outramodalidade da invenção, as contas de A e B são creditadas e debitadas nofundo comum e as transações no parceiro bancário (parceiro manipulando ocartão de débito) ocorrem no fim do dia (ou um outro tempo específico) cole-tivamente em lote com outras transações do sistema.
Em uma outra implementação da invenção, pode existir um úni-co tipo de conta em fundo comum, onde ambos os usuários não registradose os usuários sem cartão residem. Para transferências de dinheiro entre taisusuários, o dinheiro permanecerá dentro da mesma conta de fundo comum.Em uma implementação ainda adicional da invenção, podem existir mais doque dois tipos de contas em fundo comum.
Na etapa 9, depois que o usuário B se registra, B se torna umusuário sem cartão. Como um usuário sem cartão, B pode enviar e receberdinheiro como um usuário registrado. Entretanto, desde que B ainda nãorecebeu seu cartão, B não pode gastar dinheiro através do cartão. Em umaimplementação, a conta individual do usuário B é criada dentro de 24 horasdo registro bem-sucedido do usuário B. Entretanto, a conta não terá dinheiroaté que ela seja ativada na etapa 11 abaixo. Em uma outra modalidade dainvenção, uma conta em fundo comum sem cartão não é usada, e o dinheiroé transferido diretamente da conta do usuário A para a conta do usuário B.
Na etapa 10, dura tipicamente cerca de 7 a 10 dias de negóciospara fazer um novo cartão e para o usuário B recebê-lo no correio. Em umaoutra modalidade da invenção, o usuário B pode receber um outro tipo decartão, tal como um cartão de crédito ou pode escolher não receber cartãoabsolutamente.
Na etapa 11, com a ativação pelo usuário B do seu cartão, o u-suário B se torna um usuário registrado com cartão e não é mais um usuáriosem cartão. Em uma modalidade onde uma conta em fundo comum semcartão não é usada, não existirá a necessidade de transferir o saldo com aativação do cartão.
O fluxo C abaixo mostra uma outra implementação da execuçãoda transação entre um membro usuário registrado (usuário A) e um usuárionão registrado (usuário B).
Fluxo C
<table>table see original document page 79</column></row><table><table>table see original document page 80</column></row><table>
A implementação no fluxo C é similar ao fluxo A acima. Entretan-to, ao contrário do fluxo A, o fluxo C não coloca um controle na quantia detransação na conta de A (etapa 5 do fluxo A). A discussão acima para osfluxos A e B é aplicável ao fluxo C quando apropriado.
Em uma implementação, enquanto o pagamento de A está pen-dente, A pode cancelar o pagamento e B será apropriadamente notificado.Na etapa 8, no caso que existam múltiplos pagamentos pendentes, B podeter acesso a uma lista de pagamentos pendentes e ser induzido a indicar aaceitação ou rejeição de cada pagamento pendente. Se o encadeamentosecundário assíncrono do servidor (por exemplo, etapa 12) falha, ambas aspartes serão notificadas.
O fluxo D abaixo mostra uma implementação da execução datransação entre um usuário sem cartão (usuário A) e um usuário sem cartão(usuário B).Fluxo D
<table>table see original document page 81</column></row><table>Se B aceita a transação, e A é um usuário sem cartão e B é ago-ra um usuário com cartão, o dinheiro é transferido de A na conta em fundocomum sem cartão para a conta individual de B.
Se ambos A e B se tornaram usuários com cartão, o dinheiro étransferido da conta individual de A para a conta individual de B.
Se A se tornou um usuário com cartão, mas B é ainda um usuá-rio sem cartão, o dinheiro é transferido da conta individual de A para B naconta em fundo comum sem cartão.
Os comentários providos acima se aplicam ao fluxo D quandoapropriado. Por exemplo, na etapa 3, nenhum controle é colocado na contade A para a quantia da transação. A quantia da transação não é debitada daconta de A. Até que a quantia da transação seja debitada com sucesso daconta de A em uma etapa seguinte, o dinheiro fica disponível para A gastarpelo pagamento móvel ou pagamento com cartão de débito.
O usuário B pode ter uma configuração de lista branca ou delista negra. A lista branca pode ditar que B aceitará pagamentos somente deusuários especificados (que podem ficar armazenados no perfil do usuário).A lista negra pode ditar que B não aceitará pagamentos de membros especi-ficados (que podem ficar armazenados no perfil do usuário). Várias imple-mentações da invenção podem ter somente uma lista branca, somente umalista negra, ou ambas, uma lista branca e uma negra. Remetentes não auto-rizados, por causa da lista branca ou negra, serão notificados do erro depoisque sua tentativa de pagamento falha.
O fluxo E abaixo mostra uma implementação da execução datransação entre um usuário registrado sem cartão (usuário A) e um usuáriocom cartão (usuário B).Fluxo E
<table>table see original document page 83</column></row><table>Se B aceita a transação e A é agora um usuário com cartão, odinheiro é transferido da conta individual de A para a conta individual de B.
Os comentários providos acima se aplicam ao fluxo E quandoapropriado.
O fluxo F abaixo mostra uma implementação da execução datransação entre um usuário com cartão (usuário A) e um usuário sem cartão(usuário B).
Fluxo F
<table>table see original document page 84</column></row><table><table>table see original document page 85</column></row><table>
Os comentarios providos acima se aplicam ao fluxo F quandoapropriado.
O fluxo G abaixo mostra uma implementacao da execucao datransacao entre um usuario com cartao (usuario A) e um usuario com cartao(usuario B)
Fluxo G
<table>table see original document page 85</column></row><table><table>table see original document page 86</column></row><table>
Os comentários providos acima se aplicam ao fluxo G quando apropriado. O fluxo H mostra um fluxo de referência para usuários não regis- trados. O usuário A é um usuário registrado e o usuário B é um usuário não registrado.
<table>table see original document page 86</column></row><table><table>table see original document page 87</column></row><table>
Os comentários providos acima se aplicam ao fluxo H quandoapropriado. Nesse fluxo, os fundos não são automaticamente transferidos deA para B depois que B se registra. De preferência, B é convidado a se unir ecom a união de Β, A recebe uma mensagem (etapa 9) perguntando se Adeseja tentar enviar o dinheiro para B novamente. Se A deseja enviar o di-nheiro, então a A para B subseqüente será tratada como qualquer transfe-rência de usuário registrado para usuário registrado.
A implementação pode incluir uma bonificação de referência (porexemplo, $5). A mensagem na etapa 4 pode incluir uma notificação para Aque A receberá uma bonificação de referência com a união de B. Depois queB se registra na etapa 6, o usuário A será autorizado para a bonificação dereferência que é colocada na conta de A (ver etapa 8). A etapa 8 vem depoisda etapa 6, mas pode ser antes ou depois das etapas 7 e 9.
Em várias implementações do sistema, as bonificações de refe-rência podem ser pagas somente para o remetente, somente para o receptorou para ambos o remetente e o receptor. Além do mais, em uma modalidadealternativa de um fluxo de referência, depois que B se registra, o dinheiropode ser automaticamente transferido para B sem a necessidade de A envi-ar novamente uma transação de solicitação de pagamento. Em uma outramodalidade, o fluxo é: (1) usuário A (membro) envia para o usuário B (umnão membro) $X. O sistema verifica B, descobre que B não é um membro.(3) $X é rotulado como uma pendência na conta de A. (4) B é notificado queB é convidado por A a se unir ao sistema. Um incentivo de $Y + dinheiro en-viado por A estão aguardando para ser coletados. (5) B escolhe se alistarcomo um membro e recebe o incentivo de $Y imediatamente (já na conta).(6) B então recebe uma mensagem indicando que um pagamento de $X foirecebido de A. (7) $X é deduzido da conta de A. (8) A pendência viral podeser cancelada por A, porém o convite pode ainda ser processado. (9) Se Bnão aceita o convite em certo período. A quantia pendente é então liberadade volta para a conta.
Em uma modalidade adicional da invenção, o sistema de trocafinanceira pode notificar usuários através de múltiplas notificações por tran-sação, tal como com SMS e com e-mail, em casos específicos. Exemplos detais casos incluem: com o registro do novo usuário, com o registro do cartãodo sistema, com o envio ou recepção de uma referência, com a carga decrédito/débito, com a carga ou descarga de ACH/depósito direto, com a car-ga eAllowance (isto é, pagamento de conta) e com a mudança de dados deconta ou perfil.
Em um sistema de pagamento móvel, usuários registrados oumembros podem enviar pagamento para outro membro ou usuários não re-gistrados ou não membros. Em uma implementação específica, um sistemade pagamento de pessoa para pessoa permite que membros existentes deum sistema de pagamento enviem fundos para não membros com a inten-ção que o não membro se torne um membro. Essa capacidade de um siste-ma de pagamento pode ser citada como "viral" porque ela estimula registrosde novos membros em um modo de propagação exponencial.
Em uma modalidade, a invenção é um método incluindo: receberuma instrução de pagamento de um primeiro usuário para pagar um segun-do usuário uma quantia em dinheiro, onde o primeiro usuário é um usuárioregistrado e o segundo usuário é identificado por um número de telefonepara o segundo usuário; com base no número de telefone, determinar que osegundo usuário não é um usuário registrado, e enviar uma primeira mensa-gem eletrônica para um dispositivo associado com o número de telefone no-tificando o segundo usuário do pagamento pendente proveniente do primeirousuário. O método inclui: depois de enviar a primeira mensagem eletrônica,registrar o segundo usuário e apresentar ao segundo usuário uma primeiraopção para aceitar o pagamento pendente do primeiro usuário e uma se-gunda opção para rejeitar o pagamento pendente do primeiro usuário; quan-do o segundo usuário seleciona a primeira opção, debitar a quantia em di-nheiro de uma primeira conta associada com o primeiro usuário e creditar aquantia em dinheiro em uma segunda conta associada com o segundo usuá-rio; e quando o segundo usuário seleciona a segunda opção, enviar umasegunda mensagem eletrônica para o primeiro usuário que o pagamento foirejeitado.
Em uma implementação, a segunda conta fica em uma conta emfundo comum e quando o primeiro usuário é um usuário registrado sem car-tão, a primeira conta fica na conta em fundo comum, e o débito e o créditoincluem manter a quantia em dinheiro dentro da conta em fundo comum. Emuma implementação, a segunda conta fica em uma conta em fundo comum equando o primeiro usuário é um usuário registrado sem cartão, a primeiraconta fica na conta em fundo comum e o débito e o crédito incluem nãotransferir a quantia em dinheiro para fora da conta em fundo comum. Emuma implementação, quando o primeiro usuário é um usuário registrado semcartão, a primeira conta fica em uma primeira conta em fundo comum e asegunda conta fica em uma segunda conta em fundo comum, diferente daprimeira conta em fundo comum e o débito e o crédito incluem transferir aquantia em dinheiro da primeira conta em fundo comum para a segunda con-ta em fundo comum.
Em uma implementação, o primeiro usuário é um usuário regis-trado com cartão e a segunda conta fica em uma conta em fundo comum, eo débito e o crédito incluem transferir a quantia em dinheiro da primeira con-ta para a segunda conta na conta em fundo comum, por meio do que a contaem fundo comum é aumentada pela quantia em dinheiro. O cartão associadocom um registrado pode ser um cartão de débito, cartão de crédito, cartãode caixa eletrônico ou qualquer outro cartão físico mostrando um número daconta. Usando um tal cartão, o primeiro usuário pode conduzir as transaçõesindependente do dispositivo eletrônico do qual a instrução de pagamento foienviada.
Em uma implementação, o método inclui: receber, além da ins-trução de pagamento, um número de seqüência gerado por um dispositivoque enviou a instrução de pagamento, e depois de receber o número de se-qüência, gerar um número de transação para a instrução de pagamento. Emuma implementação, o processamento da instrução de pagamento ocorresomente se o número da seqüência não iguala qualquer número de seqüên-cia previamente recebido armazenado em um banco de dados. O banco dedados pode incluir números de seqüência recebidos para um período detempo rolante, tal como a última semana, as duas últimas semanas, o últimomês, os seis meses prévios ou qualquer outro período de tempo.
Em uma implementação, depois de receber o número de se-qüência, um número de seqüência esperado é gerado. A seguir, a instruçãode pagamento é processada somente se o número de seqüência iguala onúmero de seqüência esperado.
Em uma modalidade, a invenção é um método incluindo: receberuma instrução de pagamento de um primeiro usuário para pagar a um se-gundo usuário uma quantia em dinheiro, onde o primeiro usuário é um usuá-rio registrado e o segundo usuário é identificado por um número de telefonepara o segundo usuário; com base no número de telefone, determinar que osegundo usuário não é um usuário registrado e enviar uma primeira mensa-gem eletrônica para um dispositivo associado com o número do telefone no-tificando o segundo usuário do pagamento pendente proveniente do primeirousuário. O método inclui: depois de enviar a primeira mensagem eletrônica,registrar o segundo usuário e apresentar ao segundo usuário uma primeiraopção para aceitar o pagamento pendente do primeiro usuário, uma segun-da opção para rejeitar o pagamento pendente do primeiro usuário e uma ter-ceira opção para solicitar uma mudança no pagamento pendente do primeirousuário; quando o segundo usuário seleciona a primeira opção, debitar aquantia em dinheiro de uma primeira conta associada com o primeiro usuárioe creditar a quantia em dinheiro em uma segunda conta associada com osegundo usuário, quando o segundo usuário seleciona a segunda opção,enviar uma segunda mensagem eletrônica para o primeiro usuário que opagamento foi rejeitado.
Na implementação, o método inclui quando o segundo usuárioseleciona a terceira opção, enviar uma terceira mensagem eletrônica para oprimeiro usuário que o segundo usuário solicitou uma mudança no paga-mento pendente. Em uma implementação, o método inclui quando o segun-do usuário seleciona a terceira opção, receber uma solicitação do segundousuário para mudar o pagamento pendente para ter uma quantia em dinheirodiferente, enviar uma terceira mensagem eletrônica para o primeiro usuárionotificando o primeiro usuário da mudança no pagamento pendente, apre-sentar ao primeiro usuário uma quarta opção para aceitar a mudança no pa-gamento pendente ou uma quinta opção para rejeitar a mudança no paga-mento pendente, e quando o primeiro usuário seleciona a quarta opção, de-bitar a quantia em dinheiro diferente de uma conta do primeiro usuário e cre-ditar a quantia em dinheiro diferente em uma conta associada com o segun-do usuário.
O método pode também incluir depois de determinar que o se-gundo usuário não é um usuário registrado, colocar um controle na quantiaem dinheiro na primeira conta. O método pode incluir: depois de determinarque o segundo usuário não é um usuário registrado, colocar um controle naquantia em dinheiro na primeira conta e depois que um certo número de diasdecorre do tempo que a instrução do pagamento foi recebida e o segundousuário não se registrou, remover o controle na quantia em dinheiro na pri-meira conta.
O dispositivo pode ser pelo menos um de um telefone inteligen-te, dispositivo de telefonia móvel, dispositivo de e-mail portátil, assistentedigital pessoal ou computador.
Em uma modalidade, a invenção é um método incluindo: receberuma instrução de pagamento de um primeiro usuário para pagar ao segundousuário uma quantia em dinheiro, onde o primeiro usuário é um usuário re-gistrado e o segundo usuário é identificado por um número de telefone parao segundo usuário; com base no número de telefone, determinar que o se-gundo usuário não é um usuário registrado, e enviar uma primeira mensa-gem eletrônica para um dispositivo associado com o número do telefone no-tificando o segundo usuário de uma tentativa de pagamento do primeiro u-suário. O método inclui: depois de enviar a primeira mensagem eletrônica,registrar o segundo usuário, enviar ao primeiro usuário uma segunda men-sagem eletrônica para o primeiro usuário que o segundo usuário se registroue apresentar ao primeiro usuário uma primeira opção para pagar o segundousuário a quantia em dinheiro, e quando o primeiro usuário seleciona a pri-meira opção, debitar a quantia em dinheiro de uma primeira conta associadacom o primeiro usuário e creditar a quantia em dinheiro em uma segundaconta associada com o segundo usuário.
Em uma implementação, depois que o segundo usuário se regis-tra, a primeira conta é creditada com uma quantia de bonificação de referên-cia. A quantia de bonificação de referência pode ser qualquer quantia emdinheiro, tal como $5. Em uma implementação, depois que o segundo usuá-rio se registra, a segunda conta é creditada com uma quantia de bonificaçãode referência. Adicionalmente, ambos o primeiro e o segundo usuários po-dem receber bonificações de referência.
Em uma implementação, o método inclui enviar uma segundamensagem eletrônica para o primeiro usuário que o segundo usuário não éum usuário registrado. Em uma implementação, o método inclui: receber,além da instrução de pagamento, um número de seqüência gerado por umdispositivo que enviou a instrução de pagamento e depois de receber o nú-mero de seqüência, gerar um número de transação para a instrução de pa-gamento.
A figura 19 mostra o diagrama de sistema geral de uma modali-dade específica da invenção. Essa é uma vista esquemática de uma imple-mentação específica de um sistema de pagamento móvel (isto é, Obopay).Como previamente declarado, Obopay é provido meramente como um e-xemplo para ilustrar os aspectos da invenção e a invenção não deve ser limi-tada a esse exemplo. O sistema de Obopay tem um suporte de cartão dedébito. Um parceiro, Diamond Financial Products, é um parceiro. Através deDiamond, Obopay emite cartões de débito e se comunica com ECL e bancoFirst Premiere para fornecer aos usuários de Obopay a capacidade de enviare receber dinheiro entre cartões de débito. PBT (Pay by Touch) lida com astransações ACH e transações de cartão de crédito. O banco Bancorp provêcontas de quitação e tem uma relação com PBT.
A figura 20 mostra um pagamento de pessoa para pessoa entreduas contas com cartão individuais. "Cartão" se refere a um membro de O-bopay que mantém um cartão de crédito de Diamond Financial Products.Esse é um "usuário de cartão" ou "usuário com cartão", que está em con-traste com um usuário sem cartão. Um fluxo específico inclui: (1) Do telefonede U1, um pagamento P2P de $5 para U2 é iniciado. (2) Obopay envia asolicitação de P2P para Diamond (que por sua vez a envia para ECL e FirstPremier). (3) A quantia de $5 é debitada da conta do cartão de débito de U1e creditada para a conta de cartão de débito de U2. (4) Uma taxa de $0,10 édeduzida da conta de U1 e creditada na conta do banco de Diamond Finan-ciai Products no banco First Premier.
A figura 21 mostra um pagamento de pessoa para pessoa entreuma conta com cartão e uma conta de não membro. Um fluxo específicoinclui: (1) Do telefone de U1, um pagamento P2P de $5 para o não usuárioV1 é iniciado. (2) Obopay envia a solicitação de P2P para Diamond (que porsua vez a envia para ECL e First Premier). (3) A quantia de $5 é debitada daconta de cartão de débito de U1 e creditada na conta de Obopay In & Out.(4) Uma taxa de $0,10 é deduzida da conta de U1 e creditada em uma contado banco de Diamond Financial Products no banco First Premier. (5) Umregistro é introduzido na tabela de banco de dados "CONVITE" de U1. Isso éonde o registro do viral é armazenado; a transação pode ser invertida atéque o receptor viral se aliste para uma conta de Obopay.
A figura 22 mostra um pagamento de pessoa para pessoa entreuma conta com cartão e uma conta sem cartão. Um usuário "sem cartão" éum usuário de Obopay que ainda não recebeu ou ativou o seu cartão de dé-bito. Em uma outra modalidade da invenção, o cartão de débito não é reque-rido. Em uma modalidade específica, existe um estado entre o pedido docartão e a ativação onde o usuário pode ainda enviar e receber dinheiro.
Um fluxo específico inclui: (1) Do telefone, U1 inicia uma transa-ção P2P de $5 para o usuário "sem cartão" 01. A quantia de $5,00 é transfe-rida da conta de cartão de débito de U1 para a conta do banco de Obopay In& Out no First Premier. (3) Uma taxa de $0,10 é transferida (por Diamond)para uma conta do banco Diamond Financial Products no banco First Premi-er. (4) Obopay registra o aumento de $5 no saldo de 01 na razão geral deObopay.
A figura 23 mostra um pagamento de pessoa para pessoa desem cartão para sem cartão. Um fluxo específico inclui: (1) Do telefone, 01inicia uma transação P2P de $10 para o usuário "sem cartão"02. (2) os $10permanecem na conta de Obopay In & Out no First Premier. A taxa de $0,10também permanece na conta In & Out. (3) Obopay registra o aumento nosaldo de 02 e a diminuição no saldo de 01 na razão geral de Obopay.
A figura 24 mostra uma carga de cartão de crédito. Um fluxo es-pecífico inclui: (1) Da web, U1 insere o número CC para carregar $300 noseu cartão de Obopay. (2) Obopay obtém uma autorização de $300 de Pay-By-Touch para a transação do cartão de crédito. (3) Obopay envia umamensagem para Diamond iniciando um P2P de $300 de Obopay CC-MasterA/C para o cartão de débito de U1. O usuário é imediatamente creditadocom os fundos. (4) PBT quita a transação do cartão de crédito e envia $300ACH para a conta de quitação de Obopay no banco Bancorp. (5) Obopayenvia $300 ACH para Obopay CC Master A/C para reabastecer os fundos.
A figura 25 mostra o diagrama do sistema geral de uma outramodalidade específica da invenção. Os fluxos seguintes 78 a 85 são relacio-nados com a implementação do sistema na figura 77. Nessa implementaçãodo sistema, os usuários não precisarão se registrar para uma conta de car-tão de débito. Esses usuários serão chamados usuários "sem cartão" e man-terão contas virtuais. Os fundos serão mantidos em uma conta no banco (pa-ra o benefício dos usuários de Obopay).
A figura 26 mostra um pagamento de pessoa para pessoa entreuma conta sem cartão e uma conta sem cartão. Um fluxo específico inclui:(1) Do telefone de 01, um pagamento P2P de $5 para 02 é iniciado. (2)Porque ambos 01 e 02 são usuários existentes, seus fundos ficam armaze-nados na conta em fundo comum no banco Bancorp. Os $5 permanecem namesma conta, menos uma taxa de $0,10. (3) a razão geral de Obopay refletea mudança no saldo. A quantia de $5 é debitada da conta de 01 e $5 sãocreditados na conta de 02. (4) A taxa de $0,10 é transferida da conta doconsumidor em fundo comum para a conta do capital de giro.
A figura 27 mostra o pagamento de pessoa para pessoa entreuma conta sem cartão e uma conta com cartão. Um fluxo específico inclui:(1) Do telefone de 01, um pagamento P2P de $5 para U6 é iniciado. (2) Aconta do usuário 01 é debitada em $5,10. Essa mudança é refletida na ra-zão geral de Obopay. (3) Obopay (através da comunicação com Diamond)inicia uma P2P, transferindo $5 da conta de First Premier In & Out para ocartão de débito de U6. (4) Em um lote noturno, $5,10 (existe uma taxa de10 centavos para enviar o dinheiro) são movidos da conta em fundo comumde Obopay para a conta do capital de giro de Obopay no Bancorp.
A figura 28 mostra o pagamento de pessoa para pessoa em umatransação viral para um não membro. Um pagamento "viral" é um onde ummembro de Obopay, com cartão ou sem cartão, envia um pagamento paraum número de telefone de usuários que não pertencem a Obopay. Um fluxoespecífico inclui: (1) do telefone de 01, um pagamento P2P de $5 para V1 éiniciado. (2) a razão geral de Obopay reflete a mudança no saldo de 01.$5,10 são debitados da conta de 01. (3) os $5,10 permanecem na conta doconsumidor em fundo comum. A taxa é transferida mais tarde. (4) A transa-ção viral é gravada na tabela de "CONVITE" de 01 no banco de dados deObopay. Se o pagamento viral expira, os fundos retornarão para 01. (5) Ataxa de $0,10 é transferida da conta do consumidor em fundo comum para aconta do capital de giro. Isso pode ser feito em um lote noturno.
A figura 29 mostra o financiamento de incentivo. O financiamen-to de incentivo ocorre quando novos usuários de Obopay ganham uma boni-ficação de alistamento de $5 ou qualquer outra quantia. Quando o usuário sealista, esses $5 serão refletidos no saldo. Também, quaisquer fundos envia-dos de modo viral para o usuário serão transferidos para sua conta. Um pa-gamento viral pendente ocorre quando um usuário que não é Obopay rece-be, de modo viral, fundos que são mantidos na conta em fundo comum doconsumidor. O pagamento é acompanhado na "tabela de convite" dos reme-tentes, uma seção de seu próprio perfil de dados. Pagamentos virais ficamsomente "pendentes", significando que o remetente pode cancelar o pagamento.
Um fluxo específico inclui: (1) V1 (receptor dos fundos virais, nãousuário) se alista para Obopay em Obopay.com. (2) A conta é criada nobanco de dados de Obopay. (3) O saldo dos usuários em Obopay GL agorareflete a bonificação de $5 e o pagamento viral de $10. (4) os fundos envia-dos de modo viral para V1 ($10 enviados para o usuário antes do alistamen-to) permanecem na conta em fundo comum do consumidor. (5) O perfil dobanco de dados para o remetente original dos fundos virais é atualizado para"RFPAID" (referência paga). (6) Em um lote noturno, $5 são transferidos daconta sem cartão de Obopay para a conta em fundo comum do consumidor.
A figura 30 mostra a carga do cartão de crédito. A carga do car-tão de crédito é o processo de carregamento de fundos em uma conta deObopay via um cartão de crédito. A conta do capital de giro de Obopay éuma conta de banco no banco Bancorp (ou qualquer outro parceiro bancá-rio). Essa conta contém o capital de giro de Obopay e é financiada com ocapital de giro de Obopay. Essa conta é também usada como conta de qui-tação para NYCE, PBT e outros.
Um fluxo específico inclui: (1) o usuário 01 de Obopay acessaObopay.com e inicia uma carga de $300 do seu cartão Visa para sua contade Obopay. (2) Obopay, usando Pay-By-Touch como um processador, ob-tém uma autorização de $301,50 (incluindo uma taxa aproximada) para atransação do cartão de crédito. (3) A quantia de $300 é creditada na contade OI no Obopay GL. (4) Obopay transfere $300 da conta do capital de giropara a conta em fundo comum do consumidor. Isso pode ocorrer em um lotenoturno. (5) Pay-By-Touch quita a transação e a seguir inicia um $301,50ACH para a conta de quitação de Obopay no banco Bancorp. Isso pode o-correr em um lote no próximo dia.
A figura 31 mostra a carga ACH. Um fluxo específico inclui: (1)do sítio da web de Obopay, o usuário sem cartão 01 inicia uma transaçãoACH de $100 para a conta de Obopay do seu DDA. (2) Obopay inicia umdébito ACH contra o DDA dos usuários. (3) os fundos são transferidos doDDA dos usuários para a conta do capital de giro de Obopay. (4) A contados usuários é creditada com $100 no Obopay GL. (5) Obopay transfere$100 da conta de capital de giro de Obopay para a conta do consumidor emfundo comum. Isso pode ser feito em uma operação de lote noturno.
A figura 32 mostra a descarga ACH. Um fluxo específico inclui:(1) do sítio da web de Obopay, o usuário sem cartão 01 inicia uma transa-ção ACH de $100 para o seu DDA. (2) O "saldo disponível" do usuário 01 éreduzido por $100 na razão geral de Obopay. (3) através de Pay-By-Touch1um crédito ACH é postado para o DDA de 01. (4) o ACH é postado e os$100 são sacados da conta do capital de giro de Obopay. (5) O "saldo cor-rente" dos usuários é reduzido por $100 para igualar o saldo disponível. (6)Os $100 são transferidos da conta em fundo comum do consumidor de Obo-pay para a conta do capital de giro de Obopay.
A figura 33 mostra uma carga de ATM. A carga pode ser atravésde qualquer instituição de ATM tal como NYCE, PLUS, STAR e outras. Emuma implementação específica, a carga de ATM é uma carga NYCE. Umfluxo específico inclui: (1) do sítio da web de Obopay, o usuário sem cartão01 inicia uma carga NYCE de $100 do seu DDA. (Existe uma taxa de $0,99para carregar dinheiro.) (2) Obopay submete e recebe uma autorização de$100,99 de NYCE. (3) A conta de 01 no Obopay GL é creditada para $100.(4) Em um lote noturno, $100 são transferidos da conta do capital de giro deObopay para a conta em fundo comum do consumidor. (5) NYCE posta umcrédito ACH de $100,99 para a conta do capital de giro de Obopay.
Os sistemas de pagamento atuais (isto é, cartões de crédito edébito) têm custo para ambos consumidores e comerciantes. Os consumido-res podem ser cobrados com taxas de assinaturas anuais. Os comerciantessão cobrados pesadamente com taxas de intercâmbio. O que é necessário éum sistema de pagamento disponível para consumidores e comerciantesque não tenha taxas de alistamento, sem taxas de assinatura e sem taxasde transação para o consumidor ou o comerciante. Ainda, ao mesmo tempo,o "processador" que movimenta um tal sistema deve ser compensado ade-quadamente.
Esquema de pagamento de circuito fechado
Em uma modalidade, a invenção provê um método para operar ainfra-estrutura de transferência de pagamento como um sistema de paga-mento de circuito fechado. Um sistema de transação financeira de circuitofechado facilita os pagamentos sem as despesas de pagamento substanci-ais associadas com os sistemas financeiros de circuito fechado e tem umalto nível de segurança para o dono, o comerciante e outros envolvidos nastransações financeiras.
Um sistema de pagamento de circuito fechado ocorre onde oscomponentes do processo de transferência de valor acontecem sob o con-trole da entidade que possui o sistema de pagamento. Pelo fato de que odono controla o sistema, a colocação de preço subjacente fica também sob ocontrole do dono. Em contraste, dinheiro e cheques são sistemas de paga-mento abertos onde cada participante estabelece o seu preço para manipu-lar o seu pedaço da transação sem um pagamento para um operador de re-de.
A figura 35 mostra o fluxo de transação em um sistema de pa-gamento de circuito fechado. Especificamente, quando um pagamento é fei-to a partir de um dispositivo móvel 3501 para um outro dispositivo móvel3502, a solicitação para a transferência é passada para o servidor de paga-mento 3503. A solicitação é indicada pela seta de referência 3504. O servi-dor 3503 acessa a razão T para o dono da conta associado com o dispositi-vo móvel 3501 (como indicado pela seta de referência 3505) e transfere aquantia especificada para uma razão T do recebedor (como indicado pelaseta de referência 3507) se certas regras de velocidade são satisfeitas comoindicado em 3506. Depois que os fundos foram transferidos para o recebe-dor, como indicado por 3508, o servidor 3503 envia uma mensagem de noti-ficação para o recebedor como indicado em 3509. Finalmente, o dono daconta do pagador recebe uma mensagem de confirmação do servidor 3503que a transação foi concluída. De preferência, todo o sistema de circuito fe-chado é possuído por entidade única. O sistema é provido ou carregado pordonos de contas que negociam dólares para um saldo de conta mantido noservidor de pagamento (ver figura 3).
Existem várias vantagens em um sistema de pagamento de cir-cuito fechado. A vantagem primária é que o dono do sistema é capaz decontrolar a colocação do preço para ambos o remetente e o recebedor e e-xiste uma oportunidade de ganhos por participação nos fundos carregadospara o sistema. O dono do sistema de pagamento é capaz de ganhar partici-pação sobre todos os fundos no sistema até que eles sejam convertidos oudescarregados de volta para dólares. À medida que mais funções são adi-cionadas, o sistema de circuito fechado se torna mais rentável devido a umaumento nas taxas e saldos.
As proposições de valor para o dono da conta participante inclu- em:
(1) Segurança - o dinheiro do dono da conta fica bloqueado comsegurança no dispositivo móvel ao invés de ter que transportar dinheiro emum bolso ou bolsa,
(2) Garantia - verificação adequada para ver quanto dinheiro es-tá disponível na conta,
(3) Informação - atividade da conta e informação de saldo fáceis
de obter,
(4) Conveniente - o dono da conta pode mover o dinheiro emsegundos por todo o mundo ou através de uma sala.
As proposições de valor para os comerciantes incluem:
(1) Segurança - sem dinheiro,
(2) Menor custo de manipulação - sem recibos de dinheiro paracontagem, sem papéis de depósito, sem fitas de máquina adicionais,
(3) Menos custos de transação - menores taxas do que os car-tões de crédito e
(4) Fundos garantidos - sem cheques retornados.
Parceiros comerciais têm uma oportunidade única para conse-guir renda por manipular transações direcionadas para depósito de fundosem uma conta de débito pré-paga ou para o provimento de dinheiro para umdono de conta. As comissões podem ser obtidas pelos comerciantes quandoos fundos são adicionados em uma conta.
O sistema de pagamento de circuito fechado independente dapresente invenção é projetado para integrar com uma conta bancária asso-ciada. Essa conta pode ser uma conta pré-existente ou, para usuário sembanco, contas podem ser criadas ou mantidas em uma conta em fundo co-mum com o banco parceiro.
O sistema de circuito fechado mantém um banco de dados deperfil do usuário que inclui o nome do dono da conta e dados demográficos,informação usada para segurar o risco para cada dono de conta específico einformação de conta de banco vinculada para contas que serão usadas paracarregar ou descarregar fundos da conta. Ό banco de dados de perfil do u-suário também requer um sítio da web de situação do serviço do consumidore situação do consumidor para coleta dos dados de alistamento quando ascontas são abertas.
O servidor de pagamento mantém um registro de conta "T" paracada dono de conta. Essa conta é uma razão que acompanha as transaçõese saldos de cada dono de conta. Em conjunto com o banco de dados daconta Τ, o servidor de pagamento provê dados de história e saldo através dodispositivo móvel, bem como um sítio da web de situação de serviço do con-sumidor e do consumidor.
De modo a obter dinheiro para dentro e para fora do sistema depagamento de circuito fechado, a presente invenção provê três tipos de fun-ções para donos diferentes de conta.
Alguns donos de conta já terão uma conta bancária com umbanco que não é um parceiro. O sistema permite que donos de conta mo-vam os fundos para e dessa conta de banco através do sistema ACH ou a-través de uma integração direta com o DDA do dono da conta ou através deuma integração através da rede ATM. Devido ao risco envolvido, o usuárioserá submetido a controles de risco que podem incluir disponibilidade adiadados fundos transferidos (por exemplo, uma transferência da sua conta ban-cária na segunda-feira pode não ser usada até quinta-feira). Esse tempo deadiamento poderia ser reduzido com seguro adicional (pesquisando relató-rios de crédito ou obtendo declarações financeiras). Uma redução no tempode adiamento pode também ocorrer devido ao usuário ter um bom registrode crédito com um portador parceiro ou garantir os pagamentos com um car-tão de crédito que é mantido em reserva. Em geral, essa abordagem não énossa primeira escolha devido ao risco envolvido a menos que exista umaportadora envolvida que possa entregar alguns dados de seguro e consumi-dores suficientes para justificar o seguro adicional.
Onde o dono da conta se alistou como um resultado de uma re-lação com um banco parceiro, uma conexão em tempo real para o sistemade contabilidade de depósito por demanda (conta corrente) possibilita que odono da conta obtenha saldos e poste transações para a sua conta em tem-po real.
Em outros casos, o dono da conta mantém uma conta com umbanco (por exemplo, banco Bancorp ou banco First Premier) que opera obanco, porém sítios da web, cheques e declarações do consumidor transpor-tarão uma marcação de afinidade. Essa abordagem nos permitirá prover amarcação de afinidade com uma conta de banco associada (a conta serágrátis para o usuário) em um ambiente firmemente integrado.
A presente invenção refere-se a um serviço de transação finan-ceira de circuito fechado tendo poucas ou nenhuma taxa de transação e se-gurança melhorada. Uma modalidade da presente invenção abrange um mé-todo para transferência rápida, fácil, de pagamentos entre qualquer par ouentre um consumidor e comerciante. Uma implementação do método incluium dispositivo de telefonia móvel, telefone celular ou dispositivo similar co-mo o mecanismo para acessar uma conta tal como uma conta de débito pré-financiada e autorizar a transferência de fundos dessa conta para uma outraparte. Modalidades adicionais da presente invenção abrangem uma varieda-de de parceiros que incluem operadoras de telefone móvel, comerciantesnacionalmente identificados por marca e provedores de serviço financeirojunto com uma plataforma de pagamento que provê uma maneira rápida,fácil, de fazer pagamentos por indivíduos usando seus telefones celulares ououtro dispositivo de telecomunicação.
Fazer referência agora à figura 36, que mostra um sistema detransação financeira de circuito fechado de acordo com uma modalidade dapresente invenção. Nesse sistema de transação, consumidores e comercian-tes, um grupo de dois ou mais consumidores ou um grupo de dois ou maiscomerciantes podem facilmente completar as transações financeiras rapi-damente, com segurança com pouco ou nenhum custo de transação.
Esse sistema de transação financeira de circuito fechado utilizaconta de débito pré-financiada e por essa razão pode compreender um ter-minal de ponto de vendas (POS) 3612 onde cartões de débito tradicionais3606 podem ser usados como no sistema da técnica anterior - passando ocartão na leitora magnética 3613 associada com o terminal de POS 3612. Ocartão 3606 provê uma segunda visão para dentro das contas do dono daconta.
Em algumas modalidades, o terminal de POS 3612 também in-clui uma antena perto da esfera de ação (NF) e circuitos 3614. A antena NFe circuitos 3614 detectam dispositivos passivos tal como um telefone celularhabilitado em NF, um telefone celular habilitado em Bluetooth ou outro dis-positivo de transmissão de faixa curta, tal como RFID ou códigos de barras,associados com o telefone celular 3618. Assim, quando o telefone celular3618 está em proximidade com o terminal de POS, a informação da conta éautomaticamente para o terminal de POS. Em ainda outras modalidades, oterminal de POS 3612 inclui uma conexão de telefone celular que estabeleceuma conexão com o processador de transação 3630 que é também citadode maneira variada como o servidor de pagamento ou servidor, com a inicia-ção de uma transação. E para ser entendido que o processador de transa-ção 3630 inclui um ou mais sítios de servidor ou centros de dados capazesde lidar com grandes volumes de transações simultâneas. Como é bem en-tendido na técnica, tais sítios de servidor são tipicamente dispersos geogra-ficamente e ligados com a tecnologia apropriada para manter uma visão pre-cisa do estado em tempo real de todas as contas. O terminal de POS trans-fere a quantia da transação diretamente do terminal de POS para o servidorde pagamento para autorização por uma conexão de telefone celular 3615.O servidor de pagamento 3630 chama o telefone celular do dono da conta3619 para confirmar os detalhes da transação. Alguém versado na técnicaverificará que o terminal de POS pode incluir somente um ou dois entre aleitora magnética 3613, antena NF e circuitos 3614 e telefone celular 3615. Étambém para ser verificado que o terminal de POS 3612 é geralmente asso-ciado com um comerciante.
Uma vantagem considerável de uma modalidade da presenteinvenção é que ambos o telefone celular 3618 ou 3619 e o cartão 3606compartilham um PIN comum. Assim, o dono da conta não tem o inconveni-ente de ter que recordar múltiplos PINs.
Além das transações de consumidor para comerciante, a pre-sente invenção é flexível o suficiente para implementar capacidades de tran-sação financeira verdadeiras de pessoa para pessoa. Cada um dos disposi-tivos de pessoa para pessoa 3620 compreende um telefone celular que évinculado a uma conta e um dono de conta. Quando um dos pares 3620 de-seja iniciar uma solicitação de transação, tal como enviar um pagamentopara um outro par, a solicitação, a autorização e a confirmação da transaçãosão todas enviadas entre o servidor de pagamento 3630 e os pares 3620através de uma rede pública. Vantajosamente, desde que uma ou mais re-des públicas são utilizadas, não existe taxa de intercâmbio, então o custopara os participantes pode ser grátis ou tão barato de modo a compreenderuma porcentagem insignificante das transações gerais conduzidas no siste-ma, especialmente comparado com a taxa de intercâmbio típica.
Como mencionado acima, as solicitações de transação são en-caminhadas para um servidor de pagamento 3630 através de uma rede pú-blica. Em uma modalidade, a rede pública 3625 é a Internet. Em uma outramodalidade, a rede pública 3625 é a rede de telefone celular. Em ainda umaoutra modalidade, a rede pública 3625 é uma rede de rádio e em ainda umaoutra modalidade, é a rede de telefone comutada pública ou PSTN. A redepública 3625 transfere as solicitações de transação do dono da conta para oservidor de pagamento 3630.
Em uma implementação, a conexão através da rede pública3625 é uma ligação segura que conta com participantes autenticados e crip-tografia. Assim, para conexões através da Internet, o protocolo de conexãopode ser HTTPS e a ligação pode ser uma rede particular virtual ou VPN. Oservidor de pagamento 3630 é também conectado nas contas de depósitovinculadas 3635 através da rede pública 3625 (não ilustrada) ou através deuma rede financeira ou bancária ACH proprietária.
A figura 37 é um diagrama de blocos de um sistema financeirode circuito fechado de acordo com uma modalidade da invenção. Mais espe-cificamente, a simplicidade da presente invenção provê a capacidade de serubíqua e prover grande valor para os donos de conta e comerciantes. Comopreviamente discutido, a presente invenção provê um serviço de transaçãofinanceira eletrônica barata para transações de consumidor para comercian-te e para transações de pessoa para pessoa. Essa flexibilidade é provida emparte pela interface de um telefone celular 3702 de um consumidor com umterminal de POS 3612. Em uma modalidade, o consumidor pode inserir oseu número de telefone em um teclado associado com o terminal de POS equando o total da transação fica disponível, o comerciante pode enviar umaSOLICITAÇÃO DE PAGAMENTO para o telefone celular 3702 por meio deuma conexão da Internet 3706 e servidor de pagamento 3704. O servidor depagamento 3704 chamaria o telefone celular 3702 e solicitaria que o consu-midor autorizasse a transferência de fundos. O consumidor então inseririaseu PIN ou outra identificação biométrica e confirmaria a quantia para autori-zar o pagamento. O servidor de pagamento 3704 transferiria os fundos daconta de débito pré-financiada do consumidor (mais quaisquer taxas de tran-sação) para a conta dos comerciantes (menos quaisquer taxas de transa-ção).
Em modalidades alternativas, o telefone celular 3702 inclui umcircuito de comunicação perto da esfera de ação (NFC), circuito Bluetooth oucircuito RFID (não mostrado) que possibilita que o terminal de POS 3712consulte e recupere a informação de conta, tal como o número de telefonedo telefone celular. Nessa modalidade, o comerciante detectaria automati-camente a informação da conta e enviaria a solicitação para o servidor depagamento 3704. O servidor de pagamento 3704 novamente chamaria otelefone celular 3702 para solicitar o PIN ou outra identificação biométrica eautorização de pagamento.
As transações de pessoa para pessoa eliminam o terminal dePOS do processo com cada par 3707 e 3708 contatando o servidor de pa-gamento 3704 diretamente para concluir a transação financeira.
A figura 38 é um diagrama de blocos da aplicação do clientemóvel (MCA) de acordo com uma modalidade da invenção. A MCA reside notelefone celular 3802 e compreende APIs da interface do usuário 3802 e3803 e uma API de pagamento 3805. A API 3802 provê ao usuário imagensde tela que guiam um dono de conta através de várias transações financei-ras tais como identificação da outra parte, a quantia da transação, se algumae o tipo de transações que estão disponíveis. A API 3803 provê para os pro-vedores de serviço ou outros parceiros de valor adicionado (tal como servi-ços de manutenção de contabilidade ou registro) um mecanismo para aces-sar a API de pagamento 3805 para adquirir informação para prover os servi-ços de valor adicionado. A API de pagamento 3805 provê, em uma modali-dade, a lógica para implementar a presente invenção e para fazer interfacecom a camada de comunicação 3810 do telefone celular.
Um método para operar uma infra-estrutura de transferência depagamento de acordo com uma modalidade da presente invenção é comoum sistema de pagamento de circuito fechado. Um sistema de pagamentode circuito fechado ocorre onde todos os componentes do processo detransferência de valor acontecem sob o controle da entidade que possui osistema de pagamento. Pelo fato de que o dono controla o sistema, a colo-cação de preço subjacente fica também sob o controle do dono.
A figura 39 mostra o fluxo de transação no sistema de pagamen-to de circuito fechado mostrado na figura 36. Especificamente, para umatransação de pessoa para pessoa, quando um pagamento é feito a partir deum dispositivo móvel 3901 para um outro dispositivo móvel 3901, a solicita-ção para a transferência é passada para o servidor de pagamento 3903. Asolicitação é indicada pela seta de referência 3904. O servidor 3903 acessaa razão T para o dono da conta associado com o dispositivo móvel 3901(como indicado pela seta de referência 3905) e transfere a quantia especifi-cada para uma razão T do recebedor (como indicado pela seta de referência3907) se certas regras de velocidade são satisfeitas em 3906. Depois que osfundos foram transferidos para o recebedor, como indicado por 3908, o ser-vidor 3903 envia uma mensagem de notificação para o recebedor como indi-cado em 3909. Finalmente, o dono da conta do pagador recebe uma men-sagem de confirmação do servidor 3903 que a transação foi concluída. Emuma modalidade, todo o sistema de circuito fechado é possuído por entidadeúnica. O sistema é provido ou carregado por donos de contas que negociamdólares para um saldo de conta mantido no servidor de pagamento (ver figu-ra 36).
Existem várias vantagens em um sistema de pagamento de cir-cuito fechado. A vantagem primária é que o dono do sistema é capaz decontrolar a colocação do preço para ambos o remetente e o recebedor e e-xiste uma oportunidade de ganhos por participação nos fundos carregadospara o sistema. O dono do sistema de pagamento é capaz de ganhar partici-pação sobre todos os fundos no sistema até que eles sejam convertidos oudescarregados de volta para dólares. À medida que mais funções são adi-cionadas, o sistema de circuito fechado se torna mais rentável devido a umaumento nas taxas e saldos.
As proposições de valor para o dono da conta participante inclu-
em:
(1) Segurança - o dinheiro do dono da conta fica bloqueado comsegurança no dispositivo móvel ao invés de ter que transportar dinheiro emum bolso ou bolsa,
(2) Garantia - verificação adequada para ver quanto dinheiro es-tá disponível na conta,
(3) Informação - atividade da conta e informação de saldo fáceisde obter,
(4) Conveniente - o dono da conta pode mover o dinheiro emsegundos por todo o mundo ou através de uma sala.
As proposições de valor para os comerciantes incluem:
(1) Segurança - sem dinheiro,
(2) Menor custo de manipulação - sem recibos de dinheiro paracontagem, sem papéis de depósito, sem fitas de máquina adicionais,
(3) Menos custos de transação - menores taxas do que os car-tões de crédito e
(4) Fundos garantidos - sem cheques retornados.
Parceiros comerciais têm uma oportunidade única para conse-guir renda por manipular transações direcionadas para depósito de fundosem uma conta de débito pré-paga ou para o provimento de dinheiro para umdono de conta. Os comerciantes podem ganhar comissões quando os fun-dos são adicionados em uma conta usando o seu terminal de POS.
O sistema de pagamento de circuito fechado independente dapresente invenção é projetado para integrar com uma conta bancária asso-ciada. Essa conta pode ser uma conta pré-existente ou, para usuários quenão têm uma conta bancária existente, um banco parceiro pode criar umaconta.
O sistema de circuito fechado mantém um banco de dados deperfil do usuário que inclui o nome do dono da conta e dados demográficos,informação usada para segurar o risco para cada dono de conta específico einformação de conta de banco vinculada para contas que serão usadas paracarregar ou descarregar fundos da conta de débito pré-paga. O banco dedados de perfil do usuário também requer um sítio da web de situação doserviço do consumidor e situação do consumidor para coleta dos dados dealistamento quando abrindo uma conta. Vantajosamente, o presente sistemade circuito fechado faz interface com o sistema de intercâmbio do cartão decrédito para acessar linhas de crédito disponíveis sob uma conta de cartãode crédito.
O servidor de pagamento mantém um registro de conta "T" paracada dono de conta. Essa conta é uma razão que acompanha as transaçõese saldos de cada dono de conta. Em conjunto com o banco de dados daconta Τ, o servidor de pagamento provê dados de história e saldo através dodispositivo móvel, bem como um sítio da web de situação de serviço do con-sumidor e do consumidor. O banco de dados da conta T é o registro emtempo real que registra as transações quando elas ocorrem. Isso significaque quando uma transação ocorre, o remetente dos fundos pode observar osaldo na sua conta imediatamente diminuindo enquanto o receptor pode ob-servar o aumento instantâneo no seu saldo de conta. Não existe ACH ououtro retardo relacionado com a transferência ao mover os fundos entre con-tas.
De modo a obter dinheiro para dentro e para fora do sistema depagamento de circuito fechado, a presente invenção provê três tipos de fun-ções para donos diferentes de conta.
Alguns donos de conta já terão uma conta bancária com umbanco que não é um parceiro. O sistema permite que donos de conta mo-vam os fundos para e dessa conta de banco através do sistema ACH. Devi-do ao risco envolvido, o usuário será submetido a controles de risco que po-dem incluir disponibilidade adiada dos fundos transferidos (por exemplo,uma transferência da sua conta bancária na segunda-feira pode não ser u-sada até quinta-feira). Esse tempo de adiamento poderia ser reduzido comseguro adicional (pesquisando relatórios de crédito ou obtendo declaraçõesfinanceiras). Uma redução no tempo de adiamento pode também ocorrerdevido ao usuário ter um bom registro de crédito com um portador parceiroou garantir os pagamentos com um cartão de crédito que é mantido em re-serva. Em geral, essa abordagem não é planejada para ser uma escolhaprimária devido ao risco envolvido com a transferência dos fundos de fora dosistema de transação financeira de circuito fechado a menos que exista umaportadora envolvida que possa entregar alguns dados de seguro e consumi-dores suficientes para justificar o seguro adicional.
Onde o dono da conta se alistou por causa de uma relação comum banco parceiro, uma conexão em tempo real para o sistema de contabili-dade de depósito por demanda (poupanças de conta corrente ou outra contatal como uma conta de mercado do dinheiro) possibilita que o dono da contaobtenha saldos e poste transações para a sua conta em tempo real.
Em outros casos, o dono da conta mantém uma conta com obanco Bancorp ou instituição financeira similar, que opera o banco, porémtodos os sítios da web, cheques e declarações do consumidor transportarãouma marcação de afinidade. Essa abordagem permite a marcação de afini-dade com uma conta de banco associada (a conta será grátis para o usuá-rio) em um ambiente firmemente integrado.
A figura 40 mostra uma estrutura de taxa exemplar para o siste-ma financeiro de circuito fechado de acordo com uma modalidade da inven-ção. Deve ser entendido que a estrutura de taxa pode variar e que a ilustra-ção apresenta uma estrutura típica para gerar a renda de operação. Devidoà natureza ubíqua da presente invenção, as taxas de transação podem sermuito baixas ou grátis. Assim, como indicado em 4001, para transações sobuma certa quantia de dólar, a taxa de transação é abandonada. Para ilustrar,considere uma transação financeira de $1 transferida em uma base de pes-soa para pessoa. Poderia não existir taxa de transação. Enquanto a quantiaem dólar onde uma taxa de transação pode ser cobrada pode ser ajustadaarbitrariamente, tipicamente a quantia em dólar será uma quantia que é me-nor do que $25. Donos de conta seriam autorizados com um número ilimita-do de tais transações em uma base mensal.
Para taxas de transação acima do máximo selecionado, o enviopelo dono da conta (iniciando uma transação de pagamento) incorreria emcertas taxas como indicado em 4002. Para ilustrar, para quantias de transa-ções que estão entre $50 e $100, o dono da conta incorreria em uma taxa detransação de $1,00, por meio de exemplo. Para quantias acima de umaquantia selecionada (tal como acima de $100), uma taxa mais alta pode sercobrada ou negociada. Essas taxas são consideravelmente menores do quea taxa por transação cobrada pelos emissores de cartão de crédito. Em umamodalidade alternativa, a taxa de transação pode ser uma quantia nominal,tal como um centavo, $0,05 ou $0,10, que é cobrado para o remetente.
Para transações que envolvem um comerciante, o comerciantepode opcionalmente se oferecer para pagar a taxa de transação que de ou-tra forma seria cobrada para o consumidor como indicado em 4003. Alémdisso, é cobrada do comerciante uma taxa adicional para receber os fundos.Novamente, a quantia real da taxa de transação do comerciante pode variar,mas em uma modalidade é um nominal de 1 por cento da quantia de transação.
Uma despesa de serviço mensal nominal, em uma modalidade,é adicionada nas faturas para o telefone celular usado pelo provedor do ser-viço móvel como indicado em 4004. O provedor do serviço móvel e o donodo sistema de transação financeiro de circuito fechado da presente invençãocompartilham a despesa do serviço mensal em uma base rateada.
Um sistema de pagamento suportado por membros é providopara consumidores e comerciantes sem taxas de alistamento, taxas de assi-natura ou taxas de transação para consumidores ou comerciantes. Em umaimplementação específica, o sistema de pagamento de membros é um sis-tema de pagamento móvel onde os consumidores podem conduzir as tran-sações usando um dispositivo móvel tais como um telefone móvel, telefoneinteligente, assistente digital pessoal ou dispositivo de mão sem fio portátilsimilar. Os comerciantes farão uma contribuição única restituível. Essas con-tribuições são armazenadas em uma conta de crédito em fundo comum pelosistema e os dividendos flutuantes ou participação nessas contribuições fi-nanciarão o sistema.
Em uma implementação específica, o sistema de pagamentosuportado por membros (MSPS) provê um sistema de pagamento comple-tamente gratuito para consumidores e comerciantes usando os princípiosseguintes:1. Sem taxas de alistamento para consumidores ou comercian-tes
2. Sem taxas de assinatura para consumidores ou comerciantes
3. Sem taxas de transação para consumidores ou comerciantes
4. Uma contribuição do comerciante única restituível é requerida.
5. A contribuição do comerciante única é colocada em fundocomum em uma conta de crédito do MSPS.
6. A conta de crédito do MSPS gera dividendos flutuantes queproveem a compensação para a companhia de processamento do MSPS e osistema.
7. Consumidores e comerciantes podem carregar e descarregarde uma conta de giro MSPS em fundo comum (separada da conta de crédi-to).
8. Os fundos disponíveis do consumidor são pré-pagos e per-manecem dentro da conta de giro MSPS em fundo comum.
9. O sistema MSPS gerencia a conta "T" (isto é, saldo, débitos,créditos) para contas de consumidor e comerciante.
Em uma modalidade, a invenção é um método incluindo: receberuma pluralidade de contribuições de comerciante para financiar um sistemade pagamento de membros, colocar as contribuições do comerciante emuma conta de crédito em fundo comum, onde os comerciantes não recebe-rão a participação nas suas contribuições, permitir que uma pluralidade deconsumidores se tornem usuários registrados do pagamento móvel semdespesa, permitir que usuários registrados carreguem ou descarreguem fun-dos em uma conta de giro do sistema de pagamento de membros sem des-pesa e permitir que comerciantes carreguem ou descarreguem fundos naconta de giro do sistema de pagamento de membros sem despesa, onde aparticipação na conta de crédito em fundo comum financia o sistema de pa-gamento de membros.
A figura 41 mostra uma operação de crédito de carga em umaimplementação do sistema de pagamento suportado por membros da inven-ção.A figura 42 mostra um registro de consumidor no sistema de pa-gamento suportado por membros.
A figura 43 mostra as operações de carga e descarga no siste-ma de pagamento suportado por membros.
A figura 44 mostra uma transação de compra no sistema de pa-gamento suportado por membros.
Em uma implementação, a contribuição do comerciante pode seruma paga em prestações através de um período de tempo. Dependendo daquantia da contribuição, o comerciante terá maior acesso ou privilégios nosistema. Por exemplo, podem existir níveis estabelecidos de contribuiçõesque correspondem com um número de transações que um comerciante teráautorização sem taxa adicional. Também, o comerciante pode fazer umacontribuição subseqüente para aumentar os privilégios do comerciante.
Em uma implementação, o sistema de pagamento de membrospermite que um usuário registrado solicite pagamento de dinheiro para umoutro usuário registrado via um telefone móvel. O sistema de pagamento demembros pode permitir que um usuário registrado solicite pagamento de di-nheiro para um comerciante via um telefone móvel.
O sistema de pagamento de membros pode gerenciar os regis-tros de transações dos usuários registrados. O sistema de pagamento demembros gerencia os registros de transações dos comerciantes. O sistemade pagamento de membros pode gerenciar os registros de transações dosusuários registrados e dos comerciantes. Isso reduzirá os custos para oscomerciantes desde que eles não precisam gerenciar os seus próprios regis-tros de transações.
A contribuição é restituível, então o comerciante pode decidirmais tarde não participar. Por exemplo, quando um comerciante solicita umreembolso da contribuição do comerciante para o sistema de pagamento demembros, os usuários registrados não mais terão permissão para transferirdinheiro para o comerciante.
De forma geral, o comerciante não é cobrado com uma taxa detransação recorrente periódica por ser um participante do sistema de paga-mento de membros. O sistema é financiado pela flutuação no crédito emconta comum contendo as contribuições do comerciante.
Os usuários registrados podem carregar ou descarregar fundospor meio de pelo menos uma entre a câmara de compensação automática(ACH) ou conta de depósito direto (DDA). Em implementações adicionais dosistema, os usuários registrados e os comerciantes podem ser providos comnumerosas maneiras adicionais para carregar e descarregar fundos. Por e-xemplo, um usuário registrado pode escolher ter o salário do usuário ou umaporção do salário diretamente depositada no sistema.
Em uma implementação, o método inclui: permitir que um usuá-rio registrado autorize o pagamento de um comerciante através do sistemade pagamento de membros usando um esquema de autorização de dois fa-tores. Esses dois fatores de autorização podem incluir: (1) o que a pessoatem (por exemplo, telefone, cartão) e (2) o que a pessoa sabe (por exemplo,PIN, nome de solteira da mãe, pergunta de desafio). Por exemplo, o sistemapode permitir que um usuário registrado autorize o pagamento de um co-merciante através do sistema de pagamentos de membros usando um tele-fone móvel do usuário registrado e o usuário corretamente inserindo um nú-mero de identificação pessoal ou PIN.
Opcionalmente, cada usuário registrado pode também ser provi-do com um cartão de débito. Com o cartão de débito, os usuários podemfazer cargas sem, por exemplo, um telefone móvel.
Contas em fundo comum virtuais
Com referência à figura 45, em uma implementação específicada invenção, para evitar manter razões gerais para cada banco, o sistemade pagamento móvel manterá uma razão geral para a conta em fundo co-mum virtual para cada país. Isso reduz os custos de quitação e operacionaisdo sistema. Desde que o dinheiro será mantido na conta em fundo comumvirtual, o dono da conta em fundo comum virtual (por exemplo, a operadorado serviço do sistema de pagamento móvel) receberá a flutuação ou partici-pação nesse dinheiro. O receptor da flutuação na conta em fundo comumvirtual pode distribuir algumas quantias para os bancos parceiros (que nãoestão mais recebendo a flutuação nas suas razões gerais).
Um método de distribuição dos fundos flutuantes é como segue:(a) As contas que são adquiridas pelo banco parceiro serão re-conhecidas como vindo desse banco. Por exemplo, se o banco Ci comercia-liza o serviço do sistema de pagamento móvel e recruta o consumidor A,então o consumidor A pela sua duração de vida será marcado como "recru-tado por Ci". Para cada registro de usuário (discutido em outro lugar nessepedido), pode existir um campo indicando de qual origem esse usuário parti-cular foi recrutado. Alguns exemplos de origens possíveis incluem o serviçode pagamento móvel diretamente, o banco parceiro, a instituição financeiraparceira e o provedor do telefone móvel parceiro.
No fim de cada dia, o serviço do sistema de pagamento móvelestimará a quantia de fundos mantidos nas contas do serviço do sistema depagamento móvel que são marcados como recrutados por cada banco par-ceiro. Vamos chamar essa quantia estimada como sendo X-Ci, X-BA, X-ING,onde Ci, BA e ING são exemplos de instituições financeiras ou bancos.
Por exemplo, na figura 45, o membro 6504044762 foi recrutadopelo primeiro banco Ci enquanto o membro 4154443214 foi recrutado peloterceiro banco BA. Nesse exemplo, os membros são identificados pelo nú-mero de telefone. Exemplos de números de telefone para os Estados Unidosincluem 4158675309 ou 2128675309. Em uma implementação da invenção,o formato do número do telefone pode ser inserido excluindo o código deárea, tal como 7762323 ou 5550123. Por exemplo, isso pode ser usado nasituação em que o receptor está no mesmo código de área que o remetente.O sistema preencherá os dígitos do código de área adicionais automatica-mente. Como foi dito em outro lugar nesse pedido, os membros podem seridentificados por outros tipos de identificadores, tais como nome de usuáriodo mensageiro instantâneo, endereço de e-mail, número do seguro social,número de licença de motorista, número da conta e outros.
(2) Vamos chamar o restante Y. Essa é a quantia estimada defundos a serem mantidos nas contas do serviço do sistema de pagamentomóvel que não foram marcados como recrutados. Essas são contas que fo-ram recrutadas pelos parceiros sem banco ou diretos do serviço do sistemade pagamento móvel. Na figura 45, isso é representado pelo número de tele-fone 6508622730 que é indicado como sendo recrutado pelo MSPS do se-gundo banco (o provedor do serviço do sistema de pagamento móvel).
(3) A cada dia, talvez em uma hora determinada, o serviço dosistema de pagamento móvel calculará os fundos apropriados a serem man-tidos em um banco parceiro. Por exemplo, isso pode ser de acordo com asegunda fórmula: X-banco parceiro mais uma porcentagem de Υ. A porcen-tagem será negociada no momento em que a parceria do banco é estabele-cida e dependerá do nível de gasto de mercadologia. Por exemplo, para Ci,o serviço do sistema de pagamento móvel colocaria 10 por cento de Y naconta do serviço do sistema de pagamento móvel para Ci. A porcentagempode ser qualquer porcentagem tal como 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12,13, 14, 15 ou outras. A porcentagem pode ser um número inteiro ou númerofracionário incluindo 1,1, 1,2 ,1,3, 1,5, menor do que 1, menor do que 2, me-nor do que 3, menor do que 6 e outros.
Esse método é planejado para evitar o custo de manter múltiplasrazões gerais e quitação líquida exata. Isso também proporcionará ao bancoparceiro mais do que sua parte justa dos fundos do serviço do sistema depagamento móvel.
Uma conta em fundo comum virtual é usada na operação de umsistema tendo múltiplos parceiros financeiros. Em uma implementação espe-cífica, o sistema é um sistema bancário móvel. Ao invés de manter razõesgerais separadas para cada instituição financeira, o sistema manterá umaconta geral em fundo comum virtual. Isso reduzirá os custos operacionais ede quitação do sistema. O dono da conta em fundo comum virtual receberá aflutuação na conta em fundo comum virtual, e essa flutuação será distribuídapara os múltiplos parceiros financeiros de acordo com uma fórmula.
Em uma modalidade, a invenção é um método incluindo: tratarde transações financeiras de um grupo de usuários do sistema, onde astransações financeiras podem ser especificadas através de telefones móveise subgrupos dos usuários são associados com uma instituição bancária;processar as transações financeiras associadas com uma primeira institui-ção bancária, onde os usuários em um primeiro subgrupo são associadoscom a primeira instituição bancária; processar as transações financeiras as-sociadas com uma segunda instituição bancária, onde os usuários em um segundo subgrupo são associados com a segunda instituição bancária; pro-cessar as transações financeiras associadas com uma terceira instituiçãobancária, onde os usuários em um terceiro subgrupo são associados com aterceira instituição bancária; manter uma conta em fundo comum virtual in-cluindo fundos para os usuários dos primeiro, segundo e terceiro subgrupos associados com a primeira, segunda e terceira instituições bancárias e dis-tribuir um primeiro dividendo para a primeira instituição bancária com basena flutuação para os fundos na conta em fundo comum virtual para os usuá-rios do primeiro subgrupo mais uma porcentagem da flutuação nos fundosna conta em fundo comum virtual para os usuários do terceiro subgrupo.
Em uma implementação, o método inclui distribuir um segundodividendo para a segunda instituição bancária com base na flutuação paraos fundos na conta em fundo comum virtual para os usuários do segundosubgrupo mais uma porcentagem da flutuação nos fundos na conta em fun-do comum virtual para os usuários do terceiro subgrupo. Em uma implemen- tação, o método inclui receber uma instrução de um primeiro usuário no pri-meiro subgrupo para transferir dinheiro para um segundo usuário no segun-do subgrupo, onde o dinheiro não é transferido para fora da conta em fundocomum virtual. A instrução pode ser enviada de modo sem fio de um telefo-ne móvel através da troca de mensagens SMS. A instrução pode ser envia- da de modo sem fio de um telefone móvel usando uma aplicação executan-do no telefone móvel.
A terceira instituição bancária pode ser um parceiro direto dosistema. Em uma implementação, o método inclui cada usuário ser associa-do com somente uma da primeira, segunda ou terceira instituições financei- ras. Em uma implementação, o método inclui gerenciar um sistema de regis-tro para conta em fundo comum virtual, onde o sistema de registro inclui re-gistros de transações para usuários no primeiro, segundo e terceiro subgru-pos.
Em uma modalidade, a invenção é um método incluindo: tratardas transações financeiras de um grupo de usuários de um sistema, onde astransações financeiras podem ser especificadas através de telefones móveise subgrupos dos usuários são associados com uma instituição bancária;processar as transações financeiras associadas com uma primeira institui-ção bancária, onde os usuários em um primeiro subgrupo são associadoscom a primeira instituição bancária; processar as transações financeiras as-sociadas com uma segunda instituição bancária, onde os usuários em umsegundo subgrupo são associados com a segunda instituição bancária; pro-cessar as transações financeiras dos usuários em um terceiro subgrupo quesão associados com o sistema e não a primeira e a segunda instituição ban-cárias; manter uma conta em fundo comum virtual incluindo fundos para osusuários do primeiro, segundo e terceiro subgrupos associados com a pri-meira e a segunda instituições bancárias e o sistema e distribuir um primeirodividendo para a primeira instituição bancária com base na flutuação para osfundos na conta em fundo comum virtual para os usuários do primeiro sub-grupo mais uma porcentagem da flutuação nos fundos na conta em fundocomum virtual para os usuários do terceiro subgrupo.
Em uma implementação, o método inclui distribuir um segundodividendo para a segunda instituição bancária com base na flutuação paraos fundos na conta em fundo comum virtual para os usuários do segundosubgrupo mais uma porcentagem da flutuação nos fundos na conta em fun-do comum virtual para os usuários do terceiro subgrupo. Em uma implemen-tação, o método inclui receber uma instrução de um primeiro usuário no pri-meiro subgrupo para transferir dinheiro para um segundo usuário no segun-do subgrupo, onde o dinheiro não é transferido para fora da conta em fundocomum virtual. A instrução pode ser enviada de modo sem fio de um telefo-ne móvel via troca de mensagens SMS. A instrução pode ser enviada demodo sem fio de um telefone móvel usando uma aplicação executando notelefone móvel. A instrução pode ser enviada através de um navegador daInternet.Em uma implementação, cada usuário é associado com somen-te um da primeira instituição financeira, segunda instituição financeira ou osistema. Em uma implementação, o método inclui receber uma instrução deum primeiro usuário no primeiro subgrupo para transferir dinheiro para umsegundo usuário no terceiro subgrupo, onde o dinheiro não é transferido pa-ra fora da conta em fundo comum virtual. Em uma implementação, o métodoinclui controlar um sistema de registro para conta em fundo comum virtual,onde o sistema de registro inclui registros de transações para usuários noprimeiro, segundo e terceiro subgrupos.
A figura 46 mostra um método para compra rápida de acordocom uma modalidade da presente invenção. Em uma modalidade, cartazes,anúncios de jornal ou comerciais de televisão incluem um mecanismo parapossibilitar que um comprador adquira detalhes específicos sobre um produ-to que é exibido no telefone celular. Esse mecanismo pode incluir códigos debarra impressos ou um número de telefone para discar para informação. Emuma outra modalidade, uma comunicação perto da esfera de ação é utilizadapara iniciar a conexão entre o comprador e um comerciante distante comoindicado em 4601. O início da conexão ativa a MCA de modo que se o com-prador decide fazer uma compra, a MCA fica desperta e uma conexão foiestabelecida como indicado em 4602. Pela seleção de uma opção de solici-tação de compra, como indicado em 4603, o comprador pode concluir umatransação de compra com o servidor de pagamento tratando dos detalhes talcomo o endereço de "envio" e transferência de fundos. Em um curto períodode tempo que poderia variar de uns poucos minutos a alguns dias, o produtopedido será entregue como indicado em 4604.
Em uma outra modalidade, o dono da conta tem a opção de se-lecionar uma "entrega para a localização geográfica corrente" ao invés de oendereço de faturamento do dono da conta. Esse aspecto é desejável parti-cularmente quando o dono da conta está viajando e deseja fazer o pedido apartir de um menu de serviço do local, mas não deseja falar com ninguém.Nesse caso, o menu incluiria um dispositivo de comunicação perto da esferade ação de modo que o dono da conta precisasse somente selecionar a soli-citação de compra e o alimento seria entregue para o lugar onde o dono daconta está localizado.
A figura 47 mostra ainda um outro aspecto de compra rápida deacordo com uma modalidade da presente invenção. Nessa modalidade, umdono de conta conta com um pagamento de ocorrência periódica para umproduto ou um serviço. Para ilustrar, considere o trabalhador típico que todamanhã pára para comprar um jornal antes de embarcar em um trem para acidade. Com a modalidade ilustrada na figura 47, o dono da conta poderiaconfigurar uma conta pré-autorizada para tais pagamentos de ocorrênciaperiódica como indicado em 4701. A conta pré-autorizada poderia incluir otipo do produto ou o serviço que pode ser obtido, como indicado em 4702,bem como a quantia de compra permissível máxima a ser pré-autorizada,como indicado em 4703. Assim, quando o trabalhador pega o jornal, umaantena perto da esfera de ação detecta a informação da conta no telefone eenvia a quantia da transação para o servidor de pagamento que enviariauma confirmação de volta para o comerciante sem ter que aguardar que oconsumidor verifique e especificamente autorize a transação financeira comoindicado em 4704. Esse aspecto é também um método importante para ace-lerar o processo de compra para transações financeiras com tempo crítico,tal como quando um trabalhador deseja comprar um bilhete de metrô usandoo seu telefone celular à medida que ele anda através de uma borboleta. Aquantia pré-autorizada pode ser deduzida em tempo real ou processada co-mo uma transação financeira em lote, por exemplo, em uma base horária.
Para minimizar o tempo de processamento da verificação, o co-merciante pode ser notificado da pré-autorização antes do uso esperado.Com a recepção da pré-autorização, o número do telefone pode ser coloca-do em uma "lista verde" que indica que o comerciante pode aceitar paga-mento sem verificação do servidor de pagamento. A lista verde é armazena-da nos terminais de POS ou fica acessível para os terminais de POS a partirde um servidor local ao invés de a partir do servidor de transação.
Se uma conta pré-autorizada está sem saldo e o dono da contanão reabasteceu apropriadamente a conta, o número telefônico pode sercolocado em uma "lista vermelha" e proibido de uso futuro do serviço. A listavermelha pode também ser armazenada localmente pelo comerciante noPOS ou armazenada em um servidor local acoplado no equipamento dePOS. Se um número de telefone é incluído na lista vermelha, o comerciantepode aceitar uma forma alternativa de pagamento. Alternativamente, o servi-dor pode negar o serviço e enviar uma mensagem sugerindo que o dono daconta aproveite essa oportunidade para recarregar a conta do dono da con-ta. O comerciante pode aceitar o pagamento de recarga e coletar a taxa deincentivo para receber os fundos para recarga da conta do dono da conta.
A fim de acelerar as compras pré-autorizadas, em uma modali-dade, o telefone celular inclui um código de barras externamente visível quepode ser escaneado no POS para iniciar e concluir uma transação. Alternati-vamente, o código de barras pode ser exibido na tela do telefone celular eescaneado no POS. Pelo fato de que velocidade e conveniência são tão im-portantes para muitas compras diárias, o código de barras, junto com a listaverde localmente em cache possibilita que os comerciantes aceitem a com-pra "instantaneamente" e a seguir submetam a transação em um modo delote em intervalos selecionados.
Uma vantagem para o dono da conta é que se o telefone celularé perdido, a pré-autorização pode ser rapidamente suspensa acessandouma página da web para atualizar o perfil do usuário ou chamando o serviçodo consumidor. Se um telefone é relatado como perdido, novas listas verdee vermelha são imediatamente distribuídas para os comerciantes afetados,dessa maneira limitando as perdas potenciais para o dono da conta e o co-merciante. Comparar com a perda de um passe de trânsito mensal pré-pagoque é perdido - se perdido, todo o valor do passe é também perdido e a pes-soa que acha se aproveita dos benefícios do achado. Assim, as listas verdee vermelha são uma ferramenta efetiva para prevenir a fraude através doroubo ou perda do telefone com relação às contas pré-autorizadas.
Desde que cada telefone celular em uso atualmente não é equi-pado com aplicação, o servidor de pagamento se adapta ao nível de serviçodisponível para cada dono de conta. Um método para comunicar mensagensentre dispositivos de telefone celular é transmitir e receber usando o serviçode mensagem curta, que é também geralmente citado como uma "troca demensagem de texto SMS" ou simplesmente SMS, porque a maior parte dosdispositivos móveis suporta SMS. SMS é um mecanismo para entregarmensagens curtas através de redes móveis. Essa é uma maneira precisa edireta de transmissão de mensagens para e dos móveis. A mensagem (textosomente) do móvel emissor é armazenada em um servidor associado com osistema de transporte SMS que então a envia para o móvel de destino emum momento posterior. Isso significa que se o receptor não está disponível,a mensagem é armazenada e enviada mais tarde. Desde que o SMS usacanal de sinalização em oposição a canais dedicados, essas mensagenspodem ser enviadas/recebidas simultaneamente com o serviço de voz atra-vés da rede móvel. Com as redes móveis baseadas em todas as três tecno-logias celulares, com GSM, CDMA e TDMA suportando SMS, SMS é agoraum serviço de dados móvel amplamente disponível.
Com SMS, um agregador de SMS encaminha as mensagensentre o servidor de pagamento e o dono da conta em tempo real e os fundosficam imediatamente disponíveis para uso pelo receptor. Se a transação fi-" nanceira inclui uma outra parte, o servidor também usa SMS para se comu-nicar com a outra parte em tempo real novamente usando o agregador deSMS. SMS é um mecanismo particularmente importante quando um donosem conta é o receptor de uma transferência de pagamento de um dono deconta. Um problema para o dono sem conta é a ausência da MCA embutidano seu telefone, então SMS é um mecanismo para comunicação com o donosem conta. A MCA gerencia e insere um número de transação que incluichaves inalteradas que tornam o número de transação único para os servi-ços de dados SMS, HTTP e mensagens de protocolo HTTPS, mas não exis-te número de transação quando usando SMS manual.
Um sistema de transação financeira móvel SMS evita a despesae os problemas associados com ter um circuito integrado especial (isto é, umdispositivo de circuito integrado) adicionado somente para suportar e habili-tar a funcionalidade financeira de um dispositivo. A adição de componentesadicionais em um telefone celular ou outro dispositivo móvel aumenta oscustos para a fabricação e suporte no campo. Custos são também aumenta-dos se o uso do circuito integrado exige taxas de licenciamento ou outrastaxas proprietárias. Além do que, adicionar um circuito integrado no telefonecelular aumenta o consumo de potência e diminui a duração da bateria -ambos tendo conseqüências negativas para os dispositivos móveis, tal comotelefones celulares.
Embora a troca de mensagem de texto SMS funcione bem coma maior parte de todos os tipos de dispositivos celulares e certos outros tiposde dispositivos de comunicação móvel, tal como assistentes digitais portáteisou PDAs, SMS expõe senhas não criptografadas ou números de identifica-ção pessoal (PINs), bem como informação de saldo ou detalhes sobre atransação mais recente. Desde que qualquer pessoa em posse do telefonepode ler o arquivo da mensagem SMS e imediatamente saber como acessara conta de uma outra pessoa, a presente invenção dessa maneira, em umamodalidade, provê a iniciação da transação financeira por meio da mensa-gem de texto SMS com uma porção da transação concluída através de umcanal de voz.
A figura 48 é uma ilustração do nível do sistema de uma transa-ção financeira executada por pelo menos um mecanismo de troca de men-sagens SMS de acordo com uma modalidade da presente invenção. Essemétodo de transação é usado onde nenhum telefone celular é habilitado naInternet. Além do que, nenhum telefone celular carece de uma MCA incorpo-rada, então a troca de mensagens SMS é utilizada para tratar da transação.Alguém versado na técnica verificará que se um dos telefones fosse habilita-do pela Internet e tivesse instalado a MCA, então o seu lado da transaçãoocorreria através de uma ligação HTTPS e a comunicação com o outro tele-fone seria por meio da troca de mensagem SMS. É para ser entendido queHTTPS se refere ao protocolo de transferência de hipertexto através da ca-mada de soquete segura ou HTTP sobre SSL e que a ligação é uma ligaçãoda Internet. Será também verificado que a conexão da Internet provê umainterface de usuário muito mais rica, é mais segura e é mais fácil de iniciar econcluir uma transação financeira. Quando HTTPS não está disponível, aMCA pode adaptar a transação para usar o protocolo HTTP, um mecanismode transporte menos seguro. Nesse caso, a conta pode invocar a criptografiade software antes de inserir a informação de transação antes de enviá-lapara o servidor.
Se uma conexão da Internet não está disponível, o uso dasmensagens SMS (ou serviço de mensagem curta) é usado em uma modali-dade. Em uma modalidade, a aplicação do cliente móvel utiliza a função dosserviços de dados para enviar mensagens SMS binárias. Em uma outra mo-dalidade onde a aplicação do cliente móvel não está disponível, mensagensSMS de texto simples são usadas para conduzir transações financeiras comarranjos especiais sendo adotados para proteger a integridade do PIN. Serátambém ainda verificado que a carência da aplicação do cliente móvel tam-bém limita as capacidades de interface do usuário, então o usuário pode ob-ter satisfação limitada da presente invenção, mas, de outra forma, entretan-to, aproveitaria os aspectos e benefícios completos do sistema de transaçãofinanceira atual.
Com a presente invenção, a aplicação do cliente móvel selecio-na o modo para transmitir a transação financeira para o servidor 4804 (tam-bém citado como o processador de transação). Por exemplo, se uma cone-xão da Internet está disponível, a transação é conduzida usando uma liga-ção HTTPS, que é um protocolo da web que criptografa e decriptografa soli-citações de página do usuário bem como as páginas que são retornadaspelo servidor 4804. Para usar a Internet, o dono da conta meramente insereos detalhes da transação em uma página da web e seleciona "enviar" parainiciar a transação. Se uma outra parte está envolvida e essa parte tem umdispositivo habilitado na web, os detalhes da transação são providos emuma página da web. Nessa modalidade, o servidor 4804 funciona como umservidor da web.
Tipicamente, nem todos os donos de conta têm um telefone ce-lular ou dispositivo habilitado na Internet. Portanto, a presente invenção pro-porciona outros métodos para conduzir as transações financeiras a partir dotelefone celular. Tais métodos incluem o uso de serviços de dados SMS,textos simples em SMS (ambos os quais podem utilizar um canal de voz pa-ra transmitir o PIN) ou canal de voz somente.
Para um telefone celular capaz de SMS, o dono da conta trans-mite uma mensagem SMS através da porta SMS 4802 para o servidor 4804para iniciar uma transação a partir do seu telefone celular 4806 como indica-do pela seta de fluxo 4810. A porta 4802 retransmite a mensagem SMS parao servidor 4804 como indicado pela seta de fluxo 4811. Com a recepção damensagem SMS, o servidor 4804 adota a ação especificada solicitada namensagem e envia uma mensagem SMS de resposta para a porta 4802 co-mo indicado pela seta de fluxo 4812. A porta 4802 retransmite a mensagemSMS de resposta para o telefone celular 4806 como indicado pela seta defluxo 4813. Essa seqüência de eventos pode prosseguir por várias iteraçõesaté que uma transação financeira esteja completa. As mensagens SMS po-dem ser transportadas entre telefones e porta 4802 por qualquer rede decircuito comutado ou pacote comutado.
Em algumas modalidades, um canal de comunicação por voz éestabelecido como evidenciado pelos canais de voz 4815 e 4835. Quandouma mensagem SMS inicial é recebida do telefone 4806, o servidor 4804pode abrir o canal de voz 4815 discando o número do telefone associadocom a conta. Um caso onde o canal de voz 4815 é usado é para obter umPIN (recebido como DTMF ou dados de voz) para completar o processo deverificação e autenticar o usuário como o dono da conta em resposta a umamensagem SMS. DTMF refere-se a múltiplas freqüências de tom duplo, osinal que uma companhia de telefone recebe quando as teclas de toque dotelefone são pressionadas.
A mensagem SMS inicial começa com uma palavra-chave queprovê o tipo de transação solicitada - PAGAMENTO, SOLICITAR PAGA-MENTO, SALDO, TRANSFERÊNCIA õuÃJÜDÃ. Onde a mensagem SMScontém a palavra chave que indica o desejo de transferir fundos de um donode conta para um outro, a palavra-chave seria pagamento ou solicitar paga-mento. Depois da palavra-chave, a quantia é inserida com ou sem um pontodecimal. Depois da quantia, o número do telefone alvo (ou código curto, en-dereço de e-mail ou outra informação de identificação) é inserido. Essa in-formação pode ser obtida automaticamente do diretório de telefone do dis-positivo móvel. Depois do número de telefone, o dono da conta pode inseriruma mensagem em um campo de mensagem para exibição para a outraparte. Em algumas circunstâncias, essa mensagem pode ser uma mensa-gem nula. Em algumas modalidades, o dono da conta pode também inseriruma mensagem complementar para finalidades de manutenção de registro.Um código especial no campo de mensagem delineia a mensagem comple-mentar para indicar que o texto seguinte ao código especial é particular enão para ser enviado. Exemplos de código especial representativo podemser */* ou I-I ou outros códigos únicos definidos pelo usuário.
Depois que a mensagem SMS é enviada para o servidor, o PINé inserido pelo dono da conta e enviado através de uma conexão de canalde voz para o servidor de pagamento para verificar a mensagem SMS. OPIN é inserido através do teclado e pode ser qualquer código alfanumérico.O PIN é então enviado para o servidor de pagamento como uma mensagemcodificada em DTMF.
No servidor, o servidor recebe a mensagem SMS através da tra-jetória de comunicação da mensagem de texto SMS e o PIN através do ca-nal de voz. A chamada para o servidor pode ser feita pelo dono da conta ouela pode ser iniciada como um aspecto de "chamada de autenticação" peloservidor de pagamento em resposta à recepção da mensagem SMS. É de-sejável que o PIN seja enviado como uma mensagem codificada em DTMFpara manter a segurança, embora em outras modalidades, o PIN pode serfalado pelo dono da conta e convertido por um módulo de software de reco-nhecimento de voz interativo operando no servidor de pagamento ou um ou-tro servidor (não mostrado) dedicado ao tratamento das chamadas de voz.
Para ilustrar, considere o processo que ocorre quando o dono daconta usando o telefone celular 4506 solicita um saldo de conta usando umamensagem SMS endereçada para o servidor 4504. A mensagem SMS éformatada pelo usuário para incluir o tipo de transação financeira solicitada,isto é, SALDO (uma forma curta aceitável da solicitação pode ser SAL ousimplesmente S), e o número do telefone associado com a sua conta, porexemplo, 4088675309 (por exemplo, o número do telefone da Jenny). Alter-nativamente, o número da conta pode ser determinado usando o ID do cha-mador.
Quando o servidor 4804 recebe a mensagem SMS, ele inicial-mente verifica o número de seqüência ou de transação, (ver, por exemplo,figuras 54, 55 e 56). Se o número de seqüência está correto, o servidor 4804disca o número do telefone associado com a conta e solicita que o usuárioinsira um PIN. Em outras modalidades, o PIN é incluído na mensagem SMSoriginal de modo que não existe necessidade de chamar o dono da contapara verificação. Se o telefone celular 4806 é suficientemente configuradocom uma aplicação de cliente móvel, é possível criptografar a senha antesde incluí-la na mensagem SMS. A aplicação do cliente móvel usará serviçosde dados. O aspecto negativo do uso da mensagem SMS para transportar oPIN é que esse número secreto ficará visível para qualquer um que tenhaacesso ao telefone e poderia levar ao uso desautorizado por um dono semconta.
Se o PIN está correto, o servidor 4804 trata da transação solici-tada. O usuário pode escolher receber a informação solicitada por respostade voz através de canal de voz 4815 ou por mensagem SMS de retorno emcujo caso o servidor envia uma mensagem com a quantia do saldo para aporta 4802 que por sua vez a envia para o telefone celular 4806.
Em outras transações financeiras, existem dois telefones celula-res 4806 e 4808 envolvidos. Esses tipos de transações financeiras tipica-mente têm um dono da conta transferindo fundos para um recebedor quepode ser um dono de conta associado com o telefone celular 4808. Em ou-tras transações, o recebedor é um dono sem conta.
Como com a solicitação de SAL, uma solicitação para PAGA-MENTO do usuário do telefone celular 4808 é iniciada usando uma mensa-gem SMS endereçada para o servidor 4804. A mensagem SMS é formatadapara incluir o tipo de transação financeira solicitada, isto é, PAGAMENTO eo número do telefone do recebedor (por exemplo, 2127875466) e o númerodo telefone associado com a sua conta (novamente, por exemplo,4088675309). Se o telefone do dono da conta suporta a aplicação do clientemóvel, então todas as mensagens SMS trocadas entre o telefone celular 4806 e o servidor 4804 podem ser criptografadas para segurança adicional.
Quando o servidor 4804 recebe a mensagem SMS, ele inicial-mente verifica o número de seqüência ou transação (se disponível) e pros-segue somente se o número de seqüência está correto ou está indicado co-mo indisponível no registro de conta mantido pelo servidor. O servidor 4804então recebe e determina se o PIN está correto. Se ambos o número de se-qüência e o PIN estão corretos, o servidor 4804 trata da transação solicitadadebitando a conta associada com o dono da conta (por exemplo, ver figura43) e enviando uma mensagem SMS de confirmação para o dono da contaatravés da porta 4802.
Se o recebedor 4808 é um dono de conta, o servidor 4802 tam-bém envia uma mensagem de confirmação confirmando a recepção dosfundos. Se o telefone celular é um PDA móvel ou outro dispositivo habilitadoem IP1 a mensagem é enviada por HTTPS e pode ser criptografada paragarantir a segurança. A criptografia pode ser qualquer método conhecido.
Se o recebedor 4808 é um dono de conta com a aplicação docliente móvel instalada, a aplicação do cliente móvel pode criptografar assuas mensagens antes de enviá-las para o servidor 4804 e receber a men-sagem criptografada do servidor 4804.
Se o recebedor 4808 é um dono de conta, mas o telefone celular não suporta o carregamento e a execução da aplicação do cliente móvel notelefone celular, então as mensagens do servidor 4804 serão em texto sim-ples. O aspecto negativo do uso da mensagem SMS de texto simples paratransportar o PIN é que esse número secreto ficará visível para qualquer umque subseqüentemente obtenha acesso ao telefone. Isso poderia levar ao uso desautorizado por um dono sem conta a menos que o dono da contaperca tempo excluindo as mensagens SMS da sua caixa de correio do tele-fone celular. Se o recebedor 4808 não é um dono de conta, então as men-sagens SMS também será uma mensagem de texto simples.
Embora a troca de mensagens de texto SMS funcione bem comtelefones celulares e certos outros tipos de dispositivos de comunicação mó-vel, tal como assistentes digitais portáteis ou PDAs, SMS expõe senhas nãocriptografadas ou números de identificação pessoal (PINs), bem como a in-formação de saldo ou detalhes confidenciais sobre a transação mais recen-te. Desde que qualquer um em posse do telefone pode ler o arquivo damensagem SMS e imediatamente saber como acessar a conta de um outroe a outra informação confidencial, é melhor evitar usar as mensagens SMSpúblicas para transmitir o PIN.
Assim, para o dispositivo móvel emitido por um provedor de ser-viço parceiro, é desejável que os dispositivos móveis incluam a aplicação docliente móvel como um módulo de software pré-existente. Alternativamente,a aplicação do cliente móvel é preferivelmente carregável do provedor deserviço para telefones celulares que não eram originalmente equipados coma aplicação do cliente móvel. A aplicação do cliente móvel possibilita melho-ras significativas ao uso do sistema de transação financeira. A aplicação docliente móvel é invocada, diretamente pelo dono da conta ou em resposta àativação do aspecto da troca de mensagens de texto SMS no dispositivomóvel.
O seguinte é uma descrição detalhada ilustrando o uso da trocade mensagens de texto SMS para prover acesso pelos donos da conta aoservidor de pagamento a partir de qualquer telefone móvel capaz de SMS ououtro dispositivo habilitado em SMS em uma modalidade onde a aplicaçãodo cliente móvel está disponível.
Em operação, o dono da conta envia uma mensagem de textopara o servidor 4804 usando a capacidade de mensagem de texto existenteno seu telefone. A funcionalidade inclui pagamento, solicitar pagamento, sal-do, história e ajuda invocados pelo uso de qualquer um desses aspectoscomo uma palavra-chave. O dono da conta insere a palavra-chave junto cominformação adicional no corpo da mensagem de texto para construir um co-mando que é então enviado para o servidor. O acesso ao servidor pode serpor meio de um número de telefone gratuito, um código curto ou um endere-ço de e-mail, todos os quais identificam o servidor para a porta SMS. Umexemplo de um código curto é 62729 que é usado como o número de telefo-ne alvo para seus comandos de mensagem de texto para o servidor de pa-gamento. Um exemplo de um endereço de e-mail é sms@obopay.com, queé o e-mail alvo para os comandos de mensagem de texto SMS enviados pa-ra o servidor.
Para enviar um pagamento para uma outra pessoa ou um co-merciante usando o método SMS, o dono da conta inseriria a seqüência decomando mostrada na tabela C.
Tabela C
<table>table see original document page 129</column></row><table>
Cada item deve ter um espaço entre ele e o item prévio. Em umaimplementação, a palavra-chave não é sensível ao caso. O número móveldeve incluir o código de área mais o número móvel sem espaços presentesno número móvel. O dono da conta pode inserir um 1 na frente ou não donúmero de telefone. Um sinal de dólar não precisa ser inserido com a quan-tia, mas deve ser permitido. O usuário pode incluir opcionalmente uma men-sagem com o seu pagamento. A MCA criptografa a mensagem e envia comouma mensagem SMS dos serviços de dados em texto binário ao invés desimples.
Em um exemplo alternativo, o PIN é enviado em uma segundamensagem por meio de uma chamada de voz. Para enviar um pagamentopara uma outra pessoa ou um comerciante usando o método combinado deSMS mais canal de voz, o dono da conta inseriria a seqüência de comandomostrada na tabela D.
Tabela D
<table>table see original document page 129</column></row><table>
Com a recepção da mensagem SMS, o servidor 4804 chama otelefone celular associado com a mensagem SMS para estabelecer um ca-nal de voz para adquirir o PIN. O PIN é enviado para o servidor 4104 atravésdo canal de comunicação por voz 4815 - isto é, a rede celular. Em modali-dades alternativas, o PIN é enviado através da Internet ou POTS.
Quando uma solicitação por pagamento é feita para um dono deconta usando o método SMS ou o método combinado de SMS mais voz, elepode aceitar ou rejeitar a solicitação usando o sistema de troca de mensa-gens de texto SMS manual.
No lado do servidor, um ou mais centros de dados teriam siste-mas para processar as transações financeiras. Cada centro de dados conte-ria uma combinação de tecnologia de PBX/ACD/VRU para permitir múltiplosprocessamentos de chamada simultâneos. A tecnologia VRU pode ser usa-da para prover suporte DTMF que chega e que sai programável. O VRU po-de ser conectado em um sistema J2EE empreendedor que representa a ló-gica de negócios atual e o sistema de registro para as transações financei-ras. O sistema J2EE pode então integrar com bancos reais para quitaçãodas transações.
Vantajosamente, a aplicação do cliente móvel determina um mé-todo preferido, ou melhor, para enviar o PIN tal como pela aplicação SMS(serviços de dados) onde a mensagem SMS é criptografada e convertidapara binária (isto é, a mensagem não é transmitida em texto simples) ou porcanal de voz usando DTMF para manter a segurança. Em outras modalida-des, o PIN pode ser falado pelo dono da conta e convertido por um módulode software de reconhecimento de voz interativo operando no servidor ouum outro servidor (não mostrado) dedicado para lidar com as chamadas devoz.
Em uma modalidade alternativa, o PIN é criptografado pela apli-cação do cliente móvel e incluído em uma mensagem SMS subseqüente queé enviada para o servidor 4804. O servidor 4804 correlaciona as mensagenscomparando o número de telefone e o tempo que cada mensagem foi envia-da. Se o PIN foi enviado em uma mensagem que estava distante no tempocomparada com a mensagem SMS, a transação pode ser rejeitada. Se so-mente uma das duas mensagens é recebida, a transação pode ser rejeitada.Se, entretanto, ambos a mensagem SMS com os detalhes da transação fi-nanceira (mínimo de em uma palavra-chave) e o código PIN são adequada-mente recebidos e são verificados, então a transação financeira prossegue.
Em uma modalidade alternativa, quando um canal de voz estádisponível, a aplicação do cliente móvel pode invocar um módulo para codifi-car o PIN na forma DTMF. O DTMF é então enviado pela MCA para o servi-dor de pagamento junto com uma conexão de canal de voz estabelecida pe-la aplicação do cliente móvel. O módulo pode ser uma API Java que gera ostons apropriados com base na entrada do teclado. DTMF se refere à múltiplafreqüência de tom duplo, o sinal que uma companhia de telefone recebequando as teclas de toque do telefone são pressionadas.
Em ainda uma outra modalidade alternativa, a aplicação do cli-ente móvel provê uma interface do usuário (UI) na tela de exibição do dispo-sitivo móvel para guiar o dono da conta para concluir a transação financeira.Nessa modalidade, o dono da conta é guiado através do processo de cons-trução da mensagem de texto SMS pela inserção automática da palavra-chave, quantia, número de telefone alvo, senha e mensagens, se alguma.
Em ainda uma outra modalidade alternativa, a mensagem SMSpode incluir a palavra-chave, a quantia, o número do telefone alvo e a senha.Um defeito dessa implementação é que a senha ficaria visível para qualquerpessoa que controle o dispositivo móvel. Entretanto, a presente invençãolida com esse problema enviando uma mensagem para o dono da conta de-letar a mensagem enviada da pasta de registro de SMS no telefone do donoda conta. A mensagem pode também sugerir que o dono da conta desligue oregistro de mensagens das mensagens SMS que saem quando conduzindoa transação financeira usando o aspecto de SMS no futuro.
Ao invés de usar mensagens SMS de texto simples, a presenteinvenção também considera uma modalidade usando APIs JAVA carregadaspara o telefone celular para conduzir as transações financeiras. As APIs JA-VA geram telas de interface do usuário para guiar o usuário na preparaçãoda solicitação da transação. O formato da mensagem é similar a esse ilus-trado na tabela C ou tabela D.
Depois que o dono da conta concluiu a solicitação da transação,o usuário seleciona uma opção ENVIAR apresentada na interface do usuá-rio. As APIs JAVA iniciam uma chamada de voz usando a conexão do tele-fone celular para acessar um módulo de reconhecimento de voz interativo(IVR) ou interface DTMF no servidor 4804. Quando a interface DTMF captaa chamada, as APIs JAVA transmitem a solicitação de transação usandotons DTMF. As APIs JAVA podem também usar uma forma de criptografia,de modo que os tons DTMF não são facilmente decifráveis caso eles sejamgravados clandestinamente. Quando o IVR prove uma resposta para a solici-tação da transação, a resposta é também criptografada e a seguir codificadausando DTMF e transmitida através do canal de voz de volta para a parteapropriada. Devido aos aspectos de segurança aumentados das APIs JAVA,essa modalidade é comparada ao envio de SMS de texto simples.
Portanto, a comunicação pode ser por meio de um canal de voze tons DTMF. Isso prove um canal de comunicações adicional (além doSMS, serviços de dados ou aplicação de SMS, HTTP e HTTPS) para execu-tar as transações. Por ter muitos canais de comunicações, isso provê maiorconfiabilidade no sistema porque qualquer canal pode ser usado quandooutros canais não estão disponíveis.
A figura 49 mostra um método para garantir as transações finan-ceiras com base em SMS de acordo com uma modalidade da presente in-venção. Mais especificamente, para os dispositivos móveis, tal como telefo-nes celulares GSM, a instalação de uma MSA no telefone envolve a inserçãofísica de uma pequena placa de circuitos, citada como o gerador do númerode transação e criptografia ou simplesmente como gerador 4902, para inter-ceptar o tráfico de mensagem SMS.
O gerador 4902 compreende um circuito elétrico que é inseridono telefone eletricamente conectado no cartão SIM 4903. Em uma modali-dade, o gerador 4902 é uma conexão que é inserida ao redor do cartão SIM4903. Alternativamente, o gerador 4902 é um calço que é interposto entre omódulo de transmissão do telefone celular 4904 e o cartão SIM 4903. O car-tão SIM 4903 é o cartão do módulo de identidade do assinante, que é umcartão eletrônico que é inserido em um telefone celular ou outro dispositivomóvel baseado em GSM, GPRS ou 3G e identifica o assinante para a rede.
Embora cartões SIM sejam mais amplamente usados nos siste-mas GSM, módulos compatíveis são também usados para as UEs UMTS(USIM) e telefones IDEN. O cartão SIM 4903 contém o número de identifica-ção pessoal do assinante, informações tais como o número de telefone dousuário, livro de endereços, mensagens SMS bem como outras informaçõesrelacionadas com o assinante.O gerador 4902 intercepta as mensagens SMS que chegam pro-curando mensagens do servidor 1004 (ver figura 48). Quando o gerador4902 detecta uma mensagem SMS enviada pelo servidor 4804, ela funcionana maneira da aplicação do cliente móvel decriptografando a mensagem doserviço de dados SMS e apresentando uma mensagem de texto simples pa-ra o dono da conta.
O gerador 4902 também intercepta as mensagens SMS que sa-em que são almejadas para o servidor 4804. Novamente, o gerador 4903funciona para prover os serviços da aplicação do cliente móvel adicionandoum número de transação em cada transação e criptografa a mensagemSMS. Pelo fato de que o gerador 4902 contém um módulo de software em-butido, ele pode enviar a mensagem SMS como uma mensagem SMS doserviço de dados ao invés de texto simples.
O gerador 4902 é planejado para ser vendido ou de outra formaprovido como um componente separado permitindo que telefones celularesnão equipados com MCA aproveitem as vantagens de ter a aplicação docliente móvel residente no telefone celular. Em outras modalidades, o SIM4903 inclui o gerador 4902 como um circuito a bordo e é provido para o usu-ário pelo provedor de serviço do telefone celular.
A figura 50 mostra o uso de um servidor de agregação SMS se-guro de acordo com uma modalidade da presente invenção onde o gerador4902 também redireciona as mensagens SMS que saem para um servidorde agregação de SMS seguro 5011 ao invés de para o servidor SMS padrãodo provedor de serviço. O envio de mensagens SMS contendo informaçãode transação financeira para o servidor de agregação SMS seguro minimizaa oportunidade de roubo de dados, reduz a ocorrência de mensagens retar-dadas ou perdidas devido ao carregamento excessivo no servidor de SMS5010 e melhora o controle geral sobre o sistema de entrega de mensagens.
Fazer referência agora à figura 51 que mostra um processo deregistro para um novo dono de conta de acordo com uma modalidade dapresente invenção. Quando o recebedor de fundos não é ainda um dono deconta, uma modalidade da presente invenção invoca uma forma viral da a-quisição do novo consumidor onde os donos de conta existentes trazem pa-ra dentro novos donos de conta simplesmente enviando fundos para os re-cebedores sem conta. O recebedor sem conta recebe uma mensagem SMSdeclarando que ele tem fundos disponíveis e o convidando para se registrarpara ter acesso aos fundos como indicado em 5101. Um endereço da web éprovido.
O registro pode ocorrer em qualquer parceiro bancário ou emlinha em uma página da web acessada através da Internet como indicadoem 5102. O processo de registro possibilita que o recebedor abra uma contade débito pré-financiada (usando os fundos transferidos). Esse processo ésimilar à abertura de qualquer outra conta bancária, exceto que não existesaldo mínimo de conta, então, até mesmo indivíduos que não se qualificampara uma conta corrente ou de poupança em um banco podem participar.
Depois de registrado, o novo dono da conta tem uma conta res-trita "sem cartão" como indicado em 5103. Nesse estágio (fase I), o novodono da conta tem a capacidade de ver os fundos na sua conta de débitopré-paga em um tempo real. Entretanto, devido aos regulamentos bancários,o acesso à conta pelo novo dono de conta aos fundos é restrito pendente aconclusão de um relatório OFAC como indicado em 5104. "OFAC" se refereao Escritório de controle de bens estrangeiros do departamento do tesourodos Estados Unidos que administra e faz cumprir as sanções econômicas ede comércio com base na estratégia de ação estrangeira e metas de segu-rança nacionais dos E.U. contra países estrangeiros almejados, terroristas,traficantes de narcóticos internacionais não aprovados e esses engajadosem atividades relacionadas com a proliferação não aprovada de armas dedestruição em massa.
A revisão do dono da conta contra uma lista de suspeitos é umaetapa essencial no programa de consentimento do OFAC. Se um dono deconta é indicado como uma correspondência potencial com a lista do OFAC,uma investigação é iniciada para determinar se, na realidade, essa é umacorrespondência verdadeira. Até resolvido, os fundos não são liberados. Pa-còtes de software comercialmente disponíveis estão disponíveis para a veri-ficação de consentimento. A verificação do consentimento pode também i-dentificar registros em duplicata do consumidor, estabelecer ligações entreindivíduos e corporações para os negócios domésticos tradicionais e nãotradicionais, criar uma chave de "negócios domésticos" de múltiplas funçõespara acompanhar mudanças através do tempo e estabelecer processamentobaseado em regras para resolver duplicatas e criar ligações e negócios do-mésticos.
Depois que o consentimento do OFAC está completo (um pro-cesso que tipicamente demora aproximadamente 24 horas) e nenhuma liga-ção adversa identificada, o dono da conta se torna uma conta "sem cartão",que significa que a instituição financeira pode abrir uma conta de cartão dedébito pré-financiada e pedir um cartão de débito plástico para ser enviadopara o novo dono de conta como indicado em 5105. Entretanto, nesse está-gio (fase II), o novo dono de conta sem cartão tem somente disponibilidadelimitada dos fundos. Por exemplo, o novo dono de conta pode transferir osfundos para outros indivíduos usando o sistema de transação financeira dapresente invenção, porém por causa das restrições governamentais adicio-nais, os fundos não podem ser sacados ou transferidos para um comercian-te.
Em uma porção de processamento de back-end de um sistemada invenção, a conta de sujeição em fundo comum mantém os fundos trans-feridos se o recebedor não é ainda um dono de conta. Uma entrada da razãoidentifica (ver figura 39) os fundos atribuídos para cada número de telefone.Esses fundos podem ser transferidos para outras contas pelo recebedor seele se registra para uma conta. Pelo fato de que os indivíduos não podemser compelidos a se inscrever para uma conta, é possível que o recebedorrecuse pró ativamente os fundos ou simplesmente não responda. Em tais casos, os fundos são retornados para o dono da conta que iniciou a transa-ção depois que a janela de transação expirou (a janela de transação podeser uma duração selecionada tal como 30 dias ou 60 dias) ou imediatamentecom a recusa pró ativa. O servidor de transação pode enviar mensagensperiódicas de lembrete para ambos o remetente dos fundos e o recebedor. Em outros casos, o emissor dos fundos pode parar o pagamento se o rece-bedor não se registrou para obter acesso aos fundos. Esse aspecto é impor-tante onde as partes concordam em cancelar a transferência eletrônica econcluir a transação por uma outra maneira - por exemplo, usando dinheiro.
Se os fundos para todos os donos de conta são mantidos na conta em fundo comum, então quando uma nova conta é "ativada", o novodono da conta tem acesso completo e imediato aos fundos. Seus fundos sãomantidos em contas separadas para cada dono de conta, os fundos sãotransferidos da conta de sujeição para a conta do dono da conta quando aconta é ativada. Pode existir algum retardo para os fundos aparecerem na conta individual.
Depois que a conta é aberta e as verificações de consentimentopassadas, a instituição financeira solicita que um cartão de débito plásticoseja enviado para o endereço de registro para o novo dono da conta. Quan-do o cartão chega, o dono da conta chama um número de telefone gratuito para confirmar a recepção. O telefone de confirmação pode também indicarque o endereço para o dono da conta está correto.
Durante essa chamada, o dono da conta também seleciona oseu PIN. O PIN é vinculado a ambos o cartão e o número do telefone do te-lefone móvel do dono da conta. Ademais, o número da conta no cartão de débito plástico e o telefone são bloqueados juntos. O cartão pode ser usadopara sacar o dinheiro da conta ou para depositar dinheiro na conta usandoqualquer ATM bancário. Ele pode também ser usado em qualquer localiza-ção comercial onde um dispositivo de POS aceita cartões de crédito e ban-co. Nesse estágio (fase III), a conta do dono da conta está totalmente habili-tada para uso.
Fazer referência agora à figura 52 onde um sistema de detecçãode fraude em série 5200 é ilustrado como parte do processador de transação3630. A primeira série do sistema em série 5200 inclui um mecanismo base-ado em regras e componentes selecionados pelo usuário 5201. A segundasérie do sistema em série 5202 inclui componentes proprietários que nãoficam acessíveis ou visíveis para os donos de conta.
Os componentes selecionados pelo usuário incluem, por exem-plo, a capacidade do dono da conta personalizar a segurança para sua con-ta. Os donos de conta podem vincular vários números de telefone celularpara membros da família que são autorizados a acessar a conta pré-paga.Para cada número de telefone designado, o dono da conta pode especificarlimites máximos de gastos em uma base diária, semanal ou mensal. O donoda conta pode excluir certos comerciantes, números de conta ou números detelefone criando uma "lista negra" pessoal para as partes excluídas designa-das.
Uma implementação de lista negra específica permite que o do- no da conta designe exclusões de cartão desregrado tal como bloqueando atransferência de fundos para qualquer telefone tendo um código de área par-ticular ou qualquer "900" ou número estrangeiro. O dono da conta pode criaruma lista negra pessoal separada para um usuário autorizado. Esse aspectoé particularmente útil para controlar o gasto impróprio pelas crianças equipa-das com telefone celular. Qualquer número de números ou contas pode serincluído na lista negra.
Inversamente, o dono da conta pode também especificar certoscomerciantes ou números de telefone que podem ser incluídos em umatransação financeira que envolve um dos usuários autorizados. Todos osoutros comerciantes e números de telefone podem ser opcionalmente julga-dos como estando na lista negra pessoal. Novamente, esse aspecto é parti-cularmente útil para controlar o gasto de crianças permitindo compras paratrânsito, almoço e suprimentos de escola, mas não para revistas ou outrasnovidades.
Além de especificar a lista negra e a lista branca pessoais, o do-no da conta pode também pré-autorizar compras em cada um dos comerci-antes que aparecem na lista branca enquanto configurando um limite portransação nos outros números na lista branca.
O dono da conta pode personalizar um mecanismo de detecçãode fraude baseado em regras que é também implementado na primeira sé-rie.
O dono da conta pode também especificar a quantia máximapara cada transação e o número de transações que podem ser processadasem um telefone celular em um período selecionado. O dono da conta podetambém especificar a quantia máxima de fundos que devem ser depositadose retidos na conta de débito pré-paga. O processador de transação 3630varre os fundos excessivos para uma outra conta designada, tal como umaconta de poupança pessoal, em uma base diária.
A segunda série do sistema em série 5202 inclui componentesproprietários que não ficam acessíveis ou visíveis para os donos de conta.Por exemplo, a segunda série 5202 inclui um limite de gasto máximo basea-do nas médias históricas, verificação geográfica, o número histórico de tran-sações diárias. Outros mecanismos de controle de freqüência (velocidade)de transação e detecção de fraude com base em regras são também imple-mentados aqui da mesma forma.
Um mecanismo de regras de risco e fraude (não mostrado) con-trola os riscos aplicando limites de gasto e determinando a aceitabilidadedas transações solicitadas de uma perspectiva do risco. Tais sistemas dedetecção de fraude são conhecidos e são freqüentemente usados para mo-nitorar a fraude quando cartões de crédito são usados. A informação coleta-da para cada transação financeira pode ser minerada para uso pelo comer-ciante e aplicações de valor adicionado do consumidor, por aplicações demonitoramento do negócio, pelas aplicações de operações do sistema e a-plicações de monitoramento de segurança também.Fazer referência agora à figura 53, que mostra uma modalidadede conta em fundo comum para minimizar ACH e as taxas de intercâmbio docartão de crédito. Ao invés de manter uma conta de débito pré-paga separa-da para cada dono de conta, a presente modalidade utiliza uma conta dedébito pré-paga em fundo comum 5300. Quando as transações ocorrem en-tre os donos de conta como indicado em 5301, o dinheiro fica retido na contaem fundo comum 5300, mas é movido de uma conta de dono de conta paraa conta do outro dono de conta. A transferência é imediata e não incorre emqualquer taxa de transação para o operador do sistema. Por essa razão, odono da conta pode ser cobrado com pouca ou nenhuma taxa de transação.
Às vezes, os donos de conta podem adicionar fundos na contaem fundo comum como indicado em 5302. Tais fundos podem ser deposita-dos em um comerciante parceiro que concordou em aceitar fundos dos do-nos da conta que são então depositados na conta em fundo comum. Alterna-tivamente, o dono da conta pode utilizar o seu cartão de débito plástico emum ATM para depositar dinheiro ou cheques, na Internet fazendo uma trans-ferência de conta por telefone ou automaticamente como especificado napágina de perfil do usuário associada com cada conta.
Em outros momentos, os donos de conta podem transferir fun-dos para fora da conta em fundo comum como indicado em 5303. O novodono de conta pode sacar tais fundos quando ele não deseja reter um saldona sua conta de débito pré-paga.
Nessa modalidade, o operador do sistema é um agregador deconta e se torna o sistema de registro em termos de risco e controle de risco.O operador do sistema é também responsável por executar a verificação deconsentimento do OFAC. O operador do sistema pode ser um banco, umainstituição financeira ou pode subcontratar o gerenciamento de conta emfundo comum para um outro banco.
Em uma modalidade, a comunicação perto da esfera de ação éusada para se comunicar entre dispositivos móveis para concluir transaçõesfinanceiras usando a infra-estrutura da presente invenção. Em ainda umaoutra modalidade, a comunicação perto da esfera de ação é usada para secomunicar de um dispositivo móvel para um terminal de POS para concluiras transações financeiras.
Garantia e Prevenção de Fraude
Garantia e prevenção de fraude são assuntos importantes para aindústria de pagamentos e são uma fonte contínua de problemas. A infra-estrutura de transferência de pagamento móvel e métodos de operação, deacordo com a presente invenção, são ferramentas efetivas no tratamentodesses problemas. Especificamente, o uso do dispositivo móvel para condu-zir as transações financeiras permite uma transação em tempo real que usafundos que, com garantia, estão disponíveis. A parte recebedora pode verifi-car a validade da entidade que mantém os fundos e que a conta tem um sal-do suficiente para concluir a transação. Vantajosamente, a informação daconta (número do cartão de crédito, número do cartão de débito ou outraconta em uma instituição financeira) não precisa ser provida para concluir atransação.
No lado de envio da transação, a parte emissora usa um códigoPIN para identificar a pessoa com o telefone. Essa autenticação provê umalto nível de garantia porque o servidor de pagamento é capaz de identificaro dispositivo móvel usando o ID do chamador e a pessoa usando o dispositi-vo móvel é identificada por um PIN. Vantajosamente, o transferido em umamaneira segura e não é armazenado no dispositivo móvel em uma formavisível.
Adicionalmente, a transação pode ser identificada por um núme-ro de seqüência único que é determinado pela aplicação do cliente móvel e éenviado como parte da seqüência de comando para o servidor de pagamen-to. No servidor de pagamento, uma história de números de seqüência usa-dos é mantida, então as transações com números de seqüência previamenteusados não serão processadas. Depois de cada transação e antes da pró-xima transação, o dispositivo móvel atualiza o número de seqüência com umnovo número de seqüência. Por exemplo, a nova seqüência pode ser o nú-mero de seqüência antigo incrementado por 1. Em uma implementação al-ternativa, os números de seqüência podem ser qualquer número, incluindoum número aleatório. Além do mais, um algoritmo pode ser usado que criauma seqüência previsível de números. Essa seqüência de números pode sergerada usando uma semente criada de uma função de prova na informaçãotais como o número do telefone, a hora do dia ou outros. No momento dainicialização, o servidor de pagamento é provido com o número de seqüên-cia inicial e sabe o algoritmo e vê, então ele pode predizer qual número deseqüência será o próximo. Se o número de seqüência não está correto, en-tão o servidor rejeita a transação. Isso pode ajudar a impedir ataques defraude.
O número de seqüência ajuda a prevenir a fraude e também evi-ta a duplicação de transações financeiras, que podem ser devido ao protoco-lo de comunicações onde a informação de transação é enviada múltiplasvezes. Isso é similar à situação onde uma máquina de fax tenta enviar umfax novamente se ela não recebeu um reconhecimento apropriado.
Se mensagens SMS são usadas para completar uma transação,o PIN da autorização é preferivelmente um código verbal que é falado nodispositivo móvel e transmitido para o servidor de pagamento para a autenti-cação usando o software de reconhecimento de voz.
As transações comerciais são preferivelmente estruturadas parausar uma autorização ativa onde o telefone do dono da conta toca com umamensagem para aprovar a quantia em dólar transferida. Cartões de crédito echeques não podem operar com esse nível de interação.
A garantia adicional é provida pelo uso do código PIN para ativara aplicação do cliente móvel. Nessa modalidade, o código PIN ocorre emuma primeira instância para abrir a aplicação do cliente móvel e iniciar a suaoperação. O mesmo código PIN ou, preferivelmente, um código PIN separa-do é usado para a autorização das transações através da rede. Esse pro-cesso de código PIN duplo não está disponível nos cartões de crédito, che-ques ou até mesmo em cartões inteligentes.
Quando a fraude é detectada, o dispositivo móvel pode ser inca-pacitado e impedido de usar a rede para acessar a conta. Em geral, os dis-positivos móveis têm vários atributos essenciais que facilitam as salvaguar-das da garantia futura. A maior parte, se não todos esses atributos não exis-tem em cartões. Especificamente, os dispositivos móveis incluem uma fonteindependente de potência para fazer funcionar os dispositivos físicos, talcomo circuitos integrados de finalidade especial, e uma caixa ou alojamentoseguro que pode alojar dispositivos como circuitos integrados inteligentes.Os dispositivos móveis permitem a comunicação por voz e por dados atra-vés da rede de celular ou através da Internet, então a verificação da voz eum PIN podem ser usados em combinação, ou separadamente, para identi-ficar um dono de conta. As transações podem ser iniciadas e verificadas pe-lo uso da tecnologia de reconhecimento de voz e por dados inseridos atra-vés de um teclado. Em outras modalidades, a comunicação visual é providaatravés do uso de uma câmera.
Um outro nível de garantia é provido pelo uso da tecnologia delocalização, tal como um sistema de geo-posicionamento ou GPS que podedeterminar a localização física do dispositivo. Assim, se o dono da conta es-tá usando o serviço de pagamento em uma localização atípica (tal comoquando ele está em férias), o usuário da conta pode ser autenticado solici-tando que o PIN seja inserido novamente. Uma outra vantagem da tecnolo-gia de localização é que os serviços disponíveis para o dono da conta po-dem ser ajustados com base em onde ele está localizado. Por exemplo,descontos ou promoções especiais podem ser enviados junto com a confir-mação para uma transação sempre que a localização do dono da conta i-guala essa do comerciante. Em outras modalidades, se o dono da conta estána área de um comerciante que está oferecendo um desconto especial, umamensagem promocional poderia ser enviada para o dono da conta se autori-zado por seu perfil mantido pelo servidor de pagamento.
A figura 54 mostra um mecanismo e método para impedir a frau-de e múltiplas solicitações de transação em duplicata de acordo com umamodalidade da presente invenção. O mecanismo de prevenção de fraudeinclui o armazenamento de um número de seqüência em um registrador emcada telefone celular e no servidor de pagamento. Tipicamente, como indi-cado em 5401, o número de seqüência é inicializado quando o serviço depagamento do telefone celular é ativado. Ao mesmo tempo, o mesmo núme-ro de seqüência é inicializado no servidor de pagamento e armazenado emum banco de dados com as outras informações do dono da conta.
Com a recepção de uma solicitação de transação, como indica-do em 5402, o servidor de pagamento recebe um número de seqüência dotelefone celular e o compara com o número de seqüência mantido pelo ser-vidor de pagamento. Se os números de seqüência se igualam, como indica-do em 5403, então o servidor de pagamento autoriza que a transação conti-nue. Os números de seqüência em ambos o telefone celular e o servidor depagamento são então atualizados para um novo número de seqüência. Essemecanismo de garantia é usado para prevenir ataques fraudulentos ou tele-fones clonados. É solicitado então que o usuário insira o seu PIN como indi-cado em 5405. Pela junção do uso do número de seqüência com o PIN e onúmero do telefone celular, existe uma cobertura de garantia de três níveisque autentica o usuário (PIN), o número do telefone (detectado pelo ID dochamador e vinculado a uma conta específica) e o número de seqüênciapara validar a transação (previne que um intruso tente capturar uma transa-ção e a seguir submeta novamente solicitações em duplicata para uma tran-sação). O número de seqüência é também usado para discriminar múltiplastentativas do sistema SMS para entregar uma mensagem de transação demúltiplas transações válidas.
Se os números de seqüência não se igualam, o servidor de pa-gamento recusa a solicitação de transação, como indicado em 5406, e me-didas de prevenção de fraude são ativadas, como indicado em 5407. Pormeio de exemplos, quando os números de seqüência não se igualam, a con-ta pode ser congelada até que um representante do serviço de consumidorpossa determinar a causa dos números de seqüência não correspondentes.Isso pode necessitar de uma chamada telefônica para o dono da conta paraver se ele ainda está em posse do seu telefone e se ele tinha autorizado atransação tentada.
A figura 55 mostra uma outra modalidade do mecanismo e mé-todo para prevenir a fraude e múltiplas solicitações de transação em duplica-ta de acordo com uma modalidade da presente invenção.
Em 5510, um usuário (isto é, um dono de conta) inicia uma tran-sação financeira em um dispositivo de telefonia móvel (por exemplo, um tele-fone móvel). Em 5511, o usuário transmite um PIN no momento em que a transação é iniciada (opção A). Alternativamente, como indicado em 5512, ousuário não transmite um PIN no momento em que a transação é iniciada(opção B).
Em 5513, o servidor de pagamento recebe a solicitação do dis-positivo móvel para iniciar a transação financeira. O servidor verifica o núme- ro de identificação do chamador (ID do chamador) transmitido pelo dispositi-vo móvel para ver se o dispositivo móvel é um usuário autorizado do sistemaem 5514. Se o ID do chamador não está habilitado no telefone, proibir atransação como indicado em 5915. Uma mensagem de erro pode ser mos-trada para indicar que a transação foi proibida porque o ID do chamador não está habilitado. O usuário pode tentar novamente a solicitação depois dehabilitar o ID do chamador.
Se a opção B foi selecionada, o servidor deve então enviar umasolicitação para o dispositivo móvel solicitando que o usuário transmita umPIN, como indicado em 5516. Esse PIN pode ser transmitido via um teclado do dispositivo móvel ou voz (por exemplo, para uma unidade de resposta devoz interativa (IVR) do servidor).
Depois que o ID do chamador é validado, o servidor então verifi-ca o PIN transmitido do dispositivo móvel contra o PIN gravado no sistemapara verificar se o PIN iguala o número de telefone esperado como indicado em 5517. Se e somente se o PIN iguala, o servidor permitirá que a transaçãoprossiga. Se o PIN não iguala, então a transação é proibida, como indicadoem 5518.
O servidor então recebe um número de transação (também cita-do como um número de seqüência) para a transação financeira do dispositi- vo móvel. O número de transação pode ser enviado no momento em que atransação é iniciada ou mais tarde como parte da transferência de informa-ção entre o dispositivo móvel e o servidor. O número de transação incluichaves inalteradas que o tornam único.
O servidor também verifica o presente número de transação dodispositivo móvel contra uma listagem de números de transação já previa-mente usados como indicado em 5519. Essa listagem é armazenada em umbanco de dados associado com o servidor. Se o presente número de se-qüência iguala qualquer um dos números de seqüência previamente usados,o usuário não é autenticado e a transação será proibida, como indicado em5520. Essa etapa de verificação é útil na prevenção que múltiplas cópias deuma mensagem sejam tratadas como uma mensagem nova e independente.Isso também impede ataques de piratas onde um pirata interceptou umamensagem e está tentando submeter novamente uma transação antiga.
Em alguma modalidade, o servidor também verifica o número detransação como recebido do dispositivo móvel contra um número de transa-ção esperado armazenado no servidor como indicado em 5521. Se os núme-ros de seqüência não se igualam, o usuário não é autenticado e a transaçãoserá proibida como indicado em 5520.
Se ó número de seqüência do telefone iguala o número de se-qüência armazenado no servidor ou é um número não previamente usado, ousuário é autenticado e a transação financeira terá permissão para prosse-guir. Em algumas modalidades, o servidor somente executa a verificação donúmero de transação como indicado em 5519. Em algumas modalidades, oservidor somente executa a verificação do número de transação como indi-cado em 5521. Em algumas modalidades, o servidor somente executa a ve-rificação do número de transação como indicado em 5519 e em 5521. Con-tanto que o servidor determine que o número de seqüência do telefone nãofoi usado antes ou é o número de seqüência esperado, ou ambos, a transa-ção será permitida. O número de seqüência pode também ser usado comoum identificador de transação único. A etapa 5521 se une em uma etapa5622 via uma ligação 5607.
O servidor também armazena o número de seqüência prévio queé armazenado ou de outra forma indicado no servidor como um número deseqüência que foi usado, como indicado em 5622. Esses números de se-qüência previamente usados podem ser armazenados em um banco de da-dos no servidor. Se o servidor mantém um número de seqüência esperado,o número de seqüência no telefone e o servidor são incrementados em pre-paração para a próxima transação como indicado em 5623. O servidor entãoprossegue com a conclusão da transação financeira, como indicado em 5624.
Uma técnica de autenticação de três fatores autentica baseadanos fatores seguintes:
(1) verificação do ID do chamador
(2) verificação do PIN ou número de identificação pessoal
(3) verificação do número de transação
O método de validação acima apresenta algumas etapas de au-tenticação em uma ordem específica. Uma implementação da invenção exe-cuta as etapas na ordem dada. Entretanto, em outras implementações dainvenção, podem existir outras etapas incluídas ou algumas etapas podemser omitidas, ou a ordem das etapas pode ser diferente do acima. Por exem-plo, o ID do chamador, PIN e a transação podem ordenar independentes.Portanto, em uma modalidade, o PIN pode ser verificado antes do ID dochamador. Em uma outra modalidade, o número de transação pode ser veri-ficado antes do PIN. Além do mais, algumas etapas acima podem ser execu-tadas ao mesmo tempo em processadores diferentes ou núcleos de proces-sador em uma implementação de processamento paralela.
Em uma implementação, um sistema da invenção pode omitiruma ou mais das técnicas de autenticação listadas acima. Por exemplo, o IDdo chamador pode não ser autenticado, de modo que então uma abordagemde autenticação de dois fatores será usada.
Um modelo tradicional para autenticação de dois fatores é base-ado em (1)o que você tem e (2) o que você sabe. Um primeiro fator é algu-ma coisa que um usuário tem tal como um telefone móvel, assistente pesso-al digital, telefone inteligente ou cartão plástico. Um segundo fator é algumacoisa que o usuário sabe tal como um número de identificação pessoal(PIN), o nome de solteira da mãe, o endereço da rua, número do seguro so-ciai, número da licença de motorista ou número do telefone residencial.
Se uma autenticação de três fatores ou de dois fatores é usadapode depender do canal de comunicação usado pelo dispositivo móvel eservidor. Por exemplo, quando SMS ou serviços de dados SMS são usados,o ID do chamador fica disponível e uma autenticação de três fatores podeser usada. Entretanto, quando HTTP ou HTTPS é usado, o ID do chamadortipicamente não fica disponível e uma autenticação de três fatores não seráusada. Podem existir fatores adicionais usados para autenticar um dono deconta ou usuário, então a técnica pode ter mais do que três fatores. Além doque, o terceiro fator de autenticação pode ser controlado pelos componentesde software do lado do cliente e do lado do servidor.Fluxo de Autenticação Exemplar de Três Fatores
(1) Iniciar uma transação financeira em um dispositivo de telefo-nia móvel (por exemplo, telefone móvel)
(2a) (opção A) transmitir um PIN no momento em que a etapa 1ocorre
(2b) (opção b) não transmitir um PIN no momento em que a eta-pa 1 ocorre.
(3) Em um servidor, receber a solicitação do dispositivo móvelpara iniciar a transação financeira.
(4) No servidor, verificar a identificação do chamador (ID dochamador) transmitida pelo dispositivo móvel para ver se o dispositivo móvelé um usuário autorizado do sistema. Se o ID do chamador não é habilitadono telefone, proibir a transação. Mostrar a mensagem de erro indicando quea transação foi proibida porque o ID do chamador não é habilitado. O usuáriopode tentar novamente a solicitação depois de habilitar o ID do chamador.
(5) Se opção A, depois que o ID do chamador é validado, pros-seguir para a etapa 6. Se opção B, depois que o ID do chamador é validado,o servidor envia uma solicitação para o dispositivo móvel para o usuáriotransmitir um PIN. Esse PIN pode ser transmitido via um teclado do disposi-tivo móvel ou voz (por exemplo, para uma unidade de resposta de voz inte-rativa (IVR) do servidor).(6) ID do chamador foi validado, então verificar o PIN transmitidodo dispositivo móvel contra o PIN gravado no sistema. Se o PIN iguala, irpara a etapa 7.
(7) Receber um número de transação ou o número de seqüênciapara a transação financeira do dispositivo móvel. Esse número de transaçãopode ser enviado no momento em que a etapa 1 ocorre, ou pode ser envia-do mais tarde na transferência da informação entre o dispositivo móvel e oservidor. Prosseguir para 8a (opção C) ou 8b (opção D) abaixo.
(8a) (Opção C) verificar o número de seqüência do dispositivomóvel contra um número de seqüência armazenado no servidor. Se os nú-meros de seqüência não igualam, o usuário não é autenticado e a transaçãoserá proibida.
(8b) (Opção D) verificar o presente número de seqüência do dis-positivo móvel contra uma listagem ou banco de dados de número de se-qüência já previamente usado que está armazenado no servidor. Se o pre-sente número de seqüência iguala qualquer um dos números de seqüênciapreviamente usados, o usuário não é autenticado e a transação será proibi-da.
(9) Se o número de seqüência do telefone iguala o número deseqüência armazenado no servidor (para opção C) ou é um número nãopreviamente usado (para opção D), o usuário é autenticado e a transaçãofinanceira terá permissão para prosseguir. Para opção D, em outras pala-vras, contanto que o servidor determine que o número de seqüência do tele-fone não foi usado antes, a transação será permitida.
(10a) Se opção C, o número de seqüência no telefone e servidorsão incrementados na preparação para a próxima transação.
(10b) Se opção D, o número de seqüência no telefone é incre-mentado para o próximo número de seqüência. O número de seqüência pré-vio é armazenado ou de outra forma indicado no servidor como um númerode seqüência que foi usado. Esses números de seqüência previamente usa-dos podem ser armazenados em um banco de dados no servidor.
Várias implementações da autenticação do número de transaçãoou seqüência
(1) Na inicialização do serviço, usar um valor de número de tran-sação inicial armazenado em ambos o dispositivo móvel e o servidor. O nú-mero de transação inicial pode ser (1a) ou (1b).
(1a) O número de transação inicial pode ser um número inteiro
tal como 0,1,2,3,4,5,6,7,8,9,10 ou outros números.
(1b) O número de transação inicial pode ser um número aleató-rio, tal como gerado por um gerador de número pseudoaleatório e uma dadasemente. Essa semente pode ser um código de prova com base em uma propriedade ou característica do dispositivo. Por exemplo, a semente podeser baseada no número do telefone, número serial do dispositivo, proprieda-de ou valor armazenado em um circuito integrado do dispositivo, o valor derelógio em tempo real.
(2) Quando o usuário usa uma aplicação onde a autenticação donúmero da transação é usada, o valor do número da transação será alteradodo valor do número de transação inicial ou prévio para o próximo na seqüên-cia. A seqüência pode ser qualquer série, matemática, pseudoaleatório ououtra. A seqüência pode ser finita, infinita ou séries repetidas. Se uma sérierepetida, o número dos números de transação na série antes que ela repita pode ser baseado em um número de bits binários usados para representar onúmero da transação.
(2a) Por exemplo, a seqüência pode ser aritmética ou geométri-ca. Para um exemplo de uma série aritmética, um número de transação po-de ser um incrementado por 1 ou qualquer outro valor (ou decrementado por 1 ou qualquer outro valor) para obter o próximo número de transação na se-qüência. Se o número da transação é representado usando oito bits binários,a seqüência repetirá a cada 256 números. Se o número da transação é re-presentado usando dezesseis bits binários, a seqüência repetirá a cada65536 números. Portanto, quanto mais números de bits que são usados,mais longa a seqüência.
(2b) A seqüência pode ser pseudoaleatória gerada por um gera-dor de número pseudoaleatório. A seqüência de números pseudoaleatóriosserá baseada no valor da semente de partida. O número pseudoaleatóriopode ser representado usando um número de ponto flutuante. O número deponto flutuante pode ser armazenado usando uma representação de pontoflutuante binária.
(3) Depois de cada transação, o dispositivo móvel e o servidor(onde o número de transação do dispositivo móvel será autenticado contra)ambos geram o próximo número de transação na seqüência de acordo como mesmo algoritmo. Se o dispositivo móvel usa uma série aritmética, o servi-dor usará uma série aritmética. Se o dispositivo móvel usa uma série de nú-mero pseudoaleatório, o servidor usará uma série de número pseudoaleató-rio. A mesma semente usada pelo dispositivo móvel será usada pelo servi-dor. Dependendo da implementação particular, essa semente pode sertransmitida do dispositivo para o servidor, ou vice-versa, ou independente-mente determinada.
(4) O dispositivo móvel e o servidor armazenarão, cada um, nú-meros de transação respectivos. O número de transação no dispositivo mó-vel pode ser citado como um número de transação de dispositivo móvel. Onúmero de transação no servidor pode ser citado como o número de transa-ção do servidor.
(5) Quando uma transação ocorre, o servidor comparará o seunúmero de transação armazenado contra o armazenado no dispositivo mó-vel. Se os números de transação se igualam, uma autenticação ocorre e atransação terá permissão para prosseguir. De outra forma, a transação seráproibida.
(6) Depois que uma transação é permitida, os números de tran-sação serão avançados para o próximo na seqüência em ambos o dispositi-vo móvel e o servidor.
Essas técnicas de uso de um número de transação para autenti-car o dispositivo móvel ajudam a impedir a fraude, transações em duplicata eoutras circunstâncias indesejáveis. Existem muitas variações das implemen-tações específicas da autenticação do número de transação, e qualquer umadessas variações pode ser usada, e em qualquer combinação com as abor-dagens descritas acima. Por exemplo, ao invés de verificar se o número detransação de um dispositivo móvel iguala um número correspondente noservidor, a técnica de autenticação pode verificar se o número de transação(a) não iguala um número correspondente no servidor ou (b) não iguala umnúmero previamente usado no servidor (como previamente descrito nessepedido).
A figura 57 mostra um exemplo da autenticação do número deseqüência. Existe um dispositivo de computador do consumidor (por exem-plo, dispositivo de telefonia, telefone inteligente ou computador portátil) euma aplicação empreendedora. No dispositivo de computador do consumi-dor está um componente de software do cliente de autenticação do númerode seqüência (SNA). A aplicação empreendedora inclui um componente desoftware do servidor de autenticação do número de seqüência. Esses com-ponentes tratam da autenticação quando o dispositivo do consumidor enviauma transação para o servidor. Essa autenticação pode ser o terceiro fatorem uma abordagem de autenticação de três fatores.
Em uma implementação particular, o componente de autentica-ção do número de seqüência do cliente acompanha um contador criptogra-fado que inicia em um valor diferente de zero aleatório que é estabelecidodurante a instalação no lado do cliente. Com cada transação, o componenteSNA do cliente incrementa o valor do contador do cliente por um valor dife-rente de zero aleatório. O componente de autenticação do número de se-qüência do servidor acompanha os valores de contador "recebidos por últi-mo" para clientes com base no identificador do cliente. Se o valor do conta-dor do cliente que chega é maior do que o último valor recebido, então atransação é aceita. O valor do contador é armazenado e a transação é exe-cutada. De outra forma, se o valor do contador não é maior do que o últimovalor recebido, a transação é inválida e a conta pode ser suspensa. Essaimplementação é meramente uma de muitas variações possíveis de autenti-cação do número de seqüência.
A figura 58 mostra um outro exemplo da autenticação do númerode seqüência. Nessa técnica específica, dependendo do cliente do qual atransação está se originando, um tipo diferente de número de seqüência éusado e enviado para o servidor do serviço de pagamento móvel. Por exem-plo, um cliente gordo ou um cliente magro pode ser usado.
Exemplos de um cliente gordo incluem uma aplicação ou pro-grama funcionando em um telefone móvel, telefone inteligente, computadorportátil ou outro dispositivo eletrônico. A aplicação ou parte de uma aplica-ção pode ser escrita em uma linguagem de programação tais como J2ME,BREW ou .NET CF. A aplicação pode ser uma aplicação específica parapagamentos móveis. Um exemplo de um tal programa e telas de usuárioacompanhantes é descrito em outro lugar nesse pedido. Ou a funcionalidadepode ser parte de um outro programa, tal como um programa de mensageiroinstantâneo, programa de bate-papo pela Internet em tempo real, programade transferência de arquivo, programa de reprodutor de música, programade reprodutor de vídeo, programa de compartilhamento de arquivo, progra-ma de interface do serviço de pagamento de conta ou programa de divisãode conta.
Por exemplo, quando usando um programa de mensageiro ins-tantâneo (por exemplo, AOL Instant Messenger (AIM), ICQ, Yahoo! Messen-ger, Microsoft Windows Live Messenger, Google Talk ou Skype), existiráuma opção para enviar para um outro usuário um pagamento. A opção paraenviar um pagamento pode ficar acessível usando um clique no lado direitode um mouse ou através de um menu suspenso ou em cascata. O recebe-dor pode ser identificado através do nome de usuário, nome de membro,número de telefone, número de membro, número de conta ou um outro iden-tificador. O pagamento será processado através do servidor do serviço depagamento móvel.
Exemplos de um cliente magro incluem uma aplicação de nave-gador da Web, telefone ou outro dispositivo com troca de mensagens de tex-to SMS, telefone ou outro dispositivo com um navegador da WAP ou pro-grama de emulação de terminal.
Em uma implementação específica da invenção quando usandoum cliente gordo, um número de seqüência armazenado será armazenadopersistentemente em um contador no cliente gordo. Esse número de se-qüência armazenado pode seguir qualquer seqüência arbitrária tal comonúmero inteiro seqüencial ou contador binário (por exemplo, 1,2,3,4 e assimpor diante), uma seqüência aleatória baseada em um valor de semente departida conhecido ou seqüência de acordo com uma equação, fórmula ouregra. O número de seqüência armazenado pode ser armazenado, por e-xemplo, na memória flash, memória eletricamente apagável (Ε^2), memórianão volátil, memória com reserva de bateria, unidade rígida ou outra memó-ria.
Com cada transação, uma chave inalterada (chamada um núme-ro de seqüência em outras implementações da invenção) é enviada para osistema de pagamento móvel. Para um cliente gordo, a chave incluirá umacombinação de ID de membro e o número de seqüência armazenado. Essenúmero de seqüência armazenado pode ser o próximo número de seqüênciaarmazenado não utilizado. Quando o sistema de pagamento móvel recebe achave inalterada do cliente gordo, a transação é armazenada em uma tabelade transação junto com essa chave inalterada. Na tabela de transação, éesperado que cada chave inalterada seja única. Então, se o sistema de pa-gamento móvel recebe uma outra transação com uma chave inalterada pre-viamente recebida, a transação pode ser desconsiderada desde que ela éprovavelmente uma transação em duplicata ou um problema de segurança.
Em uma implementação específica, a conta do usuário pode sermarcada com uma violação de segurança potencial para a pessoa investi-gar. Se um usuário tem um número de tais violações ou um número de taisviolações acima de um período de tempo particular, então a conta pode serautomaticamente suspensa para investigação pendente.
Em uma implementação específica da invenção quando usandoum cliente magro, a chave inalterada incluirá o ID do membro, o ID alvo,quantia de transação e tempo (ou carimbo de tempo). O sistema de paga-mento móvel receberá essa chave inalterada e manipulará similarmente asituação quando recebendo uma chave inalterada de cliente gordo.
Portanto, um sistema de pagamento móvel da invenção podefuncionar com tipos diferentes de clientes e cada tipo de cliente pode enviartipos diferentes de chaves inalteradas ou números de seqüência. Essa mo-dalidade tem dois tipos diferentes de chaves inalteradas, mas em outrasmodalidades, pode existir qualquer número de tipos de chave inalterada oude número de seqüência. Por exemplo, podem existir três, quatro, cinco,seis, sete, oito ou mais tipos de chave.
Uma técnica é usada para garantir a autenticidade de uma fontede transmissão sem fio que está solicitando que uma transação seja execu-tada por um sistema. A transação pode ser uma transferência de dinheiro depessoa para pessoa ou outra transação de troca de valor. A fonte de trans-missão sem fio pode ser um telefone móvel ou outro dispositivo similar. Afonte de transmissão sem fio transmite uma chave com a solicitação da tran-sação. O sistema determinará a autenticidade da transação baseado nachave transmitida. Se a transmissão é determinada como sendo autêntica, atransação será executada. Várias abordagens para determinar a autentici-dade são discutidas. A técnica pode também ser usada para impedir a exe-cução de transmissões em duplicata.
Em uma modalidade, a invenção é um método incluindo receberuma solicitação eletrônica para uma transação de troca de valor, transmitidade modo sem fio de um dispositivo do usuário; receber com a solicitaçãoeletrônica uma chave transmitida associada com a solicitação eletrônica edeterminar se a chave transmitida existe em uma tabela de transações. Se achave transmitida não está na tabela de transações, a transmissão seráconsiderada autêntica. Portanto, a chave transmitida e a transação de trocade valor são inseridas na tabela de transação, e a transação de troca de va-lor é processada pelo sistema. Se a chave transmitida está na tabela detransações, a transmissão não é considerada autêntica (ou pode ser umatransmissão em duplicata). Portanto, a transação de troca de valor não éexecutada pelo sistema. O dispositivo do usuário pode ser um telefone móvel.
Em uma implementação, a chave transmitida inclui um identifi-cador eletrônico identificando um usuário que solicitou a transação de trocade valor e um número de seqüência. O número de seqüência é armazenadono dispositivo do usuário e avançado para um próximo número na seqüênciaantes que uma próxima transação de troca de valor seja transmitida pelodispositivo do usuário. A seguir, cada transmissão válida deve ter um núme-ro de seqüência diferente ou único.
O número de seqüência pode ser armazenado em uma memórianão volátil ou de outra forma persistente no dispositivo do usuário, tais comoflash, memória eletricamente apagável (ΕΛ2), armazenamento magnético oumemória com reserva de bateria. Isso garantirá que cada transmissão tenhaum valor único.
A chave transmitida pode incluir um número pseudoaleatório, talcomo gerado usando um gerador de número pseudoaleatório usando umvalor de semente particular. O valor de semente mudará toda vez que umnovo número pseudoaleatório é gerado, então uma seqüência de númerospseudoaleatórios será gerada.
Em uma implementação, a chave transmitida inclui um primeiroidentificador eletrônico identificando um usuário que solicitou a transação detroca de valor, um segundo identificador eletrônico identificando um usuárioque é um alvo da transação de troca de valor, uma quantia de valor da tran-sação de troca de valor e um tempo associado com a transação de troca devalor.
Em uma implementação, a transação de troca de valor pode serenviar dinheiro de um primeiro usuário associado com o dispositivo do usuá-rio para um segundo usuário associado com um outro dispositivo do usuário.Por exemplo, o primeiro usuário pode solicitar pagamento de uma certaquantia de dinheiro da conta do primeiro usuário para o segundo usuário.
A chave transmitida não é exibida no dispositivo do usuário, en-tão ela não será conhecida para o usuário. Isso pode ser útil para impedirpessoas que tentam "clonar" a conta de um outro usuário e usar o dinheirona conta de um outro usuário. Se a chave transmitida é exibida, um outrousuário pode ser capaz de mais facilmente determinar o próximo número naseqüência, a função ou a equação sendo usada para gerar as chaves ououtra informação que pode ajudar a inverter a técnica da chave. Em umaimplementação adicional, a chave transmitida é criptografada para tornardifícil interceptar a transmissão sem fio da chave.
A solicitação eletrônica pode ser feita através do serviço de trocade mensagens de texto SMS do dispositivo do usuário. A chave pode tam-bém ser transmitida usando o serviço de troca de mensagem de texto SMS.
Quando usando tipos diferentes de clientes ou programas, achave transmitida pode ser gerada ou obtida diferentemente, tal como porfunções diferentes. Por exemplo, a chave pode incluir informação diferente.A chave pode incluir a primeira informação quando o dispositivo do usuárioenvia a solicitação eletrônica usando um primeiro cliente de aplicação e achave transmitida compreende a primeira informação quando o dispositivodo usuário envia a solicitação eletrônica usando um primeiro cliente de apli-cação, que é diferente do primeiro cliente de aplicação. Exemplos da primei-ra informação podem ser uma chave incluindo um número de seqüência queé persistentemente armazenado. Exemplos da segunda informação podemser uma chave incluindo um tempo ou carimbo de tempo.
Um primeiro cliente de aplicação pode ser um cliente gordo, talcomo uma aplicação do serviço de transação de troca de valor dedicado e-xecutando no dispositivo do usuário (por exemplo, escrito em J2ME, BREWou .NET CF) ou aplicação de mensageiro instantâneo. Um segundo clientede aplicação pode ser o cliente magro tal como uma aplicação de troca demensagens SMS no dispositivo do usuário, navegador WAP no dispositivodo usuário ou navegador da Web no dispositivo do usuário. Quando envian-do a solicitação do cliente gordo, pode existir o valor persistente armazenado(tal como contador armazenado) e isso é usado na chave. Entretanto, quan-do enviando a solicitação de um cliente magro, pode não existir um valorarmazenado persistente e um tempo ou carimbo de tempo pode ser usadona chave ao invés disso. O sistema será capaz de lidar com a recepção dechaves diferentes ou tipos de chave diferentes.
Se a chave transmitida está na tabela de transações, isso signi-fica que a transmissão foi possivelmente enviada previamente ou alguémestá tentando invadir o sistema. A conta do usuário pode ser suspensa e oassunto investigado mais. Isso impedirá transações ilegais adicionais naconta do usuário.
Além do que, o processamento da transação de troca de valorpode incluir gerar um número identificador de transação para a transação detroca de valor. Esse número identificador de transação será gerado pelo sis-tema processando a solicitação. Uma mensagem eletrônica pode ser envia-da para o dispositivo do usuário incluindo o número identificador da transa-ção. O número identificador da transação pode ser visível no dispositivo dousuário. Isso permite que o usuário tenha um número de referência para atransação, então o usuário pode discutir ou questionar sobre a transaçãodiretamente com uma representação do serviço ao consumidor. Esse identi-ficador de transação pode não ser relacionado completamente com a chavede autenticação (que é gerada no dispositivo do usuário). O identificador detransação pode ser gerado por um parceiro bancário tratando da transação.Em uma implementação alternativa, a chave pode ser usada na geração oucriação do identificador da transação.
Em uma modalidade, a invenção é um método incluindo receberuma solicitação eletrônica para uma transação de troca de valor, transmitidade modo sem fio de um dispositivo do usuário; receber uma chave transmiti-da associada com a solicitação eletrônica; gerar uma chave esperada; com-parar a chave transmitida com a chave esperada e se a chave transmitidaiguala a chave esperada, processar a transação de troca de valor. A transa-ção de troca de valor pode ser enviar dinheiro de um primeiro usuário asso-ciado com o dispositivo do usuário para um segundo usuário associado comum outro dispositivo do usuário, onde os dispositivos do usuário são telefo-nes móveis.
A geração da chave esperada pode incluir avaliar uma função ouequação usando um valor de semente armazenado para uma conta de usuá-rio associada com a transação de troca de valor. Além do que, a conta dousuário pode também armazenar informação sobre a função particular ouequação a usar para gerar a chave esperada. Por exemplo, alguns usuáriospodem usar uma função particular para gerar uma chave enquanto outrosusuários usam outras funções. Diferentes sementes de partida são usadaspara usuários diferentes, e depois de cada uso, uma nova semente será cri-ada para gerar a próxima chave. Em outras palavras, o método também in- clui depois de avaliar a função, determinar um próximo valor de semente naseqüência e substituir o valor de semente armazenado para a conta do usu-ário com o próximo valor de semente na seqüência.
Por exemplo, o dispositivo do usuário tem um contador que con-ta em uma seqüência particular e gera chaves nessa seqüência usando uma função particular (por exemplo, gerador de número pseudoaleatório). No la-do do servidor ou sistema, o servidor saberá a chave esperada porque ela éarmazenada no perfil do usuário e também saberá a função a usar para ge-rar a chave. Se a chave esperada iguala a chave transmitida, então a solici-tação do usuário é autenticada. Como declarado acima, a função ou equa- ção usada pode variar ou mudar por usuário ou dispositivo ou até mesmopor uso. A identificação de qual função ou equação usar para gerar a chaveesperada será armazenada em algum lugar no sistema tal como em um per-fil do usuário.
Em particular, a invenção pode incluir: recuperar de um perfil de usuário associado com a transação de troca de valor um valor de semente;recuperar da informação do perfil do usuário uma função de acordo com aqual a chave transmitida foi gerada e avaliar a função usando o valor de se-mente. Como discutido acima, um método da invenção pode ou não incluir afunção diferente. Em tal caso, a informação de função não precisaria ser ar-mazenada no perfil.
Se a chave transmitida não iguala a chave esperada, a transa-ção de troca de valor não será executada. Uma conta de usuário associadacom a transação de troca de valor pode ser suspensa para impedir transfe-rências adicionais de dinheiro desde que uma violação na segurança ocor- reu. A conta pode ser indicada (por exemplo, exibição em uma tela, envian-do um e-mail, enviando uma mensagem instantânea) para um administradordo sistema, que pode investigar mais. Ou um e-mail automático pode serenviado para o usuário contatar o serviço do consumidor porque uma viola-ção da segurança ocorreu na conta do usuário.
O processamento da transação de troca de valor pode incluir:gerar um número identificador de transação, diferente da chave esperada,para a transação de troca de valor e enviar uma mensagem eletrônica para odispositivo do usuário incluindo o número identificador da transação, onde onúmero identificador da transação é exibido no dispositivo do usuário.
Infra-estrutura do sistema de pagamento - aplicação do clientemóvel (MCA)
Em uma modalidade, a MCA é baseada na plataforma Java 2,Edição Empreendedora (J2EE) e contém uma interface simples, intuitiva.Como um resultado, os donos de conta inserem seus dados de solicitação -tais como quantia, número do telefone ou outra informação de identidade daconta tal como um endereço de e-mail ou ID do mensageiro instantâneo daconta receptora e o PIN. Projetada para ser flexível e fácil de configurar, aMCA tem versões diferentes para linguagens diferentes e é projetada parafuncionar sob Java 2 edição móvel (J2ME), dot Net (.NET) bem como WAP,BREW, Symbian e SIM Toolkit ou outros protocolos móveis e pode ser por-tada para plataformas tais como dispositivos celulares, PDAs ou outros dis-positivos eletrônicos móveis. Java, .Net, Brew, Symbian e Sim Toolkit sãojulgadas como marcas registradas de seus donos respectivos. A MCA estátambém disponível para o sistema operacional do telefone, incluindo Nokia,Motorola, Samsung, Sanyo e outras marcas comuns. Vantajosamente, ne-nhum dispositivo semicondutor especial ou "circuito integrado" no dispositivomóvel é necessário para executar as transações financeiras seguras, decusto efetivo e móveis.
Para iniciar a operação, os donos da conta instalam (ou têm ins-talado) a MCA no seu telefone móvel. A provisão da aplicação pode ser con-duzida nas maneiras seguintes:
(1) Através da provisão por ar usando um envio de dados (push)WAP, o servidor de pagamento envia uma mensagem para o dono da containiciar o carregamento da aplicação. Alternativamente, o dono da conta podeusar a recuperação de dados (pull) WAP para enviar uma mensagem para oservidor de pagamento iniciar o processo,
(2) A provisão de proximidade nos centros de serviço do consu-midor, localizações comerciais parceiras ou provedores de serviço móvelpodem instalar a MCA através de Bluetooth, infravermelho ou outra conexãosem fio perto da esfera de ação,
(3) O carregamento pela Internet onde os donos da conta podemcarregar o programa através da Internet e instalá-lo através de uma portaUSB - ou até mesmo carregar o programa de um telefone para um outro ou
(4) Em um cartão SIM onde os donos da conta podem adquirirdispositivos com a MCA já instalada no cartão SIM.
Em um cenário exemplar, um usuário tem um dispositivo móvelequipado com a capacidade de comunicação perto da esfera de ação. Ousuário pode ver um produto ou item que deseja comprar. O usuário colocao dispositivo móvel do usuário em proximidade com um dispositivo de comu-nicação perto da esfera de ação associado com o produto ou item. A seguir,a exibição do dispositivo móvel questiona se o usuário aprovará uma transa-ção para comprar o produto ou item. Se o usuário aprova, a transação é pro-cessada. O usuário receberá o item, tal como recolhendo de um ponto deentrega ou o item pode ser entregue para o endereço de correspondência dousuário. O usuário pode ser questionado por um PIN ou pergunta de desafiopara verificar que ele aprovou a transação.
Um aspecto da invenção é um sistema de pagamento móvel ouserviço. Esse pedido discute muitas modalidades específicas e implementa-ções de componentes individuais e elementos, variações e modificaçõesdesses e combinações desses. Um sistema da invenção pode incluir qual-quer uma das variações ou implementações específicas discutidas, unica-mente ou em qualquer combinação. Nesse pedido, um exemplo de uma im-plementação específica de um sistema de pagamento móvel é provido, eessa implementação específica é o sistema Obopay. O sistema Obopay émeramente uma implementação de um sistema de pagamento móvel e édiscutido para descrever mais facilmente vários aspectos da invenção. Ainvenção abrange muitas implementações de sistema de pagamento móvele não é limitada às implementações específicas descritas.
Aplicação do cliente móvel (MCA) nos processos de aplicação móvel
A aplicação do cliente móvel permite que pessoas paguem ami-gos, lojas e transfiram fundos por seu dispositivo móvel. Um dono de contapode acessar a aplicação do cliente móvel para enviar dinheiro ou solicitardinheiro de outra pessoa com um dispositivo móvel que suporta as capaci-dades de troca de mensagem de texto ou Internet móvel. Eles podem tam-bém ver o saldo e a história da sua conta em tempo real.
A aplicação do cliente móvel suporta os seguintes aspectos: pa-gamento, saldo, história, solicitação de pagamento, referência ou convite,adicionar dinheiro (isto é, carregar), definições, ajuda. A MCA pode ser usa-da para enviar dinheiro de uma conta de dono de conta para qualquer assi-nante móvel cujo dispositivo suporta troca de mensagem de texto. O donoda conta enviando o dinheiro precisa ser um dono de conta; entretanto, apessoa ou comerciante para o qual ele está enviando dinheiro não precisa.
A transação financeira pode ser iniciada por qualquer um, o pa-gador ou o recebedor. Se o pagador inicia a transação, a MCA é usada parainiciar a transação. Para usar a MCA para enviar dinheiro de uma conta dedébito pré-paga, o dono da conta passará através de uma seqüência de etapas:
(1) Abrir a MCA no dispositivo móvel do dono da conta. Isso le-vará o dono da conta para uma tela de exibição que exibe um logotipo e slo-gan. O dono da conta então pressiona "entrar" para continuar. Isso levará odono da conta para a tela do menu principal que exibe um menu dos aspec-tos da MCA incluindo pagamento, saldo, história, solicitação de pagamento,referência ou convite, adicionar dinheiro (isto é, carga), definições e ajuda.
(2) O dono da conta então seleciona a opção pagamento paraenviar um pagamento. Isso levará o dono da conta para a tela de pagamentoonde o dono da conta inserirá o número de telefone para o qual ele desejaenviar o seu pagamento.(3) Para selecionar um número de telefone no livro de telefonedo dono da conta, o dono da conta selecionará as opções (da tecla progra-mável esquerda inferior no dispositivo móvel) e então encontrará (a partir domenu de opções) qual trará o livro de endereços de telefone existente dodono da conta e permitirá que ele selecione um nome nele. Opcionalmente,o dono da conta pode inserir o número do telefone diretamente do teclado.Em uma outra modalidade, o dono da conta insere um código curto para i-dentificar um recebedor comercial desejado. Depois que o dono da containseriu o número móvel, ele selecionará OK.
(4) Isso o levará para a tela de quantia onde o dono da containserirá a quantia que ele deseja pagar. Dependendo do perfil do recebedor,uma tela de gorjeta pode aparecer que oferece para o dono da conta a opor-tunidade para adicionar uma gratificação na quantia que ele deseja pagar.
(5) Quando o dono da conta seleciona OK, ele será levado paraa tela de mensagem onde ele pode adicionar uma mensagem para sua tran-sação. Essa mensagem pode ser um texto, anexo de áudio ou de vídeo. Seo dono da conta não deseja adicionar uma mensagem, ele pode simples-mente clicar OK antes de escrever uma mensagem e nenhuma mensagemserá adicionada na sua transação. Se a rede de transmissão tem largura dabanda limitada, o dono da conta pode ser limitado no tipo e duração da men-sagem. Se a parte receptora para a transação não tem um dispositivo móvelcapaz de lidar com mensagens de vídeo ou áudio, a mensagem pode serarmazenada no servidor por um período curto para permitir a recuperaçãosubseqüente através da Internet.
(6) Depois que o dono da conta seleciona OK, ele será trazidopara a tela do PIN onde ele inserirá o seu PIN e selecionará OK. Quandoinserindo o PIN, os caracteres alfanuméricos não aparecem na tela, mas aoinvés disso um pseudo-caractere é exibido no lugar. Também, o PIN nãopode ser encontrado em um registro de mensagem ou outros registros nodispositivo móvel. Se uma outra pessoa fosse ter acesso ao dispositivo mó-vel, ela não seria capaz de determinar o PIN.
Isso levará o dono da conta para a tela de confirmação que mos-trará para ele a seguinte informação:
Pagar para: (número do telefone alvo)
Quantia:
Quaisquer taxas de transação relevantes:
Mensagem (se ele deixou alguma)
Depois que o dono da conta seleciona OK, ele será levado auma tela com a seguinte informação:
Pagador
Se o recebedor alvo tem um dono de conta existente
Mensagem
Pago para: (número do telefone alvo)
Quantia
Data: dd/mm/aaaa hh:mm
Trans: xxxx
Se o recebedor alvo não tem uma conta existente, então umamensagem tal como: Nota: O recebedor que você pagou não é um dono deconta registrado. O recebedor recebeu uma mensagem com instruções so-bre como receber o pagamento.
Mensagem
Pago para: (número do telefone alvo)
Quantia
Data: dd/mm/aaaa hh:mm
Trans: xxxx
Recebedor:
Se o recebedor alvo é um dono de conta existente, o recebedorreceberá uma mensagem que ele tem um novo item adicionado na sua con-ta. Quando ele abre o item, ele verá um recibo de transação com a seguinteinformação:
Data: dd/mm/aaaa hh:mm
Quantia:
De: (número do telefone do pagador)
Se o recebedor alvo ainda não tem uma conta existente, o rece-bedor receberá uma mensagem de texto que diz "você tem dinheiro" e que oinstrui a acessar um sítio da web, tal como www.obopay.com para se tornarum dono de conta e receber o seu dinheiro. O processo para o registro denovo dono de conta é detalhado mais tarde nesse documento.
Se a transação financeira é iniciada pelo recebedor, a MCA éusada para iniciar a transação solicitando o pagamento do pagador. Um e-xemplo de uma transação iniciada pelo recebedor é onde um serviço de en-trega de pizza disca o número da pessoa que pediu a pizza um pouco antesde quando a pizza é entregue. Quando o dispositivo móvel é respondido, é dada ao dono da conta a oportunidade de fazer o pagamento via a infra-estrutura de pagamento móvel da presente invenção.
Para usar a MCA para solicitar dinheiro de uma conta, o dono daconta passa através de uma seqüência similar de etapas:
(1) Abrir a MCA no dispositivo móvel do dono da conta. Isso Ie- vará o dono da conta para uma tela de exibição que exibe um logotipo e slo-gan. O dono da conta então pressiona "entrar" para continuar. Isso levará odono da conta para a tela do menu principal que exibe um menu dos aspec-tos da MCA incluindo pagamento, saldo, história, solicitação de pagamento,referência ou convite, adicionar dinheiro, definições e ajuda.
(2) O dono da conta então seleciona a opção solicitação parasolicitar um pagamento e inserirá o número de telefone para o qual ele dese-ja enviar a sua solicitação.
(3) Para selecionar um número de telefone no livro de telefonedo dono da conta, o dono da conta selecionará as opções (da tecla progra- mável esquerda inferior no dispositivo móvel) e então encontrará (a partir domenu de opções) qual trará o livro de endereços de telefone existente dodono da conta e permitirá que ele selecione um nome nele. Esse livro deendereços pode corresponder, por meio de ilustração, com uma lista de nú-meros de telefones para donos de conta que solicitaram uma entrega de piz- za. Como parte da solicitação, a pessoa da entrega pode anexar uma tela degorjeta que oferece ao dono da conta a oportunidade de adicionar uma grati-ficação na quantia que ele deseja pagar.(4) Quando o recebedor seleciona OK, ele será levado para atela de mensagem onde ele pode adicionar uma mensagem para sua tran-sação. Em uma modalidade, essa mensagem pode ser um texto, anexo deáudio ou de vídeo. Se o recebedor não deseja adicionar uma mensagem, elepode simplesmente clicar OK antes de escrever uma mensagem e nenhumamensagem será adicionada na sua transação.
(5) Depois que o dono da conta seleciona OK1 ele será trazidopara a tela do PIN onde ele inserirá o seu PIN, opcionalmente inserindo umagorjeta e selecionando OK. A solicitação será enviada para o pagador quetem a opção de aprovar a transação inserindo o seu PIN e pressionando OK.Como mencionado acima, o PIN é mantido confidencial e seguro, de modoque pessoas desautorizadas não podem determinar o PIN meramente ob-tendo acesso não autorizado ao dispositivo móvel.
O pagamento será inicialmente processado e o recebedor rece-berá a notificação do pagamento. Se não existem problemas com a transa-ção, o dono da conta não receberá qualquer notificação adicional. Se quais-quer problemas surgirem com o pagamento (isto é, fundos insuficientes),ambos o dono da conta e o recebedor alvo serão notificados. A notificaçãoquanto a quaisquer problemas com o pagamento prontamente ocorrerá de-pois que o pagamento é enviado de modo que as partes possam confirmar atransação.
A MCA pode também ser usada por um dono de conta para veri-ficar o saldo atual da sua conta de débito pré-paga do seu dispositivo móvel.Para usar a MCA para verificar o seu saldo, o dono da conta passará atravésdas seguintes etapas:
(1) Abrir a MCA no telefone do dono da conta,
(2) Isso levará o dono da conta para a tela de exibição que exibeo logotipo e slogan. O dono da conta pressionará entrar para continuar.
Isso levará o dono da conta para a tela de menu principal queexibe um menu dos aspectos da MCA incluindo pagamento, saldo, história,solicitação de pagamento, cenário e ajuda. O dono da conta selecionará sal-do para verificar o seu saldo.Isso levará o dono da conta para a tela de PIN onde ele inseriráo seu PIN e selecionará OK.
Isso levará o dono da conta para a tela de saldo que proverápara ele a seguinte informação:
Data: dd/mm/aaa hh:mm
Saldo:
Quando o dono da conta seleciona OK1 ele será levado de voltapara a tela do menu principal.
A MCA pode ser usada por um dono de conta para ver a históriadas suas últimas n, onde η é um número inteiro (tal como 3 ou 5, por meiode exemplo), transações e o saldo corrente da sua conta de débito pré-pagaa partir do seu dispositivo móvel. Para usar a MCA para verificar a sua histó-ria, o dono da conta passará através das seguintes etapas:
(1) Abrir a MCA no dispositivo móvel do dono da conta. Isso Ie-vará o dono da conta para a tela de exibição que exibe o logotipo e slogan.O dono da conta então pressiona entrar para continuar.
(2) Isso levará o dono da conta para a tela de menu principal queexibe um menu dos aspectos da MCA incluindo pagamento, saldo, história,solicitação de pagamento, cenário e ajuda. O dono da conta selecionará his-tória para verificar a sua história.
(3) Isso levará o dono da conta para a tela de PIN onde ele inse-rirá o seu PIN e selecionará OK.
(4) Isso levará o dono da conta para a tela de história que prove-rá para ele a seguinte informação:
Dados da transação e quantia da transação: DD/MM (+/-)$.$$
O dono da conta será capaz de selecionar qualquer uma dastransações listadas para obter mais informação sobre essa transação espe-cífica. Para fazer isso, ele rola sobre a transação específica que ele desejaver e a seleciona. Isso o levará para uma tela com a seguinte informação:
Data: D D/M M/A A AA HH:MM:SS
Quantia: (+/-)$.$$
Para: (número de telefone do recebedor ou pagador)Mensagem: (se disponível)
O dono da conta então seleciona OK para retornar para a tela dehistória. Daqui, ele pode ver uma outra transação ou retornar para a tela domenu principal.
Além do que, o dono da conta pode associar a sua conta comsoftware de aplicação de contabilidade tal que cada transação é gravada emum banco de dados para uso no orçamento, planejamento, manutenção deregistro ou para finalidades de imposto. Nessa modalidade, o dono da contapode adicionar uma segunda mensagem que designa o pagamento, se envi-ado ou recebido, de acordo com a natureza da transação financeira. Por e-xemplo, quando o dono da conta compra uma refeição enquanto em umaviagem de negócios, a segunda mensagem pode indicar que a transação éuma despesa reembolsável, dedutível de imposto. A despesa é gravada pelosoftware de aplicação de contabilidade. O software da aplicação de contabi-lidade pode ser provido pela plataforma do servidor (ver figura 3) ou por umparceiro do provedor de software. O software da aplicação de contabilidadepode ser uma opção de valor adicionado onde o dono da conta pode pagaruma despesa mensal para acessar.
Quando o dono da conta seleciona a tecla programável de retor-no, ele será levado de volta para a tela do menu principal.
Como mencionado acima, a MCA pode ser usada para solicitardinheiro por um dono de conta da conta de qualquer outro dono de conta.Ambos o dono de conta que solicita o dinheiro e o dono da conta da qual eleestá solicitando dinheiro, devem ser donos de conta. Em uma outra imple-mentação da invenção, o serviço permite a transação de solicitação de pa-gamento para membros sem serviço (isto é, solicitação de pagamento viral).Para usar a MCA para solicitar um pagamento de um dono de conta, o donoda conta solicitante passará através das etapas seguintes. Abrir a MCA nodispositivo móvel do dono da conta solicitante. Isso levará o dono da contapara a tela de exibição que exibe o logotipo e slogan. O dono da conta entãopressiona entrar para continuar. Isso levará o dono da conta para a tela domenu principal que exibe um menu dos aspectos da MCA incluindo paga-mento, saldo, história, solicitação de pagamento, referência ou convite, defi-nições e ajuda.
O dono da conta selecionará solicitação de pagamento para so-licitar um pagamento. Isso levará o dono da conta para a tela de enviar ondeo dono da conta inserirá o número do telefone móvel de onde ele deseja en-viar a sua solicitação de pagamento. Para selecionar um número de telefoneno livro de endereços do dono da conta, o dono da conta selecionará opções(da tecla programável esquerda inferior no dispositivo móvel) e a seguir en-contrará (a partir do menu de opções) que trará o livro de endereços de tele-fone existente do dono da conta e permitirá que ele selecione um nome nele.
Depois que o dono da conta inseriu o número móvel, ele selecionará OK.
Isso o levará para a tela de quantia onde o dono da conta inseri-rá a quantia que ele deseja pagar. O dono da conta solicitante seleciona seele deseja ou não solicitar uma GORJETA (isto é, a capacidade do solicitan-te adicionar uma quantia além da quantia que ele está solicitando). Quandoo dono da conta seleciona OK, ele será levado para a tela de mensagemonde ele pode adicionar um texto ou mensagem de áudio ou vídeo para suatransação. Se o dono da conta não deseja adicionar uma mensagem, elepode clicar OK antes de escrever uma mensagem e nenhuma mensagemserá adicionada na sua transação.
Depois que o dono da conta seleciona OK, ele será trazido paraa tela do PIN onde ele inserirá o seu PIN e selecionará OK. Isso levará odono da conta para a tela de confirmação que mostrará para ele a seguinteinformação:
Enviar para: (número do telefone alvo)
Quantia:
Solicitação de gorjeta (ligado/desligado)
Quaisquer taxas de transação relevantes:
Mensagem (se ele deixou uma)
Depois que o dono da conta seleciona OK, ele será levado para
uma tela com a seguinte informação:SolicitanteMensagem
Enviado para: (número do telefone alvo)Quantia
Data: dd/mm/aaaa hh:mmTrans: xxxx
Solicitado:
O solicitado receberá uma mensagem que ele tem um novo itemdo servidor de pagamento. Quando o dono da conta abre o item, ele abrirá aMCA e levará o dono da conta para a tela de exibição que exibe o logotipo eo slogan. O dono da conta pressiona entrar para continuar. A seguir, o donoda conta será levado para a solicitação de pagamento onde ele verá a se-guinte informação.
Mensagem (se aplicável)Pagar para (número do telefone do solicitante)Quantia
Data: dd/mm/aaaa hh:mmID da transação
O recebedor será capaz de aceitar ou rejeitar a solicitação dopagamento. Se o recebedor aceita a solicitação, ele selecionará a tecla pro-20 gramável 'aceitar'. Se o recebedor aceita a solicitação e uma solicitação deGORJETA foi enviada pelo dono da conta solicitante aceitando a solicitação,isso levará o recebedor para uma tela de quantia de GORJETA onde elepode adicionar uma GORJETA. Depois de inserir a GORJETA e selecionarOK, o dono da conta será levado para a tela do PIN. Depois que o recebedorinsere o seu PIN e seleciona OK, ele será levado para a tela de confirmação.A tela de confirmação inclui a informação seguinte:
Pagar para (número de telefone do solicitante do pagamento)Quantia
GORJETA (se aplicável)Depois que o recebedor seleciona OK, a transação será proces-sada e o recebedor será levado para uma tela com a seguinte informação:Enviado para: (número de telefone do solicitante do pagamento)Quantia
Saldo:
Data D D/M M/A A AA HH:MM
Trans: (ID da transação)
Depois que o recebedor seleciona OK1 ele retornará para o me-nu principal.
Se o recebedor rejeita a solicitação, ele selecionará a tecla pro-gramável rejeitar. O solicitante do pagamento receberá uma notificaçãoquanto a se a sua solicitação de pagamento foi aceita ou rejeitada. A notifi-cação incluirá a seguinte informação:
Mensagem: (se aplicável)
De: (número de telefone do recebedor)
Quantia:
Data D D/M M/A A AA HH:MM:SS
Trans:
O dono da conta pode mudar as definições pré-definidas quesão configuráveis pelo dono da conta. Atualmente, isso inclui mudar o proto-colo (isto é, SMS ou HTTP) que ele usa para enviar e receber a informaçãode pagamento entre seu dispositivo móvel e o servidor. Isso pode tambémincluir outra informação configurável pelo dono da conta nas versões futurasda aplicação. Para mudar a definição na sua MCA, o dono da conta passariaatravés das etapas seguintes: Abrir a MCA no dispositivo móvel do dono daconta.
Isso levará o dono da conta para a tela de exibição que exibe ologotipo e slogan. O dono da conta então pressiona entrar para continuar.Isso levará o dono da conta para a tela do menu principal que exibe um me-nu dos aspectos da MCA incluindo pagamento, saldo, história, solicitação depagamento, referência ou convite, definições e ajuda.
O dono da conta selecionará definições para mudar as suas de-finições. Isso o levará para a tela de definições onde ele pode selecionar adefinição que ele deseja modificar. Atualmente, a sua única opção é protoco-lo. Quando o dono da conta seleciona protocolo, ele será levado para a telade protocolo. O dono da conta será capaz de selecionar HTTP ou SMS natela de protocolo. Por pré-definição, sua aplicação é ajustada para HTTP.Para retornar para a tela de protocolo, o dono da conta precisará selecionara tecla programável de retorno. Para retornar para o menu principal, o dono5 da conta precisará selecionar a tecla programável de retorno.
O dono da conta será capaz de ver uma tela de ajuda da MCA.Isso incluirá uma breve descrição da aplicação e instruções sobre onde odono da conta pode ir para obter mais ajuda. Para ver a seção de ajuda daMCA, o dono da conta passaria através das seguintes etapas. Abrir a MCAno dispositivo móvel do dono da conta. Isso levará o dono da conta para atela de exibição que exibe o logotipo e slogan. O dono da conta precisarápressionar entrar para continuar.
Isso levará o dono da conta para a tela do menu principal queexibe um menu dos aspectos da MCA incluindo pagamento, saldo, história,solicitação de pagamento, definições e ajuda. O dono da conta selecionaráajuda para ver a ajuda. Isso o levará para a tela de ajuda principal que omunirá com as ligações para o seguinte:
Uma breve descrição da MCA, tal como:
Obopay nos deixa enviar dinheiro, fazer compras e solicitar pa-gamentos usando seu telefone. Também usar seu cartão de débito para fa-zer compras e para sacar dinheiro. Mais:
Ligação para a página de aspectos que exibe, por exemplo:Você será convidado a inserir um número de telefone do donoda conta, uma quantia e o seu PIN quando fazendo o seguinte. Mais:
Pagamento que exibe, por exemplo:
Usar o aspecto de pagamento de Obopay para enviar dinheiropara outra pessoa com um telefone móvel ou VOIP. Se ele ainda não temuma conta de débito pré-paga, ele será direcionado para um sítio da webpara criar uma. Para cancelar um pagamento, vá para obopay.com para ob-ter informação.
Saldo que exibe, por exemplo:
Usar saldo para obter quantia disponível na sua conta.História que exibe, por exemplo:
Usar a história para obter transações recentes e saldo disponí-vel. Selecionar um para obter detalhes.
Solicitar pagamento que exibe, por exemplo:
Usar solicitação de pagamento para pedir dinheiro para um donode conta de telefone móvel. A adição de mensagem e a solicitação de gorje-ta são opcionais.
Ligação para página de ajuda na entrada de informação que exi-be, por exemplo:
Números de telefone - quando selecionando pagamento ou soli-citação de pagamento, inserir o número de telefone com o código de área.Sem traços ou espaços.
Quantias que exibe, por exemplo:
Entre $0,01 - $9999,99. Não é necessário adicionar pontos de- cirnais - adicionar zeros para quantias em dólar.
O seu PIN que exibe, por exemplo:
O seu PIN foi provido quando você ativou a sua conta. Se você oesqueceu, chamar 888-80B0PAY.
Ligação para página de ajuda em atalhos
Retorno: retorna para a tela prévia.
Limpar: apaga o último caractere digitado.
Contatos: acessa o seu livro de endereços.
Sair: fecha a aplicação.
Ligação para página de ajuda nos FAQs Garantia
Obopay provê transações seguras através da criptografia detransações na camada de rede, na camada de aplicação e na camada detransação. Para mais informação visitar www.obopay.com.
Plano de dados (Internet)
Você não precisa de um plano de dados para usar Obopay. En-tretanto, você precisará de um plano de dados para carregar Obopay paraum novo telefone. Também um plano de dados pode otimizar o desempenhodo serviço de Obopay.
Custo?
Sacar dinheiro?
Usar o seu cartão de débito em qualquer ATM que aceita umcartão de crédito ou solicitar uma verificação de Obopay emwww.obopay.com.
Cancelar transação
Para cancelar uma transação para um dono sem conta vá parawww.obopay.com/help e selecione cancelar pagamento. Os pagamentospara donos de conta podem somente ser cancelados se a transação não foiautorizada (fraude). Para cancelar uma transação não autorizada chamar888-80B0PAY
Adicionar dinheiro?
Vá para www.obopay.com e selecione o botão de carga de contaPIN esquecido.
Se você o esqueceu, chamar 888-80B0PAY.
Ligação para página de ajuda no suporte
Para mais informação, vá para obopay.com ou chame 888-80B0PAY
Ligação para página de ajuda em sobreversão de software
Tamanho do arquivo:
Vantajosamente, a MCA possibilita que os donos da conta criemum perfil fora de linha que pode ser configurado para resposta automáticaquando o seu dispositivo móvel está desligado ou fora de alcance. Por e-xemplo, o dono da conta poderia configurar a sua conta para aceitação au-tomática de depósitos de dinheiro ou aceitação automática de saques dedonos de conta especificados. Se o dispositivo móvel do dono da conta estáligado, quaisquer transações fora de linha poderiam ser recuperadas cha-mando o servidor de pagamento para uma pesquisa de saldo ou uma solici-tação de história. Em outras alternativas, o dono da conta poderia especificarque a informação da conta fosse entregue por SMS ou correio de voz.Protocolo de transmissão de dados (wire protocol)Protocolo de transmissão de dados da plataforma e MCAVisão geral
O protocolo de transmissão de dados da plataforma e MCA éusado em conjunto com o codec da MCAP para serializar/desserializar (seri-alize/deserialize) dados para comunicação entre vários dispositivos execu-tando MCAs e o centro de dados alojando serviços baseados em J2EE. Oprotocolo de transmissão de dados da plataforma e MCA especifica o forma-to dos dados serializados passados entre os dispositivos e o centro de da-dos. O codec da MCAP é o componente nos dispositivos móveis e o centrode dados manipula a serialização e a desserialização de acordo com as es-pecificações do protocolo de transmissão de dados da plataforma e MCA. Afigura 59 mostra uma ilustração direta dos conceitos básicos.
O seguinte mostra solicitações de serviço do dispositivo móvel erepresentações de transmissão de dados exemplares.
Uma solicitação de serviço que é iniciada pelo dispositivo móvelé a chamada PaymentService.payP2P. Essa função executa o pagamentode dono de conta para dono de conta, a assinatura do método java é:
Qualquer coisa diferente de um valor de retorno é explicada nodiagrama. Na resposta, o valor de retorno é incluído além de código extra(overhead), a seqüência do valor de retorno começa com um código do tipode objeto (9 nesse caso, traduzir para CommonPaymentSummary), atributosnão nulos do valor de retorno segue, por exemplo, atributo #1 - paymentA-mount - tem um valor de $1,27, etc.
Fazer referência agora à figura 60 que é um exemplo que mostrauma invocação bem sucedida da chamada de serviço invocando a chamadaPaymentService.retrieveBalance. Essa chamada recupera o saldo da contapara uma conta.
A parte de solicitação não é diferente do exemplo prévio, mas aresposta agora representa uma exceção sendo lançada como um resultadoda chamada do serviço. O tipo de objeto 6 representa um valor de retorno dotipo EWPBusinessException, seus atributos são explicados na figura 61.Uma outra solicitação de serviço do dispositivo móvel e repre-sentações de transmissão de dados exemplares é a chamada PaymentSer-vice.retrieveHistory. Como o nome indica, essa função recupera a história datransação de uma conta.
A figura 62 demonstra uma invocação bem-sucedida, o úniconotável aqui é que o "tipo de objeto" (10) do valor de retorno é agora seguidopor um indicador de seta "<", isso significa que o valor de retorno é um ar-ranjo de objetos do tipo 10, que significa CommonTransactionSummary.
Uma outra solicitação de serviço iniciada pelo dispositivo é afunção requestPay que é usada para solicitar um pagamento de um outromembro.
A função payRequestPay é usada em resposta à chamada re-questPay, essa chamada aprova o pagamento solicitado.
Uma outra função é a função RegistrationService.whoAml queestabelece o serviço com o centro de dados e é chamada quando a aplica-ção é invocada pela primeira vez.
Uma outra categoria de solicitações é essa enviada pelo servi-dor, as características dessas solicitações são que (1) elas são atualmentesomente enviadas por SMS, (2) elas são geralmente notificações de eventosdo servidor para os dispositivos, (3) não existem respostas síncronas paratais solicitações.
Para ser consistente com a arquitetura de plataforma e MCA quelida com as chamadas iniciadas pelo dispositivo, a presente invenção im-plementou o manipulador de tais notificações no dispositivo como "serviçosdo dispositivo" com as mesmas assinaturas ServiceProxy quando métodosnesses "serviços do dispositivo" são invocados do lado do servidor. O proto-colo de transmissão de dados e codec são exatamente os mesmos que es-sas solicitações iniciadas pelo dispositivo. Aqui está uma lista de "serviçosdo dispositivo" atualmente disponíveis e seus métodos:
Serviço de pagamente J2ME
P2pNotify - notifica o alvo de p2p do pagamento
requestPay - notifica o membro de uma solicitação requestPaynotifyRequestPayReceived - notifica o alvo da operação de soli-citação de pagamento da recepção do pagamento da solicitação de paga-mento.
cancelViraINotify - notifica o alvo viral do cancelamento do pa-gamento viral
Visão geral técnica da MCAP
Outros serviços de dispositivo podem ser facilmente definidos eadicionados na MCA e são julgados como sendo baseados nas considera-ções técnicas de uma modalidade particular.
O projeto de alto nível da MCA & plataforma (MCAP), bem comoos esboços seqüenciais da interface do usuário (UI)1 é agora discutido e a-presenta um conjunto completo de aspectos móveis que são esperados erequeridos pela MCAP. A MCAP é basicamente uma aplicação de consumi-dor/comerciante móvel de "carteira móvel" ou de "pagamento por telefone".
A interface do usuário da MCAP é simples já que ela somente requer a en-trada etapa por etapa dos dados de solicitação (tais como quantia, PIN1 etc.)e a seguir exibição dos dados de resposta. Por meio de ilustração e compa-ração, a interface do usuário da MCAP não requer as complexidades gráfi-cas de uma aplicação de jogo móvel.
De preferência, a MCAP é escrita em uma linguagem que é fa-cilmente portada para funcionar em tantos dispositivos móveis quanto possí-vel. Entretanto, a infra-estrutura da MCAP espera que certa funcionalidadeesteja presente no dispositivo móvel. Por exemplo, a capacidade de exibircampos de entrada e capturar entradas do dono da conta é requerida. A ca-pacidade de utilizar os serviços de dados do dispositivo móvel via invoca-ções da API HTTPS programáticas é também requerida se a capacidade deutilizar os serviços de texto SMS do dispositivo móvel via invocações da APISMS programáticas não está disponível.
A capacidade para utilizar os serviços de dados persistentes dodispositivo móvel via invocações da API programáticas. Por exemplo, a ca-pacidade de armazenar dados persistentemente no cartão SIM ou outramemória não transitória é uma funcionalidade opcional. Similarmente, a ca-pacidade de interceptar as mensagens que chegam para o dispositivo móvele "acordar" a MCAP para processamento é também opcional. Essa funciona-lidade provê, por exemplo, a capacidade de interceptar uma mensagemSMS que chega (em uma porta específica) e tratá-la pela MCAP. A capaci-dade de integrar programaticamente com o "livro de endereços" do dispositi-vo móvel tal que um campo de entrada específico pode ser "vinculado" aolivro de endereços é também opcional. A capacidade de notificar programati-camente o dono da conta do dispositivo móvel dos eventos notáveis via som,vibração ou luz é opcional.
De preferência, a MCAP é modularizada tal que ela é facilmenteimplementada em J2ME e demonstrada em .NET bem como J2ME, BREW,Symbian e .NET CF (previamente Windows Mobile).
A figura 63 mostra as camadas de projeto OMAP de alto nívelpara um dispositivo móvel.
A figura 64 é um diagrama de fluxo que mostra o projeto de co-municação OMAP e o esquema de codificação de solicitação/resposta queusa uma única seqüência de texto com pares delimitados de parâme-tro/valor.
A figura 65 mostra o projeto de persistência OMAP utilizando omecanismo de memória persistente do dispositivo móvel e um diagrama deestado que mostra o projeto de notificação do usuário ΟΜΑΡ.
A figura 66 mostra a paleta de tela OMAP para uma modalidade.
A figura 67 é um diagrama de estado que mostra as transiçõesde tela ΟΜΑΡ.
A figura 68 mostra um Ieiaute para o menu principal ΟΜΑΡ.
A figura 69 mostra o fluxo de tela de pagamento OMAP da pers-pectiva da origem. Em outras modalidades da invenção, o aspecto de "pagardinheiro" pode ser chamado "enviar dinheiro" no lugar disso.
A figura 70 mostra o fluxo de tela de pagamento OMAP da pers-pectiva do alvo.
A figura 71 mostra o fluxo de tela de solicitação de pagamentoOMAP da perspectiva da origem da solicitação. Em outras modalidades dainvenção, o aspecto de "solicitar pagamento" pode ser chamado "obter di-nheiro" no lugar disso.
A figura 72 mostra o fluxo de tela de solicitação de pagamentoOMAP da perspectiva de aceite do alvo.
A figura 73 mostra o fluxo de tela de solicitação de pagamento
OMAP onde o alvo nega uma solicitação.
A figura 74 mostra o fluxo de tela de solicitação de pagamentoOMAP onde ambos a origem e o alvo aceitam uma solicitação.
A figura 75 mostra o fluxo de tela de solicitação de pagamentoOMAP onde ambos a origem e o alvo negam uma solicitação.
A figura 76 mostra o fluxo de tela de saldo ΟΜΑΡ.
A figura 77 mostra o fluxo de tela da história ΟΜΑΡ.
A figura 78 mostra o fluxo de tela das definições OMAP na ori-gem.
A figura 79 e 80 mostram os fluxos de tela do sistema ΟΜΑΡ.
Especificamente, a figura 79 mostra o fluxo de leia para o OMAP para um IDmóvel desconhecido. A figura 80 mostra o fluxo de tela de exceção do sis-tema OMAP onde uma solicitação falha.
As figuras 81 a 86 mostram telas do usuário e fluxos para umaaplicação de telefone móvel para execução de pagamentos de pessoa parapessoa. Em uma implementação, essa aplicação é uma aplicação indepen-dente que funciona em um telefone móvel que possibilita que os usuáriosenviem pagamentos para outros usuários, solicitem pagamento de outrosusuários, verifiquem a informação de saldo, verifiquem a história da transa-ção e executem outras funções.
O usuário pode mudar as definições tais como o tamanho dafonte (por exemplo, pequena, média ou grande). Um protocolo para comuni-cação com o sistema pode ser selecionado, tais como HTTPS, HTTP ouSMS. O usuário pode solicitar que exista uma notificação de som ou luz, ouambos, quando recebendo um pagamento. Existe uma alternação de gorje-ta, então o usuário pode ter uma tela de gorjeta exibida ou não exibida noalvo (ou telefone do recebedor) para uma solicitação de pagamento. A se-guir, o recebedor pode enviar mais dinheiro do que o usuário solicitou nasolicitação de pagamento.
Existe um menu de contatos onde um usuário pode salvar e es-colher contatos para pagar ou dos quais solicitar pagamento. Existe umcampo de mensagem ou de memorando onde um usuário pode inserir umamensagem junto com a solicitação de enviar pagamento ou solicitar paga-mento. Por exemplo, o usuário pode dizer ao alvo, "dinheiro p/ almoço". E-xiste uma tela onde o usuário pode inserir o pin do usuário. O pin não seráexibido, mas ao invés disso, asteriscos, espaços em branco ou um outro ca-ractere será exibido no lugar. Pode existir uma tela para listar toda a transa-ção e proporcionar ao usuário uma oportunidade para confirmar a transaçãoantes de enviar. Se existe um erro, o usuário pode selecionar editar a tran-sação antes de enviar.
A aplicação pode também incluir uma ajuda ou um guia breve dousuário para auxiliar o usuário e responder a pergunta do usuário quanto aouso do sistema.
API dos Serviços financeiros
A interface entre os dispositivos móveis e o proxy do serviço daplataforma de carteira eletrônica (EWP) inclui componentes de serviço talcomo o serviço de pagamento e o serviço de registro e sua hierarquia de altonível dos objetos de exceção. As classes de transporte de dados de negó-cios que são retornadas das chamadas de serviço são também descritas.
Serviço de pagamento
Esse serviço de negócios é definido e implementado de acordocom uma definição da infra-estrutura do serviço de aplicação para a EWP. Oserviço de pagamento compreende chamadas de método de repasse paraum sistema bancário parceiro. O banco parceiro gerencia o sistema oficial deregistros, processamento de pagamento e informação de conta e membro.Os dados controlados dentro da EWP que estão além do que é necessáriopara integrar com o banco parceiro são para uso interno somente.
Pacote:
com.ewp.servicesClasse.
As interfaces de programação de aplicação (APIs) definidas paraesse serviço são:
payP2P - executa uma transação de dono de conta para donode conta (p2p) entre dois membros consumidores.
retrieveBalancee - recupera o saldo disponível para a conta es-pecificada
retrieveHistory - recupera os últimos cinco registros de transaçãopara a conta especificada, incluindo uma sexta linha que mostra o saldo dis-ponível
requestPay - primeira etapa de uma interação de duas partesonde um membro solicita pagamento de um outro membro
payRequestPay - segunda etapa de uma interação de duas par-tes onde o recebedor da solicitação para pagamento faz o pagamento ourejeita fazer o pagamento
Detalhes são providos nas subseções seguintes. Observe quequaisquer valores monetários retornados serão apresentados como um tipojava.lang.String com o seguinte formato <símbolo monetá-rio><dólares><centavos>. Por exemplo, vinte dólares e vinte e cinco centa-vos em dólares americanos têm a representação de seqüência "$20,55".Assinatura do método: payP2P
Esse método suporta uma chamada de um dispositivo móvelpara fazer um pagamento para um outro membro que tem uma conta asso-ciada com um número de dispositivo móvel. O resultado da transação é en-viado para o telefone móvel do membro que chama. Além disso, uma notifi-cação para recepção do dinheiro é enviada para o recebedor.Parâmetros de entrada:
srcDevKey - Valor de seqüência que é geralmente o número detelefone da conta que inicia o pagamento
srcPin - Valor de seqüência que é o PIN para a conta que faz asolicitação
tgtDevKey - Valor de seqüência que é geralmente o número detelefone da conta que recebe o pagamento
transactionAmount - Valor de seqüência que é a quantia do pa-gamento a fazer para a conta receptora.
paymentMemo - Seqüência que é uma nota curta do pagadorpara o recebedor do pagamento.
Objeto do tipo de retorno:
PaymentSummary - objeto de recipiente que inclui o número deconta alvo, quantia de pagamento e dados de saldo disponível. Ver descri-ção de classe PaymentSummarv para mais informação.
Assinatura do método: retrieveBalance
Esse método suporta uma chamada de um dispositivo móvelpara obter o saldo da conta corrente do membro. O resultado é enviado parao telefone móvel do membro que chama.
Parâmetros de entrada:
devKey - Valor de seqüência que é geralmente o número de te-lefone da conla que está solicitando o seu saldo.
pin - Valor de seqüência que é o PIN para a conta que faz a soli-citação.
Objeto do tipo de retorno:
BalanceSummary - objeto do recipiente que inclui os dados desaldo disponível. Ver descrição de classe BalanceSummary para mais infor-mação.
Assinatura do método: retrieveHistory
Esse método suporta uma chamada de um dispositivo móvelpara recuperar as cinco transações mais recentes do membro e inclui o sal-do de conta corrente na sua exibição da história. O resultado é enviado parao telefone móvel do membro que chama.
Parâmetros de entrada:
devKey - Valor de seqüência que é geralmente o número de te-lefone da conta que está solicitando a sua história de transação.
pin - Valor de seqüência que é o PIN para a conta que faz a soli-citação.Objeto do tipo de retorno:
TransactionSummary[] - um arranjo de objetos de recipiente emque cada um inclui o valor da quantia, chave de débito/crédito/saldo e carim-bo de tempo dos dados da transação. Ver descrição de classe Transaction-Summary para mais informação.
Assinatura do método: payRequestPay
Esse método suporta uma chamada de um dispositivo móvelpara aceitar ou rejeitar uma solicitação por pagamento. O resultado da tran-sação é enviado para o telefone móvel do membro que paga. Além disso,uma notificação para recepção do dinheiro é enviada para o recebedor.
Parâmetros de entrada:
payerDevKey - Valor de seqüência que é geralmente o númerode telefone da conta que satisfaz a solicitação para pagamento (o mesmoque a fonte para payP2P)
payerPin - Valor de seqüência que é o PIN para a conta que sa-tisfaz a solicitação para pagamento.
tgtDevKey - Valor de seqüência que é o número de telefone daconta que recebe o pagamento ou uma chave de referência usada para i-dentificar uma chave de conexão JNDI para um dispositivo associado com aconta recebendo o pagamento
paymentAmount - Valor de seqüência que é a quantia de paga-mento a fazer para a conta recebedora.
tipAmount - Valor de seqüência que é a quantia do pagamentode gorjeta a adicionar no total da transação
acceptRequest - Valor booleano que indica se a solicitação parapagamento foi aceita ou não (verdadeiro = aceito)
transactionRef - Valor de seqüência que é o número de referên-cia da transação da solicitação original para pagamento
requestText - Seqüência que é a nota curta do dono da contasolicitando o pagamento para o dono da conta fazendo o pagamento.
memoText - Seqüência que é uma nota curta do pagador para orecebedor do pagamento.Objeto do tipo de retorno:
PayRequestSummary - objeto do recipiente que inclui o númerode referência da transação, número de conta alvo, quantia de pagamento edados de saido disponível. Ver descrição de classe PayRequestSummary para mais informação.
Assinatura do método: requestPay
Esse método invoca um método de serviço de dispositivo paranotificar o membro alvo sobre uma solicitação para pagamento de um outromembro.
Parâmetros de entrada:
srcDevKey - Valor de seqüência que é o número de telefone daconta iniciando a solicitação para solicitação de pagamento ou uma referên-cia de chave usada para identificar uma chave de conexão JNDI para umdispositivo associado com a conta fazendo a solicitação por pagamento. srcPin - Valor de seqüência que é o PIN para a conta que faz asolicitação
tgtDevKey - Valor de seqüência que é geralmente o número detelefone da conta que deve receber a solicitação para notificação de paga-mento
transactionAmount - Valor de seqüência que é a quantia do pa-gamento solicitado.
tipRequest - Valor booleano que indica se apresentar ou nãouma tela de solicitação de gorjeta para o recebedor da solicitação.
requestText - Seqüência que é uma nota curta do solicitante do pagamento para o dono da conta fazendo o pagamento.
Objeto do tipo de retorno:
PayRequestSummary - objeto do recipiente que inclui o númerode referência da transação, número de conta alvo, quantia de pagamento edados de saldo disponível. Ver descrição de classe PayRequestSummary para mais informação.
Serviço de registro
Esse serviço de negócios é definido e implementado de acordocom a definição da infra-estrutura do serviço de aplicação para a EWP. Oserviço de registro provê métodos a serem usados para chamadas de servi-ço da web do sistema do banco parceiro de volta para o sistema EWP. Em-bora o banco parceiro mantenha a informação de conta e membro oficiais, aEWP precisa saber o mapeamento entre o número de cartão de débito pré-pago de um membro e o número de telefone móvel do membro. Esses da-dos, e potencialmente mais, serão persistentes no sistema EWP.
Pacote:
com.ewp.services
Classe:
As interfaces de programação da aplicação (APIs) definidas paraesse serviço são:
addRegistrationlnfo - cria registros de dados pertencentes a umaconta
Detalhes são providos na subseção seguinte.
Assinatura do método: addRegistrationlnfo
Esse método persiste o número do dispositivo como um registrode dados da conta. Se mais informação está disponível, tal como nome domembro, então o método também persistirá a informação adicional. Refe-rências entre objetos de dados serão feitas como necessário. O método re-torna um objeto do recipiente que indica o estado de registro da conta.
Parâmetros de entrada:
regContainerList - objeto do recipiente RegistrationContainer quecontém de modo mínimo o telefone associado com uma conta.
Objeto do tipo de retorno:
ArrayList de objetos RegistrationContainer - uma lista de objetosdo recipiente contendo informação que deve ter persistido.
Objetos de transferência
Cada um dos objetos de transferência descrito nessa seção pro-vê procriadores e compositores para cada um dos seus atributos de classe eum construtor predefinido. Os objetos nessa seção implementam a interfacejava.io.Serializable e uma interface Transferlnterface, que é um dono de lu-gar para as necessidades comuns potenciais da interface bem como pro-vendo um tipo de base.
BalanceSummary
O objeto do recipiente retornado da API paymentServicelnterfa-ce.retrieveBalanceMobile().
Pacote:
com.ewp.transferobjectsClasse:
public class BalanceSummary
implementa Transferlnterface, Serializável
Atributos:
currentBalanceAmount - Valor da seqüência que é a quantiamonetária de fundos atualmente disponível para uso
errorCode - Valor da seqüência que indica a natureza do erro,ajustar somente se estado = 0
status - Valor da seqüência que indica se um erro ocorreu ounão durante a execução do serviço: 1 = OK, 0 = erro
requestDate - Valor da seqüência que é o carimbo de tempo daauditoria para a solicitação de saldo
PaymentSummary
O objeto do recipiente retornado da API PaymentServiceInterfa-ce.payP2PMobile(). Esse objeto é também passado nas chamadas de au-tenticação de notificação para a interface do dispositivo móvel com valorespara exibição.
Pacote:
com.ewp.transferobjects
Classe:
public class PaymentSummary
implementa Transferlnterface, Serializável
Atributos:
newBalanceAmount - Valor da seqüência que é a quantia mone-tária dos fundos atualmente disponível para uso.paymentAmount - Valor da seqüência que é a quantia monetáriados fundos pagos
sourceDeviceKey - Valor da seqüência que é o número de tele-fone da conta que fez o pagamento
targetBalanceAmount - Valor da seqüência que é a quantia mo-netária dos fundos atualmente disponíveis para uso na conta alvo
targetDeviceKey - Valor da seqüência que é o número do telefo-ne da conta para a qual o pagamento foi feito
errorCode - Valor da seqüência que indica a natureza do erro,ajustar somente se estado = 0
status - Valor da seqüência que indica se um erro ocorreu ounão durante a execução do serviço: 1 = OK, O = erro
requestDate - Valor da seqüência que é o carimbo de tempo datransação para a solicitação de pagamento
O objeto do recipiente retornado da API PaymentServiceInterfa-ce.retrieveHistoryMobile().
Pacote:
com .e wp.transf e robjects
Classe:
public class TransactionSummary
implementa Transferlnterface, Serializável
Atributos:
transactionDate - Valor da seqüência que é um valor do tempouniversal coordenado (UTC) representado por milissegundos desde a meia-noite de 1 de janeiro de 1970. A data é essa da transação inicial.
settleDate - Valor da seqüência que é um valor do tempo univer-sal coordenado (UTC) representado por milissegundos desde a meia-noitede 1 de janeiro de 1970. A data é essa de quando a transação foi liquida-da/concluída.
transactionAmount - Valor da seqüência que é a quantia monetá-ria da transação específica
transactionKey - Valor da seqüência que indica se a quantia datransação representa um crédito ("+"), débito ("-") ou saldo ("saldo").
transactionType - Valor da seqüência que indica o tipo de tran-sação: P2P, POS1 ATM, CARGA, SAL
IocationName - Valor da seqüência que identifica onde a transa-ção ocorreu, por exemplo, um ID de loja ou um ID de ATM
errorCode - Valor da seqüência que indica a natureza do erro,ajustar somente se estado = O
status - Valor da seqüência que indica se um erro ocorreu ounão durante a execução do serviço: 1 = OK, O = erroPayRequestSummary
Um objeto do recipiente passado nas chamadas de autenticaçãode notificação para a interface do dispositivo móvel com valores para exibi-ção. Pacote:
com.ewp,transferobjectsClasse:
classe pública PayRequestSummaryimplementa Transferlnterface, Serializável
Atributos:
acceptRequest - Valor booleano que indica se a solicitação parapagamento é aceita ou não. O valor de VERDADEIRO significa para proces-sar um pagamento p2p.
paymentAmount - Valor da seqüência que é a quantia monetáriados fundos a serem pagos
payerBalanceAmount - Valor da seqüência que é a quantia monetária dos fundos atualmente disponíveis para uso
payerDeviceKey - Valor da seqüência que é o número de telefo-ne da conta para a qual um pagamento é solicitado
requesterDeviceKey - Valor da seqüência que é o número detelefone da conta fazendo a solicitação de pagamento e para quem um pa-gamento será feito
targetBalanceAmount - Valor da seqüência que é a quantia mo-netária dos fundos atualmente disponíveis para uso na conta alvotransactionRef - Valor da seqüência que é o número de referên-cia da transação gerado pelo servidor
errorCode - Valor da seqüência que indica a natureza do erro,ajustar somente se estado = 0
status - Valor da seqüência que indica se um erro ocorreu ounão durante a execução do serviço: 1 = OK1 O = erro
requestDate - Valor da seqüência que é o carimbo de tempo datransação para a solicitação de pagamento
tipRequest - Valor booleano que indica se uma quantia de gorje-ta deve ser solicitada ou não do recebedor
Classes de exceção
EWPServiceException
A classe de exceção de base definida para o sistema EWP. To-das as exceções lançadas dos serviços herdarão dessa classe de base ouuma de suas subclasses. Pacote:
com.ewp.core. exceptionsClasse:
classe pública EWPException estende ThrowableAtributos:
errorCode - Valor da seqüência que identifica um código de erroúnico no sistema EWP. Esse código será definido como uma constante Ja-va. Ele será usado nos arquivos message.property para identificar seqüên-cias de localização.
errorText - Valor da seqüência da mensagem de erro que é re-gistrado no registro do sistema EWP.
InternaIException
Essa exceção representa todos os erros do sistema e serviçoque ocorrem que devem ser mantidos internos ao sistema EWP. A origemdesses erros tipicamente não é propagada de volta para a aplicação do cli-ente. Pacote:
com.ewp.core.exceptionsClasse:classe pública InternaIException estende EWPExceptionAtributos: herdados da classe pai.BusinessException
Essa exceção representa erros que podem ser apresentadospara a aplicação do cliente. A mensagem de erro contida no objeto da exce-ção não é a mensagem mostrada para um dono de conta. A mensagem deerro retornada para um dono de conta estará em uma forma inteligível para odono da conta e localizada. A tradução de errorCode para mensagem deerro ocorre na porta. Pacote:
com.ewp.core.exceptionsClasse:
classe pública BusinessException estende EWPExceptionAtributos: herdados da classe pai.Códigos de erro
Códigos de erro que algumas vezes aparecem como código deestado do evento TrasactionEvent e código de estado do evento AuditEvent.Favor fazer referência a ErrorCodesAndNotifications.doc para códigos deerro e definições.
Objetos de negócios
Essa seção trata dos objetos de dados usados em uma modali-dade. Um conjunto de objetos de dados é definido nos documentos do proje-to EWP_Design_Pilot.doc e EWPDOModel_v2.vsd. Esses objetos represen-tam todo o projeto do sistema EWP além dessa modalidade. Exemplos dosobjetos de negócios para uma modalidade são apresentados na tabela se-guinte. Será verificado que os próprios objetos podem conter somente umsubconjunto dos atributos propostos no modelo de projeto EWPDOMo-del_v2.vsd.
A tabela seguinte mostra o nome da classe do objeto de negó-cios, seu nome de tabela de dados correspondente, os nomes de atributo, osnomes da coluna da tabela de dados correspondente e uma taxa estimadade crescimento para a tabela de dados.<table>table see original document page 190</column></row><table><table>table see original document page 191</column></row><table><table>table see original document page 192</column></row><table><table>table see original document page 193</column></row><table><table>table see original document page 194</column></row><table><table>table see original document page 195</column></row><table><table>table see original document page 196</column></row><table><table>table see original document page 197</column></row><table><table>table see original document page 198</column></row><table><table>table see original document page 199</column></row><table>
Legenda: Objeto de negócios / nome da tabela de dados / atributos usados /nome da coluna da tabela de dados / taxa de crescimentoConta/ 80 registros de solicitações inicialmente / 4 registros de solicitaçõesvirais por semana /1 por registro / todos os eventos da transação + solicita-ções de registros / 2 por conta por dia / membro / membro consumidor Illl (*)1 por registro / membro comerciante Illl (*) 1 por registro / endereço / perfil /convite
(*) se dados do membro são mantidos
Texto em itálico indica campos que não serão definidos.
Texto em negrito indica campos que serão definidos, mas nãoserão usados (valores nulos nos objetos).
PaymentProcessorHelper
Essa seção define as APIs de teste para emular a existência dobanco parceiro como o processador de pagamento e mantenedor do sistemade registro. Pacote:
com.ewp.integration.interface - define os métodos ajudantes.com.ewp.integration.implementations - para implementações dainterface a ser usada pelos serviços executando os métodos ajudantes com.ewp.integration.paymentProcessor - para serviços execu-tando o método ajudanteClasse:
classe pública PaymentProcessorHelper
As interfaces de programação da aplicação (APIs) definidas parao ajudante são:
balance = manipula a solicitação para retornar o saldo disponível
atual
history - manipula a solicitação para retornar uma lista dos cinco(5) últimos registros de transação e um saldo atual p2p - manipula a transação de pagamento p2p
verifyPin - manipula a solicitação para validar um pin contra uma
conta
Assinatura do método: saldopublic BaIanceSummary balance ( String sourceMobilelC, String sourcePIN)
Assinatura do método: históriapublic TransactionSummary[]hisroty(String devNumber,String pin);
Assinatura do método: p2ppublic PaymentSummary.p2p(String srcDevNumber,string srcPin,String tgtDevNumber, String transactionAmoun);
Serviços de valor adicionado
Muitos pequenos negócios usam um serviço de contabilidadecomercial para lidar com os recebíveis das contas e sua razão geral. A pre-sente invenção preferivelmente se vincula no serviço de contabilidade paraprover um serviço de valor adicionado que elimina uma etapa de entrada dedados e mantém um registro apropriado de todas as transações. Quandouma transação financeira é concluída, a plataforma de pagamento posta opagamento automaticamente para o sistema de recebível das contas. Umamensagem, anotação de voz ou outro recurso de designação do tipo detransação financeira é também enviado para o serviço de contabilidade.
Transações fora de linha
As modalidades da presente invenção discutidas se referem aum sistema em linha em tempo real onde o saldo do dono da conta é manti-do no servidor de pagamento. Entretanto, existem casos onde uma opção depagamento fora de linha é desejável. Dessa maneira, em uma modalidadeda presente invenção, o saldo na conta do dono da conta é armazenado emum circuito integrado preso ou associado com o dispositivo móvel. O circuitointegrado, que é freqüentemente citado como um circuito integrado inteligen-te, é atualizado à medida que as transações ocorrem. Um exemplo de um talcircuito integrado inteligente é um circuito integrado inteligente fabricado porSony Corporation e conhecido como o circuito integrado FeIiCa. Uma trans-missão em lote no fim do dia ocorre entre cada comerciante e o provedor dosistema de pagamento para efetuar a quitação.
A opção do pagamento fora de linha é ilustrada nas figuras 87 e88 em conjunto com a arquitetura em linha em tempo real de uma modalida-de da presente invenção que é mostrada na figura 89. Com referência emprimeiro lugar à figura 89, a MCA 8901, residente no dispositivo móvel 8701,faz interface com um circuito integrado (associado com o dispositivo móvel8701) que funciona como o gerenciador fora de linha 8702. Ambos a MCA eo gerenciador fora de linha 8902 têm acesso a uma memória compartilhada8903. Em uma modalidade, o gerenciador fora de linha 8902 também temuma memória interna onde ele armazena cada transação antes que ele atua-lize a memória compartilhada 8903. O gerenciador fora de linha 8902 é con-trolado pela MCA em termos de definição de um saldo de conta inicial dispo-nível para as transações fora de linha, bem como limpando as transaçõesultrapassadas do gerenciador fora de linha 8902 depois que o dispositivo8901 sincroniza novamente as contas. A nova sincronização é executadapela MCA 8901 usando a plataforma de comunicações 8904 em um tempoestabelecido todo dia ou quando uma transação em linha perto de ocorrer éiniciada pelo dono da conta.
Fazer referência agora à figura 87, quando o gerenciador fora delinha é ativado e detecta um terminal POS do comerciante, uma transaçãopode ocorrer no modo fora de linha. Desse modo, o gerenciador fora de linha8902 é responsável pela interface com o terminal do POS 8702 para deduzira quantia da transação. Quando o gerenciador 8902 detecta uma solicitaçãode pagamento, ele envia uma mensagem para a MCA solicitar autorizaçãoou, alternativamente, aguarda a autorização do usuário. Tal autorização po-de ser uma tecla selecionada ou combinação de teclas sendo pressionadasem resposta à solicitação de autorização. Como indicado pela seta de refe-rência 8703, o pagamento é enviado para o POS 8702. Em resposta, o POS8702 aceita o pagamento e envia um recibo como indicado pela seta de refe-rência 8704. O gerenciador 8902 mantém um saldo corrente da quantia dis-ponível para compras fora de linha como indicado em 8705.
Em um momento posterior, o dispositivo móvel 8701 deve sin-cronizar novamente com o servidor de pagamento 8806, um processo que éilustrado na figura 88. Desde que o gerenciador fora de linha mantém o sal-do do dono da conta disponível para compras fora de linha, ele periodica-mente envia um relatório de gasto fora de linha e o saldo final para o servi-dor de pagamento 8806 como indicado pela seta de referência 8807. Tipi-camente, a nova sincronização ocorre no fim ou no começo de cada dia. Du-rante a nova sincronização, o gerenciador fora de linha transmite para o ser-vidor 8806 o resumo das transações, que inclui a quantia da transação juntocom um carimbo de data e o número de identificação do comerciante comoindicado pela seta de referência 8808. O servidor 8806 reconhece a transa-ção e reajusta a quantia da transação fora de linha disponível para um valorapós a sincronização como indicado pela seta de referência 8809. É para serentendido que o valor armazenado para uso pelo gerenciador fora de linhapode ser selecionado pelo usuário. Assim, a cada dia, semana ou mês, odono da conta poderia iniciar com uma quantia pré-selecionada de fundosdisponíveis para transações fora de linha. Para confirmar os saldos, o servi-dor 8806 também sincroniza as contas com cada comerciante 8802 comoindicado pela seta de referência 8810.
As vantagens dessa modalidade fora de linha comparada com oenvio de dinheiro fora de linha através de um telefone móvel equipado so-mente com um circuito integrado inteligente incluem:
(1) A perda do dispositivo móvel não significa perda do dinheiroporque com a sincronização em linha, as contas podem ser fechadas e ossaldos podem ser transferidos para uma nova conta e
(2) As contas com problema podem ser facilmente desativadas ea seguir novamente habilitadas depois da resolução do problema.
A vantagem primária da transação fora de linha é o tempo detransação muito pequeno para concluir uma transação. As transações forade linha são um benefício para o dono da conta onde uma transação autori-zada por rede pode ser muito lenta. Entretanto, a combinação do modeloautorizado por rede em tempo real da presente invenção quando combinadocom as capacidades de pagamento fora de linha provê um sistema versátil,adaptável e útil.
Como descrito acima, a presente invenção se refere a uma pla-taforma de pagamento móvel e serviço que provê um método rápido, seguroe fácil para fazer pagamentos por indivíduos usando um dispositivo móvel.Os fundos são acessados do dispositivo móvel do dono da conta, que podeser um telefone celular, PDA ou outro dispositivo de comunicação orientadoa pacote, para fazer e receber pagamentos. As transações financeiras sãoconduzidas em uma base de pessoa para pessoa (P2P) onde cada parte éidentificada por um indicador único tal como um número de telefone ou códi-go de barras. Uma aplicação de cliente móvel (MCA), residente no dispositi-vo móvel, simplifica o acesso e a execução das transações financeiras emuma maneira rápida, segura.A figura 90 mostra a infra-estrutura da aplicação J2ME para aMCA de acordo com uma modalidade da presente invenção. As seqüênciasde tela 9000 são compostas de uma série de uma ou mais instâncias declasses DataScreen, tal como ilustrado em 9001. Uma instância DataScreenpermite que um usuário proveja entrada específica ou informação de leitura.Especializações de DataFieIdScreen 9002 permitem a entrada para umaquantia em dólar, número de telefone, texto ou número de identificação pes-soal, etc. Instâncias DataFieIdScreen são responsáveis por validar a entradados dados do usuário. MenuDataScreen 9003 e ListDataScreen 9004 prove-em várias capacidades de seleção de menu e lista. Variações implementama seleção única (botão de rádio), múltiplas seleções (caixas de verificação)ou interação do estilo do menu. Instâncias ReadOnIyDataScreen 9005 pro-veem saída. Especializações proveem formatação apropriada para os dadossendo exibidos. Variações implementam a seleção única (botão de rádio),múltiplas seleções (caixas de verificação) ou interação do estilo do menu.Instâncias ReadOnIyDataScreen proveem saída. Especializações proveemformatação apropriada para os dados sendo exibidos.
A figura 91 mostra os diagramas de seqüência de tela e iniciali-zação da aplicação (MCA). A seqüência de partida da aplicação mostrada nafigura 91 mostra como a classe de base do menu gerencia a exibição e aseleção dos seus itens de menu contidos. Classes do item de menu definemsua funcionalidade associada - por exemplo, pagamento, saldo, história, etc.Tipicamente, isso inicia uma seqüência de tela.
A figura 92 mostra classes de seqüência de tela. Seqüências detela 9201 agrupam uma série de instâncias DataScreen e conduzem a se-qüência iniciada através das ações do usuário tal como entrada de dados eseleção dos botões OK e retorno. As instâncias da seqüência de tela tam-bém implementam o comportamento iniciado pela conclusão da seqüênciade tela. Tipicamente, isso resulta na invocação de um método de serviço -isto é, uma chamada para um serviço no lado do servidor tal como um pa-gamento de pessoa para pessoa. Seqüências iniciadas pela notificação doservidor são ilustradas em 9202.A figura 93 mostra a invocação do serviço síncrono J2ME EWP.As invocações do serviço síncrono são iniciadas por uma ação do usuário talcomo a conclusão de uma seqüência de tela tal como pagamento. Nessecaso, o mesmo encadeamento que inicia a comunicação com o serviço nolado do servidor também processa o valor de retorno.
A figura 94 mostra a invocação do serviço assíncrono J2MEEWP. Se, entretanto, o protocolo é SMS, o serviço é invocado em uma ma-neira assíncrona e o encadeamento completa depois que a mensagem(SMS) foi enviada. O valor de retorno do serviço no lado do servidor é mani-pulado em um novo encadeamento gerado do encadeamento do sistemaque recebe a notificação da mensagem.
Em uma modalidade, esta invenção está relacionada com osdispositivos de comunicações móveis para consumidores e, mais particular-mente, com as maneiras de aumentar a funcionalidade dos telefones celula-res e outros dispositivos móveis de comunicações do consumidor com mó-dulos de identificação removíveis.
A maior parte dos dispositivos móveis de comunicações do con-sumidor, por exemplo, telefones celulares, PDAs (assistentes digitais pesso-ais), computadores Iaptop e assim por diante, contém um cartão de módulode identificação removível (IM) ou circuito integrado que identifica unicamen-te uma conta de consumidor específica para uma portadora de rede de co-municações sem fio. O cartão de IM/circuito integrado armazena os dados eprovê alguns dos "intelectos" que permite que o dispositivo móvel de comu-nicações do consumidor hospedeiro funcione, por exemplo, para fazer e re-ceber chamadas de voz, para enviar ou receber mensagens, para fazer fun-cionar aplicações do computador e assim por diante. Isso permite que umusuário, por exemplo, facilmente troque telefones celulares removendo o seucartão de IM/circuito integrado de um telefone e inserindo novamente o car-tão/circuito integrado em um outro telefone. A necessidade de ativar o se-gundo telefone celular pela rede de comunicações é eliminada.
Tipos diferentes de dispositivos móveis de comunicações deconsumidor usam tipos diferentes de cartões de IM/circuitos integrados. Porexemplo, um cartão SIM (módulo de identidade do assinante) funciona comdispositivos GSM (sistema global para comunicações móveis). Um outro tipode cartão de IM/circuito integrado é um USIM (módulo de identidade de as-sinante universal) que opera com os dispositivos UMTS (sistema de teleco-municações móvel universal) e ainda um outro é o RUIM (módulo de identi-dade do usuário removível) para dispositivos CDMA (acesso múltiplo pordivisão de código). Para finalidades desse pedido de patente, qualquer car-tão de IM/circuito integrado é chamado simplesmente um IM ou módulo deidentificação.
Mas a despeito do tipo, os IMs e seus dispositivos móveis decomunicações hospedeiros são geralmente sistemas "fechados", proprietá-rios para as portadoras da rede de comunicações sem fio (por exemplo, Cin-gular, T-Mobile, Verizon e assim por diante), o fabricante do dispositivo mó-vel de comunicações de consumidor e os fabricantes de IM (por exemplo,Gemplus, Oerthur e assim por diante). Contudo, os protocolos de comunica-ções, e a interface entre os dispositivos de comunicações hospedeiros deIM, isto é, o dispositivo móvel de comunicações de consumidor e os IMs sãoabertos pelos padrões técnicos estabelecidos pela ISO (Organização dospadrões internacionais).
A presente invenção tira vantagem desses padrões abertos paracriar funcionalidades adicionais para o dispositivo móvel de comunicaçõesde consumidor hospedeiro sem interferir com as operações do IM. O disposi-tivo móvel de comunicações do consumidor ainda opera com o IM, mas fun-cionalidade adicional é "inserida" no dispositivo. A presente invenção permiteque as restrições das portadoras móveis, fabricantes de aparelhos e fabri-cantes de IM sejam ignoradas, de modo que as aplicações do programa mó-vel podem funcionar no dispositivo móvel de comunicações de consumidorpara funcionalidade melhorada do dispositivo.
A CPU PIP tem um sistema operacional, citações (call-outs) deinterface do evento, citações de processamento após o cartão IM.
A figura 95 mostra um dispositivo móvel de comunicações deconsumidor exemplar, um telefone celular típico 9500 nesse caso, que podese beneficiar da presente invenção. Dentro do telefone celular está um IM(módulo de identificação) que se ajusta em um soquete de IM. Como decla-rado anteriormente, o IM contém a informação de identificação do usuáriopara o acesso à rede de comunicações e com o IM inserido no soquete deIM, o dispositivo 9500 pode operar com a rede de comunicações sem fio emum modo convencional.
A figura 96 mostra uma modalidade da presente invenção. UmIM 9619, quer na forma de um cartão ou circuito integrado, é montado emum alojamento fino 9617 que também mantém uma unidade de processa-mento programável 9618. O alojamento 9617 interliga o IM 9619 e a unidadede processamento programável 9618, e por um cabo de fita fino 9616, o alo-jamento 9617 é conectado em um adaptador do IM 9615.
O adaptador do IM 9615 pode se ajustar dentro do soquete doIM do dispositivo móvel de comunicações do consumidor 9500, como ilus-trado na figura 97. O adaptador do IM 9615 se ajusta no soquete do IM 9625do telefone celular 9500 que tem sua cobertura traseira (não mostrada) re-movida. Como mostrado, o adaptador do IM 9615 se ajusta dentro do soque-te do IM 9625 e conecta o IM 9619 através do cabo de fita 9616 e da unida-de de processamento programável 9619. Desde que o cabo 9616 é flexível,o alojamento 9617 pode ser movido para dentro do telefone celular 9500,como mostrado na figura 98. Na prática, uma bateria (não mostrada) para otelefone celular 9500 pode ser instalada sobre o soquete do IM 9625 e o a-daptador do IM 9615 e a seguir o alojamento 9617 movido sobre a bateria,antes que a cobertura possa ser substituída como mostrado na figura 95.
A figura 99 mostra as conexões elétricas entre o adaptador doIM 9615, o cabo de fita 9616, a unidade de processamento programável9618 e o IM 9619. Todo o tráfego eletrônico (isto é, comunicações de dados)entre o soquete do IM 9625 no dispositivo móvel de comunicações do con-sumidor 9500 e o IM 9619 deve passar através da unidade de processamen-to programável 9618. Como explicado abaixo, a unidade de processamentoprogramável 9618 opera como uma porta para permitir que o tráfego eletrô-nico atravesse desimpedido para comunicações sem fio convencionais, ounativas, em um caso. Em um outro caso, o tráfego eletrônico pode ser inter-ceptado e enriquecido por aplicações de programa funcionando na unidadede processamento programável 9618 para prover funcionalidade enriquecidapara o usuário do dispositivo 9500.
A unidade de processamento programável 9618 pode ser im-plementada em um microcontrolador, um ASIC (circuito integrado específicoda aplicação), um assim chamado SOC (sistema em um circuito integrado) eoutros circuitos integrados. Cada um desses tipos de circuitos integradostem uma ou mais unidades de processador e memória de capacidade varia-da e oferece graus diferentes de personalização, capacidade e custos paraas exigências particulares das aplicações do programa. A memória da uni-dade de processamento programável 9618 mantém as aplicações do pro-grama para funcionalidades enriquecidas e as unidades do processador e-xecutam as aplicações do programa. As aplicações do programa são trans-feridas através da rede de comunicações sem fio.
Em qualquer caso, a unidade de processamento programável9618 opera com um sistema operacional 10110, citações de interface deevento 10111, citações de processamento após o IM 10112, uma inscriçãode aplicação 10113 e uma linguagem programática e tempo de execução10114, como ilustrado na figura 101. O sistema operacional facilita as comu-nicações de repasse entre o dispositivo móvel de comunicações do consu-midor hospedeiro 9500 e o IM 9619, como explicado previamente. O sistemaoperacional também provê citações programáticas para as aplicações deprograma que estão registradas e instaladas na unidade de processamentoprogramável 9618.
As citações da interface do evento 10111 proveem uma interfacede evento programática que uma aplicação de programa implementa a fimde obter controle programático do dispositivo móvel de comunicações doconsumidor hospedeiro com eventos de dispositivo móvel específico, porexemplo, um aperto de um botão, um sinal de campainha e assim por diante.Durante esse controle, a aplicação do programa tem a capacidade de adi-cionar funcionalidade e processamento ao evento.As citações do processamento após o IM 10112 proveem umainterface de evento programática que uma aplicação de programa implemen-ta a fim de obter o controle programático do dispositivo móvel de comunica-ções do consumidor hospedeiro com um retorno do processamento do IM nativo do evento do dispositivo móvel de comunicações do consumidor. O IMé sempre incluído por último na cadeia de processamento de um evento.Durante esse controle, a aplicação do programa tem a capacidade de adi-cionar funcionalidade e o pós-processamento no evento antes que o disposi-tivo móvel de comunicações de consumidor recupere o controle.
A inscrição de aplicação 10113 provê uma configuração de mo-do que as aplicações do programa podem ser registradas como interessadasem eventos específicos (e, portanto ser programaticamente chamadasquando esses eventos ocorrem). Várias aplicações de programa podem ser' registradas para o mesmo evento e são chamadas em uma cadeia.
A linguagem programática e tempo de execução 10114 provêuma linguagem programática e plataformas sobre as quais as aplicaçõessão criadas. Várias linguagens/tempos de execução adequados que são pa-drões incluem BREW (Binary Runtime Environment for Wireless) desenvol-vido por Qualcomm1 Inc. de São Diego, Califórnia para prover um conjunto padrão de interfaces de programação da aplicação para desenvolvedoresfacilmente adicionarem novos aspectos e aplicações no hardware sem fiobaseado em Qualcomm, isto é, aparelhos equipados com conjunto de circui-tos integrados CDMA, J2ME (java 2 Mobile Edition), uma tecnologia baseadaem Java para sistemas móveis de Sun Microsystems, Inc. de Santa Clara, Califórnia; .NET da Microsoft, Inc. de Redmond, Washington para proveruma plataforma de desenvolvimento de software para o sistema operacionalWindows e usá XML (linguagem de marcação estendida) e Symbian, umaplataforma projetada para dispositivos móveis por um empreendimento con-junto de muitas companhias, incluindo L.M. Ericsson de Estocolmo, Suécia e Nokia Corp. de Espoo, Finlândia. Naturalmente, a linguagem/plataformasprecedentes representam somente exemplos e outras linguagens poderiamser usadas.Alguns exemplos de aplicações de programa que podem estarfuncionando na unidade de processamento programável são descritos nessepedido. Por exemplo, abaixo, a aplicação descreve uma maneira de enviaros dados através do canal de voz, ao invés do canal de dados, da rede decomunicações sem fio de um dispositivo móvel de comunicações do consu-midor. Em uma aplicação de programa, o dispositivo móvel de comunica-ções do consumidor pode enviar mensagens de texto para um outro disposi-tivo móvel de comunicações de consumidor através do seu canal de voz. Emum outro pedido de patente, os pagamentos móveis podem ser executadospelo dispositivo móvel de comunicações do consumidor através do seu canalde voz.
Até agora, o dispositivo móvel de comunicações do consumidor,tal como o telefone celular 9500 da figura 95, foi descrito como requerendosomente um IM que se ajusta dentro do soquete do IM do dispositivo paraengatar em uma rede de comunicações sem fio. Por outro lado, computado-res Iaptop tipicamente não têm um soquete de IM incorporado. Os computa-dores Iaptop usam um adaptador USB 10021 que aceita o IM do usuário e oadaptador USB 10021 é conectado em um conector USB 10022 que se ajus-0 ta na porta USB do computador laptop. A figura 100 mostra como o adapta-dor de IM previamente descrito 9615 se ajusta no adaptador USB 10021 pa-ra colocar o IM 9619 em contato com o computador laptop hospedeiro. Como IM 9619 em contato com o computador laptop para engatar a rede de co-municações sem fio, a unidade de processamento programável 9618 permitefuncionalidade adicional através de aplicações de programa.
Dispositivos móveis de comunicações de consumidor, tal comotelefones celulares, geralmente usam um canal de voz para transmitir e re-ceber vozes. A presente invenção provê uma maneira para que as aplica-ções de programa comuniquem os seus dados através do canal de voz dosdispositivos móveis de comunicações de consumidor.
A presente invenção permite que as aplicações que podem sercriadas em qualquer número de plataformas de programação/tempos de e-xecução para aplicações móveis sejam colocadas em rede pelo canal de vozdo dispositivo móvel de comunicações de consumidor hospedeiro. Platafor-mas exemplares incluem BREW (Binary Runtime Environment for Wireless)desenvolvido por Qualcomm, Inc. de São Diego, Califórnia para prover umconjunto padrão de interfaces de programação da aplicação para desenvol-vedores facilmente adicionarem novos aspectos e aplicações no hardwaresem fio baseado em Qualcomm, isto é, aparelhos equipados com conjuntode circuitos integrados CDMA, J2ME (java 2 Mobile Edition), uma tecnologiabaseada em Java para sistemas móveis de Sun Microsystems, Inc. de SantaClara, Califórnia; .NET da Microsoft, Inc. de Redmond, Washington para pro-ver uma plataforma de desenvolvimento de software para o sistema opera-cional Windows e usa XML (linguagem de marcação estendida), Symbian,uma plataforma projetada para dispositivos móveis por um empreendimentoconjunto de muitas companhias, incluindo L.M. Ericsson de Estocolmo, Sué-cia e Nokia Corp. de Espoo, Finlândia. Naturalmente, outras plataformas deprogramação/tempos de execução podem ser usadas.
A figura 102 mostra um arranjo pelo qual os dados são transmi-tidos através de um canal de voz de uma rede de comunicações sem fio, deacordo com uma modalidade da presente invenção. Um dispositivo móvel decomunicações de consumidor exemplar 10210, por exemplo, um telefonecelular, PDA e semelhantes, se comunica através de um canal de voz 10211da rede de comunicações sem fio. Ordinariamente essas comunicações sãoconversações. Uma API (interface do programa de aplicação) 10223 permiteque os dados de uma aplicação móvel, isto é, a aplicação do cliente hospe-deiro 10211, implementada em uma plataforma/tempo de execução descritaacima se comunique através do canal de voz 10211 para um sistema deservidor 10212. A API 10223 codifica os dados em tons para transmissãoatravés do canal de voz 10211. Nesse exemplo, DTMF de longa duração(múltipla freqüência por tom duplo) é usada, mas outra codificação adequa-da para o canal de voz pode ser usada.
Com tons DTMF sendo recebidos, o servidor 10212 através darede de comunicações sem fio engata a unidade de IVR (resposta de vozinterativa) 10226 para codificar os tons. A IVR pode enviar e receber tonsDTMF (algumas vezes chamados de "tons de toque") e é encontrada emmuitos sistemas de resposta de telefone automática atuais. Isso permite queum computador interaja automaticamente com um humano usando tecnolo-gias de reconhecimento de voz, reprodução de áudio, texto para fala (TTS) eDTMF. Um "arquivo complementar" da IVR é uma API adaptada com IVRpara colocar os dados em uma forma apropriada para uma aplicação 10222no servidor 10212. Isso permite que a aplicação 10221 hospedada no dispo-sitivo móvel de comunicações de consumidor 10210 se comunique com aaplicação empreendedora 10222 hospedada no servidor 10212 através docanal de voz 10211. Os sinais de dados percorrem em ambas as direçõesentre as duas aplicações 10221 e 10222. Comunicações simplesmente entreo dispositivo móvel de comunicações do consumidor 10210 e o servidor10212 são exemplos de comunicações de cliente/servidor através do canalde voz. Por outro lado, a operação da aplicação do servidor 10222 poderiaser para simplesmente retransmitir os dados do dispositivo móvel de comu-nicações de consumidor 10210 para um outro dispositivo móvel de comuni-cações de consumidor. Esse é um exemplo de comunicações par através docanal de voz.
A API em uma modalidade da presente invenção, por exemplo,as APIs 10223 e 10224 da figura 102, é baseada em um modelo "sendRe-quest()"/processRequest()" simples com estruturas de dados de respos-ta/solicitação bem conhecidas em ambos os lados do cliente e do servidor.As APIs 10223 e 10224 são um conjunto em par de APIs de cliente e servi-dor que os desenvolvedores de aplicação móvel e servidor empreendedorusam para construir uma aplicação completa de cliente/servidor. O softwarede processamento de dados de voz (isto é, componentes da biblioteca) emambos os lados do cliente (dispositivo móvel de comunicações do consumi-dor) e servidor implementam algoritmos de processamento de dados de vozpara comunicação de dados através do canal de voz. Esses algoritmos sãodistintos, naturalmente, das aplicações particulares de cliente/servidor 10221e 10223.
Um exemplo de uma API é como segue:Função do cliente SendRequest():
Essa é a interface de API única que uma aplicação de clientemóvel usa a fim de enviar uma solicitação/dados para uma aplicação de ser-vidor empreendedora.
Entrada: uma estrutura de solicitação
Saída: uma estrutura de resposta
Função do servidor ProcessRequest():
Essa é a interface de API única que a aplicação de servidor em-preendedora implementa a fim de processar uma solicitação do cliente mó-vel que chama. A lógica de processamento é completamente a responsabili-dade da aplicação empreendedora "hospedeira" e também é a responsabili-dade da aplicação empreendedora hospedeira montar os dados de respostaque serão retornados para o cliente móvel que chama.
Entrada: uma estrutura de solicitação
Saída: uma estrutura de resposta
Estrutura de solicitação:
CommandID - Um valor numérico que representa unicamenteum comando (e dados de parâmetro associados) que é entendido por ambasas aplicações do cliente hospedeiro e servidor.
ServerAddress - Um valor numérico que representa um "númerode telefone" que será usado a fim de "discar" uma chamada de voz que al-cançará o componente IVR do servidor que "front ends" o serviço empreen-dedor alvo.
ParameterData - Um arranjo de ParameterData que é associadocom "essa" solicitação CommandID.
Estrutura de resposta:
ResponseID - Um valor numérico que representa unicamenteuma resposta (e dados de parâmetro associados) que é entendida por am-bas as aplicações do cliente hospedeiro e servidor.
ParameterData - Um arranjo de ParameterData que é associadocom "esse" resultado ResponselD.
Estrutura do ParameterData:ParameterID - Um valor numérico que representa unicamenteum parâmetro dentro de um dado Commandld e é entendido por ambas asaplicações de cliente hospedeiro e servidor.
ParameterType - Um valor numérico com as seguintes defini- ções:
1 - numérico
2 - alfa...outros tipos
ParameterVaIue - O valor real do parâmetro Codificação/decodificação
Como mencionado acima, uma API pode usar diferentes algo-ritmos de codificação/decodificação, de acordo com a presente invenção. Oseguinte é um exemplo para codificação com DTMF. Essas regras da codifi-cação DTMF são baseadas em regras geralmente aceitas de entrada de números e letras usando a marcação de teclado encontrada nos telefones:Todos os elementos de dados são finalmente codificados como
um número.
Cada elemento de dados completo termina com um código "#".Elementos de dados de número usam seus números DTMF as- sociados.
Elementos de dados de número são enviados como seqüência
inteira.
Cada seqüência completa do elemento de dados do númerotermina com um código "#".
Elementos de dados alfa são divididos em elementos de caracte-re individuais.
Elementos de alfa caractere individuais são codificados usandoo seguinte esquema:"A"=2
"B"=22
"C"=222"D"=3Έ"=33
"F"=333
... e assim por diante usando regras de codificação alfa DTMF padrões.
Elementos de alfa caractere individuais terminam com código "#".
Cada elemento de dados alfa completo termina com um código
Cada estrutura de solicitação/resposta completa termina com umcódigo "#".
O exemplo de codificação acima mostra caracteres alfabéticosnuméricos e maiúsculos especificamente. Entretanto, a codificação para ca-racteres especiais e minúsculos pode ser feita também.
Portanto, os elementos da API descritos acima proveem um pro-tocolo pelo qual os dados das aplicações do programa podem se comunicaratravés do cariai de voz dos dispositivos móveis de comunicações de con-sumidor.
Exemplos de aplicações de dados de canal de voz
Um exemplo de uma aplicação é a troca de mensagens de textosimples através do canal de voz, ao invés de através de um canal de dadoscomo feito convencionalmente. A aplicação 10221 hospedada pelo dispositi-vo móvel de comunicações de consumidor 10210 da figura 102, por exem-plo, envia sinais alfanuméricos com uma identificação do recebedor, por e-xemplo, um número de telefone, através do canal de voz 10211. A aplicaçãoempreendedora 10222 no servidor 10212 simplesmente retransmite os si-nais alfanuméricos para o recebedor designado através de um outro canalde voz. Naturalmente, é assumido que o recebedor também tem as capaci-dades descritas de recepção e envio de dados através de um canal de voz.
Um exemplo mais complexo de uma aplicação em rede que utili-za mais totalmente os aspectos particulares da API descritos acima é umafuncionalidade de pagamento móvel para consumidores móveis. Todas ascomunicações de dados requeridas de cliente/servidor são executadas atra-vés de uma "chamada de telefone" do canal de voz. Nesse exemplo da apli-cação, é assumido que os consumidores móveis tenham dispositivos móveisde comunicações de consumidor que são capazes de executar uma aplica-ção de pagamento móvel e o plano do serviço móvel do consumidor permitechamadas de voz somente. Um consumidor "de origem" deseja enviar di-nheiro da sua conta móvel para a conta móvel de um amigo ("consumidoralvo"). Ambos os consumidores de origem e alvo são "alistados" com o ser-viço que a aplicação empreendedora do servidor provê. A aplicação do ser-vidor empreendedora provê uma API do serviço da web que transfere fundosde uma conta de origem para uma conta alvo.
Os comandos nesse exemplo são payRequest representado porCommandID 1 e payResponse, representado como CommandID 2. As estru-turas de dados do parâmetro são definidas nas duas tabelas abaixo:
Tabela E: Definição dos dados do parâmetro payRequest:
<table>table see original document page 216</column></row><table>Tabela F: Definição dos dados do parâmetro payResponse
<table>table see original document page 217</column></row><table>
Agora para o consumidor de origem pagar um consumidor alvo,as operações e interações seguintes ocorrem:
A aplicação do cliente móvel hospedeiro interage com o consu-midor de origem e reúne os seguintes dados:
sourceAccountNumber- "123456789"sourcePIN - "4321"payAmount-"15"sourceAccountNumber - "987654321"payMessage - "THANKS"
A aplicação do cliente móvel hospedeiro "sabe" os dados se-guintes como um resultado do contexto e configuração:commandID - "1" (isto é, payRequest)serverAddress - "8885551212" (isto é, o "número do telefone"do componente IVR da aplicação empreendedora)
A aplicação móvel hospedeira reúne as seguintes estruturas dedados:
ParameterDate[1]ParameterID = 1ParameterType = 1ParameterVaIue = "123456789"ParameterData[2]ParameterID = 2ParameterType = 1ParameterVaIue = "4321"ParameterData[3]ParameterID = 3ParameterType = 1ParameterVaIue = "15"ParameterData[4]ParameterID = 4
ParameterType = 1ParameterVaIue = "987654321"ParameterData[5]ParameterID = 5ParameterType = 2
ParameterVaIue = "Thanks"
Solicitação
commandID = 1serverAddress = "885551212"
parameterData = 5 arranjo do elemento ParameterData de cima
A aplicação móvel então chama a API SendRequest() usando osdados de estrutura de solicitação acima. O controle agora passa para a APIdo cliente.
A API do cliente agora executa o algoritmo de codificação e con-verte a estrutura de solicitação para a seguinte seqüência de texto:
1 #1#1#123456789#2#1#4321#3#1#15#4#1#987654321#5#2#8#44#2#66#55#7777###
Aplicando as regras acima do exemplo codificado acima, o se-guinte é observado:
O "1#" dianteiro significa "CommandID 1" que é conhecido comosendo um comando "payRequest"
O "1#" seguinte significa "ParameterlD 1" que é conhecido comosendo um parâmetro "sourceAccountNumber".
O "1#" seguinte significa "tipo de parâmetro AMD 1" que é co-nhecido como sendo "numérico".
O "123456789#" seguinte significa que o valor sourceAccount-Number é "123456789".... e assim por diante para os tipos de parâmetro numérico.
O "8#44#2##66#55#7777##" posterior é a codificação alfaDTMF para a palavra "OBRIGADO". O último "#" indica uma seqüênciacompleta do elemento de alfa dados.
O "#" final indica o fim dos dados de solicitação/resposta com-pletos.
Retornando para as operações da aplicação exemplar,
A API então disca o "número de telefone" do servidor indicado(isto é, "8885551212") e inicia uma chamada de voz.
O componente IVR do servidor "apanha" e aguarda os dados desolicitação DTMF codificados.
A API do cliente então transmite toda a solicitação DTMF codifi-cada acima.
Quando o # final é recebido, o componente do "arquivo comple-mentar" IVR do servidor começa a decodificar os dados de solicitação DTMFcodificados. Para fazer isso, o "arquivo complementar" IVR usa o inversodas regras de codificação apresentadas acima.
O "arquivo complementar" IVR agora montou uma duplicata exa-ta da estrutura de solicitação do cliente, somente agora no espaço de memó-ria no lado do servidor.
O "arquivo complementar" IVR agora invoca a aplicação do ser-vidor empreendedora via a interface ProcessRequest() que a aplicação doservidor empreendedora implementou.
A aplicação do servidor empreendedora processa a solicitaçãode acordo.
A aplicação do servidor empreendedora então monta uma estru-tura de resposta justo como a aplicação do cliente móvel montou a estruturade solicitação.
A aplicação do servidor empreendedora retorna a estrutura deresposta e controla para o arquivo complementar IVR.
O arquivo complementar IVR então codifica a estrutura de res-posta como descrito acima (isto é, nesse caso com o estado e elementos dedados transactionNumber).
A IVR transmite os dados de resposta DTMF codificados para aAPI da aplicação do cliente móvel.
A API da aplicação do cliente móvel decodifica os dados de res-posta DTMF codificados em uma estrutura de resposta no lado do clienteusando as regras de decodificação descritas acima (isto é, nesse caso emuma estrutura de resposta).
A API retorna a estrutura de resposta e controle para a aplicaçãomóvel do cliente hospedeiro.
A aplicação móvel do cliente hospedeiro recupera o controle,tem acesso à estrutura de resposta do servidor e continua o processamento.
Portanto, a presente invenção provê aplicações de programapara se comunicar através do canal de voz dos dispositivos móveis de co-municações de consumidor. Como mencionado anteriormente, a codificaçãodiferente de DTMF poderia ser selecionada para acelerar a transmissão dosdados através do canal de voz. Tal codificação poderia depender da aplica-ção particular no dispositivo móvel de comunicações de consumidor hospe-deiro e servidor empreendedor correspondente. Os dispositivos móveis decomunicações do consumidor poderiam ser adaptados para comunicar da-dos de aplicação do programa através do canal de voz, ao invés do canal dedados, da rede de comunicações sem fio.
Várias modalidades específicas da invenção incluem:
1. Um sistema de pagamento individualizado móvel compreen-dendo:
um cliente móvel,
um servidor para gerenciar um sistema de pagamento de circuitofechado e
um protocolo que possibilita que o cliente móvel funcione, emconjunto com o servidor, como uma "carteira móvel".
2. O sistema da reivindicação 1, no qual o protocolo também
compreende:
uma UI simplificada que somente requer a entrada etapa poretapa dos dados de solicitação e a seguir a exibição dos dados de resposta.
3. O sistema da reivindicação 1, também compreendendo recur-so para utilizar os serviços de dados do dispositivo móvel via invocações deAPI HTTPS programáticas.
4. O sistema da reivindicação 3, também compreendendo o re-curso de garantia para invocar as invocações de API HTTPS programáticas.
5. O sistema da reivindicação 1, também compreendendo recur-so para utilizar os serviços de texto SMS do dispositivo móvel via invocaçõesde API SMS programáticas.
6. Um sistema de pagamento individualizado móvel, compreen-dendo:
uma aplicação de cliente móvel dedicada a executar transaçõesfinanceiras e
um servidor, adaptado para se comunicar com a aplicação docliente, para prover um serviço de pagamento utilizando chamadas de méto-do de repasse para um sistema de banco parceiro.
7. O sistema da reivindicação 6, também compreendendo umaconta em fundo comum mantida pelo sistema do banco parceiro.
8. O sistema da reivindicação 7, no qual a dita conta em fundocomum representa uma pluralidade de cartões de débito pré-pagos.
9. O sistema da reivindicação 8, no qual o dito cartão de débitopré-pago é vinculado a uma conta corrente no sistema do banco parceiro.
10. O sistema da reivindicação 8, no qual cada um dos ditos car-tões de débito pré-pagos pode ser recarregado pela transferência de fundospara ou de uma conta vinculada em resposta a uma chamada telefônica ini-ciada pelo programa do cliente.
11. O sistema da reivindicação 6, também compreendendo pelomenos uma aplicação de cliente móvel adicional em que a combinação dadita aplicação de cliente móvel, do servidor e da pelo menos uma aplicaçãode cliente móvel adicional compreende um sistema de pagamento de circuitofechado.
12. O sistema da reivindicação 6, no qual a combinação da ditaaplicação de cliente móvel, do servidor e da pelo menos uma aplicação decliente móvel adicional compreende um sistema de transferência de paga-mento de pessoa para pessoa.
13. O sistema da reivindicação 6, no qual a combinação da ditaaplicação de cliente móvel, do servidor e da pelo menos uma aplicação decliente móvel adicional compreende um sistema de transferência de paga-mento de par para comerciante.
14. Um sistema de pagamento individualizado móvel, compre-endendo:
um protocolo de transmissão de dados de plataforma e cliente éusado em conjunto com um codec MCAP para serializar/desserializar os da-dos para comunicação entre uma pluralidade de dispositivos móveis e a pla-taforma, a plataforma compreendendo um centro de dados hospedando ser-viços com base em J2EE.
15. O sistema da reivindicação 14, em que o codec MCAP é umcomponente nos dispositivos móveis.
16. O sistema da reivindicação 14, em que o centro de dadostrata da serialização e desserialização de acordo com as especificações doprotocolo de transmissão de dados de cliente e de plataforma.
17. O sistema da reivindicação 14, em que a certa funcionalida-de está presente no dispositivo móvel incluindo a capacidade de exibir cam-pos de entrada e capturar entradas do dono da conta, a capacidade de utili-zar os serviços de dados do dispositivo móvel via invocações de API HTTPSprogramáticas.
18. O sistema da reivindicação 14, em que a certa funcionalida-de está presente no dispositivo móvel incluindo a capacidade de exibir cam-pos de entrada e capturar entradas do dono da conta, a capacidade de utili-zar os serviços de dados do dispositivo móvel via serviços de texto SMS dodispositivo móvel via invocações de API SMS programáticas.
19. O sistema da reivindicação 14, em que os serviços de dadospersistentes do dispositivo móvel via invocações de API programáticas.
20. O sistema da reivindicação 14, em que os dispositivos mó-veis compreendem a capacidade de interceptar mensagens que chegampara o dispositivo móvel e "despertar" o MCAP para processamento aondeuma mensagem SMS que chega é interceptada em uma porta específica etratada pelo protocolo.
21. O sistema da reivindicação 14, em que o dispositivo móvelcompreende recurso para integrar de modo programático com um "livro deendereços" do dispositivo móvel tal que um campo de entrada específicopode ser "vinculado" ao livro de endereço e notificar de modo programático odono da conta do dispositivo móvel dos eventos notáveis via som, vibraçãoou luz.
22. Um método para operar um sistema de pagamento de circui-to fechado compreendendo:
ativar uma aplicação de cliente em um dispositivo habilitado em IP,
estabelecer um canal de comunicação para um servidor de pa-gamento,
transferir uma solicitação proveniente da aplicação do clientepara o servidor de pagamento, em que a solicitação inclui uma quantia depagamento e um número de identificação para identificar o recebedor,
ajustar saldos da conta para refletir a solicitação enotificar o recebedor da recepção do pagamento.
23. O método, da reivindicação 22, também compreendendo:estabelecer uma conta para o recebedor se o pagamento é dire-cionado para um número para o qual não existe conta e
uma incitação viral para um usuário abrir uma conta para rece-ber os fundos depositados na conta estabelecida.
24. O método, da reivindicação 22, também compreendendo:solicitar que o solicitante do pagamento adicione uma quantia de
"gorjeta" se o perfil para o recebedor indica que uma gorjeta é apropriada eajustar os saldos para refletir o pagamento adicional da gorjeta.
25. O método, da reivindicação 22, também compreendendo:quitar cada transação em tempo real alocando fundos para con-tas respectivas de uma conta em fundo comum.
26. O método, da reivindicação 22, também compreendendo:quitar transações selecionadas em um modo fora de linha.
27. O método, da reivindicação 26, também compreendendo ini-ciar uma transação com base em uma ligação de comunicação perto da es-fera de ação.
28. O método, da reivindicação 26, também compreendendo ini-ciar uma transação com base em uma ligação de comunicação estabelecidapor um transponder de identificação de freqüência de rádio (RFID) e recep-tor.
29. O método, da reivindicação 26, também compreendendo re-gistrar uma descrição de cada transação em um programa de contabilidadejunto com a quantia da transação.
30. O método, da reivindicação 29, em que o registro compreen-de enviar uma descrição verbal da transação em tempo real para um pro-grama de contabilidade.
31. O método, da reivindicação 29, em que o registro compreen-de enviar uma descrição de texto da transação em tempo real para um pro-grama de contabilidade por SMS.
32. O método, da reivindicação 22, em que iniciar a aplicação docliente compreénde:
inserir uma primeira senha para identificar o usuário e para ativara operação da aplicação do cliente,
inserir uma segunda senha para estabelecer uma ligação seguracom o servidor de pagamento e
verificar se as senhas igualam o ID do chamador esperado.
33. Um método para conduzir uma transação financeira compre-endendo:
enviar uma solicitação por uma transação financeira provenientede um dispositivo móvel para um servidor de pagamento por uma primeiratrajetória de comunicação,
enviar um número de identificação pessoal (PIN) por uma se-gunda trajetória de comunicação,
associar a solicitação com o PIN no servidor de pagamento econcluir a transação financeira com base na associação entre asolicitação e o PIN.
34. O método, da reivindicação 33, em que o envio da solicita-ção também compreende:
formar um comando e
enviar o comando pelo serviço de mensagem curta (SMS).
35. O método, da reivindicação 34, em que formar o comandotambém compreende:
solicitar pagamento.
36. O método, da reivindicação 35, em que formar o comandotambém compreende:
solicitar pagamento para um par.
37. O método, da reivindicação 35, em que formar o comandotambém compreende:
solicitar pagamento para um comerciante.
38. O método, da reivindicação 35, em que formar o comandotambém compreende:
adicionar uma mensagem no comando.
39. O método, da reivindicação 38, em que formar o comandotambém compreende:
adicionar uma notação de manutenção de registro no comando.
40. O método, da reivindicação 39, em que enviar o comandotambém compreende:
enviar o comando para uma aplicação de contabilidade.
41. O método, da reivindicação 39, em que enviar o comandotambém compreende:
enviar o comando para um provedor de serviço de valor adicio-nado.
42. O método, da reivindicação 33, em que formar o comandotambém compreende:solicitar um saldo de conta.
43. O método, da reivindicação 42, também compreendendo:receber uma mensagem de saldo da conta por SMS.
44. O método, da reivindicação 33, também compreendendo:solicitar uma história da conta.
45. O método, da reivindicação 44, também compreendendo:receber uma mensagem da história da conta por SMS.
46. O método, da reivindicação 33, também compreendendo:solicitar que uma solicitação de pagamento seja enviada paraum par.
47. O método, da reivindicação 46, também compreendendo:enviar uma solicitação para mensagem de pagamento por SMSpara o par.
48. O método, da reivindicação 47, também compreendendo:receber uma indicação que o pagamento foi autorizado ou recu-sado, a indicação enviada por SMS.
49. O método, da reivindicação 48, também compreendendo:solicitar que o par estabeleça uma conta da qual o pagamentopara o solicitante é feito, a solicitação enviada por SMS.
50. O método, da reivindicação 33, também compreendendo:solicitar ajuda.
51. O método, da reivindicação 50, também compreendendo:receber uma mensagem de ajuda por SMS.
52. O método, da reivindicação 33, em que o dispositivo móvel éum telefone celular.
53. O método, da reivindicação 33, em que a primeira trajetóriade comunicação é o canal de comunicação de texto SMS e a segunda traje-tória de comunicação é um canal de comunicação por voz.
54. O método, da reivindicação 53, em que o PIN é codificadoem DTMF.
55. O método, da reivindicação 53, em que o PIN é articulado ea seguir decodificado por um sistema de reconhecimento de voz interativo.56. Um método para conduzir uma transação financeira usandoum dispositivo móvel compreendendo:
ativar uma aplicação de cliente móvel para gerenciar a solicita-ção financeira,
exibir uma interface do usuário para formar um comando,
enviar uma solicitação compreendendo o comando para umatransação financeira proveniente do dispositivo móvel para um servidor depagamento por uma primeira trajetória de comunicação,
enviar um número de identificação pessoal (PIN) por uma se-gunda trajetória de comunicação,'
associar a solicitação com o PIN no servidor de pagamento e
concluir a transação financeira com base na associação entre asolicitação e o PIN.
57. O método, da reivindicação 56, em que o envio da solicita-ção também compreende:
enviar o comando por um protocolo de mensagem.
58. O método, da reivindicação 57, em que formar o comandotambém compreende:
solicitar pagamento.
59. O método, da reivindicação 56, em que formar o comandotambém compreende:
solicitar pagamento para um par.
60. O método, da reivindicação 59, em que formar o comandotambém compreende:
solicitar pagamento para um comerciante.
61. O método, da reivindicação 56, em que formar o comandotambém compreende:
adicionar uma mensagem no comando.
62. O método, da reivindicação 61, em que formar o comandotambém compreende:
adicionar uma notação de manutenção de registro no comando.
63. O método, da reivindicação 62, em que enviar o comandotambém compreende:
enviar o comando para uma aplicação de contabilidade.
64. O método, da reivindicação 62, em que enviar o comandotambém compreende:
enviar o comando para um provedor de serviço de valor adicionado.
65. O método, da reivindicação 56, em que formar o comandotambém compreende:
solicitar um saldo de conta.
66. O método, da reivindicação 65, também compreendendo:receber uma mensagem de saldo da conta por um protocolo se-lecionado.
67. O método, da reivindicação 56, também compreendendo:solicitar uma história da conta.
68. O método, da reivindicação 67, também compreendendo:receber uma mensagem da história da conta por um protocoloselecionado.
69. O método, da reivindicação 56, também compreendendo:solicitar que uma solicitação de pagamento seja enviada paraum par.
70. O método, da reivindicação 69, também compreendendo:enviar uma solicitação para mensagem de pagamento por umprotocolo selecionado para o par.
71. O método, da reivindicação 70, também compreendendo:receber uma indicação que o pagamento foi autorizado ou recu-sado, a indicação enviada por SMS.
72. O método, da reivindicação 71, também compreendendo:solicitar que o par estabeleça uma conta da qual o pagamentopara o solicitante é feito, a solicitação enviada por SMS.
73. O método, da reivindicação 56, também compreendendo:solicitar ajuda.
74. O método, da reivindicação 73, também compreendendo:receber uma mensagem de ajuda por SMS.
75. O método, da reivindicação 56, em que o dispositivo móvel éum telefone celular.
76. Um sistema de pagamento individualizado móvel compreen-dendo:
uma aplicação de cliente móvel dedicada à execução de transa-ções financeiras e
um servidor, adaptado para se comunicar com a aplicação docliente, para prover um serviço de pagamento vinculado a uma selecionadade uma pluralidade de contas.
77. O sistema, da reivindicação 76, também compreendendopelo menos uma aplicação de cliente móvel adicional em que a combinaçãoda dita aplicação de cliente móvel, do servidor e da pelo menos uma aplica-ção de cliente móvel adicional compreende um sistema de pagamento decircuito fechado com pequenas taxas de transação.
78. O sistema, da reivindicação 76, também compreendendopelo menos uma aplicação de cliente móvel adicional em que a combinaçãoda dita aplicação de cliente móvel, do servidor e da pelo menos uma aplica-ção de cliente móvel adicional compreende um sistema de pagamento decircuito fechado sem taxas de transação.
79. O sistema, da reivindicação 76, compreendendo um sistemade transferência de pagamento de pessoa para pessoa.
80. O sistema, da reivindicação 79, compreendendo uma taxa deserviço mensal cobrada para cada par.
81. O sistema, da reivindicação 76, compreendendo um sistemade transferência de pagamento de consumidor para comerciante onde é co-brada do consumidor uma taxa de transação.
82. O sistema, da reivindicação 81, também compreendendoselecionar um plano de pagamento do comerciante que paga a taxa de tran-sação em nome do consumidor.
83. Um método para compra rápida compreendendo:selecionar um produto,ativar uma aplicação de cliente móvel para tratar de uma transa-ção financeira,
fazer uma compra e
automaticamente receber o produto selecionado em um endereço especificado.
84. Um método para compra rápida compreendendo:selecionar um produto,
ativar uma aplicação de cliente móvel para tratar de uma transa-ção financeira,
fazer uma compra e
automaticamente receber o produto selecionado em uma locali-zação geográfica especificada.
85. O método, da reivindicação 84, também compreendendo ati-var a transação com uma varredura de código de barras usando um códigode barras externamente visível associado com um telefone celular.
86. O método, da reivindicação 84, também compreendendo ati-var a transação com um dispositivo de comunicação perto da esfera de açãoassociado com um telefone celular.
87. O método, da reivindicação 84, também compreendendo ati-var a transação com um dispositivo de RFID associado com um telefone celular.
88. Um método para compra rápida compreendendo:pré-autorizar uma compra por um produto ou serviço selecionado,
fazer uma compra com um telefone celular eeliminar qualquer ação adicional pelo consumidor para autorizara compra.
89. O método, da reivindicação 88, também compreendendo ati-var a transação com uma varredura de código de barras usando um códigode barras externamente visível associado com o telefone celular.
90. O método, da reivindicação 88, também compreendendo ati-var a transação com um dispositivo de comunicação perto da esfera de açãoassociado com um telefone celular.
91. O método, da reivindicação 88, também compreendendo ati-var a transação com um dispositivo de RFID associado com um telefone ce-lular.
92. Um método para impedir a submissão fraudulenta de transa-ções financeiras em duplicata inseridas a partir de um telefone celular com-preendendo:
comparar um número de seqüência recebido de um telefone ce-lular com um número de seqüência esperado antes de autorizar uma transa-ção financeira e
permitir que a transação prossiga se os números de seqüênciase igualam.
93. O método, da reivindicação 92, também compreendendo:solicitar um PIN e
comparar um número de telefone adquirido do ID do chamador eo PIN com um banco de dados para verificar se o uso do telefone celular élegítimo,
eliminar qualquer ação adicional pelo consumidor para autorizara compra.
94. Um método para impedir a submissão fraudulenta de transa-ções financeiras em duplicata inseridas a partir de um telefone celular com-preendendo:
comparar um número de seqüência recebido de um telefone ce-lular com uma lista de números de seqüência previamente usados antes deautorizar uma transação financeira e
permitir que a transação prossiga se o número de seqüência re-cebido não iguala qualquer um dos números de seqüência previamente usa-dos.
95. O método, da reivindicação 94, também compreendendo:solicitar um PIN e
comparar um número de telefone adquirido do ID do chamador eo PIN com um banco de dados para verificar se o uso do telefone celular élegítimo,
eliminar qualquer ação adicional pelo consumidor para autorizara compra.
96. Um método para impedir a submissão fraudulenta de transa- ções financeiras em duplicata inseridas a partir de um telefone celular com-preendendo:
comparar um número de seqüência recebido de um telefone ce-lular com um número de seqüência esperado antes de autorizar uma transa-ção financeira,
comparar o número de seqüência recebido de um telefone celu-lar com um número de seqüência esperado antes de autorizar uma transa-ção financeira epermitir que a transação prossiga se os números de seqüênciase igualam na primeira etapa de comparação e não se igualam na segunda etapa de comparação.
97. O método, da reivindicação 96, também compreendendo:solicitar um PIN ecomparar um número de telefone adquirido do ID do chamador eo PIN com um banco de dados para verificar se o uso do telefone celular é legítimo.
98. Um método para impedir a submissão fraudulenta de umatransação financeira inserida a partir de um telefone celular compreendendo:
iniciar a transação financeira enviando uma solicitação tendo umprimeiro identificador, a solicitação enviada usando um primeiro canal de comunicação,
enviar um PIN usando tons de DTMF através de um segundocanal de comunicação,concluir a transação financeira somente se a solicitação e o PINigualam uma conta comum.
99. Um método para impedir a submissão fraudulenta de umatransação financeira inserida a partir de um telefone celular compreendendo:receber uma solicitação para iniciar a transação financeira emum primeiro canal de comunicação, a solicitação tendo um primeiro identifi-cador de conta,
receber um PIN usando tons de DTMF através de um segundocanal de comunicação e
concluir a transação financeira somente se a solicitação e o PINigualam uma conta comum.
100. O método da reivindicação 99, também compreendendoiniciar uma chamada telefônica para um número de telefone indicado peloprimeiro identificador de conta.
101. O método da reivindicação 99, em que o primeiro canal decomunicação é o canal de transmissão do SMS.
102. Um método para impedir fraude em uma transação finan-ceira inserida a partir de um telefone celular usando SMS compreendendo:
formar uma primeira mensagem SMS de texto simples com ins-truções para uma transação financeira no telefone celular,
enviar a mensagem SMS para um processador de transação,interceptar a mensagem SMS e
converter a mensagem SMS interceptada para uma mensagemde serviços de dados antes de enviar a mensagem SMS convertida para oprocessador de transação.
103. O método da reivindicação 102, também compreendendo:enviar uma segunda mensagem de texto simples contendo uma
senha para o processador de transação,
interceptar a segunda mensagem SMS e
converter a segunda mensagem SMS interceptada para umamensagem de serviços de dados antes de enviar a mensagem SMS conver-tida para o processador de transação.
104. O método da reivindicação 103, também compreendendoarmazenar a primeira mensagem SMS de texto simples em uma pasta detransação no telefone celular.
105. O método da reivindicação 103, também compreendendocriptografar a primeira e a segunda mensagens SMS de texto simples antesde converter para a mensagem de serviços de dados.
106. O método da reivindicação 103, em que a etapa de inter-cepção é executada por uma conexão de circuito, a conexão de circuito in-cluindo uma aplicação de cliente móvel (MCA) interposta entre o telefonecelular e seu cartão SIM.
107. Um dispositivo de telefone celular tendo um cartão SIM, odispositivo também compreendendo um circuito interposto entre o cartão SIM eo telefone celular e adaptado para interceptar mensagens SMS enviadas paraou recebidas de um processador de transação, o circuito compreendendo ele-mentos lógicos para criptografar e converter as mensagens interceptadas paramensagens de serviços de dados antes das mensagens interceptadas seremenviadas para o processador de transação e para decriptografar e converter asmensagens de serviços de dados para mensagem SMS de texto simples paraas mensagens recebidas do processador de transação.
108. Um dispositivo móvel para conduzir transações financeirascompreendendo:
uma camada de comunicação,
um API do programa,
uma API da interface do usuário para fazer interface com a API do programa e
uma API da interface do usuário para fazer interface com os ser-viços de valor adicionado.
109. O dispositivo, da reivindicação 108, em que a capacidadede utilizar serviços de dados SMS do dispositivo móvel via serviços de textoSMS do dispositivo móvel via invocações de API SMS programáticas.
110. O dispositivo, da reivindicação 108, em que a capacidadede utilizar serviços de dados persistentes do dispositivo móvel via invoca-ções de API programáticas para os serviços de valor adicionado.
111. Um sistema financeiro de circuito fechado compreendendo:
um processador de transação adaptado para receber solicita-ções por transações financeiras provenientes de uma pluralidade de donos de conta,uma pluralidade de telefones celulares, cada um associado comum correspondente dos donos de conta,
uma rede de comunicações para ligar os telefones celulares noprocessador de transação.
112. O sistema, da reivindicação 111, também compreendendouma conta de razão para transferir fundos de um dono de conta para pelomenos um outro dono de conta sem incorrer em taxas de transação de car-tão de crédito ou taxas ACH de banco.
113. O sistema, da reivindicação 111, também compreendendouma conta em fundo comum compreendendo todos os fundos mantidos pe-los donos de conta, a conta em fundo comum associada com a conta de ra-zão para gerenciar a transferência de fundos entre donos de conta.
114. O sistema, da reivindicação 113, também compreendendorecurso para injetar fundos na conta em fundo comum a partir de uma fonteexterna.
115. O sistema, da reivindicação 114, também compreendendorecurso para remover fundos da conta em fundo comum.
116. Um método para operar um sistema financeiro de circuitofechado compreendendo:manter uma conta em fundo comum contendo fundos de todos
os donos de conta,
receber solicitações de transação financeira de pelo menos umdono de conta para transferir fundos e
manter uma conta de razão para acompanhar os fundos na con-ta em fundo comum que são atribuídos para cada dono de conta.
117. O método, da reivindicação 116, em que os fundos sãotransferidos para pelo menos um outro dono de conta.
118. O método, da reivindicação 116, em que os fundos sãotransferidos para um dono sem conta.
119. O método, da reivindicação 118, também compreendendoavisar o dono sem conta da disponibilidade de fundos por meio de umamensagem SMS.
120. O método, da reivindicação 119, também compreendendoabrir uma nova conta para o dono sem conta, dessa maneira tornando o do-no sem conta um novo dono de conta.
121. O método, da reivindicação 120, em que o novo dono deconta é obtido sem despesa de publicidade.
122. O método, da reivindicação 120, também compreendendoiniciar uma verificação de consentimento (OFAC) no novo dono de conta.
123. O método, da reivindicação 122, também compreendendo:designar o novo dono de conta como um dono de conta "semcartão" e
conceder ao dono de conta sem cartão acessibilidade limitadaaos fundos.
124. O método, da reivindicação 123, também compreendendoemitir um cartão de débito para o dono da conta sem cartão enviando o car-tão de débito para um endereço de registro.
125. O método, da reivindicação 124, também compreendendo:receber uma confirmação da recepção do cartão no endereço deregistro e
designar o dono da conta sem cartão como um dono de contacom acesso total aos fundos mantidos na conta em fundo comum.
126. O método, da reivindicação 116, em que a manutenção,recepção e manutenção são todas controladas por uma entidade única.
127. O método, da reivindicação 126, em que a entidade única éo sistema de registro e assume o risco de manter a conta em fundo comum.
128. Um sistema para impedir a submissão fraudulenta de umatransação financeira inserida a partir de um telefone celular compreendendo:uma primeira série controlável por um dono de conta euma segunda série controlável por uma entidade de gerencia-mento.
129. O sistema, da reivindicação 128, em que a primeira sérietambém compreende:
recurso para designar donos de conta elegíveis para receberdinheiro das contas controladas pelo dono da conta e
recurso para designar donos de conta inelegíveis para receberdinheiro das contas controladas pela dono da conta.
130. O sistema, da reivindicação 128, em que a primeira sérietambém compreende recurso para especificar limites de gasto para usuáriosdas contas controladas pelo dono da conta.
131. O sistema, da reivindicação 128, em que a segunda sérietambém compreende recurso para especificar limites de velocidade de gastopara usuários das contas controlados pelo dono da conta.
132. O sistema, da reivindicação 128, em que a segunda sérietambém compreende recurso para detectar transações fraudulentas.
133. Um dispositivo móvel para conduzir transações financeirascompreendendo:
uma conexão de comunicação por voz,
uma API JAVA executando no dispositivo móvel para gerar umaAPI da interface do usuário para criar solicitações de transação,
uma API JAVA executando no dispositivo móvel para transmitir asolicitação para o processador de transação usando tons DTMF.
134. O dispositivo, da reivindicação 133, também compreendendo:
uma API JAVA executando no dispositivo móvel para receberuma resposta codificada em DTMF proveniente do processador de transa-ção e
uma API JAVA executando no dispositivo móvel para converter aresposta codificada para uma forma legível pelo ser humano na interface dousuário.
135. O dispositivo, da reivindicação 134, também compreenden-do recurso para criptografar a solicitação antes de transmitir e para decripto-grafar a resposta antes de converter.
136. Um sistema de transação financeira compreendendo:um primeiro dispositivo móvel para iniciar uma transação finan-ceira tendo recurso para selecionar um canal de comunicação para iniciar atransação financeira e
um processador de transação.
137. O sistema, da reivindicação 136, também compreendendorecurso associado com o processador de transação para determinar um ca-nal de comunicação para avisar um segundo dispositivo móvel que umatransação financeira ocorreu onde a transação financeira inclui pelo menosdois donos de conta.
138. O sistema, da reivindicação 137, em que o canal de comu-nicação selecionado pelo primeiro dispositivo não é o mesmo que o tipo decanal de comunicação selecionado pelo servidor de transação para contataro segundo dispositivo móvel.
139. O método, da reivindicação 102, também compreendendo:enviar uma mensagem SMS contendo uma senha para o pro-cessador de transação por meio de um agregador SMS seguro.
Existem muitos produtos existentes, e potencialmente um gran-de número de novos produtos, que se beneficiarão da presente invenção.Por exemplo, qualquer dispositivo de telefone habilitado na Internet, tal comoum telefone de voz através de IP (VOIP) pode ser usado para praticar a pre-sente invenção mesmo embora ele possa estar afixado em uma localizaçãoespecífica e não seja necessariamente móvel. Em outras modalidades, osendereços de e-mail podem ser usados além de ou no lugar dos números detelefone para identificar uma ou mais partes para uma transação financeira.Além do que, a presente invenção não é limitada aos telefones celulares,mas preferivelmente inclui qualquer dispositivo móvel, aparelho, PDA ou ou-tro dispositivo de comunicação tendo a capacidade de se conectar em umcanal de comunicação tais como o telefone, Internet, celular ou outra rede decomunicação ligada por fiação ou sem fio.
Também será verificado que um ou mais dos elementos repre-sentados nos desenhos ou figuras podem também ser implementados emuma maneira mais separada ou integrada, ou até mesmo removidos ou tor-nados inoperáveis em certos casos, conforme seja útil de acordo com umaaplicação particular.Embora a invenção tenha sido descrita com relação a suas mo-dalidades específicas, essas modalidades são meramente ilustrativas, e nãorestritivas da invenção. Por exemplo, modalidades adicionais podem incluirvárias arquiteturas de exibição, sensores biométricos, sensores de pressão,sensores de temperatura, sensores de luz, sensores químicos, sensores deraio X e outros eletromagnéticos, amplificadores, arranjos de porta, outroscircuitos lógicos, impressoras e circuitos de memória para implementar asvárias modalidades descritas. O telefone celular pode ser qualquer dispositi-vo de comunicação.
Adicionalmente, quaisquer setas de sinal nos desenhos ou figu-ras devem ser consideradas como somente exemplares, e não limitadoras, amenos que de outra forma especificamente mencionado. Além do mais, otermo "ou" como usado nesse pedido é geralmente planejado para significar"e/ou" a menos que de outra forma indicado. Combinações de componentesou etapas também serão consideradas como sendo mencionadas, onde aterminologia é prevista como tornando obscura a capacidade de separar oucombinar.
Como usado na descrição desse pedido e por todas as reivindi-cações que seguem, "um", "uma" e "o", "a" incluem referências plurais a me-nos que o contexto claramente dite de outra forma. Também, como usadonessa descrição e por todas as reivindicações que seguem, o significado de"em" inclui "em" e "sobre" a menos que o contexto claramente dite de outraforma.
Essa descrição da invenção foi apresentada com as finalidadesde ilustração e descrição. Ela não é planejada para ser exaustiva ou paralimitar a invenção à forma precisa descrita e muitas modificações e varia-ções são possíveis à luz dos ensinamentos acima. As modalidades foramescolhidas e descritas a fim de explicar melhor os princípios da invenção esuas aplicações práticas. Essa descrição possibilitará que outros versadosna técnica utilizem e pratiquem melhor a invenção em várias modalidades ecom várias modificações como sejam adequadas para um uso particular. Oescopo da invenção é definido pelas reivindicações seguintes.

Claims (93)

REIVINDICAÇÕES
1. Sistema de transações financeiras compreendendo:uma interface do consumidor, acoplada em uma rede, compre-endendo:uma interface da Web para tratar de solicitações de transaçãoprovenientes de um cliente do navegador da Web,um navegador da Internet móvel para tratar de solicitações detransação de um navegador da Internet móvel em um cliente de telefonemóvel,uma interface de SMS para tratar de solicitações de transaçãousando troca de mensagens de texto SMS euma interface de aplicação de cliente móvel para tratar de solici-tações provenientes de uma aplicação de cliente móvel executando no clien-te do telefone móvel.
2. Sistema, da reivindicação 1, no qual a interface do consumi-dor também compreende:uma interface de resposta de voz interativa para tratar de solici-tações provenientes de um canal de voz de telefone.
3. Sistema, da reivindicação 1, compreendendo:uma conta em fundo comum para usuários recentemente regis-trados, em que os usuários recentemente registrados podem conduzir astransações provenientes de usuários registrados imediatamente depois doregistro.
4. Sistema, da reivindicação 1, em que a interface de aplicaçãodo cliente móvel permite uma transação de envio de dinheiro, transação decarregamento de conta, transação de descarregamento de conta e transa-ção de pesquisa de saldo.
5. Sistema, da reivindicação 1, em que a interface do consumi-dor também compreende:uma interface de mensageiro instantâneo para tratar de solicita-ções provenientes de um cliente de mensageiro instantâneo.
6. Sistema, da reivindicação 1, compreendendo:uma interface de parceiro financeiro,uma interface comercial, em que usuários através da interfacedo consumidor podem acessar o seu dinheiro em um banco unido ao siste-ma através da interface do parceiro financeiro e transferir dinheiro para co-merciantes unidos à interface comercial.
7. Sistema da reivindicação 1, compreendendo:um sistema de registros gerenciado pelo sistema de transaçãofinanceira, registrando as transações executadas através da interface doconsumidor.
8. Sistema da reivindicação 1, compreendendo:uma conta em fundo comum gerenciada pelo sistema de transa-ção financeira, em que uma pluralidade dos clientes acessando o sistemaatravés da interface do consumidor tem uma conta na conta em fundo co-mum.
9. Sistema da reivindicação 8, em que uma pluralidade dos clien-tes não tem uma conta na conta em fundo comum, mas ao invés disso, umaconta em uma instituição financeira, que tem acesso ao sistema.
10. Método compreendendo:prover uma interface de programa aplicativo para conduzir astransações com um primeiro parceiro financeiro,prover uma interface de troca de mensagens SMS para recebersolicitações para conduzir transações eprover uma interface de aplicação de cliente móvel para recebersolicitações para conduzir transações, em que através da interface do men-sageiro SMS ou da interface do cliente móvel, um cliente pode solicitar umatransferência de dinheiro de uma primeira conta no primeiro parceiro finan-ceiro para uma segunda conta no segundo parceiro financeiro.
11. Método, da reivindicação 10, compreendendo:prover uma interface de programa aplicativo para conduzir astransações com um segundo parceiro financeiro, em que através da interfa-ce do mensageiro SMS ou da interface do cliente móvel, um cliente podesolicitar uma transferência de dinheiro de uma conta no primeiro parceirofinanceiro para uma conta no segundo parceiro financeiro.
12. Método da reivindicação 10, compreendendo:prover um sistema de registro para registrar transações solicita-das através das interfaces de cliente móvel e de troca de mensagens SMS.
13. Método compreendendo:exibir uma primeira tela em um mostrador de um telefone móvelpara mostrar uma pluralidade de opções compreendendo uma primeira op-ção para pagar dinheiro para um outro e uma segunda opção para solicitarinformação de saldo,com o usuário selecionando a primeira opção, exibir uma segun-da tela onde o usuário insere um número de telefone alvo para o qual enviaro pagamento,depois que o usuário insere o número do telefone alvo, exibiruma terceira tela onde o usuário insere uma quantia de transação,depois que o usuário insere o número do telefone, exibir umaquarta tela onde o usuário insere um código PIN edepois que o usuário insere o código PIN, enviar de modo semfio a informação da transação compreendendo o número do telefone alvo, aquantia da transação e o código PIN para um servidor para processamento.
14. Método compreendendo:depois que o usuário insere o número do telefone alvo, exibiruma quinta tela onde o usuário insere uma mensagem opcional.
15. Método, da reivindicação 13, compreendendo:com o usuário selecionando a segunda opção, enviar de modosem-fim uma solicitação por informação de saldo para o servidor,receber informação de saldo proveniente do servidor eexibir a informação de saldo em uma quinta tela.
16. Método, da reivindicação 13, em que a primeira tela tambémprovê uma terceira opção para solicitar pagamento de um outro.
17. Método, da reivindicação 13, em que a segunda tela temuma terceira opção que, com a seleção pelo usuário, provê ao usuário o a -cesso a um livro de endereços do qual o usuário pode selecionar uma entra-da para usar como o número de telefone alvo.
18. Método, da reivindicação 13, em que a informação de tran-sação compreende um número de seqüência gerado pelo telefone móvel.
19. Método, da reivindicação 13, em que fundos são mantidosno servidor e não no telefone móvel.
20. Método, da reivindicação 13, também compreendendo:com a recepção de uma solicitação de solicitar pagamento notelefone móvel, exibir a quinta tela onde o usuário pode inserir uma quantiade gorjeta.
21. Método, compreendendo:receber uma instrução de pagamento proveniente de um primei-ro usuário para pagar a um segundo usuário uma quantia em dinheiro, ondeo primeiro usuário é um usuário registrado e o segundo usuário é identifica-do por um número de telefone para o segundo usuário,com base no número de telefone, determinar que o segundo u-suário não é um usuário registrado,enviar uma primeira mensagem eletrônica para um dispositivoassociado com o número do telefone notificando o segundo usuário do pa-gamento pendente proveniente do primeiro usuário,depois de enviar a primeira mensagem eletrônica, registrar osegundo usuário e apresentar ao segundo usuário uma primeira opção paraaceitar o pagamento pendente proveniente do primeiro usuário e uma se-gunda opção para rejeitar o pagamento pendente proveniente do primeirousuário,quando o segundo usuário seleciona a primeira opção, debitar aquantia em dinheiro de uma primeira conta associada com o primeiro usuárioe creditar a quantia em dinheiro em uma segunda conta associada com osegundo usuário equando o segundo usuário seleciona a segunda opção, enviaruma segunda mensagem eletrônica para o primeiro usuário que o pagamen-to foi declinado.
22. Método, da reivindicação 21, em que a segunda conta ficaem uma conta em fundo comum e quando o primeiro usuário é um usuárioregistrado sem cartão, a primeira conta fica na conta em fundo comum e odébito e o crédito compreendem manter a quantia em dinheiro dentro daconta em fundo comum.
23. Método, da reivindicação 21, em que a segunda conta ficaem uma conta em fundo comum e quando o primeiro usuário é um usuárioregistrado sem cartão, a primeira conta fica na conta em fundo comum e odébito e o crédito compreendem não transferir a quantia em dinheiro fora daconta em fundo comum.
24. Método, da reivindicação 21, em que quando o primeiro usu-ário é um usuário registrado sem cartão, a primeira conta fica em uma pri-meira conta em fundo comum e a segunda conta fica em uma segunda con-ta em fundo comum, diferente da primeira conta em fundo comum, e o débitoe o crédito compreendem transferir a quantia em dinheiro da primeira contaem fundo comum para a segunda conta em fundo comum.
25. Método, da reivindicação 21, em que o primeiro usuário é umusuário registrado com cartão e a segunda conta fica em uma conta em fun-do comum, e o débito e o crédito compreendem transferir a quantia em di-nheiro da primeira conta para a segunda conta na conta em fundo comum,por meio do que a conta em fundo comum é aumentada pela quantia emdinheiro.
26. Método, da reivindicação 21, compreendendo:receber, além da instrução de pagamento, um número de se-qüência gerado por um dispositivo que enviou a instrução de pagamento edepois de receber o número de seqüência, gerar um número detransação para a instrução de pagamento.
27. Método, da reivindicação 21, compreendendo:processar a instrução de pagamento somente se o número daseqüência não iguala qualquer número de seqüência previamente recebidoarmazenado em um banco de dados.
28. Método, da reivindicação 27, em que o banco de dadoscompreende números de seqüência recebidos para um período de temporolante.
29. Método, da reivindicação 21, compreendendo:depois de receber o número de seqüência, gerar um número deseqüência esperado eprocessar a instrução de pagamento somente se o número deseqüência iguala o número de seqüência esperado.
30. Método, compreendendo:receber uma instrução de pagamento proveniente de um primei-ro usuário para pagar a um segundo usuário uma quantia em dinheiro, ondeo primeiro usuário é um usuário registrado e o segundo usuário é identifica-do por um número de telefone para o segundo usuário,com base no número de telefone, determinar que o segundo u-suário não é um usuário registrado,enviar uma primeira mensagem eletrônica para um dispositivoassociado com o número do telefone notificando o segundo usuário do pa-gamento pendente proveniente do primeiro usuário,depois de enviar a primeira mensagem eletrônica, registrar osegundo usuário e apresentar para o segundo usuário uma primeira opçãopara aceitar o pagamento pendente proveniente do primeiro usuário, umasegunda opção para rejeitar o pagamento pendente proveniente do primeirousuário e uma terceira opção para solicitar uma mudança no pagamentopendente proveniente do primeiro usuário,quando o segundo usuário seleciona a primeira opção, debitar aquantia em dinheiro de uma primeira conta associada com o primeiro usuárioe creditar a quantia em dinheiro em uma segunda conta associada com osegundo usuário equando o segundo usuário seleciona a segunda opção, enviaruma segunda mensagem eletrônica para o primeiro usuário que o pagamen-to foi declinado.
31. Método, da reivindicação 30, compreendendo:quando o segundo usuário seleciona a terceira opção, enviaruma terceira mensagem eletrônica para o primeiro usuário que o segundousuário solicitou uma mudança no pagamento pendente.
32. Método, da reivindicação 30, compreendendo:quando o segundo usuário seleciona a terceira opção,receber uma solicitação proveniente do segundo usuário paramudar o pagamento pendente para ter uma quantia em dinheiro diferente,enviar uma terceira mensagem eletrônica para o primeiro usuá-rio notificando o primeiro usuário da mudança no pagamento pendente,apresentar ao primeiro usuário uma quarta opção para aceitar amudança no pagamento pendente ou uma quinta opção para rejeitar a mu-dança no pagamento pendente equando o primeiro usuário seleciona a quarta opção, debitar aquantia em dinheiro diferente de uma conta do primeiro usuário e creditar aquantia em dinheiro diferente em uma conta associada com o segundo usuá-rio.
33. Método, da reivindicação 30, em que o dispositivo é pelomenos um de um telefone inteligente, dispositivo de telefonia móvel, disposi-tivo de e-mail portátil, assistente digital pessoal ou computador.
34. Método, da reivindicação 30, compreendendo:depois de determinar que o segundo usuário não é um usuárioregistrado, colocar um controle na quantia em dinheiro na primeira conta.
35. Método, da reivindicação 30, compreendendo:depois de determinar que o segundo usuário não é um usuárioregistrado, colocar um controle na quantia em dinheiro na primeira conta edepois que um certo número de dias decorre do momento emque a instrução de pagamento foi recebida e o segundo usuário não se re-gistrou, remover o controle na quantia em dinheiro na primeira conta.
36. Método, compreendendo:receber uma instrução de pagamento proveniente de um primei-ro usuário para pagar a um segundo usuário uma quantia em dinheiro, ondeo primeiro usuário é um usuário registrado e o segundo usuário é identifica-do por um número de telefone para o segundo usuário,com base no número de telefone, determinar que o segundo u-suário não é um usuário registrado,enviar uma primeira mensagem eletrônica para um dispositivoassociado com o número do telefone notificando o segundo usuário de umpagamento tentado proveniente do primeiro usuário,depois de enviar a primeira mensagem eletrônica, registrar osegundo usuário, enviar ao primeiro usuário uma segunda mensagem ele-trônica para o primeiro usuário que o segundo usuário se registrou e apre-sentar ao primeiro usuário uma primeira opção para pagar ao segundo usuá-rio a quantia em dinheiro equando o primeiro usuário seleciona a primeira opção, debitar aquantia em dinheiro de uma primeira conta associada com o primeiro usuárioe creditar a quantia em dinheiro em uma segunda conta associada com osegundo usuário.
37. Método, da reivindicação 36, compreendendo:depois que o segundo usuário se registra, creditar a primeiraconta com uma quantia de bonificação de referência.
38. Método, da reivindicação 36, compreendendo:depois que o segundo usuário se registra, creditar a segundaconta com uma quantia de bonificação de referência.
39. Método, da reivindicação 36, compreendendo:enviar uma segunda mensagem eletrônica para o primeiro usuá-rio que o segundo usuário não é um usuário registrado.
40. Método, da reivindicação 36, compreendendo:receber, além da instrução de pagamento, um número de se-qüência gerado por um dispositivo que enviou a instrução de pagamento edepois de receber o número de seqüência, gerar um número detransação para a instrução de pagamento.
41. Método, compreendendo:receber uma solicitação eletrônica por uma transação de trocade valor, transmitida de modo sem fio de um dispositivo do usuário,receber com a solicitação eletrônica uma chave transmitida as-sociada com a solicitação eletrônica,determinar se a chave transmitida existe em uma tabela de tran-sações,se a chave transmitida não está na tabela de transações, inserira chave transmitida e a transação de troca de valor na tabela de transações,e processar a transação de troca de valor,se a chave transmitida está na tabela de transações, não agirsobre a transação de troca de valor.
42. Método, da reivindicação 41, em que a chave transmitidacompreende um identificador eletrônico identificando um usuário que solici-tou a transação de troca de valor e um número de seqüência, o número deseqüência sendo armazenado no dispositivo do usuário e avançado para umpróximo número na seqüência antes que uma próxima transação de troca devalor seja transmitida pelo dispositivo do usuário.
43. Método, da reivindicação 42, em que o número de seqüênciaé armazenado em uma memória não volátil no dispositivo do usuário.
44. Método, da reivindicação 41, em que a chave transmitidacompreende um número pseudoaleatório.
45. Método, da reivindicação 41, em que a chave transmitidacompreende um primeiro identificador eletrônico identificando um usuárioque solicitou a transação de troca de valor, um segundo identificador eletrô-nico identificando um usuário que é um alvo da transação de troca de valor,uma quantia de valor da transação de troca de valor e um tempo associadocom a transação de troca de valor.
46. Método, da reivindicação 41, em que a transação de troca devalor compreende enviar dinheiro de um primeiro usuário associado com odispositivo do usuário para um segundo usuário associado com um outrodispositivo do usuário.
47. Método, da reivindicação 41, em que o dispositivo do usuárioé um telefone móvel.
48. Método, da reivindicação 41, em que a chave transmitidanão é exibida no dispositivo do usuário.
49. Método, da reivindicação 41, em que a solicitação eletrônicaé através de um serviço de troca de mensagens de texto SMS do dispositivodo usuário.
50. Método, da reivindicação 41, em que a chave transmitidacompreende primeira informação quando o dispositivo do usuário envia a solicitação eletrônica usando um primeiro cliente de aplicação e a chavetransmitida compreende primeira informação quando o dispositivo do usuárioenvia a solicitação eletrônica usando um primeiro cliente de aplicação, que édiferente do primeiro cliente de aplicação.
51. Método, da reivindicação 50, em que o primeiro cliente de aplicação é uma aplicação de serviço de transação de troca de valor dedica-da executando no dispositivo do usuário, e o segundo cliente da aplicação éuma aplicação de troca de mensagens SMS do dispositivo do usuário.
52. Método, da reivindicação 41, em que se a chave transmitidaestá na tabela de transações, suspender uma conta de um usuário enviando a solicitação eletrônica.
53. Método, da reivindicação 41, em que o processamento datransação de troca de valor compreende:gerar um número identificador de transação para a transação detroca de valor, enviar uma mensagem eletrônica para o dispositivo do usuárioincluindo o número identificador da transação, em que o número identificadorda transação é visível no dispositivo do usuário.
54. Método, compreendendo:receber uma solicitação eletrônica para uma transação de troca de valor, transmitida de modo sem fio de um dispositivo do usuário,receber uma chave transmitida associada com a solicitação ele-trônica,gerar uma chave esperada,comparar a chave transmitida com a chave esperada e se a chave transmitida iguala a chave esperada, processar atransação de troca de valor.
55. Método, da reivindicação 54, em que gerar a chave esperadacompreende avaliar uma função usando um valor de semente armazenadopara uma conta de usuário associada com a transação da troca de valor, e ométodo também compreende depois de avaliar a função, determinar um pró-ximo valor de semente na seqüência e substituir o valor da semente arma-zenado para a conta do usuário pelo próximo valor de semente na seqüên-cia.
56. Método, da reivindicação 54, compreendendo:se a chave transmitida não iguala a chave esperada, não agirsobre a transação de troca de valor e suspender uma conta de usuário as-sociada com a transação da troca de valor.
57. Método, da reivindicação 54, em que o processamento datransação da troca de valor compreende:gerar um número identificador da transação, diferente da chaveesperada, para a transação da troca de valor, enviar uma mensagem eletrônica para o dispositivo do usuárioincluindo o número identificador da transação, em que o número identificadorda transação é exibido no dispositivo do usuário.
58. Método, da reivindicação 54, em que a transação de troca devalor compreende enviar dinheiro de um primeiro usuário associado com odispositivo do usuário para um segundo usuário associado com um outrodispositivo do usuário.
59. Método, da reivindicação 54, em que a chave esperada é umnúmero pseudoaleatório.
60. Método, da reivindicação 54, em que gerar a chave esperadacompreende:recuperar, de um perfil de usuário associado com a transação detroca de valor, um valor de semente,recuperar a partir da informação do perfil do usuário em umafunção de acordo com a qual a chave transmitida foi gerada eavaliar a função usando o valor de semente.
61. Método, compreendendo:tratar de transações financeiras de um grupo de usuários de umsistema, em que as transações financeiras podem ser especificadas atravésde telefones móveis e subgrupos dos usuários são associados com uma ins-tituição bancária,processar as transações financeiras associadas com uma pri-meira instituição bancária, em que os usuários em um primeiro subgrupo sãoassociados com a primeira instituição bancária,processar transações financeiras associadas com uma segundainstituição bancária, em que os usuários em um segundo subgrupo são as-sociados com a segunda instituição bancária, processar as transações financeiras associadas com uma tercei-ra instituição bancária, em que os usuários em um terceiro grupo são asso-ciados com a terceira instituição bancária,manter uma conta em fundo comum virtual compreendendo fun-dos para os usuários dos primeiro, segundo e terceiro subgrupos associadoscom a primeira, a segunda e a terceira instituições bancárias edistribuir um primeiro dividendo para a primeira instituição ban-cária com base na flutuação para os fundos na conta em fundo comum virtu-al para os usuários do primeiro subgrupo mais uma porcentagem da flutua-ção nos fundos na conta em fundo comum virtual para os usuários do tercei-ro subgrupo.
62. Método, da reivindicação 61, compreendendo:distribuir um segundo dividendo para a segunda instituição ban-cária com base na flutuação para os fundos na conta em fundo comum virtu-al para os usuários do segundo subgrupo mais uma porcentagem da flutua-ção nos fundos na conta em fundo comum virtual para os usuários do tercei-ro subgrupo.
63. Método, da reivindicação 61, compreendendo:receber uma instrução proveniente de um primeiro usuário noprimeiro subgrupo para transferir dinheiro para um segundo usuário no se-gundo subgrupo, em que o dinheiro não é transferido fora da conta em fundocomum virtual.
64. Método, da reivindicação 63, em que a instrução é enviadade modo sem fio de um telefone móvel via a troca de mensagens SMS.
65. Método, da reivindicação 63, em que a instrução é enviadade modo sem fio de um telefone móvel usando uma aplicação executandono telefone móvel.
66. Método, da reivindicação 61, em que a terceira instituiçãobancária é um parceiro direto do sistema.
67. Método, da reivindicação 61, em que cada usuário é associ-ado com somente uma entre a primeira, a segunda ou a terceira instituiçõesfinanceiras.
68. Método, da reivindicação 61, compreendendo:gerenciar um sistema de registro para conta em fundo comumvirtual, em que o sistema de registro compreende registros de transaçõespara usuários no primeiro, segundo e terceiro subgrupos.
69. Método, compreendendo:tratar de transações financeiras de um grupo de usuários de umsistema, em que as transações financeiras podem ser especificadas atravésde telefones móveis e subgrupos dos usuários são associados com uma ins-tituição bancária,processar transações financeiras associadas com uma primeirainstituição bancária, em que os usuários em um primeiro subgrupo são as-sociados com a primeira instituição bancária,processar as transações financeiras associadas com uma se-gunda instituição bancária, em que os usuários em um segundo subgruposão associados com a segunda instituição bancária,processar as transações financeiras dos usuários em um terceirosubgrupo que são associadas com o sistema e não as primeira e segundainstituições bancárias,manter uma conta em fundo comum virtual compreendendo fun-dos para os usuários dos primeiro, segundo e terceiro subgrupos associadoscom a primeira e segunda instituições bancárias e o sistema edistribuir um primeiro dividendo para a primeira instituição ban-cária com base na flutuação para os fundos na conta em fundo comum virtu-al para os usuários do primeiro grupo mais uma porcentagem de flutuaçãonos fundos na conta em fundo comum virtual para os usuários do terceirosubgrupo.
70. Método, da reivindicação 69, compreendendo:distribuir um segundo dividendo para a segunda instituição ban-cária com base na flutuação para os fundos na conta em fundo comum virtu-al para os usuários do segundo subgrupo mais uma porcentagem da flutua-ção nos fundos na conta em fundo comum virtual para os usuários do tercei-ro subgrupo.
71. Método, da reivindicação 69, compreendendo:receber uma instrução proveniente de um primeiro usuário noprimeiro subgrupo para transferir dinheiro para um segundo usuário no se-gundo subgrupo, em que o dinheiro não é transferido fora da conta em fundocomum virtual.
72. Método, da reivindicação 71, em que a instrução é enviadade modo sem fio de um telefone móvel via troca de mensagens SMS.
73. Método, da reivindicação 71, em que a instrução é enviadade modo sem fio de um telefone móvel usando uma aplicação executandono telefone móvel.
74. Método, da reivindicação 69, em que cada usuário é associ-ado com somente um entre a primeira instituição financeira, a segunda insti-tuição financeira ou o sistema.
75. Método, da reivindicação 69, compreendendo:receber uma instrução proveniente de um primeiro usuário noprimeiro subgrupo para transferir dinheiro para um segundo usuário no ter-ceiro subgrupo, em que o dinheiro não é transferido fora da conta em fundocomum virtual.
76. Método, da reivindicação 71, em que a instrução é enviadavia um navegador da Internet.
77. Método, da reivindicação 71, compreendendo:gerenciar um sistema de registro para a conta em fundo comumvirtual, em que o sistema de registro compreende registros de transaçõespara usuários no primeiro, segundo e terceiro subgrupos.
78. Método, compreendendo:receber uma pluralidade de contribuições comerciais para finan-ciar um sistema de pagamentos de membros,colocar as contribuições comerciais em uma conta de confiançaem fundo comum, em que os comerciantes não receberão participação nassuas contribuições,permitir que uma pluralidade de consumidores se torne usuáriosregistrados do pagamento móvel sem despesa,permitir que os usuários registrados carreguem ou descarre-guem fundos em uma conta de giro do sistema de pagamento de membrossem despesa epermitir que os comerciantes carreguem ou descarreguem fun-dos na conta de giro do sistema de pagamento de membros sem despesa,por meio disso a participação na conta de confiança em fundo comum finan-cia o sistema de pagamento de membros.
79. Método, da reivindicação 78, em que o sistema de pagamen-to de membros permite que um usuário registrado solicite pagamento de di-nheiro para um outro usuário registrado via um telefone móvel.
80. Método, da reivindicação 78, em que o sistema de pagamen-to de membros permite que um usuário registrado solicite pagamento de di-nheiro para um comerciante via um telefone móvel.
81. Método, da reivindicação 78, em que o sistema de pagamen-to de membros gerencia registros de transações dos usuários registrados.
82. Método, da reivindicação 78, em que o sistema de pagamen-to de membros gerencia registros de transações dos comerciantes.
83. Método, da reivindicação 78, em que o sistema de pagamen-to de membros gerencia registros de transações dos usuários e comercian-tes registrados.
84. Método, da reivindicação 78, em que quando um comercian-te solicita um reembolso da contribuição do comerciante para o sistema depagamento de membros, os usuários registrados não terão mais permissãode transferir dinheiro para o comerciante.
85. Método, da reivindicação 78, em que não é cobrada do co-merciante uma taxa de transação recorrente periódica por ser um participan-te do sistema de pagamento de membros.
86. Método, da reivindicação 78, em que os usuários registradospodem carregar ou descarregar fundos por meio de pelo menos uma da câ-mara de compensação automatizada (ACH) ou conta de depósito direto(DDA).
87. Método, da reivindicação 78, compreendendo:permitir que um usuário registrado autorize o pagamento de umcomerciante através do sistema de pagamento de membros usando um es-quema de autorização de dois fatores.
88. Método, da reivindicação 78, compreendendo:permitir que um usuário registrado autorize o pagamento de umcomerciante através do sistema de pagamento de membros usando um tele-fone móvel do usuário registrado e o usuário corretamente inserindo um nú-mero de identificação pessoal.
89. Método, da reivindicação 78, em que cada usuário registradoé provido com um cartão de débito.
90. Sistema substancialmente como descrito.
91. Sistema substancialmente como mostrado.
92. Método substancialmente como mostrado.
93. Método substancialmente como descrito.
BRPI0710089-2A 2006-03-30 2007-03-30 sistema de pagamento individualizado móvel BRPI0710089A2 (pt)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US74401306P 2006-03-30 2006-03-30
US60/744,013 2006-03-30
US74493006P 2006-04-15 2006-04-15
US60/744,930 2006-04-15
US87048406P 2006-12-18 2006-12-18
US60/870,484 2006-12-18
PCT/US2007/065721 WO2008027620A1 (en) 2006-03-30 2007-03-30 Mobile person-to-person payment system

Publications (1)

Publication Number Publication Date
BRPI0710089A2 true BRPI0710089A2 (pt) 2011-08-23

Family

ID=38532095

Family Applications (2)

Application Number Title Priority Date Filing Date
BRPI0710089-2A BRPI0710089A2 (pt) 2006-03-30 2007-03-30 sistema de pagamento individualizado móvel
BRPI0710021-3A BRPI0710021A2 (pt) 2006-03-30 2007-03-30 sistema de pagamento individualizado móvel

Family Applications After (1)

Application Number Title Priority Date Filing Date
BRPI0710021-3A BRPI0710021A2 (pt) 2006-03-30 2007-03-30 sistema de pagamento individualizado móvel

Country Status (6)

Country Link
US (3) US20070255653A1 (pt)
EP (4) EP2407918A1 (pt)
BR (2) BRPI0710089A2 (pt)
CA (2) CA2647636A1 (pt)
MX (2) MX2008012504A (pt)
WO (2) WO2008027621A1 (pt)

Cited By (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10078821B2 (en) 2012-03-07 2018-09-18 Early Warning Services, Llc System and method for securely registering a recipient to a computer-implemented funds transfer payment network
US10318936B2 (en) 2012-03-07 2019-06-11 Early Warning Services, Llc System and method for transferring funds
US10395247B2 (en) 2012-03-07 2019-08-27 Early Warning Services, Llc Systems and methods for facilitating a secure transaction at a non-financial institution system
US10395223B2 (en) 2012-03-07 2019-08-27 Early Warning Services, Llc System and method for transferring funds
US10438175B2 (en) 2015-07-21 2019-10-08 Early Warning Services, Llc Secure real-time payment transactions
US10748127B2 (en) 2015-03-23 2020-08-18 Early Warning Services, Llc Payment real-time funds availability
US10769606B2 (en) 2015-03-23 2020-09-08 Early Warning Services, Llc Payment real-time funds availability
US10832246B2 (en) 2015-03-23 2020-11-10 Early Warning Services, Llc Payment real-time funds availability
US10839359B2 (en) 2015-03-23 2020-11-17 Early Warning Services, Llc Payment real-time funds availability
US10846662B2 (en) 2015-03-23 2020-11-24 Early Warning Services, Llc Real-time determination of funds availability for checks and ACH items
US10956888B2 (en) 2015-07-21 2021-03-23 Early Warning Services, Llc Secure real-time transactions
US10963856B2 (en) 2015-07-21 2021-03-30 Early Warning Services, Llc Secure real-time transactions
US10970695B2 (en) 2015-07-21 2021-04-06 Early Warning Services, Llc Secure real-time transactions
US10970688B2 (en) 2012-03-07 2021-04-06 Early Warning Services, Llc System and method for transferring funds
US11037121B2 (en) 2015-07-21 2021-06-15 Early Warning Services, Llc Secure real-time transactions
US11037122B2 (en) 2015-07-21 2021-06-15 Early Warning Services, Llc Secure real-time transactions
US11062290B2 (en) 2015-07-21 2021-07-13 Early Warning Services, Llc Secure real-time transactions
US11144928B2 (en) 2016-09-19 2021-10-12 Early Warning Services, Llc Authentication and fraud prevention in provisioning a mobile wallet
US11151522B2 (en) 2015-07-21 2021-10-19 Early Warning Services, Llc Secure transactions with offline device
US11151523B2 (en) 2015-07-21 2021-10-19 Early Warning Services, Llc Secure transactions with offline device
US11157884B2 (en) 2015-07-21 2021-10-26 Early Warning Services, Llc Secure transactions with offline device
US11386410B2 (en) 2015-07-21 2022-07-12 Early Warning Services, Llc Secure transactions with offline device
US11593800B2 (en) 2012-03-07 2023-02-28 Early Warning Services, Llc System and method for transferring funds
EP4250220A3 (en) * 2011-11-29 2023-12-06 Zuora, Inc. Configurable billing with subscriptions having conditional components

Families Citing this family (860)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8910876B2 (en) 1994-05-25 2014-12-16 Marshall Feature Recognition, Llc Method and apparatus for accessing electronic data via a familiar printed medium
US7712668B2 (en) * 1994-05-25 2010-05-11 Marshall Feature Recognition, Llc Method and apparatus for accessing electronic data via a familiar printed medium
US8261993B2 (en) 1994-05-25 2012-09-11 Marshall Feature Recognition, Llc Method and apparatus for accessing electronic data via a familiar printed medium
US20120030593A1 (en) * 1995-11-13 2012-02-02 Lakshmi Arunachalam Method and apparatus for enabling real-time bi-directional transactions on a network
AU7584298A (en) 1997-05-21 1998-12-11 E.S.P. Communications, Inc. System, method and apparatus for "caller only" initiated two-way wireless communication with caller generated billing
US7146338B2 (en) 2001-06-28 2006-12-05 Checkfree Services Corporation Inter-network financial service
US7483856B2 (en) 2001-01-17 2009-01-27 Xprt Ventures, Llc System and method for effecting payment for an electronic auction commerce transaction
US7949605B2 (en) * 2001-02-23 2011-05-24 Mark Itwaru Secure electronic commerce
US7775426B2 (en) * 2001-04-23 2010-08-17 Paul David K Method and system for facilitating electronic funds transactions
US8870070B2 (en) 2010-10-13 2014-10-28 Square, Inc. Card reader device
US9324100B2 (en) 2002-02-05 2016-04-26 Square, Inc. Card reader with asymmetric spring
US9495675B2 (en) 2002-02-05 2016-11-15 Square, Inc. Small card reader configured to be coupled to a mobile device
US9286635B2 (en) 2002-02-05 2016-03-15 Square, Inc. Method of transmitting information from efficient communication protocol card readers to mobile devices
US9224142B2 (en) 2002-02-05 2015-12-29 Square, Inc. Card reader with power efficient architecture that includes a power supply and a wake up circuit
US9305314B2 (en) 2002-02-05 2016-04-05 Square, Inc. Methods of transmitting information to mobile devices using cost effective card readers
US9016572B2 (en) 2010-10-13 2015-04-28 Square, Inc. Systems and methods for financial transaction through miniaturized card with ASIC
US9916581B2 (en) 2002-02-05 2018-03-13 Square, Inc. Back end of payment system associated with financial transactions using card readers coupled to mobile devices
US9262757B2 (en) 2002-02-05 2016-02-16 Square, Inc. Method of transmitting information from a card reader with a power supply and wake-up circuit to a mobile device
US8573486B2 (en) 2010-10-13 2013-11-05 Square, Inc. Systems and methods for financial transaction through miniaturized card reader with confirmation of payment sent to buyer
US8870071B2 (en) 2010-10-13 2014-10-28 Square, Inc. Read head device with selected sampling rate
US9495676B2 (en) 2002-02-05 2016-11-15 Square, Inc. Method of transmitting information from a power efficient card to a mobile device
US8302860B2 (en) 2010-10-13 2012-11-06 Square, Inc. Read head device with narrow card reading slot
US9582795B2 (en) 2002-02-05 2017-02-28 Square, Inc. Methods of transmitting information from efficient encryption card readers to mobile devices
US8876003B2 (en) 2010-10-13 2014-11-04 Square, Inc. Read head device with selected output jack characteristics
US8500018B2 (en) 2010-10-13 2013-08-06 Square, Inc. Systems and methods for financial transaction through miniaturized card reader with decoding on a seller's mobile device
US9262777B2 (en) 2002-02-05 2016-02-16 Square, Inc. Card reader with power efficient architecture that includes a wake-up circuit
US8235287B2 (en) 2010-10-13 2012-08-07 Square, Inc. Read head device with slot configured to reduce torque
US20120005039A1 (en) 2002-02-05 2012-01-05 Jack Dorsey Method of conducting financial transactions
US8573487B2 (en) 2010-10-13 2013-11-05 Square, Inc. Integrated read head device
WO2003091849A2 (en) 2002-04-23 2003-11-06 The Clearing House Service Company L.L.C. Payment identification code system
US10853890B2 (en) 2012-09-19 2020-12-01 Mastercard International Incorporated Social media transaction visualization structure
US9092828B2 (en) * 2012-09-19 2015-07-28 Mastercard International Incorporated Purchase Data sharing platform
DE10310527B4 (de) 2003-03-11 2008-11-20 Christian Hogl Verfahren zum Initiieren und/oder Durchführen einer Zahlungstransaktion
US20050097046A1 (en) 2003-10-30 2005-05-05 Singfield Joy S. Wireless electronic check deposit scanning and cashing machine with web-based online account cash management computer application system
US8725607B2 (en) 2004-01-30 2014-05-13 The Clearing House Payments Company LLC Electronic payment clearing and check image exchange systems and methods
US11017097B2 (en) 2004-05-14 2021-05-25 Peter N. Ching Systems and methods for prevention of unauthorized access to resources of an information system
US8016185B2 (en) * 2004-07-06 2011-09-13 Visa International Service Association Money transfer service with authentication
US20100081375A1 (en) * 2008-09-30 2010-04-01 Apple Inc. System and method for simplified control of electronic devices
US7598855B2 (en) 2005-02-01 2009-10-06 Location Based Technologies, Inc. Apparatus and method for locating individuals and objects using tracking devices
CA2610216A1 (en) * 2005-06-06 2006-12-14 Sms.Ac, Inc. Billing system and method for micro-transactions
EP1922883A2 (en) * 2005-09-07 2008-05-21 SMS. AC, Inc. Automated billing and distribution platform for application providers
US8833644B2 (en) 2005-10-11 2014-09-16 National Payment Card Association Payment system and methods
US8447700B2 (en) 2005-10-11 2013-05-21 Amazon Technologies, Inc. Transaction authorization service
US9064252B2 (en) 2005-10-11 2015-06-23 National Payment Card Association Payment system and methods
US8205791B2 (en) 2005-10-11 2012-06-26 National Payment Card Association Payment system and methods
US8352376B2 (en) * 2005-10-11 2013-01-08 Amazon Technologies, Inc. System and method for authorization of transactions
US20090030757A1 (en) * 2005-12-19 2009-01-29 Uri Admon Content Distribution for Mobile Phones
US8019365B2 (en) * 2005-12-31 2011-09-13 Michelle Fisher Conducting a payment using a secure element and SMS
US8662384B2 (en) * 2006-02-28 2014-03-04 Google Inc. Text message payment
US20080287095A1 (en) * 2006-03-20 2008-11-20 Sms.Ac Systems and methods for generation, registration and mobile phone billing of a network-enabled application with one-time opt-in
US7826421B2 (en) * 2006-03-20 2010-11-02 Sms.Ac, Inc. Application pod integration with automated mobile phone billing and distribution platform
US20070255653A1 (en) 2006-03-30 2007-11-01 Obopay Inc. Mobile Person-to-Person Payment System
US20080052373A1 (en) * 2006-05-01 2008-02-28 Sms.Ac Systems and methods for a community-based user interface
US7966263B2 (en) * 2006-05-04 2011-06-21 First Data Corporation Wireless phone RF presentation instrument with sensor control
US9466057B2 (en) * 2006-05-04 2016-10-11 First Data Corporation RF presentation instrument with sensor control
US7835720B2 (en) * 2006-05-19 2010-11-16 Sms.Ac, Inc. Systems and methods for automatic generation, registration and mobile phone billing of a pod using third party web page content
US9848081B2 (en) * 2006-05-25 2017-12-19 Celltrust Corporation Dissemination of real estate information through text messaging
US8260274B2 (en) * 2006-05-25 2012-09-04 Celltrust Corporation Extraction of information from e-mails and delivery to mobile phones, system and method
US8280359B2 (en) * 2006-05-25 2012-10-02 Celltrust Corporation Methods of authorizing actions
WO2007139909A2 (en) * 2006-05-25 2007-12-06 Celltrust Corporation Secure mobile information management system and method
US8225380B2 (en) * 2006-05-25 2012-07-17 Celltrust Corporation Methods to authenticate access and alarm as to proximity to location
US8965416B2 (en) * 2006-05-25 2015-02-24 Celltrust Corporation Distribution of lottery tickets through mobile devices
US9572033B2 (en) 2006-05-25 2017-02-14 Celltrust Corporation Systems and methods for encrypted mobile voice communications
US20070293187A1 (en) * 2006-06-15 2007-12-20 Motorola, Inc. Method and System for Enabling Location Based Wireless Communication Services
US9135626B2 (en) * 2006-06-30 2015-09-15 Nokia Technologies Oy Advertising middleware
US8467766B2 (en) 2006-07-06 2013-06-18 Qualcomm Incorporated Methods and systems for managing payment sources in a mobile environment
US9911114B2 (en) 2006-07-06 2018-03-06 Qualcomm Incorporated Methods and systems for making a payment via a stored value card in a mobile environment
US8160959B2 (en) * 2006-07-06 2012-04-17 Firethorn Mobile, Inc. Methods and systems for payment transactions in a mobile environment
US8510220B2 (en) * 2006-07-06 2013-08-13 Qualcomm Incorporated Methods and systems for viewing aggregated payment obligations in a mobile environment
US8121945B2 (en) * 2006-07-06 2012-02-21 Firethorn Mobile, Inc. Methods and systems for payment method selection by a payee in a mobile environment
US8489067B2 (en) 2006-07-06 2013-07-16 Qualcomm Incorporated Methods and systems for distribution of a mobile wallet for a mobile device
US20080010204A1 (en) * 2006-07-06 2008-01-10 Firethorn Holdings, Llc Methods and Systems For Making a Payment Via a Paper Check in a Mobile Environment
US8145568B2 (en) * 2006-07-06 2012-03-27 Firethorn Mobile, Inc. Methods and systems for indicating a payment in a mobile environment
US10115112B2 (en) 2006-08-31 2018-10-30 Visa U.S.A. Inc. Transaction evaluation for providing rewards
US10037535B2 (en) * 2006-08-31 2018-07-31 Visa U.S.A. Inc. Loyalty program parameter collaboration
US20080059302A1 (en) * 2006-08-31 2008-03-06 Fordyce Iii Edward W Loyalty program service
US20090024614A1 (en) * 2006-09-06 2009-01-22 Sms.Ac Systems and methods for online content searching
US9047601B2 (en) 2006-09-24 2015-06-02 RFCyber Corpration Method and apparatus for settling payments using mobile devices
US8708227B1 (en) 2006-10-31 2014-04-29 United Services Automobile Association (Usaa) Systems and methods for remote deposit of checks
US7873200B1 (en) 2006-10-31 2011-01-18 United Services Automobile Association (Usaa) Systems and methods for remote deposit of checks
US8799147B1 (en) 2006-10-31 2014-08-05 United Services Automobile Association (Usaa) Systems and methods for remote deposit of negotiable instruments with non-payee institutions
US8351677B1 (en) 2006-10-31 2013-01-08 United Services Automobile Association (Usaa) Systems and methods for remote deposit of checks
US7885451B1 (en) 2006-10-31 2011-02-08 United Services Automobile Association (Usaa) Systems and methods for displaying negotiable instruments derived from various sources
US7876949B1 (en) 2006-10-31 2011-01-25 United Services Automobile Association Systems and methods for remote deposit of checks
EP2103019A4 (en) 2007-01-09 2012-07-11 Visa Usa Inc CONTACT-FREE TRANSACTION
US20080177668A1 (en) * 2007-01-24 2008-07-24 Bruno Delean Computerized person-to-person payment system and method without use of currency
US20080200144A1 (en) * 2007-02-16 2008-08-21 Ginsberg Todd D System and Method for Providing Alerts Over a Network
US8935187B2 (en) * 2007-03-07 2015-01-13 Playspan, Inc. Distributed payment system and method
US20080228582A1 (en) * 2007-03-15 2008-09-18 Fordyce Edward W Loyalty program for merchant inventory
US8959033B1 (en) 2007-03-15 2015-02-17 United Services Automobile Association (Usaa) Systems and methods for verification of remotely deposited checks
US10380559B1 (en) 2007-03-15 2019-08-13 United Services Automobile Association (Usaa) Systems and methods for check representment prevention
US20080232561A1 (en) * 2007-03-20 2008-09-25 Microsoft Corporation Advertising funded data access services
US20090319425A1 (en) * 2007-03-30 2009-12-24 Obopay, Inc. Mobile Person-to-Person Payment System
US20090287601A1 (en) 2008-03-14 2009-11-19 Obopay, Inc. Network-Based Viral Payment System
US9111189B2 (en) 2007-10-31 2015-08-18 Location Based Technologies, Inc. Apparatus and method for manufacturing an electronic package
US8774827B2 (en) 2007-04-05 2014-07-08 Location Based Technologies, Inc. Apparatus and method for generating position fix of a tracking device in accordance with a subscriber service usage profile to conserve tracking device power
US8224355B2 (en) * 2007-11-06 2012-07-17 Location Based Technologies Inc. System and method for improved communication bandwidth utilization when monitoring location information
US8244468B2 (en) 2007-11-06 2012-08-14 Location Based Technology Inc. System and method for creating and managing a personalized web interface for monitoring location information on individuals and objects using tracking devices
US8102256B2 (en) 2008-01-06 2012-01-24 Location Based Technologies Inc. Apparatus and method for determining location and tracking coordinates of a tracking device
US8497774B2 (en) 2007-04-05 2013-07-30 Location Based Technologies Inc. Apparatus and method for adjusting refresh rate of location coordinates of a tracking device
US20080249937A1 (en) * 2007-04-06 2008-10-09 Walls Robert K Payment card based remittance system with delivery of anti-money laundering information to receiving financial institution
JP5156254B2 (ja) * 2007-04-17 2013-03-06 楽天株式会社 情報処理装置、情報処理方法、及び情報処理プログラム
US8543496B2 (en) * 2007-04-27 2013-09-24 American Express Travel Related Services Company, Inc. User experience on mobile phone
US8620260B2 (en) 2007-04-27 2013-12-31 American Express Travel Related Services Company, Inc. Payment application download to mobile phone and phone personalization
US20080270301A1 (en) * 2007-04-27 2008-10-30 American Express Travel Related Services Co., Inc. Mobile payment system and method
US8688570B2 (en) * 2007-04-27 2014-04-01 American Express Travel Related Services Company, Inc. System and method for performing person-to-person funds transfers via wireless communications
US20080288376A1 (en) 2007-04-27 2008-11-20 Cashedge, Inc. Centralized payment hub method and system
US10395264B2 (en) 2007-04-30 2019-08-27 Visa U.S.A. Inc. Payment account processing which conveys financial transaction data and non financial transaction data
US8433127B1 (en) 2007-05-10 2013-04-30 United Services Automobile Association (Usaa) Systems and methods for real-time validation of check image quality
US8538124B1 (en) 2007-05-10 2013-09-17 United Services Auto Association (USAA) Systems and methods for real-time validation of check image quality
US20090005014A1 (en) * 2007-06-28 2009-01-01 Vernick Michael David Call back system and method for directing customer service representative to a mobile device associated with a customer
US8768778B2 (en) 2007-06-29 2014-07-01 Boku, Inc. Effecting an electronic payment
US20090063178A1 (en) * 2007-08-17 2009-03-05 Sms.Ac Systems and methods for a mobile, community-based user interface
US10068225B2 (en) * 2007-08-18 2018-09-04 Espensify, Inc. System and method for utilizing a universal prepaid card
US9830582B1 (en) 2007-08-18 2017-11-28 Expensify, Inc. System, computer readable medium, and method for authorizing purchase using on-demand prepaid card
US10163092B2 (en) 2007-08-18 2018-12-25 Expensify, Inc. System and method for establishing a payment mechanism with a plurality of merchants
US7945482B2 (en) * 2007-08-23 2011-05-17 Ebay Inc. Viewing shopping information on a network-based social platform
US7720722B2 (en) 2007-08-23 2010-05-18 Ebay Inc. Sharing shopping information on a network-based social platform
US20100169170A1 (en) * 2007-08-30 2010-07-01 Fordyce Iii Edward W Merchant offer program
US8660966B2 (en) * 2007-08-31 2014-02-25 Microsoft Corporation Payment system and method
US20090069049A1 (en) 2007-09-12 2009-03-12 Devicefidelity, Inc. Interfacing transaction cards with host devices
US9304555B2 (en) 2007-09-12 2016-04-05 Devicefidelity, Inc. Magnetically coupling radio frequency antennas
US20090070263A1 (en) * 2007-09-12 2009-03-12 Wachovia Corporation Peer to peer fund transfer
US8915447B2 (en) 2007-09-12 2014-12-23 Devicefidelity, Inc. Amplifying radio frequency signals
US8070057B2 (en) 2007-09-12 2011-12-06 Devicefidelity, Inc. Switching between internal and external antennas
US9311766B2 (en) 2007-09-12 2016-04-12 Devicefidelity, Inc. Wireless communicating radio frequency signals
US7729989B1 (en) 2007-09-19 2010-06-01 Amazon Technologies, Inc. Method and apparatus for message correction in a transaction authorization service
US10657503B1 (en) * 2007-09-19 2020-05-19 Capital One Services, Llc System and method of providing a customer with method of making a payment to a third party using a remote dispensing machine
US8239326B1 (en) 2007-09-19 2012-08-07 Amazon Technologies, Inc. Method and apparatus for authorizing transactions using transaction phrases in a transaction authorization service
US8249935B1 (en) 2007-09-27 2012-08-21 Sprint Communications Company L.P. Method and system for blocking confidential information at a point-of-sale reader from eavesdropping
US9058512B1 (en) 2007-09-28 2015-06-16 United Services Automobile Association (Usaa) Systems and methods for digital signature detection
US7707113B1 (en) * 2007-09-28 2010-04-27 Sprint Communications Company L.P. Method and system for setting levels of electronic wallet security
US8121957B1 (en) 2007-10-01 2012-02-21 Google Inc. Discrete verification of payment information
US9883381B1 (en) 2007-10-02 2018-01-30 Sprint Communications Company L.P. Providing secure access to smart card applications
US20090106148A1 (en) * 2007-10-17 2009-04-23 Christian Prada Pre-paid financial system
US8654974B2 (en) 2007-10-18 2014-02-18 Location Based Technologies, Inc. Apparatus and method to provide secure communication over an insecure communication channel for location information using tracking devices
US8358826B1 (en) 2007-10-23 2013-01-22 United Services Automobile Association (Usaa) Systems and methods for receiving and orienting an image of one or more checks
US9898778B1 (en) 2007-10-23 2018-02-20 United Services Automobile Association (Usaa) Systems and methods for obtaining an image of a check to be deposited
US9159101B1 (en) 2007-10-23 2015-10-13 United Services Automobile Association (Usaa) Image processing
US9892454B1 (en) 2007-10-23 2018-02-13 United Services Automobile Association (Usaa) Systems and methods for obtaining an image of a check to be deposited
US20090112767A1 (en) 2007-10-25 2009-04-30 Ayman Hammad Escrow system and method
US8046301B1 (en) 2007-10-30 2011-10-25 United Services Automobile Association (Usaa) Systems and methods to modify a negotiable instrument
US7996315B1 (en) 2007-10-30 2011-08-09 United Services Automobile Association (Usaa) Systems and methods to modify a negotiable instrument
US8001051B1 (en) 2007-10-30 2011-08-16 United Services Automobile Association (Usaa) Systems and methods to modify a negotiable instrument
US7996316B1 (en) 2007-10-30 2011-08-09 United Services Automobile Association Systems and methods to modify a negotiable instrument
US7996314B1 (en) 2007-10-30 2011-08-09 United Services Automobile Association (Usaa) Systems and methods to modify a negotiable instrument
US8320657B1 (en) 2007-10-31 2012-11-27 United Services Automobile Association (Usaa) Systems and methods to use a digital camera to remotely deposit a negotiable instrument
US8290237B1 (en) 2007-10-31 2012-10-16 United Services Automobile Association (Usaa) Systems and methods to use a digital camera to remotely deposit a negotiable instrument
US7896232B1 (en) 2007-11-06 2011-03-01 United Services Automobile Association (Usaa) Systems, methods, and apparatus for receiving images of one or more checks
US7900822B1 (en) 2007-11-06 2011-03-08 United Services Automobile Association (Usaa) Systems, methods, and apparatus for receiving images of one or more checks
US8357034B2 (en) 2007-11-08 2013-01-22 Igt Gaming system and method providing third party promotions
CN100565597C (zh) * 2007-11-16 2009-12-02 北京飞天诚信科技有限公司 一种自助充值的系统和方法
US7689508B2 (en) * 2007-11-20 2010-03-30 Wells Fargo Bank N.A. Mobile device credit account
US9098844B2 (en) 2007-11-20 2015-08-04 Wells Fargo Bank, N.A. Mobile electronic wallet
US20090138794A1 (en) * 2007-11-27 2009-05-28 Joseph Becker System and method for securing web applications
US8126806B1 (en) 2007-12-03 2012-02-28 Sprint Communications Company L.P. Method for launching an electronic wallet
US20090157523A1 (en) * 2007-12-13 2009-06-18 Chacha Search, Inc. Method and system for human assisted referral to providers of products and services
US7958052B2 (en) 2007-12-31 2011-06-07 Mastercard International Incorporated Methods and systems for cardholder initiated transactions
US20090182674A1 (en) * 2008-01-14 2009-07-16 Amol Patel Facilitating financial transactions with a network device
US8055184B1 (en) 2008-01-30 2011-11-08 Sprint Communications Company L.P. System and method for active jamming of confidential information transmitted at a point-of-sale reader
US10552701B2 (en) * 2008-02-01 2020-02-04 Oath Inc. System and method for detecting the source of media content with application to business rules
US20090204503A1 (en) * 2008-02-07 2009-08-13 First Data Corporation Methods and systems for establishing investment accounts associated with presentation instruments
US10380562B1 (en) 2008-02-07 2019-08-13 United Services Automobile Association (Usaa) Systems and methods for mobile deposit of negotiable instruments
WO2009100477A1 (en) * 2008-02-15 2009-08-20 Rubik Financial Limited An interface
US8577804B1 (en) * 2008-02-20 2013-11-05 Collective Dynamics LLC Method and system for securing payment transactions
US11816665B2 (en) 2008-02-20 2023-11-14 Stripe, Inc. Method and system for multi-modal transaction authentication
US9852426B2 (en) 2008-02-20 2017-12-26 Collective Dynamics LLC Method and system for secure transactions
US8141780B2 (en) 2008-02-23 2012-03-27 Cedar Ridge Research Llc System and method for data card emulation
US8285643B2 (en) * 2008-06-12 2012-10-09 Monncello Enterprises, LLC System and method for processing gift cards
US20120150643A1 (en) * 2010-12-14 2012-06-14 Moneyhoney Llc System and method for processing remainder amounts of money from gift cards
US20140207662A1 (en) 2008-03-13 2014-07-24 Giftya Llc System and method for managing gifts
US20120150743A1 (en) * 2010-12-14 2012-06-14 Moneyhoney Llc System and method for transferring redemption rights to gift cards
US10489776B2 (en) 2008-03-13 2019-11-26 Giftya Llc System and method for managing gift credits
US20140214666A1 (en) 2008-03-13 2014-07-31 Giftya Llc System and method for managing gifts
US10949833B2 (en) 2008-03-13 2021-03-16 Giftya Llc Technologies for generating and displaying virtual and interactive egifts
US20140249902A1 (en) 2008-03-13 2014-09-04 Giftya Llc System and method for providing a customer survey
US20120150732A1 (en) * 2010-12-14 2012-06-14 Moneyhoney Llc System and method for processing gift cards according to a communication context
US20120150600A1 (en) * 2010-12-14 2012-06-14 Moneyhoney Llc System and method for confirming application of a gift to a transaction
US20120150730A1 (en) * 2010-12-14 2012-06-14 Moneyhoney Llc System and method for processing group gift cards
US20140250001A1 (en) * 2010-12-14 2014-09-04 Giftya Llc System and method for processing gifts between different payment account types
US8676704B2 (en) 2008-03-13 2014-03-18 Giftya Llc Method for transferring funds
US7974859B1 (en) 2008-03-18 2011-07-05 United Services Automobile Association Systems and methods for modeling insurance coverage
US7983938B1 (en) 2008-03-18 2011-07-19 United Services Automobile Association Systems and methods for modeling recommended insurance coverage
US7983937B1 (en) 2008-03-18 2011-07-19 United Services Automobile Association Systems and methods for modeling recommended insurance coverage
US7966202B1 (en) 2008-03-18 2011-06-21 United Services Automobile Association Systems and methods for modeling insurance coverage
US7966201B1 (en) 2008-03-18 2011-06-21 United Services Automobile Association Systems and methods for modeling insurance coverage
US7966200B1 (en) 2008-03-18 2011-06-21 United Services Automobile Association Systems and methods for modeling insurance coverage
US8249961B1 (en) 2008-03-19 2012-08-21 United States Automobile Association Systems and methods for managing consolidated purchasing, billing and payment information
US8117100B1 (en) 2008-03-19 2012-02-14 Unites Services Automobile Association (USAA) Systems and methods for managing consolidated purchasing, billing and payment information
US8620826B2 (en) 2008-03-27 2013-12-31 Amazon Technologies, Inc. System and method for receiving requests for tasks from unregistered devices
US8204827B1 (en) 2008-03-27 2012-06-19 Amazon Technologies, Inc. System and method for personalized commands
US8244592B2 (en) * 2008-03-27 2012-08-14 Amazon Technologies, Inc. System and method for message-based purchasing
CA2719794C (en) 2008-03-28 2020-10-27 Celltrust Corporation Systems and methods for secure short messaging service and multimedia messaging service
US20090248533A1 (en) * 2008-03-31 2009-10-01 Txttunes Limited Systems and methods for conducting transactions
US8655310B1 (en) 2008-04-08 2014-02-18 Sprint Communications Company L.P. Control of secure elements through point-of-sale device
US20090259532A1 (en) * 2008-04-11 2009-10-15 Microsoft Corporation Peer-to-peer compensation in an intent-compensation scheme
US20090259537A1 (en) * 2008-04-14 2009-10-15 Microsoft Corporation Advertisement-funded software
US8799149B2 (en) * 2008-04-16 2014-08-05 Visa U.S.A. Inc. Loyalty rewards optimization bill payables and receivables service
WO2009136404A2 (en) * 2008-04-17 2009-11-12 Atom Technologies Limited A system and method for implementing a secure transaction through mobile communicating device
US20090265252A1 (en) * 2008-04-21 2009-10-22 Charles Dale Fletcher Money pooling with electronic invoice
US9626821B2 (en) * 2008-04-24 2017-04-18 Qualcomm Incorporated Electronic payment system
US8180705B2 (en) * 2008-04-30 2012-05-15 Intuit Inc. Method and apparatus for initiating a funds transfer using a mobile device
US9953313B2 (en) 2008-05-09 2018-04-24 Verient, Inc. System and method for distributed payment products
US11080678B2 (en) 2008-05-09 2021-08-03 Verient, Inc. Payment processing platform
WO2009138848A2 (en) * 2008-05-14 2009-11-19 Fundamo (Pty) Ltd Mobile commerce payment system
US20090287599A1 (en) * 2008-05-15 2009-11-19 Bank Of America Corporation Monetary Transfer Approval Via Mobile Device
US20090287603A1 (en) * 2008-05-15 2009-11-19 Bank Of America Corporation Actionable Alerts in Corporate Mobile Banking
AU2009249272B2 (en) 2008-05-18 2014-11-20 Google Llc Secured electronic transaction system
GB0809386D0 (en) * 2008-05-23 2008-07-02 Vidicom Ltd Transferring funds electronically
GB0809381D0 (en) 2008-05-23 2008-07-02 Vidicom Ltd Funds transfer electronically
GB0809383D0 (en) 2008-05-23 2008-07-02 Vidicom Ltd Customer to supplier funds transfer
GB0809382D0 (en) * 2008-05-23 2008-07-02 Vidicom Ltd Funds transfer electronically
AU2009260473B2 (en) 2008-05-28 2015-05-07 Visa International Service Association Gateway service platform
US8069114B2 (en) 2008-05-29 2011-11-29 Ebay, Inc. Method and system for processing transfer requests
US20140250002A1 (en) * 2008-05-29 2014-09-04 Giftya Llc System and method for processing a gift card via the cloud
US8543091B2 (en) * 2008-06-06 2013-09-24 Ebay Inc. Secure short message service (SMS) communications
US20090307140A1 (en) * 2008-06-06 2009-12-10 Upendra Mardikar Mobile device over-the-air (ota) registration and point-of-sale (pos) payment
US8401681B2 (en) 2008-06-08 2013-03-19 Apple Inc. System and method for placeshifting media playback
US11258652B2 (en) 2008-06-08 2022-02-22 Apple Inc. System and method for placeshifting media playback
US9626363B2 (en) 2008-06-08 2017-04-18 Apple Inc. System and method for placeshifting media playback
EP2304678A1 (en) * 2008-06-09 2011-04-06 Obopay Inc. Mobile payment system
US8351678B1 (en) 2008-06-11 2013-01-08 United Services Automobile Association (Usaa) Duplicate check detection
EP3054408A1 (en) 2008-06-24 2016-08-10 HSBC Technology & Services (USA) Inc. Methods and systems for verifying customer supplied financial account information using debit and credit transactions
US8655341B2 (en) * 2008-06-24 2014-02-18 Haim Boukai Methods for mobile phone applications
CN102105863B (zh) * 2008-06-24 2015-02-11 哈伊姆·布卡伊 用于移动电话应用程序的方法
FR2933217A1 (fr) * 2008-06-27 2010-01-01 Commissariat Energie Atomique Dispositif de paiement dematerialise d'une facture en utilisant des titres de paiement prepayes
KR100988230B1 (ko) * 2008-06-30 2010-10-18 주식회사 티모넷 휴대폰을 이용한 전자지불수단의 충전금액 이전시스템 및그 방법
US20090321522A1 (en) * 2008-06-30 2009-12-31 Jonathan Charles Lohr Utilizing data from purchases made with mobile communications device for financial recordkeeping
US8187972B2 (en) * 2008-07-01 2012-05-29 Teledyne Scientific & Imaging, Llc Through-substrate vias with polymer fill and method of fabricating same
US20100017413A1 (en) * 2008-07-17 2010-01-21 Ian Edward James Systems and methods for transferring value
US9324098B1 (en) 2008-07-22 2016-04-26 Amazon Technologies, Inc. Hosted payment service system and method
US20100036767A1 (en) * 2008-08-06 2010-02-11 Sharoff Narasimha N Reserving amount of payment from financial account balance
US20100042539A1 (en) * 2008-08-18 2010-02-18 Sanjeev Dheer Money Movement Network Hub System
US8275097B2 (en) * 2008-08-28 2012-09-25 Ebay Inc. Voice phone-based method and system to authenticate users
US8422758B1 (en) 2008-09-02 2013-04-16 United Services Automobile Association (Usaa) Systems and methods of check re-presentment deterrent
CN101667275A (zh) * 2008-09-04 2010-03-10 阿里巴巴集团控股有限公司 一种离线充值方法及系统
US7936736B2 (en) 2008-09-08 2011-05-03 Proctor Jr James Arthur Enforcing policies in wireless communication using exchanged identities
US10504185B1 (en) 2008-09-08 2019-12-10 United Services Automobile Association (Usaa) Systems and methods for live video financial deposit
US9747621B1 (en) * 2008-09-23 2017-08-29 Amazon Technologies, Inc. Widget-based integration of payment gateway functionality into transactional sites
US20100082466A1 (en) * 2008-09-26 2010-04-01 Mark Carlson Beneficiary initiated p2p, p2b payment model
US20100082485A1 (en) * 2008-09-30 2010-04-01 Apple Inc. Portable point of purchase devices and methods
US7885880B1 (en) 2008-09-30 2011-02-08 United Services Automobile Association (Usaa) Atomic deposit transaction
US8060627B2 (en) * 2008-09-30 2011-11-15 Apple Inc. Device-to-device workflows
US9070149B2 (en) 2008-09-30 2015-06-30 Apple Inc. Media gifting devices and methods
US8239276B2 (en) * 2008-09-30 2012-08-07 Apple Inc. On-the-go shopping list
US9037513B2 (en) * 2008-09-30 2015-05-19 Apple Inc. System and method for providing electronic event tickets
US9026462B2 (en) * 2008-09-30 2015-05-05 Apple Inc. Portable point of purchase user interfaces
US8275710B1 (en) 2008-09-30 2012-09-25 United Services Automobile Association (Usaa) Systems and methods for automatic bill pay enrollment
US20100082490A1 (en) * 2008-09-30 2010-04-01 Apple Inc. Systems and methods for secure wireless transactions
US8131645B2 (en) * 2008-09-30 2012-03-06 Apple Inc. System and method for processing media gifts
US8850052B2 (en) * 2008-09-30 2014-09-30 Apple Inc. System and method for simplified resource sharing
US10380573B2 (en) * 2008-09-30 2019-08-13 Apple Inc. Peer-to-peer financial transaction devices and methods
US7962411B1 (en) * 2008-09-30 2011-06-14 United Services Automobile Association (Usaa) Atomic deposit transaction
US20100078471A1 (en) * 2008-09-30 2010-04-01 Apple Inc. System and method for processing peer-to-peer financial transactions
US8215546B2 (en) * 2008-09-30 2012-07-10 Apple Inc. System and method for transportation check-in
US20100078472A1 (en) 2008-09-30 2010-04-01 Apple Inc. Group peer-to-peer financial transactions
US7974899B1 (en) 2008-09-30 2011-07-05 United Services Automobile Association (Usaa) Atomic deposit transaction
US20100082455A1 (en) * 2008-09-30 2010-04-01 Apple Inc. Real-time bargain hunting
US8832182B2 (en) 2008-10-03 2014-09-09 Omnego Inc. System and method for providing a universal electronic wallet
US8391599B1 (en) 2008-10-17 2013-03-05 United Services Automobile Association (Usaa) Systems and methods for adaptive binarization of an image
US9195981B2 (en) * 2008-10-23 2015-11-24 Ims Health Incorporated System and method for authorizing transactions via mobile devices
US7949587B1 (en) 2008-10-24 2011-05-24 United States Automobile Association (USAA) Systems and methods for financial deposits by electronic message
US7970677B1 (en) 2008-10-24 2011-06-28 United Services Automobile Association (Usaa) Systems and methods for financial deposits by electronic message
US10867298B1 (en) * 2008-10-31 2020-12-15 Wells Fargo Bank, N.A. Payment vehicle with on and off function
US20100114768A1 (en) 2008-10-31 2010-05-06 Wachovia Corporation Payment vehicle with on and off function
DK2461297T3 (da) * 2008-11-12 2020-12-21 Idemia Denmark As Anordning og fremgangsmåde til distribution af et personligt id-nummer
US20100125492A1 (en) * 2008-11-14 2010-05-20 Apple Inc. System and method for providing contextual advertisements according to dynamic pricing scheme
US20100131347A1 (en) * 2008-11-24 2010-05-27 Research In Motion Limited Electronic payment system using mobile wireless communications device and associated methods
CA2645363A1 (en) * 2008-11-27 2010-05-27 Isidore Papadopoulos Infrastructure for instantaneous domestic and international mobile consumer commerce payment
US8341631B2 (en) 2009-04-10 2012-12-25 Open Invention Network Llc System and method for application isolation
CN101499153A (zh) * 2008-12-26 2009-08-05 北京握奇数据系统有限公司 实现安全移动支付的方法及装置
JP5296221B2 (ja) 2008-12-29 2013-09-25 テレフオンアクチーボラゲット エル エム エリクソン（パブル） Ｎｆｃ対応デバイスにアプリケーションをインストールする方法及びｎｆｃ対応デバイス、サーバノード、コンピュータ可読媒体、コンピュータプログラム
US20100169182A1 (en) * 2008-12-30 2010-07-01 Masih Madani Mobile payment method and system using the same
US8200582B1 (en) 2009-01-05 2012-06-12 Sprint Communications Company L.P. Mobile device password system
US8060449B1 (en) 2009-01-05 2011-11-15 Sprint Communications Company L.P. Partially delegated over-the-air provisioning of a secure element
US9928490B1 (en) 2009-01-16 2018-03-27 Wells Fargo Bank, N.A. System and method for transferring funds
US8041639B2 (en) * 2009-01-23 2011-10-18 Vidicom Limited Systems and methods to facilitate online transactions
US8116730B2 (en) * 2009-01-23 2012-02-14 Vidicom Limited Systems and methods to control online transactions
US9652761B2 (en) 2009-01-23 2017-05-16 Boku, Inc. Systems and methods to facilitate electronic payments
US10783581B2 (en) * 2009-01-28 2020-09-22 Headwater Research Llc Wireless end-user device providing ambient or sponsored services
GB2467530A (en) * 2009-02-03 2010-08-11 Eservglobal Uk Ltd Credit transfer between telecommunications networks
US9767354B2 (en) 2009-02-10 2017-09-19 Kofax, Inc. Global geographic information retrieval, validation, and normalization
TWI496097B (zh) * 2009-02-10 2015-08-11 Alibaba Group Holding Ltd Off - line value - added method and system
US8768845B1 (en) 2009-02-16 2014-07-01 Sprint Communications Company L.P. Electronic wallet removal from mobile electronic devices
US8452689B1 (en) 2009-02-18 2013-05-28 United Services Automobile Association (Usaa) Systems and methods of check detection
US8548426B2 (en) 2009-02-20 2013-10-01 Boku, Inc. Systems and methods to approve electronic payments
US9990623B2 (en) 2009-03-02 2018-06-05 Boku, Inc. Systems and methods to provide information
US10430873B2 (en) 2009-03-02 2019-10-01 Kabbage, Inc. Method and apparatus to evaluate and provide funds in online environments
US10956728B1 (en) 2009-03-04 2021-03-23 United Services Automobile Association (Usaa) Systems and methods of check processing with background removal
US20100235275A1 (en) * 2009-03-06 2010-09-16 Carl Ansley Card Processing
US20100228683A1 (en) * 2009-03-06 2010-09-09 TxVia, Inc. Issuing systems, acquiring systems, and payment networks/systems development
US8700530B2 (en) 2009-03-10 2014-04-15 Boku, Inc. Systems and methods to process user initiated transactions
BRPI1014196A8 (pt) * 2009-03-26 2017-07-25 Nokia Corp Método e aparelho para proporcionar transações de pagamento off-line com transferência de dados mínima
US8160943B2 (en) 2009-03-27 2012-04-17 Boku, Inc. Systems and methods to process transactions based on social networking
US8224727B2 (en) 2009-05-27 2012-07-17 Boku, Inc. Systems and methods to process transactions based on social networking
US8401940B1 (en) * 2009-04-10 2013-03-19 Open Invention Network Llc System and method for usage billing of hosted applications
US10423944B1 (en) * 2009-04-10 2019-09-24 Open Invention Network Llc System and method for usage billing of hosted applications
US8131258B2 (en) 2009-04-20 2012-03-06 Boku, Inc. Systems and methods to process transaction requests
US7937291B2 (en) * 2009-04-22 2011-05-03 Visa U.S.A. Inc. Providing an announcement about transactions of a target merchant to a consumer
US8160934B2 (en) * 2009-04-22 2012-04-17 Visa U.S.A. Inc. Notification of resources of interest to members of a consumer group
US8543468B2 (en) * 2009-04-22 2013-09-24 Visa U.S.A. Inc. Bidding to receive data after a consumer is in a zone
US20100274567A1 (en) * 2009-04-22 2010-10-28 Mark Carlson Announcing information about payment transactions of any member of a consumer group
US20100274566A1 (en) * 2009-04-22 2010-10-28 Mark Carlson Location based processing of announcements for delivery to an announcement recipient
US20100274626A1 (en) * 2009-04-22 2010-10-28 Mark Carlson Receipt of communications from announcement recipients of consumer data
US20100274627A1 (en) * 2009-04-22 2010-10-28 Mark Carlson Receiving an announcement triggered by location data
CA2759922A1 (en) * 2009-04-22 2010-10-28 Visa U.S.A. Inc. Triggered announcement
US8032413B2 (en) 2009-04-22 2011-10-04 Visa U.S.A. Inc. Auctioning of announcements
US9235831B2 (en) 2009-04-22 2016-01-12 Gofigure Payments, Llc Mobile payment systems and methods
US20100274625A1 (en) * 2009-04-22 2010-10-28 Mark Carlson Targeting merchant announcements triggered by consumer activity relative to a surrogate merchant
US8706626B2 (en) 2009-05-26 2014-04-22 Bradley Wilkes Systems and methods for provisionally transferring an electronic currency
US8306910B2 (en) 2009-05-26 2012-11-06 Capital Will LLC Systems and methods for electronically circulating a currency
US8630951B2 (en) * 2009-05-26 2014-01-14 Capitalwill Llc Systems and methods for electronically circulating a currency
US9721261B2 (en) 2009-05-26 2017-08-01 CapitalWill, LLC Systems and methods for electronically circulating a conditional electronic currency
US9721235B2 (en) 2009-05-26 2017-08-01 Capitalwill Llc Systems and methods for electronically circulating a currency
US8645303B2 (en) * 2009-06-01 2014-02-04 Advance Response, LLC. Methods and systems for creating, accessing, and communicating content
KR20100130712A (ko) * 2009-06-04 2010-12-14 에스케이 텔레콤주식회사 전자화폐 송금 시스템 및 전자화폐 송금 방법
US9595028B2 (en) 2009-06-08 2017-03-14 Boku, Inc. Systems and methods to add funds to an account via a mobile communication device
CN101576989A (zh) * 2009-06-09 2009-11-11 阿里巴巴集团控股有限公司 移动终端中实现支付的方法及移动设备
US8612352B2 (en) 2010-10-13 2013-12-17 Square, Inc. Decoding systems with a decoding engine running on a mobile device and coupled to a payment system that includes identifying information of second parties qualified to conduct business with the payment system
US8701997B2 (en) 2010-10-13 2014-04-22 Square, Inc. Decoding systems with a decoding engine running on a mobile device and using financial transaction card information to create a send funds application on the mobile device
US9436955B2 (en) 2009-06-10 2016-09-06 Square, Inc. Methods for transferring funds using a payment service where financial account information is only entered once with a payment service and need not be re-entered for future transfers
US20120095911A1 (en) * 2009-06-16 2012-04-19 Smart Hub Pte. Ltd. Transaction system and method
US8271362B2 (en) * 2009-06-22 2012-09-18 Mastercard International, Inc. Methods and apparatus for providing centralized web services for funds transfer system
US9697510B2 (en) 2009-07-23 2017-07-04 Boku, Inc. Systems and methods to facilitate retail transactions
US8542921B1 (en) 2009-07-27 2013-09-24 United Services Automobile Association (Usaa) Systems and methods for remote deposit of negotiable instrument using brightness correction
US9474137B1 (en) * 2009-08-03 2016-10-18 Michael Wein Substrate with lighting effect
US9519892B2 (en) 2009-08-04 2016-12-13 Boku, Inc. Systems and methods to accelerate transactions
US9779392B1 (en) 2009-08-19 2017-10-03 United Services Automobile Association (Usaa) Apparatuses, methods and systems for a publishing and subscribing platform of depositing negotiable instruments
US9996825B1 (en) * 2009-08-20 2018-06-12 Apple Inc. Electronic device enabled payments
US8977571B1 (en) 2009-08-21 2015-03-10 United Services Automobile Association (Usaa) Systems and methods for image monitoring of check during mobile deposit
US9262754B1 (en) 2009-08-21 2016-02-16 Wells Fargo Bank, N.A. Request tracking system and method
US8699779B1 (en) 2009-08-28 2014-04-15 United Services Automobile Association (Usaa) Systems and methods for alignment of check during mobile deposit
WO2011032263A1 (en) * 2009-09-17 2011-03-24 Meir Weis Mobile payment system with two-point authentication
US8660911B2 (en) 2009-09-23 2014-02-25 Boku, Inc. Systems and methods to facilitate online transactions
US8224709B2 (en) 2009-10-01 2012-07-17 Boku, Inc. Systems and methods for pre-defined purchases on a mobile communication device
KR101590340B1 (ko) * 2009-10-09 2016-02-01 삼성전자주식회사 터치 스크린을 구비한 이동통신 단말기의 메시지 송수신 장치 및 방법
CN102598046A (zh) 2009-10-13 2012-07-18 平方股份有限公司 通过小型化读卡器进行金融交易的系统和方法
US8602875B2 (en) 2009-10-17 2013-12-10 Nguyen Gaming Llc Preserving game state data for asynchronous persistent group bonus games
MX2012004585A (es) * 2009-10-19 2012-09-28 Faber Financial Llc Sistema y metodo para una estacion de pago movil.
US8864586B2 (en) 2009-11-12 2014-10-21 Nguyen Gaming Llc Gaming systems including viral gaming events
US20210005047A1 (en) 2009-11-12 2021-01-07 Nguyen Gaming Llc Gaming system supporting data distribution to gaming devices
US9626826B2 (en) 2010-06-10 2017-04-18 Nguyen Gaming Llc Location-based real-time casino data
US8597108B2 (en) 2009-11-16 2013-12-03 Nguyen Gaming Llc Asynchronous persistent group bonus game
US8483448B2 (en) 2009-11-17 2013-07-09 Scanable, Inc. Electronic sales method
WO2011063177A1 (en) * 2009-11-20 2011-05-26 Mobisave Corporation System and method of electronically verifying required proof-of-performance to secure promotional rewards
CN102081769A (zh) * 2009-11-27 2011-06-01 阿里巴巴集团控股有限公司 支付数据处理方法、系统、支付终端及支付服务器
US20110137789A1 (en) * 2009-12-03 2011-06-09 Venmo Inc. Trust Based Transaction System
US8412626B2 (en) 2009-12-10 2013-04-02 Boku, Inc. Systems and methods to secure transactions via mobile devices
US20110143710A1 (en) * 2009-12-16 2011-06-16 Boku, Inc. Systems and methods to facilitate electronic payments
US10255591B2 (en) 2009-12-18 2019-04-09 Visa International Service Association Payment channel returning limited use proxy dynamic value
US8566188B2 (en) 2010-01-13 2013-10-22 Boku, Inc. Systems and methods to route messages to facilitate online transactions
GR1007336B (el) * 2010-01-19 2011-07-05 Καφετζης, Νικολαος Γεωργιου Μεθοδος-πρωτοκολλο διενεργειας τηλε-ηλεκτρονικων συναλλαγων
EP2355033A1 (en) * 2010-01-22 2011-08-10 Rajesh Shakkarwar Systems and methods for controlling payment processing
US10719876B2 (en) * 2010-01-22 2020-07-21 Verient, Inc. Systems and methods for controlling payment processing
US20110191177A1 (en) * 2010-01-29 2011-08-04 Bank Of America Corporation Pre-population of merchant check-out entry fields
US20110191150A1 (en) * 2010-01-29 2011-08-04 Bank Of America Corporation Mobile integrated merchant offer program and customer shopping using product level information
US20110191238A1 (en) * 2010-01-29 2011-08-04 Bank Of America Corporation Variable merchant settlement options
US20110191149A1 (en) * 2010-01-29 2011-08-04 Bank Of America Corporation Customer-selected payment clearinghouse
US20110191184A1 (en) * 2010-01-29 2011-08-04 Bank Of America Corporation Mobile location integrated merchant offer program and customer shopping
US8442894B2 (en) * 2010-01-29 2013-05-14 Bank Of America Corporation Guaranteed merchant payment in a card-not-present transaction
US8930265B2 (en) 2010-01-29 2015-01-06 Bank Of America Corporation Monitoring retail transactions associated with a financial institution-based merchant offer program and determining savings metrics
US20110191173A1 (en) * 2010-01-29 2011-08-04 Bank Of America Corporation Offer determination and settlement for integrated merchant offer program and customer shopping
US20110191180A1 (en) * 2010-01-29 2011-08-04 Bank Of America Corporation Search analyzer system for integrated merchant offer program and customer shopping
US20110191157A1 (en) * 2010-01-29 2011-08-04 Bank Of America Corporation Integrated merchant offer program and customer shopping
US20110191181A1 (en) * 2010-01-29 2011-08-04 Bank Of America Corporation Wish list for integrated merchant offer program and customer shopping
US20110191161A1 (en) * 2010-02-02 2011-08-04 Xia Dai Secured Mobile Transaction Device
US20110196790A1 (en) 2010-02-05 2011-08-11 Milne Benjamin P Transaction processing system
US20110196787A1 (en) * 2010-02-09 2011-08-11 Idt Corporation System And Method Of Transferring Money To An Electronic Wallet
US20110213671A1 (en) * 2010-02-26 2011-09-01 Boku, Inc. Systems and Methods to Process Payments
US8463705B2 (en) 2010-02-28 2013-06-11 International Business Machines Corporation Systems and methods for transactions on the telecom web
US20110217994A1 (en) * 2010-03-03 2011-09-08 Boku, Inc. Systems and Methods to Automate Transactions via Mobile Devices
TWI502524B (zh) * 2010-03-05 2015-10-01 Alibaba Group Holding Ltd Payment data processing method, system, payment terminal and payment server
BR112012022785A2 (pt) * 2010-03-08 2016-06-14 Telefonica Sa método e sistema para realizar uma transação
TWI567664B (zh) * 2010-03-08 2017-01-21 阿里巴巴集團控股有限公司 移動式終端中實現支付的方法及移動式設備
US8219542B2 (en) 2010-03-25 2012-07-10 Boku, Inc. Systems and methods to provide access control via mobile phones
US8583504B2 (en) 2010-03-29 2013-11-12 Boku, Inc. Systems and methods to provide offers on mobile devices
US20110238483A1 (en) * 2010-03-29 2011-09-29 Boku, Inc. Systems and Methods to Distribute and Redeem Offers
US10304051B2 (en) 2010-04-09 2019-05-28 Paypal, Inc. NFC mobile wallet processing systems and methods
US10134031B2 (en) 2010-04-09 2018-11-20 Paypal, Inc. Transaction token issuing authorities
US11887105B2 (en) 2010-04-09 2024-01-30 Paypal, Inc. Transaction token issuing authorities
US8696470B2 (en) 2010-04-09 2014-04-15 Nguyen Gaming Llc Spontaneous player preferences
US10445723B2 (en) * 2010-04-09 2019-10-15 Paypal, Inc. NFC-transaction processing systems and methods
US20110264583A1 (en) * 2010-04-22 2011-10-27 David Cooper Inter-network invoicing payment method and system
US8355987B2 (en) 2010-05-06 2013-01-15 Boku, Inc. Systems and methods to manage information
US9129340B1 (en) 2010-06-08 2015-09-08 United Services Automobile Association (Usaa) Apparatuses, methods and systems for remote deposit capture with enhanced image detection
WO2011158124A2 (en) * 2010-06-14 2011-12-22 Ape Payment Oy Online time based post payment system
WO2011156884A1 (en) * 2010-06-17 2011-12-22 Consumer Mt Inc. Electronic payment system and method
WO2011163525A1 (en) * 2010-06-23 2011-12-29 Obopay, Inc. Mobile networked payment system
WO2012021716A2 (en) 2010-08-11 2012-02-16 Boku, Inc. Systems and methods to identify carrier information for transmission of premium messages
CN102376133A (zh) * 2010-08-17 2012-03-14 中华票服网路股份有限公司 无纸化电子发票系统
US8068011B1 (en) 2010-08-27 2011-11-29 Q Street, LLC System and method for interactive user-directed interfacing between handheld devices and RFID media
US11012480B2 (en) 2010-09-13 2021-05-18 Jeffrey W. Mankoff Modifying signal associations in complex computing networks
US8504433B2 (en) * 2010-09-21 2013-08-06 Ebay Inc. Transaction split fees
US9805348B2 (en) 2010-09-22 2017-10-31 Mastercard International Incorporated Methods and systems for initiating a financial transaction by a cardholder device
US20120084205A1 (en) * 2010-10-01 2012-04-05 Sanjeev Dheer Disconnected person-to-person payment system and method including independent payor and payee direction for value source and destination
CA2812611C (en) * 2010-10-13 2016-06-14 Square, Inc. Payment methods with a payment service and tabs selected by a first party and opened by a second party at any geographic location of the first party's mobile device
US8602305B2 (en) 2010-10-13 2013-12-10 Square, Inc. Decoding systems with a decoding engine running on a mobile device configured to be coupled and decoupled to a card reader with wake-up electronics
US10121133B2 (en) 2010-10-13 2018-11-06 Walmart Apollo, Llc Method for self-checkout with a mobile device
US8571989B2 (en) 2010-10-13 2013-10-29 Square, Inc. Decoding systems with a decoding engine running on a mobile device and coupled to a social network
US9454866B2 (en) 2010-10-13 2016-09-27 Square, Inc. Method of conducting financial transactions where a payer's financial account information is entered only once with a payment system
US8640953B2 (en) 2010-10-13 2014-02-04 Square, Inc. Decoding system running on a mobile device and coupled to a payment system that includes at least one of, a user database, a product database and a transaction database
US8701996B2 (en) 2010-10-13 2014-04-22 Square, Inc. Cost effective card reader and methods to be configured to be coupled to a mobile device
US8573489B2 (en) 2010-10-13 2013-11-05 Square, Inc. Decoding systems with a decoding engine running on a mobile device with a touch screen
US8678277B2 (en) 2010-10-13 2014-03-25 Square, Inc. Decoding system coupled to a payment system that includes a cryptographic key
US9619797B2 (en) 2010-10-13 2017-04-11 Square, Inc. Payment methods with a payment service and tabs selected by a first party and opened by a second party at an geographic location of the first party's mobile device
US9852457B2 (en) 2010-10-15 2017-12-26 League Sports Services Llc Method and system to facilitate transactions between organization registrants and merchandise suppliers
US20120124496A1 (en) 2010-10-20 2012-05-17 Mark Rose Geographic volume analytics apparatuses, methods and systems
US10052551B2 (en) 2010-11-14 2018-08-21 Nguyen Gaming Llc Multi-functional peripheral device
US9486704B2 (en) 2010-11-14 2016-11-08 Nguyen Gaming Llc Social gaming
US9595161B2 (en) 2010-11-14 2017-03-14 Nguyen Gaming Llc Social gaming
US9235952B2 (en) 2010-11-14 2016-01-12 Nguyen Gaming Llc Peripheral management device for virtual game interaction
US20180053374A9 (en) 2010-11-14 2018-02-22 Binh T. Nguyen Multi-Functional Peripheral Device
US9564018B2 (en) 2010-11-14 2017-02-07 Nguyen Gaming Llc Temporary grant of real-time bonus feature
CN102467678B (zh) * 2010-11-16 2015-04-22 北京中电华大电子设计有限责任公司 一种具有双频通讯机制的射频sim卡
US10176477B2 (en) 2010-11-16 2019-01-08 Mastercard International Incorporated Methods and systems for universal payment account translation
US20120130889A1 (en) * 2010-11-19 2012-05-24 Mastercard International Incorporated Financial card method, device and system utilizing bar codes to identify transaction details
US20120143707A1 (en) * 2010-12-07 2012-06-07 Deepak Jain Executing Reader Application
US9292870B2 (en) * 2010-12-13 2016-03-22 Qualcomm Incorporated System and method for point of service payment acceptance via wireless communication
US20120150615A1 (en) * 2010-12-14 2012-06-14 Isaacson Thomas M System and method for an application programming interface for processing gifts
US8699994B2 (en) 2010-12-16 2014-04-15 Boku, Inc. Systems and methods to selectively authenticate via mobile communications
US8412155B2 (en) 2010-12-20 2013-04-02 Boku, Inc. Systems and methods to accelerate transactions based on predictions
US20120158528A1 (en) * 2010-12-21 2012-06-21 Ebay, Inc. Efficient transactions at a point of sale location
CN103282929B (zh) 2010-12-23 2020-04-10 贝宝公司 操作移动装置完成账户持有者的atm交易的方法及交易系统
CN102568124A (zh) * 2010-12-24 2012-07-11 汉斯·杰里·乌尔本·彼得森 一种在现有计费设备与移动支付系统间通信的方法
US8583496B2 (en) 2010-12-29 2013-11-12 Boku, Inc. Systems and methods to process payments via account identifiers and phone numbers
WO2012092125A1 (en) * 2010-12-29 2012-07-05 Boku, Inc. Pan charging to account established with an msisdn
US8700524B2 (en) 2011-01-04 2014-04-15 Boku, Inc. Systems and methods to restrict payment transactions
US9576159B1 (en) 2011-01-24 2017-02-21 Square, Inc. Multiple payment card reader system
US9792636B2 (en) 2011-01-25 2017-10-17 Dwolla, Inc. Social network transaction processing system
CA2824685A1 (en) * 2011-01-28 2012-08-02 Royal Canadian Mint/Monnaie Royale Canadienne Electronic transaction risk management
US10134087B1 (en) * 2011-02-16 2018-11-20 Amazon Technologies, Inc. Payment cards
US8688512B2 (en) 2011-02-17 2014-04-01 Boku, Inc. Offer insertion system
US9589256B1 (en) 2011-04-07 2017-03-07 Wells Fargo Bank, N.A. Smart chaining
US8690051B1 (en) * 2011-04-07 2014-04-08 Wells Fargo Bank, N.A. System and method for receiving ATM deposits
US9292840B1 (en) 2011-04-07 2016-03-22 Wells Fargo Bank, N.A. ATM customer messaging systems and methods
WO2012142131A2 (en) 2011-04-11 2012-10-18 Visa International Service Association Interoperable financial transactions via mobile devices
WO2012142315A2 (en) 2011-04-13 2012-10-18 Visa International Service Association Message routing using logically independent recipient identifiers
US8433657B2 (en) * 2011-04-15 2013-04-30 Ofinno Technologies, Llc Secure and mobile financial transaction
SK500202011A3 (sk) 2011-04-22 2013-05-03 Logomotion, S. R. O. Method of cashless transfer money from person to person through mobile phone
WO2012148842A1 (en) 2011-04-26 2012-11-01 Boku, Inc. Systems and methods to facilitate repeated purchases
US9830622B1 (en) 2011-04-28 2017-11-28 Boku, Inc. Systems and methods to process donations
US9191217B2 (en) 2011-04-28 2015-11-17 Boku, Inc. Systems and methods to process donations
EP2705479A4 (en) * 2011-05-03 2014-12-24 Panther Payments Llc METHOD AND SYSTEM FOR FACILITATING PERSON-TO-PERSON PAYMENTS
US10223674B2 (en) 2011-05-11 2019-03-05 Riavera Corp. Customized transaction flow for multiple transaction types using encoded image representation of transaction information
US9721243B2 (en) 2011-05-11 2017-08-01 Riavera Corp. Mobile payment system using subaccounts of account holder
US9715704B2 (en) 2011-05-11 2017-07-25 Riavera Corp Merchant ordering system using optical machine readable image representation of invoice information
US9547861B2 (en) 2011-05-11 2017-01-17 Mark Itwaru System and method for wireless communication with an IC chip for submission of pin data
US20120290415A1 (en) * 2011-05-11 2012-11-15 Riavera Corp. Mobile image payment system
US9785935B2 (en) 2011-05-11 2017-10-10 Riavera Corp. Split mobile payment system
US9734498B2 (en) * 2011-05-11 2017-08-15 Riavera Corp Mobile image payment system using short codes
CA2835733A1 (en) 2011-05-11 2012-11-15 Mark Itwaru Mobile image payment system using short codes
US8616453B2 (en) 2012-02-15 2013-12-31 Mark Itwaru System and method for processing funds transfer between entities based on received optical machine readable image information
US8346672B1 (en) 2012-04-10 2013-01-01 Accells Technologies (2009), Ltd. System and method for secure transaction process via mobile device
WO2012156977A1 (en) 2011-05-17 2012-11-22 Accells Technologies (2009), Ltd. System and method for performing a secure transaction
US9098850B2 (en) 2011-05-17 2015-08-04 Ping Identity Corporation System and method for transaction security responsive to a signed authentication
CN102810154B (zh) * 2011-06-02 2016-05-11 国民技术股份有限公司 一种基于可信模块的生物特征采集融合方法和系统
US8538845B2 (en) 2011-06-03 2013-09-17 Mozido, Llc Monetary transaction system
CA2875445A1 (en) * 2011-06-09 2012-12-13 Accells Technologies (2009), Ltd. A transaction system and method for use with a mobile device
US11049110B2 (en) * 2011-06-17 2021-06-29 Zelis Payments, Llc Healthcare transaction facilitation platform apparatuses, methods and systems
US20120323777A1 (en) * 2011-06-20 2012-12-20 Liberty Michael A Business to business mobile vault
CN102289895A (zh) * 2011-06-21 2011-12-21 上海北大方正科技电脑系统有限公司 一种网络票据处理终端及网络票据处理方法
CA2841267C (en) * 2011-07-11 2017-06-13 Square, Inc. Method of conducting financial transactions
US20130019195A1 (en) * 2011-07-12 2013-01-17 Oracle International Corporation Aggregating multiple information sources (dashboard4life)
US10438176B2 (en) 2011-07-17 2019-10-08 Visa International Service Association Multiple merchant payment processor platform apparatuses, methods and systems
US20130031009A1 (en) * 2011-07-28 2013-01-31 Apple Inc. Ad-hoc cash dispensing network
NZ594388A (en) 2011-08-03 2013-05-31 Serko Ltd Allocating expenses of a traveller's itinerary to cost centres within an Enterprise Resource Planning system
US8924287B1 (en) * 2011-08-18 2014-12-30 Sprint Communications Company L.P. System and methods for mobile electronic funds transfers
US10318941B2 (en) 2011-12-13 2019-06-11 Visa International Service Association Payment platform interface widget generation apparatuses, methods and systems
AU2012303620B2 (en) 2011-08-31 2017-09-14 Ping Identity Corporation System and method for secure transaction process via mobile device
US8862767B2 (en) 2011-09-02 2014-10-14 Ebay Inc. Secure elements broker (SEB) for application communication channel selector optimization
GB2494436A (en) * 2011-09-08 2013-03-13 Royal Bank Scotland Plc Wireless payment using blind identifier
FR2980017A1 (fr) * 2011-09-14 2013-03-15 Oberthur Technologies Systeme et procede de traitement d'une transaction financiere
US8555363B2 (en) 2011-09-16 2013-10-08 Google Inc. Authenticating a user of a system using near field communication
US8506378B2 (en) 2011-09-21 2013-08-13 Igt Gaming system, gaming device, and method providing advertising messages to players based on a determination of a positive winning gaming session
ITTO20110858A1 (it) * 2011-09-26 2013-03-27 Messagenet S P A Metodo e sistema per la gestione della comunicazione tra due utenti
US20130080333A1 (en) * 2011-09-27 2013-03-28 Oleksandr Kamotskyy Electronic wallet using allocation of funds
US20130232084A1 (en) * 2011-09-30 2013-09-05 Turkcell Teknoloji Arastirma Ve Gelistirme Anonim Sirketi Mobile Financial Transaction System and Method
AU2011378113A1 (en) * 2011-09-30 2014-04-17 BPAY Group Limited Payment requests
CN102402827B (zh) * 2011-09-30 2014-12-10 重庆南天数据资讯服务有限公司 应用于移动通信终端的pos刷卡支付装置
US10083247B2 (en) 2011-10-01 2018-09-25 Oracle International Corporation Generating state-driven role-based landing pages
US9672686B2 (en) 2011-10-03 2017-06-06 Nguyen Gaming Llc Electronic fund transfer for mobile gaming
US9630096B2 (en) 2011-10-03 2017-04-25 Nguyen Gaming Llc Control of mobile game play on a mobile vessel
EP2579199A1 (fr) * 2011-10-06 2013-04-10 Gemalto SA Procédé de paiement d'un produit ou d'un service sur un site marchand par l'intermédiaire d'une connexion Internet et terminal correspondant
CN103065243A (zh) * 2011-10-19 2013-04-24 王晓辰 具有收、付双重功能的手机钱包
US8647203B2 (en) * 2011-11-04 2014-02-11 Target Brands, Inc. Transaction product with selectively illuminated buttons
US20130124416A1 (en) * 2011-11-11 2013-05-16 Bewo Technologies Pvt. Ltd Method and system for transferring funds over a voice call
US10438196B2 (en) 2011-11-21 2019-10-08 Mozido, Inc. Using a mobile wallet infrastructure to support multiple mobile wallet providers
US9208488B2 (en) 2011-11-21 2015-12-08 Mozido, Inc. Using a mobile wallet infrastructure to support multiple mobile wallet providers
US9378514B2 (en) 2011-11-23 2016-06-28 Richard Tabor Secure tokenless transaction system and method
GB2497077A (en) * 2011-11-23 2013-06-05 Barclays Bank Plc Peer-to-peer payment registration and activation
CN103136245A (zh) * 2011-11-29 2013-06-05 深圳市腾讯计算机系统有限公司 一种虚拟货币余额旁路查询方法及系统
US20130144738A1 (en) * 2011-12-01 2013-06-06 Spenzi, Inc. Gifting and Sharing Using SMS Messages for Shared Coupon/Gift-Card Auto-Redemption and Multi-Source Payment from Buyer's Mobile Phone
US10096022B2 (en) * 2011-12-13 2018-10-09 Visa International Service Association Dynamic widget generator apparatuses, methods and systems
US9953378B2 (en) * 2012-04-27 2018-04-24 Visa International Service Association Social checkout widget generation and integration apparatuses, methods and systems
US9111301B2 (en) 2011-12-13 2015-08-18 Boku, Inc. Activating an account based on an SMS message
US10127540B2 (en) 2011-12-19 2018-11-13 Paypal, Inc. System and method for facilitating electronic financial transactions during a phone call
US20130159181A1 (en) * 2011-12-20 2013-06-20 Sybase 365, Inc. System and Method for Enhanced Mobile Wallet
US20140019339A1 (en) * 2011-12-21 2014-01-16 Hyperwallet Systems, Inc. Communication protocol for electronic funds transfer systems
JP5550630B2 (ja) * 2011-12-28 2014-07-16 楽天株式会社 電子マネーサーバ、電子マネー処理方法及び電子マネー処理プログラム
US10380565B1 (en) 2012-01-05 2019-08-13 United Services Automobile Association (Usaa) System and method for storefront bank deposits
US10146795B2 (en) 2012-01-12 2018-12-04 Kofax, Inc. Systems and methods for mobile image capture and processing
US8989515B2 (en) 2012-01-12 2015-03-24 Kofax, Inc. Systems and methods for mobile image capture and processing
US20130212003A1 (en) * 2012-02-10 2013-08-15 Intuit Inc. Mobile money order
US8763896B2 (en) * 2012-02-23 2014-07-01 XRomb Inc. System and method of loading a transaction card and processing repayment on a mobile device
US9811827B2 (en) 2012-02-28 2017-11-07 Google Inc. System and method for providing transaction verification
WO2013130716A1 (en) * 2012-02-29 2013-09-06 Patel Upen System and method to manage information for conducting secure transactions
US9373112B1 (en) 2012-03-16 2016-06-21 Square, Inc. Ranking of merchants for cardless payment transactions
US20130275296A1 (en) * 2012-03-16 2013-10-17 esdatanetworks INC Proximal Customer Transaction Incented By Donation of Auto-Boarded Merchant
CA2865936A1 (en) * 2012-03-19 2013-09-26 Royal Canadian Mint/Monnaie Royale Canadienne Using bar-codes in an asset storage and transfer system
US20130246296A1 (en) 2012-03-19 2013-09-19 @Pay LLC Method for processing multimodal mobile donations via text message and email communication
WO2013140196A1 (en) * 2012-03-23 2013-09-26 Jetchev Dimitar A system for electronic payments with privacy enhancement via trusted third parties
US20160132859A1 (en) * 2012-03-30 2016-05-12 Google Inc. Initiating peer-to-peer transactions with a magnetic strip card
US20140019341A1 (en) * 2012-04-10 2014-01-16 Kabbage, Inc. Method, apparatus and computer readable storage to effectuate an instantaneous monetary transfer
US20130268435A1 (en) * 2012-04-10 2013-10-10 Ebay Inc. Friendly funding source messaging
US8924292B1 (en) 2012-04-25 2014-12-30 Wells Fargo Bank, N.A. System and method for a mobile wallet
US20130297485A1 (en) * 2012-05-01 2013-11-07 Mastercard International Incorporated Crowd-Sourced Credit Rating and Debt Tracking System to Facilitate Small Purchases on Trust Based Credit
US8949974B2 (en) * 2012-05-11 2015-02-03 Tyfone, Inc. Mobile device with password protected desktop screen
US9014662B1 (en) 2012-06-25 2015-04-21 Sprint Communications Company L.P. Pre-paid phone cash wallet
US20140006276A1 (en) * 2012-06-28 2014-01-02 Bank Of America Corporation Mobile wallet account number differentiation
US9619790B2 (en) 2012-07-02 2017-04-11 Moneygram International, Inc. Systems and methods for emergency money transfer transactions
US10255632B2 (en) 2012-07-02 2019-04-09 Kabbage, Inc. Method and apparatus to evaluate and provide funds in online environments
US9325203B2 (en) 2012-07-24 2016-04-26 Binh Nguyen Optimized power consumption in a gaming device
CN102855558A (zh) * 2012-07-26 2013-01-02 深圳一卡通新技术有限公司 一种实现银行卡与手机号关联的方法
US9704184B2 (en) 2012-07-27 2017-07-11 @Pay Ip Holdings Llc Email payment gateway for donations
US10853836B2 (en) * 2012-08-13 2020-12-01 Groupon, Inc. Unified payment and return on investment system
EP2698755A1 (en) * 2012-08-17 2014-02-19 redpixtec. GmbH Mobile Payment System
WO2014031887A1 (en) * 2012-08-23 2014-02-27 Gcs Investments, Ltd. Distributor business to retailer business payment system and method using mobile phones
USD770478S1 (en) 2012-09-07 2016-11-01 Bank Of America Corporation Communication device with graphical user interface
KR20140033672A (ko) * 2012-09-10 2014-03-19 삼성전자주식회사 이벤트에 관련된 정보를 전송하는 방법 및 디바이스
US9619806B2 (en) * 2012-09-14 2017-04-11 Bank Of America Corporation Peer-to-peer transfer of funds for a specified use
CN103679528A (zh) * 2012-09-26 2014-03-26 中国银联股份有限公司 给予持卡用户脱卡账号的方法及系统
US8626659B1 (en) 2012-09-28 2014-01-07 Fiserv, Inc. Facilitating presentation of content relating to a financial transaction
US10176666B2 (en) 2012-10-01 2019-01-08 Nguyen Gaming Llc Viral benefit distribution using mobile devices
US9082119B2 (en) 2012-10-17 2015-07-14 Royal Bank of Canada. Virtualization and secure processing of data
US11210648B2 (en) 2012-10-17 2021-12-28 Royal Bank Of Canada Systems, methods, and devices for secure generation and processing of data sets representing pre-funded payments
US11080701B2 (en) 2015-07-02 2021-08-03 Royal Bank Of Canada Secure processing of electronic payments
US11449854B1 (en) 2012-10-29 2022-09-20 Block, Inc. Establishing consent for cardless transactions using short-range transmission
SE536684C2 (sv) * 2012-11-16 2014-05-20 Mobile Payment Solutions Holding Nordic Ab Förfarande för att köpa en produkt med hjälp av en bärbar kommunikationsenhet
SE536683C2 (sv) * 2012-11-16 2014-05-20 Mobile Payment Solutions Holding Nordic Ab Förfarande för att utföra en betalning med hjälp av en bärbar kommunikationsenhet
EP2736005A1 (en) * 2012-11-21 2014-05-28 Zakir Ibadullah oglu Mahalov Electronic payment system
SE536803C2 (sv) * 2012-12-06 2014-09-02 Mobile Payment Solutions Holding Nordic Ab Förfarande för att köpa eller begära ut en produkt med hjälpav en bärbar kommunikationsenhet
US10552810B1 (en) 2012-12-19 2020-02-04 United Services Automobile Association (Usaa) System and method for remote deposit of financial instruments
US20140188728A1 (en) 2012-12-31 2014-07-03 Fiserv, Inc. Systems and methods for performing financial transactions
US10789594B2 (en) 2013-01-31 2020-09-29 Moshir Vantures, Limited, LLC Method and system to intelligently assess and mitigate security risks on a mobile device
US20140222671A1 (en) * 2013-02-07 2014-08-07 Aurelio Elias System and method for the execution of third party services transaction over financial networks through a virtual integrated automated teller machine on an electronic terminal device.
US9652791B1 (en) 2013-02-08 2017-05-16 Square, Inc. Updating merchant location for cardless payment transactions
US20160180317A1 (en) * 2013-03-11 2016-06-23 Google Inc. Offline peer-to-peer transactions
US9355312B2 (en) 2013-03-13 2016-05-31 Kofax, Inc. Systems and methods for classifying objects in digital images captured using mobile devices
US9208536B2 (en) 2013-09-27 2015-12-08 Kofax, Inc. Systems and methods for three dimensional geometric reconstruction of captured image data
US9704146B1 (en) 2013-03-14 2017-07-11 Square, Inc. Generating an online storefront
US9940616B1 (en) 2013-03-14 2018-04-10 Square, Inc. Verifying proximity during payment transactions
US9600976B2 (en) 2013-03-15 2017-03-21 Nguyen Gaming Llc Adaptive mobile device gaming system
US11030851B2 (en) 2013-03-15 2021-06-08 Nguyen Gaming Llc Method and system for localized mobile gaming
US9495679B2 (en) 2013-03-15 2016-11-15 @Pay Ip Holdings Llc Automated application programming interface (API) system and method
US20160260067A1 (en) * 2013-03-15 2016-09-08 Elwha Llc Devices, methods, and systems for managing one or more resources for one or more extrinsic client entities
US9814970B2 (en) 2013-03-15 2017-11-14 Nguyen Gaming Llc Authentication of mobile servers
US9536232B2 (en) 2013-03-15 2017-01-03 Square, Inc. Transferring money using email
US10607209B2 (en) * 2013-03-15 2020-03-31 TGALLISON Technologies, LLC System and method for transferring payments and documents with a web-based management system
US9449321B2 (en) 2013-03-15 2016-09-20 Square, Inc. Transferring money using email
US20140279429A1 (en) * 2013-03-15 2014-09-18 Elwha LLC, a limited liability company of the State of Delaware Devices, methods, and systems for accepting multiple nonuniform input channels
US10421010B2 (en) 2013-03-15 2019-09-24 Nguyen Gaming Llc Determination of advertisement based on player physiology
US20140279424A1 (en) * 2013-03-15 2014-09-18 Elwha Llc Devices, methods, and systems for technologically shifting options and modalities
US20140279423A1 (en) * 2013-03-15 2014-09-18 Elwha Llc Methods, systems, and devices for handling multiple disparate systems
US20140279458A1 (en) * 2013-03-15 2014-09-18 Elwha Llc Devices, methods, and systems for assisting multiple discrete devices
US9576425B2 (en) 2013-03-15 2017-02-21 Nguyen Gaming Llc Portable intermediary trusted device
US10102512B1 (en) * 2013-03-19 2018-10-16 Wilmington Savings Fund Society, Fsb Systems and methods for financial data transfer
US10311435B2 (en) * 2013-03-28 2019-06-04 Morphotrust Usa Llc System and method for transaction authentication
CA2909104A1 (en) * 2013-04-12 2014-10-16 Riavera Corp. Mobile payment system using subaccounts of account holder
US20140316841A1 (en) * 2013-04-23 2014-10-23 Kofax, Inc. Location-based workflows and services
ES2514941B1 (es) * 2013-04-26 2015-04-07 Mobile Dreams Consulting S.L.L. Pulsera de identificación personal
JP6055954B2 (ja) * 2013-04-28 2016-12-27 テンセント テクノロジー （シェンツェン） カンパニー リミテッド オブジェクト処理のためのシステム及び方法
CA2851895C (en) 2013-05-08 2023-09-26 The Toronto-Dominion Bank Person-to-person electronic payment processing
US9940608B2 (en) * 2013-05-16 2018-04-10 Mts Holdings, Inc. Real time EFT network-based person-to-person transactions
WO2014189750A1 (en) * 2013-05-20 2014-11-27 Ling Marvin T Conducting fund transfer between two entities and its application asa cell phone wallet
US10387874B1 (en) 2013-05-30 2019-08-20 Google Llc Mobile transactions with merchant identification codes
CN103620629B (zh) * 2013-05-31 2017-11-03 华为技术有限公司 转账信息处理方法及设备
US9481197B2 (en) 2013-06-05 2016-11-01 Morphotrust Usa, Llc System and method for credential authentication
CN103325037A (zh) * 2013-06-06 2013-09-25 上海讯联数据服务有限公司 一种基于语音识别的移动支付安全验证方法
US10229400B2 (en) 2013-06-07 2019-03-12 Swoop Ip Holdings Llc System and method for two-click validation
US20140372300A1 (en) * 2013-06-14 2014-12-18 Simon Blythe Smart card electronic wallet system
ITMI20131126A1 (it) * 2013-07-04 2015-01-05 Sempla Srl Metodo e sistema per la gestione di transazioni elettroniche
CN103440576A (zh) * 2013-07-18 2013-12-11 南京爱沓信息技术有限公司 一种移动直接支付系统
CN104301455B (zh) * 2013-07-19 2017-11-03 中国银联股份有限公司 安全性信息交互终端
US9924322B2 (en) 2013-07-23 2018-03-20 Square, Inc. Computing distances of devices
US9384497B2 (en) 2013-07-26 2016-07-05 Bank Of America Corporation Use of SKU level e-receipt data for future marketing
JP6122363B2 (ja) * 2013-08-25 2017-04-26 株式会社オプティム 決済端末、決済システム、決済方法、決済端末用プログラム
US11138578B1 (en) 2013-09-09 2021-10-05 United Services Automobile Association (Usaa) Systems and methods for remote deposit of currency
US9832646B2 (en) * 2013-09-13 2017-11-28 Network Kinetix, LLC System and method for an automated system for continuous observation, audit and control of user activities as they occur within a mobile network
US10515368B1 (en) 2013-10-01 2019-12-24 Wells Fargo Bank, N.A. Interbank account verification and funds transfer system and method
US9165291B1 (en) 2013-10-15 2015-10-20 Square, Inc. Payment transaction by email
US9727866B2 (en) 2013-10-15 2017-08-08 Intuit Inc. Methods systems and computer program products for verifying consumer identity during transaction
US9286514B1 (en) 2013-10-17 2016-03-15 United Services Automobile Association (Usaa) Character count determination for a digital image
US10417635B1 (en) 2013-10-22 2019-09-17 Square, Inc. Authorizing a purchase transaction using a mobile device
US8892462B1 (en) 2013-10-22 2014-11-18 Square, Inc. Proxy card payment with digital receipt delivery
US9836739B1 (en) 2013-10-22 2017-12-05 Square, Inc. Changing a financial account after initiating a payment using a proxy card
US9922321B2 (en) 2013-10-22 2018-03-20 Square, Inc. Proxy for multiple payment mechanisms
US9317745B2 (en) 2013-10-29 2016-04-19 Bank Of America Corporation Data lifting for exception processing
US9412135B2 (en) 2013-10-29 2016-08-09 Bank Of America Corporation Check data lift for online accounts
US9384393B2 (en) 2013-10-29 2016-07-05 Bank Of America Corporation Check data lift for error detection
US10832278B2 (en) 2013-11-04 2020-11-10 Mastercard International Incorporated System and method for card-linked services
US9589276B2 (en) * 2013-11-04 2017-03-07 Mastercard International Incorporated System and method for card-linked services
US9754275B2 (en) * 2013-11-04 2017-09-05 Mastercard International Incorporated System and method for card-linked services
US9760908B2 (en) * 2013-11-04 2017-09-12 Mastercard International Incorporated System and method for card-linked services
US10217092B1 (en) 2013-11-08 2019-02-26 Square, Inc. Interactive digital platform
US10489754B2 (en) 2013-11-11 2019-11-26 Visa International Service Association Systems and methods to facilitate the redemption of offer benefits in a form of third party statement credits
US20150134507A1 (en) * 2013-11-12 2015-05-14 Bank Of America Corporation Electronic documents for person to person payment
US10163148B1 (en) 2013-11-13 2018-12-25 Square, Inc. Wireless beacon shopping experience
JP2016538783A (ja) 2013-11-15 2016-12-08 コファックス， インコーポレイテッド モバイル映像データを用いて長尺文書の合成画像を生成するためのシステムおよび方法
US8910868B1 (en) 2013-11-27 2014-12-16 Square, Inc. Firmware management
US9633236B1 (en) 2013-12-11 2017-04-25 Square, Inc. Power harvesting in reader devices
US8931699B1 (en) 2013-12-11 2015-01-13 Square, Inc. Bidirectional audio communication in reader devices
US11205163B2 (en) 2013-12-18 2021-12-21 PayRange Inc. Systems and methods for determining electric pulses to provide to an unattended machine based on remotely-configured options
US11481781B2 (en) 2013-12-18 2022-10-25 PayRange Inc. Processing interrupted transaction over non-persistent network connections
US20150170133A1 (en) * 2013-12-18 2015-06-18 Mozido, Inc. System, apparatus and method for proximity recognition and transfer
US8856045B1 (en) 2013-12-18 2014-10-07 PayRange Inc. Mobile-device-to-machine payment systems
US11966895B2 (en) 2013-12-18 2024-04-23 PayRange Inc. Refund centers for processing and dispensing vending machine refunds via an MDB router
US10019724B2 (en) 2015-01-30 2018-07-10 PayRange Inc. Method and system for providing offers for automated retail machines via mobile devices
US20180240096A1 (en) * 2017-02-16 2018-08-23 PayRange Inc. Mobile payment module with dual function radio transmitter
US9875473B2 (en) 2013-12-18 2018-01-23 PayRange Inc. Method and system for retrofitting an offline-payment operated machine to accept electronic payments
US11966926B2 (en) 2013-12-18 2024-04-23 PayRange Inc. Method and system for asynchronous mobile payments for multiple in-person transactions conducted in parallel
US11481780B2 (en) 2013-12-18 2022-10-25 PayRange Inc. Method and system for asynchronous mobile payments for multiple in-person transactions conducted in parallel
US9659296B2 (en) 2013-12-18 2017-05-23 PayRange Inc. Method and system for presenting representations of payment accepting unit events
US11074580B2 (en) 2013-12-18 2021-07-27 PayRange Inc. Device and method for providing external access to multi-drop bus peripheral devices
US11475454B2 (en) 2013-12-18 2022-10-18 PayRange Inc. Intermediary communications over non-persistent network connections
US10127528B2 (en) * 2013-12-20 2018-11-13 Movocash, Inc. Financial services ecosystem
US20150178698A1 (en) 2013-12-23 2015-06-25 Egan Schulz Systems and methods for transportation check-in and payment using beacons
US10810682B2 (en) 2013-12-26 2020-10-20 Square, Inc. Automatic triggering of receipt delivery
US10621563B1 (en) * 2013-12-27 2020-04-14 Square, Inc. Apportioning a payment card transaction among multiple payers
US11068875B2 (en) 2013-12-30 2021-07-20 Apple, Inc. Person-to-person payments using electronic devices
CN104753907B (zh) * 2013-12-31 2017-03-29 腾讯科技（深圳）有限公司 基于即时通信或社交应用的数据处理方法和装置
WO2015112870A1 (en) 2014-01-25 2015-07-30 Cloudpin Inc. Systems and methods for location-based content sharing using unique identifiers
US9830651B1 (en) 2014-01-29 2017-11-28 Square, Inc. Crowdfunding framework
US10198731B1 (en) 2014-02-18 2019-02-05 Square, Inc. Performing actions based on the location of mobile device during a card swipe
US9256769B1 (en) 2014-02-25 2016-02-09 Square, Inc. Mobile reader device
US9224141B1 (en) 2014-03-05 2015-12-29 Square, Inc. Encoding a magnetic stripe of a card with data of multiple cards
US10482449B1 (en) 2014-03-10 2019-11-19 Jpmorgan Chase Bank, N.A. Person to person payment system and method
US10692059B1 (en) 2014-03-13 2020-06-23 Square, Inc. Selecting a financial account associated with a proxy object based on fund availability
US9619792B1 (en) 2014-03-25 2017-04-11 Square, Inc. Associating an account with a card based on a photo
US9864986B1 (en) 2014-03-25 2018-01-09 Square, Inc. Associating a monetary value card with a payment object
US11429948B2 (en) * 2014-04-15 2022-08-30 Capital One Services, Llc System and method for inter-bank and intra-bank mobile banking communications and transfers
CN103956177B (zh) * 2014-04-17 2016-05-04 长春理工大学 基于物联网的板级可扩充点播系统
USD769274S1 (en) 2014-04-21 2016-10-18 Square, Inc. Display screen with a graphical user interface
US10346846B2 (en) 2014-04-24 2019-07-09 Swoop Ip Holdings Llc SMS and social media dual authorization, management oversight, and non-password security in email based e-commerce
CN104851188B (zh) * 2014-04-29 2017-10-13 黄云 一种实时在线自助充值的智能卡充值系统及充值方法
US9569767B1 (en) 2014-05-06 2017-02-14 Square, Inc. Fraud protection based on presence indication
US10242351B1 (en) * 2014-05-07 2019-03-26 Square, Inc. Digital wallet for groups
US9959529B1 (en) 2014-05-11 2018-05-01 Square, Inc. Open tab transactions
US20150332223A1 (en) 2014-05-19 2015-11-19 Square, Inc. Transaction information collection for mobile payment experience
US10304043B1 (en) 2014-05-21 2019-05-28 Square, Inc. Multi-peripheral host device
US10445826B1 (en) 2014-05-26 2019-10-15 Square, Inc. Merchant financing system
US9727912B1 (en) * 2014-05-26 2017-08-08 Square, Inc. Approaches for merchant financing
US9786005B1 (en) 2014-05-26 2017-10-10 Square, Inc. System and methods for financing merchant business needs
US9984412B1 (en) * 2014-05-26 2018-05-29 Square, Inc. Approaches to location based merchant financing
US9836743B2 (en) 2014-06-04 2017-12-05 Visa International Service Association Systems and methods to register merchants for data processing in an electronic transaction system
US10614445B1 (en) * 2014-06-04 2020-04-07 Square, Inc. Proximity-based payments
US20150356547A1 (en) * 2014-06-05 2015-12-10 Lutfi Abed System and method for providing tipping and review services via a mobile device
USD762651S1 (en) 2014-06-06 2016-08-02 Square, Inc. Mobile device case
US10043174B1 (en) * 2014-06-13 2018-08-07 Intuit Inc. Bitcoin transaction using text message
US20150363776A1 (en) * 2014-06-17 2015-12-17 Securesit System and Method for Managing a Payment Transaction
US10783515B2 (en) * 2014-06-19 2020-09-22 IroFit Technologies Oy Method and system for conducting wireless electronic credit card transactions
US9760740B1 (en) 2014-06-23 2017-09-12 Square, Inc. Terminal case with integrated dual reader stack
US20160005035A1 (en) * 2014-07-02 2016-01-07 Mistral Mobile Secure financial transaction using plain text sms
US9256770B1 (en) 2014-07-02 2016-02-09 Square, Inc. Terminal case with integrated reader and shortened base
US20160005023A1 (en) * 2014-07-07 2016-01-07 Google Inc. Conducting financial transactions by telephone
FR3023640B1 (fr) * 2014-07-10 2016-08-12 Roam Data Inc Procede de gestion d'une transaction, serveur, produit programme d'ordinateur et medium de stockage correspondants.
US11507931B1 (en) 2014-07-31 2022-11-22 Block, Inc. Payout payment platform
US9799025B2 (en) 2014-08-19 2017-10-24 Square, Inc. Energy harvesting bidirectional audio interface
US10692156B2 (en) * 2014-09-05 2020-06-23 Thomas Skala Payment system and method
US10963868B1 (en) 2014-09-09 2021-03-30 Square, Inc. Anonymous payment transactions
CN104199958A (zh) * 2014-09-18 2014-12-10 浪潮软件集团有限公司 一种智能数据分析比对推送方法
AU2015330644A1 (en) * 2014-10-10 2017-04-20 Royal Bank Of Canada Systems for processing electronic transactions
US10565642B1 (en) 2014-10-23 2020-02-18 Square, Inc. Inventory management with capital advance
US11295308B1 (en) 2014-10-29 2022-04-05 The Clearing House Payments Company, L.L.C. Secure payment processing
US9760788B2 (en) 2014-10-30 2017-09-12 Kofax, Inc. Mobile document detection and orientation based on reference object characteristics
US20160125370A1 (en) 2014-10-31 2016-05-05 Square, Inc. Money transfer by use of a syntax
US9836786B1 (en) 2014-11-13 2017-12-05 Square, Inc. Intelligent division of funds across merchant accounts
CN104376455A (zh) * 2014-12-04 2015-02-25 苏州海博智能系统有限公司 一种银行卡转账支付的方法
US11068884B2 (en) 2014-12-04 2021-07-20 Hierstar (Suzhou)., Ltd. E-wallet transfer payment method and system based on PKI smart card
CN105721404B (zh) * 2014-12-04 2019-01-29 阿里巴巴集团控股有限公司 基于计算机系统的业务处理方法及其装置
US9990613B1 (en) * 2014-12-12 2018-06-05 Square, Inc. Bill payment using direct funds transfer
GB2533340A (en) 2014-12-17 2016-06-22 Ibm Network system and method for transferring cryptocurrencies between a user account and a receiving account
US10062072B2 (en) * 2014-12-19 2018-08-28 Facebook, Inc. Facilitating sending and receiving of peer-to-business payments
US11699148B2 (en) 2014-12-23 2023-07-11 Swoop Ip Holdings Llc Email address token integration
US9787856B2 (en) * 2014-12-29 2017-10-10 Tracfone Wireless, Inc. Hybrid network based metering server for a shared service and tracking client for wireless services
US10185946B2 (en) 2014-12-31 2019-01-22 Fiserv, Inc. Facilitating presentation of content relating to a financial transaction
US20160203469A1 (en) * 2015-01-09 2016-07-14 Mohamed Yaya Cisse System and method of facilitating monetary transactions
US11354651B2 (en) 2015-01-19 2022-06-07 Royal Bank Of Canada System and method for location-based token transaction processing
CA2974151C (en) 2015-01-19 2023-11-21 Royal Bank Of Canada Secure processing of electronic payments
US10902512B1 (en) 2015-01-22 2021-01-26 Square, Inc. Third party merchant financing
US11551198B2 (en) 2015-01-28 2023-01-10 Swoop Ip Holdings Llc Email-based e-commerce with near field communication
US10164932B2 (en) 2015-01-30 2018-12-25 Loturas Incorporated Communication system and server facilitating message exchange and related methods
US9824394B1 (en) 2015-02-06 2017-11-21 Square, Inc. Payment processor financing of customer purchases
US11216468B2 (en) 2015-02-08 2022-01-04 Visa International Service Association Converged merchant processing apparatuses, methods and systems
US9355285B1 (en) 2015-02-12 2016-05-31 Square, Inc. Tone-based wake up circuit for card reader
US9825959B2 (en) * 2015-02-13 2017-11-21 Ebay Inc. Portable electronic device with user-configurable API data endpoint
US10019698B1 (en) 2015-02-13 2018-07-10 Square, Inc. Merchant cash advance payment deferrals
US10664836B2 (en) * 2015-02-17 2020-05-26 Dave's Slingshot, LLC Payment system and method
US9769642B2 (en) * 2015-02-20 2017-09-19 Tracfone Wireless, Inc. Method and system for family plan sharing of wireless services
US9773242B1 (en) * 2015-03-19 2017-09-26 Square, Inc. Mobile point-of-sale crowdfunding
US11636462B2 (en) 2015-03-20 2023-04-25 Block, Inc. Context-aware peer-to-peer transfers of items
US11429975B1 (en) 2015-03-27 2022-08-30 Wells Fargo Bank, N.A. Token management system
US9892458B1 (en) 2015-03-31 2018-02-13 Square, Inc. Invoice financing and repayment
US9779432B1 (en) * 2015-03-31 2017-10-03 Square, Inc. Invoice financing and repayment
US10453086B1 (en) 2015-04-01 2019-10-22 Square, Inc. Individualized incentives to improve financing outcomes
US10163083B2 (en) 2015-04-13 2018-12-25 Bank Of America Corporation Account activity management system
CN104809611A (zh) * 2015-04-20 2015-07-29 王宏旭 一种基于云平台下物联网移动金融支付方法和系统
US9781105B2 (en) 2015-05-04 2017-10-03 Ping Identity Corporation Fallback identity authentication techniques
EP3091492A1 (en) * 2015-05-05 2016-11-09 Mastercard International Incorporated Systems, methods, devices, and computer readable media for enabling electronic payment transfers
US9436938B1 (en) 2015-05-13 2016-09-06 Square, Inc. Transaction payment processing by multiple data centers
US10402790B1 (en) 2015-05-28 2019-09-03 United Services Automobile Association (Usaa) Composing a focused document image from multiple image captures or portions of multiple image captures
US10026062B1 (en) 2015-06-04 2018-07-17 Square, Inc. Apparatuses, methods, and systems for generating interactive digital receipts
US10339517B2 (en) * 2015-06-26 2019-07-02 Mastercard International Incorporated System and methods for providing gratuity based on location
US10834027B2 (en) * 2015-06-27 2020-11-10 Mcafee, Llc Protection of sensitive chat data
US11042882B2 (en) 2015-07-01 2021-06-22 The Clearing House Payments Company, L.L.C. Real-time payment system, method, apparatus, and computer program
US11694168B2 (en) 2015-07-01 2023-07-04 The Clearing House Payments Company L.L.C. Real-time payment system, method, apparatus, and computer program
US10535067B2 (en) 2015-07-01 2020-01-14 Mastercard International Incorporated Electronic incremental payments
US10311413B2 (en) 2015-07-01 2019-06-04 Mastercard International Incorporated By-item bill payments
US10621567B2 (en) 2015-07-01 2020-04-14 Mastercard International Incorporation Electronic grace period billing
US11599879B2 (en) 2015-07-02 2023-03-07 Royal Bank Of Canada Processing of electronic transactions
US10387846B2 (en) 2015-07-10 2019-08-20 Bank Of America Corporation System for affecting appointment calendaring on a mobile device based on dependencies
US10387845B2 (en) 2015-07-10 2019-08-20 Bank Of America Corporation System for facilitating appointment calendaring based on perceived customer requirements
CN106357589B (zh) * 2015-07-13 2019-12-27 腾讯科技（深圳）有限公司 一种可支配对象处理方法及装置
US10242285B2 (en) 2015-07-20 2019-03-26 Kofax, Inc. Iterative recognition-guided thresholding and data extraction
US11170364B1 (en) 2015-07-31 2021-11-09 Wells Fargo Bank, N.A. Connected payment card systems and methods
SG10201506519SA (en) * 2015-08-18 2017-03-30 Mastercard International Inc Method and system for contactless financial transactions
US10127532B1 (en) 2015-08-19 2018-11-13 Square, Inc. Customized transaction flow
US10410194B1 (en) 2015-08-19 2019-09-10 Square, Inc. Customized tipping flow
US10817933B2 (en) * 2015-09-03 2020-10-27 Bank Of America Corporation Financial health smartwatch
US11170337B2 (en) * 2015-09-28 2021-11-09 Newstore Inc. Authenticated transfer of an article using verification tokens
US20170109540A1 (en) * 2015-10-16 2017-04-20 Bank Of America Corporation Tokenization of financial account information for use in transactions
SG10201509087QA (en) * 2015-11-04 2017-06-29 Mastercard International Inc Methods and systems for dispensing physical currency
CN105827685A (zh) * 2015-11-17 2016-08-03 广东亿迅科技有限公司 一种客户信息管理系统及方法
CN106845966B (zh) * 2015-12-04 2021-07-27 阿里巴巴集团控股有限公司 货款信息处理方法及装置
US11488124B2 (en) * 2015-12-07 2022-11-01 Money Flow, Llc Payment system based on a global database of invoices
WO2017099680A1 (en) * 2015-12-11 2017-06-15 Turkcell Teknoloji Arastirma Ve Gelistirme Anonim Sirketi An integrated mobile account credit transfer system
US20170169407A1 (en) 2015-12-14 2017-06-15 Mikko Vaananen Method and means for social network payments
US10853784B2 (en) 2016-01-04 2020-12-01 Bank Of America Corporation Real-time determination of resource availability for usage
US10068211B2 (en) 2016-01-04 2018-09-04 Bank Of America Corporation Reallocation of resources system
US10506641B2 (en) 2016-01-04 2019-12-10 Bank Of America Corporation Resource optimization allocation system
US10021672B2 (en) 2016-01-04 2018-07-10 Bank Of America Corporation Resource allocation based on available resources via interactive interface
US10535054B1 (en) 2016-01-12 2020-01-14 Square, Inc. Purchase financing via an interactive digital receipt
FR3046864B1 (fr) 2016-01-18 2018-11-16 Proton World International N.V. Controle d'applications dans un terminal mobile
KR20230133398A (ko) * 2016-01-25 2023-09-19 애플 인크. 비-네이티브 크리덴셜들과 함께 전자 디바이스들을 사용하는 거래들의 수행
US10628811B2 (en) 2016-03-15 2020-04-21 Square, Inc. System-based detection of card sharing and fraud
EP3779753A3 (en) * 2016-03-15 2021-05-12 Visa International Service Association Validation cryptogram for interaction
US10410200B2 (en) 2016-03-15 2019-09-10 Square, Inc. Cloud-based generation of receipts using transaction information
US9743272B1 (en) 2016-03-28 2017-08-22 Bank Of America Corporation Security implementation for resource distribution
US9507984B1 (en) 2016-03-28 2016-11-29 Bank Of America Corporation Resource tag generation and deployment for resource valuation and distribution
US10135817B2 (en) 2016-03-28 2018-11-20 Bank Of America Corporation Enhancing authentication and source of proof through a dynamically updatable biometrics database
US10080132B2 (en) 2016-03-28 2018-09-18 Bank Of America Corporation System for adaptation of multiple digital signatures in a distributed network
US10039113B2 (en) 2016-03-28 2018-07-31 Bank Of America Corporation Intelligent resource procurement system based on physical proximity to related resources
US10636019B1 (en) 2016-03-31 2020-04-28 Square, Inc. Interactive gratuity platform
SG10201602905QA (en) * 2016-04-13 2017-11-29 Mastercard Asia Pacific Pte Ltd Payment Approval Method And System
US10990935B1 (en) * 2016-04-28 2021-04-27 Wells Fargo Bank, N.A. Transferring funds between two parties
US10769630B2 (en) * 2016-05-11 2020-09-08 Mastercard International Incorporated Mobile person to person voice payment
JP6668934B2 (ja) * 2016-05-12 2020-03-18 株式会社リコー サービス提供システム、サービス提供装置、サービス提供方法、プログラム
US20170364898A1 (en) * 2016-06-15 2017-12-21 SocialPay LLC Mobile payment system and method
US10796253B2 (en) 2016-06-17 2020-10-06 Bank Of America Corporation System for resource use allocation and distribution
US10038607B2 (en) 2016-06-17 2018-07-31 Bank Of America Corporation System for aggregated machine-initiated resource distribution
US10103936B2 (en) 2016-06-21 2018-10-16 Bank Of America Corporation Computerized resource reallocation system for transferring resource blocks based on custodian event
US10334462B2 (en) 2016-06-23 2019-06-25 Bank Of America Corporation Predictive analytics for resource development based on information communicated from inter-related communication devices
US10992679B1 (en) 2016-07-01 2021-04-27 Wells Fargo Bank, N.A. Access control tower
US11386223B1 (en) 2016-07-01 2022-07-12 Wells Fargo Bank, N.A. Access control tower
US11935020B1 (en) 2016-07-01 2024-03-19 Wells Fargo Bank, N.A. Control tower for prospective transactions
US10439913B2 (en) 2016-07-01 2019-10-08 Bank Of America Corporation Dynamic replacement and upgrade of existing resources based on resource utilization
US11886611B1 (en) 2016-07-01 2024-01-30 Wells Fargo Bank, N.A. Control tower for virtual rewards currency
US11615402B1 (en) 2016-07-01 2023-03-28 Wells Fargo Bank, N.A. Access control tower
US10366389B2 (en) 2016-07-28 2019-07-30 Visa International Service Association Connected device transaction code system
EP3279847A1 (en) * 2016-08-04 2018-02-07 Mastercard International Incorporated Mobile push payments
EP3282675B1 (en) * 2016-08-11 2020-01-29 Nxp B.V. Network node and method for identifying a node in transmissions between neighbouring nodes of a network
US10916090B2 (en) 2016-08-23 2021-02-09 Igt System and method for transferring funds from a financial institution device to a cashless wagering account accessible via a mobile device
USD837227S1 (en) 2016-09-12 2019-01-01 Square, Inc. Display screen with graphical user interface for a mobile device
US20180075444A1 (en) * 2016-09-12 2018-03-15 Square, Inc. Processing a mobile payload
US10127400B2 (en) 2016-09-26 2018-11-13 Bank Of America Corporation Control device for aggregation and distribution of machine-initiated resource distribution
US10891617B2 (en) * 2016-09-30 2021-01-12 Mastercard International Incorporated Systems and methods for biometric identity authentication
US10636029B2 (en) 2016-11-14 2020-04-28 Bank Of America Corporation System for priority presentation integration on third party systems for limiting resource disbursement
SG10201609649RA (en) * 2016-11-17 2018-06-28 Mastercard International Inc Method and system for facilitating a cashless transaction
US10748154B2 (en) * 2016-12-23 2020-08-18 Early Warning Services, Llc System and method using multiple profiles and scores for assessing financial transaction risk
US10402807B1 (en) 2017-02-28 2019-09-03 Square, Inc. Estimating interchange fees for card payments
US10425313B2 (en) 2017-04-05 2019-09-24 International Business Machines Corporation Tuple traffic management
SG11201907191VA (en) * 2017-04-05 2019-09-27 Visa Int Service Ass System and method for electronic receipt services
US11556936B1 (en) 2017-04-25 2023-01-17 Wells Fargo Bank, N.A. System and method for card control
CN110663055A (zh) 2017-05-16 2020-01-07 苹果公司 促进用户帐户之间的资金转移
CN110945551A (zh) * 2017-05-30 2020-03-31 维萨国际服务协会 用于维护公共网络上的交易完整性的系统、方法和计算机程序产品
SG11201911608WA (en) * 2017-06-13 2020-01-30 Visa Int Service Ass Method, system, and computer program product for controlling transaction velocity limits
GB201709876D0 (en) * 2017-06-20 2017-08-02 Levy Jean Marc Funds transfer using a voice call
US11062388B1 (en) 2017-07-06 2021-07-13 Wells Fargo Bank, N.A Data control tower
US20190043037A1 (en) 2017-08-02 2019-02-07 Marco Andres Guirola Martin System and method for providing secured services
WO2019027488A1 (en) * 2017-08-02 2019-02-07 Wepay, Inc. SYSTEMS AND METHODS FOR INSTANT ACTIVATION OF A MERCHANT PROVIDING SECURE PAYMENT AT A POINT OF SALE
CN107516196A (zh) * 2017-09-04 2017-12-26 杭州哲信信息技术有限公司 一种移动支付系统及其移动支付方法
US11615421B2 (en) * 2017-09-12 2023-03-28 Mastercard International Incorporated Methods, system and computer program product for selectively responding to presentation of payment card information
US11386747B2 (en) 2017-10-23 2022-07-12 Aristocrat Technologies, Inc. (ATI) Gaming monetary instrument tracking system
US10297106B1 (en) 2017-10-31 2019-05-21 Jordan Simons Distributed multi-ledger gambling architecture
US10872370B2 (en) 2017-11-14 2020-12-22 Tommy Run LLC Systems and methods for on-demand delivery of construction materials and other items
US10796363B1 (en) 2017-11-15 2020-10-06 Square, Inc. Customized financing based on transaction information
US10692140B1 (en) 2017-11-15 2020-06-23 Square, Inc. Customized financing based on transaction information
US11188887B1 (en) 2017-11-20 2021-11-30 Wells Fargo Bank, N.A. Systems and methods for payment information access management
US10803350B2 (en) 2017-11-30 2020-10-13 Kofax, Inc. Object detection and image cropping using a multi-detector approach
US10410021B1 (en) 2017-12-08 2019-09-10 Square, Inc. Transaction object reader with digital signal input/output and internal audio-based communication
US20190180361A1 (en) * 2017-12-13 2019-06-13 Creative Venture Solutions, Ltd. System and method for cost sharing
US11144924B2 (en) 2017-12-14 2021-10-12 Mastercard International Incorporated Facilitating peer-to-peer transactions using virtual debit accounts of virtual wallets
US11087301B1 (en) 2017-12-19 2021-08-10 Square, Inc. Tamper resistant device
US20210233163A1 (en) * 2018-01-12 2021-07-29 Lydians Elektronik Para Ve Odeme Hizmetleri Anonim Sirketi Account balance sharing system
TR202000322A1 (tr) * 2020-01-09 2020-12-21 Lydians Elektronik Para Ve Oedeme Hizmetleri Anonim Sirketi Kredi̇ karti paylaşim si̇stemi̇
US10846679B2 (en) 2018-01-16 2020-11-24 Capital One Services, Llc Peer-to-peer payment systems and methods
US20190251589A1 (en) * 2018-02-12 2019-08-15 Steven L. VanFleet Method and system for a centralized gateway processing center for the registration and transaction processing of card linked services connected to debit transactions
US11893581B1 (en) 2018-02-20 2024-02-06 Block, Inc. Tokenization for payment devices
US10192215B1 (en) 2018-03-02 2019-01-29 Capital One Services, Llc Trigger peer to peer payment with financial cards and phone camera
GB201805933D0 (en) * 2018-04-10 2018-05-23 Visa Europe Ltd Electronic Transaction System
US11494782B1 (en) 2018-04-27 2022-11-08 Block, Inc. Equity offers based on user actions
US11341523B1 (en) * 2018-04-27 2022-05-24 Block, Inc. Person-to-person gift offers based on user actions
US11030752B1 (en) 2018-04-27 2021-06-08 United Services Automobile Association (Usaa) System, computing device, and method for document detection
US11488195B1 (en) 2018-04-27 2022-11-01 Block, Inc. Reward offer redemption for payment cards
US11436577B2 (en) 2018-05-03 2022-09-06 The Clearing House Payments Company L.L.C. Bill pay service with federated directory model support
US11544712B2 (en) * 2018-06-11 2023-01-03 Tbol Inc. Secure multi-factor tokenization-based sub-cryptocurrency payment platform
US20200013028A1 (en) * 2018-07-09 2020-01-09 American Express Travel Related Services Company, Inc. Peer-to-peer money transfers
USD905059S1 (en) 2018-07-25 2020-12-15 Square, Inc. Card reader device
US11893554B2 (en) 2018-08-30 2024-02-06 International Business Machines Corporation Secure smart note
US11769147B2 (en) * 2018-08-30 2023-09-26 International Business Machines Corporation Secure smart note
SG11202101601VA (en) 2018-08-31 2021-03-30 Visa Int Service Ass Method, system, and computer program product for providing installment payment options for a payment transaction
US11765262B2 (en) 2018-09-27 2023-09-19 Iqx Corp. Customer capture using dynamically generated customized webpages
EP3867850A4 (en) * 2018-10-16 2022-07-13 Digimax Global Solutions ELECTRONIC PROXIMITY CREDITS EXCHANGE SYSTEM AND ASSOCIATED METHOD
US11842331B2 (en) * 2018-10-24 2023-12-12 Capital One Services, Llc Network of trust for bill splitting
US11494757B2 (en) 2018-10-24 2022-11-08 Capital One Services, Llc Remote commands using network of trust
US11244382B1 (en) 2018-10-31 2022-02-08 Square, Inc. Computer-implemented method and system for auto-generation of multi-merchant interactive image collection
US11210730B1 (en) 2018-10-31 2021-12-28 Square, Inc. Computer-implemented methods and system for customized interactive image collection based on customer data
US11645613B1 (en) 2018-11-29 2023-05-09 Block, Inc. Intelligent image recommendations
US11386422B2 (en) 2018-12-05 2022-07-12 Paypal, Inc. Passive management of multiple digital tokens for an electronic transaction
US11157987B2 (en) * 2018-12-07 2021-10-26 Paypal, Inc. System and method for obtaining recommendations using scalable cross-domain collaborative filtering
US11531916B2 (en) 2018-12-07 2022-12-20 Paypal, Inc. System and method for obtaining recommendations using scalable cross-domain collaborative filtering
US11449491B2 (en) * 2019-01-14 2022-09-20 PolySign, Inc. Preventing a transmission of an incorrect copy of a record of data to a distributed ledger system
CA3137139A1 (en) * 2019-04-19 2020-10-22 EZ-Tip LLC Improved system and method for paying and receiving gratuities
US11514428B2 (en) * 2019-07-10 2022-11-29 Slip Cash Inc. Device for launching multiple peer to peer cashless payment applications on mobile devices
US11367067B2 (en) * 2019-10-04 2022-06-21 Bank Of America Corporation System for secure distribution of peer requests for resources
US20210174354A1 (en) * 2019-11-14 2021-06-10 Horus Foster, Inc. Anonymous peer-to-peer payment system
US11165580B2 (en) 2019-11-26 2021-11-02 Bank Of America Corporation Encrypted data transmission system for secure resource distribution
SG10202000987TA (en) * 2020-02-04 2021-09-29 Mastercard International Inc Method and system for open-loop person-to-person payments
US11526874B2 (en) 2020-06-11 2022-12-13 Seagate Technology Llc Offline value transfer using asymmetric cryptography
WO2022015268A2 (en) * 2020-07-12 2022-01-20 Lydians Elektronik Para Ve Odeme Hizmetleri Anonim Sirketi Account balance sharing system
US20220027873A1 (en) * 2020-07-24 2022-01-27 Capital One Services, Llc Peer-to-peer (p2p) payment with security protection for payee
WO2022047582A1 (en) * 2020-09-02 2022-03-10 Centigram International, Ltd Blockchain-based technologies for secure offline transaction processing
US10992606B1 (en) 2020-09-04 2021-04-27 Wells Fargo Bank, N.A. Synchronous interfacing with unaffiliated networked systems to alter functionality of sets of electronic assets
US11741201B2 (en) 2020-09-09 2023-08-29 The Toronto-Dominion Bank Systems and methods for initiating an authenticated session
US11055692B1 (en) * 2020-09-10 2021-07-06 Square, Inc. Application integration for contactless payments
US11544695B2 (en) 2020-09-10 2023-01-03 Block, Inc. Transaction identification by comparison of merchant transaction data and context data
US11968195B2 (en) 2020-09-14 2024-04-23 Swoop Ip Holdings Llc Email-based authentication for sign in and security
TR202016108A2 (pt) * 2020-10-09 2020-10-21
RU2761419C1 (ru) * 2020-11-11 2021-12-08 Акционерное общество "Национальная система платежных карт" Способ и система для перевода денежных средств со счета на счет
US11900755B1 (en) 2020-11-30 2024-02-13 United Services Automobile Association (Usaa) System, computing device, and method for document detection and deposit processing
US11887098B1 (en) 2020-12-08 2024-01-30 Wells Fargo Bank, N.A. Systems and methods for peer-to-peer rewards and gift card transfer via messaging
US11386416B1 (en) * 2020-12-09 2022-07-12 Ronald Wayne Wolverton Contactless entertainer tipping and service ordering system
US11546338B1 (en) 2021-01-05 2023-01-03 Wells Fargo Bank, N.A. Digital account controls portal and protocols for federated and non-federated systems and devices
US20220270068A1 (en) * 2021-02-19 2022-08-25 Highline Technologies Inc. Payment network and method for paying recurring bills
US11636474B2 (en) 2021-05-18 2023-04-25 Visa International Service Association System and method for implementing a key-code based money transfer
EP4348548A1 (en) 2021-06-02 2024-04-10 Paymentus Corporation Methods, apparatuses, and systems for user account-affiliated payment and billing, consolidated digital biller-payment wallets
US20230010678A1 (en) * 2021-07-07 2023-01-12 Affirm, Inc. Method and Apparatus for Facilitating Financial Transactions Backed by Crypto Assets
US11645636B2 (en) * 2021-07-22 2023-05-09 Paypal, Inc. Enabling user to user interactions in multi-user video conference applications
US20230038555A1 (en) * 2021-08-06 2023-02-09 Bank Of America Corporation Value Exchange and Intelligent Recommendation Engine
US20230267444A1 (en) * 2022-02-18 2023-08-24 Bank Of America Corporation Proximity-based device pairing system via acoustic communication for secure resource transfer
US20240095691A1 (en) * 2022-09-16 2024-03-21 Vocalink International Limited Systems and methods for use in cancellation of or closure of network requests

Family Cites Families (140)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
BE794977A (fr) * 1972-02-05 1973-05-29 Siemens Ag Dispositif de commutation pour organes utilisateurs electriques telecommandes
US5155860A (en) * 1988-12-27 1992-10-13 Cellular Communications Corporation Cellular portable telephone battery pack and programmer interface
US5159592A (en) * 1990-10-29 1992-10-27 International Business Machines Corporation Network address management for a wired network supporting wireless communication to a plurality of mobile users
US5257414A (en) * 1990-11-26 1993-10-26 Motorola, Inc. Apparatus for accepting and retaining a memory card
CA2059078C (en) * 1991-02-27 1995-10-03 Alexander G. Fraser Mediation of transactions by a communications system
CA2064646A1 (en) * 1991-04-02 1992-10-03 Kipling W. Fyfe Automatic number assignment module selection for mobile telephone
US5249218A (en) * 1992-04-06 1993-09-28 Spectrum Information Technologies, Inc. Programmable universal interface system
US5406584A (en) * 1992-09-01 1995-04-11 X-Com, Inc. Time shift keying digital communications system
DE69324445T2 (de) * 1992-11-27 1999-09-30 Denso Corp Tragbares elektronisches Gerät
DE4307122A1 (de) * 1993-03-06 1994-09-08 Sel Alcatel Ag Chipkarte
US5348485A (en) * 1993-04-12 1994-09-20 Electronic Retailing Systems Int'l Inc. Electronic price display system with vertical rail
US5465206B1 (en) * 1993-11-01 1998-04-21 Visa Int Service Ass Electronic bill pay system
US5557516A (en) * 1994-02-04 1996-09-17 Mastercard International System and method for conducting cashless transactions
US5742905A (en) * 1994-09-19 1998-04-21 Bell Communications Research, Inc. Personal communications internetworking
US5915023A (en) * 1997-01-06 1999-06-22 Bernstein; Robert Automatic portable account controller for remotely arranging for transfer of value to a recipient
US6012634A (en) * 1995-03-06 2000-01-11 Motorola, Inc. Dual card and method therefor
US5677955A (en) * 1995-04-07 1997-10-14 Financial Services Technology Consortium Electronic funds transfer instruments
WO1997002539A1 (fr) * 1995-07-06 1997-01-23 Hitachi, Ltd. Systeme d'envoi de monnaie electronique
US5893080A (en) * 1995-07-25 1999-04-06 Bottomline Technologies, Inc. Disbursement system and method
US5757917A (en) * 1995-11-01 1998-05-26 First Virtual Holdings Incorporated Computerized payment system for purchasing goods and services on the internet
US5778178A (en) * 1995-11-13 1998-07-07 Arunachalam; Lakshmi Method and apparatus for enabling real-time bi-directional transactions on a network
JPH09259193A (ja) * 1996-03-19 1997-10-03 Fujitsu Ltd 電子マネーシステムの取引方法
US6044360A (en) * 1996-04-16 2000-03-28 Picciallo; Michael J. Third party credit card
EP0960402B1 (en) * 1996-06-19 2007-09-26 Behruz Vazvan Real time system and method for remote purchase payment and remote bill payment transactions and transferring of electronic cash and other required data
US5903874A (en) * 1996-06-27 1999-05-11 Mci Communications Corporation System and method for electronic coupon management
US5903880A (en) * 1996-07-19 1999-05-11 Biffar; Peter C. Self-contained payment system with circulating digital vouchers
US5815426A (en) * 1996-08-13 1998-09-29 Nexcom Technology, Inc. Adapter for interfacing an insertable/removable digital memory apparatus to a host data part
US5790790A (en) * 1996-10-24 1998-08-04 Tumbleweed Software Corporation Electronic document delivery system in which notification of said electronic document is sent to a recipient thereof
US6175922B1 (en) * 1996-12-04 2001-01-16 Esign, Inc. Electronic transaction systems and methods therefor
US5937396A (en) * 1996-12-04 1999-08-10 Konya; Arpad System for ATM/ATM transfers
DE69603971T2 (de) * 1996-12-13 2000-03-30 Ericsson Telefon Ab L M Verfahren und System zur Durchführung von Geldtransaktionen
US5963647A (en) * 1997-02-14 1999-10-05 Citicorp Development Center, Inc. Method and system for transferring funds from an account to an individual
FI105637B (fi) * 1997-07-02 2000-09-15 Sonera Oyj Menetelmä tilaajaidentiteettimoduulille tallennettujen sovellusten hallintaan
US5903878A (en) * 1997-08-20 1999-05-11 Talati; Kirit K. Method and apparatus for electronic commerce
US6029144A (en) * 1997-08-29 2000-02-22 International Business Machines Corporation Compliance-to-policy detection method and system
US6125349A (en) * 1997-10-01 2000-09-26 At&T Corp. Method and apparatus using digital credentials and other electronic certificates for electronic transactions
GB2330923A (en) * 1997-10-28 1999-05-05 Ibm Transaction manager
US20020194099A1 (en) * 1997-10-30 2002-12-19 Weiss Allan N. Proxy asset system and method
AUPP411098A0 (en) * 1998-06-15 1998-07-09 Newcom Technologies Pty Ltd Communication method and apparatus improvements
EP0987642A3 (en) * 1998-09-15 2004-03-10 Citibank, N.A. Method and system for co-branding an electronic payment platform such as an electronic wallet
EP1116194A1 (de) * 1998-09-22 2001-07-18 Siemens Aktiengesellschaft Verfahren und system zum bezahlen von waren oder diensten
US6032136A (en) * 1998-11-17 2000-02-29 First Usa Bank, N.A. Customer activated multi-value (CAM) card
US6611913B1 (en) * 1999-03-29 2003-08-26 Verizon Laboratories Inc. Escrowed key distribution for over-the-air service provisioning in wireless communication networks
AU4501600A (en) * 1999-04-30 2000-11-17 X.Com Corporation System and method for electronically exchanging value among distributed users
US6496851B1 (en) * 1999-08-04 2002-12-17 America Online, Inc. Managing negotiations between users of a computer network by automatically engaging in proposed activity using parameters of counterproposal of other user
WO2001041419A1 (en) 1999-11-30 2001-06-07 Citibank, N.A. System and method for performing an electronic transaction using a transaction proxy with an electronic wallet
JP2001357202A (ja) 1999-12-06 2001-12-26 Ebank Kk 電子決済システム及び電子決済方法
US7395241B1 (en) * 2000-01-19 2008-07-01 Intuit Inc. Consumer-directed financial transfers using automated clearinghouse networks
KR20010091827A (ko) * 2000-03-18 2001-10-23 정상훈 통신 단말 번호를 이용한 송금 시스템 및 송금 방법
AU2000278920B2 (en) * 2000-05-17 2006-11-30 Symstream Technology Holdings No.2 Pty Ltd Octave pulse data method and apparatus
US7031939B1 (en) * 2000-08-15 2006-04-18 Yahoo! Inc. Systems and methods for implementing person-to-person money exchange
US20020025795A1 (en) * 2000-08-24 2002-02-28 Msafe Inc., Method, system and device for monitoring activity of a wireless communication device
US7392388B2 (en) * 2000-09-07 2008-06-24 Swivel Secure Limited Systems and methods for identity verification for secure transactions
US7774231B2 (en) * 2000-09-29 2010-08-10 Nokia Corporation Electronic payment methods for a mobile device
US20020152179A1 (en) * 2000-10-27 2002-10-17 Achiezer Racov Remote payment method and system
WO2002042926A1 (en) * 2000-11-20 2002-05-30 Ecrio Inc. Method for downloading bar code encoded information with a mobile communication
GB2372615A (en) 2000-12-27 2002-08-28 Robert Joseph Gerard Macnamee Telephone based payment system
CA2332656A1 (en) * 2001-01-26 2002-07-26 Certapay Inc. Online payment transfer and identity management system and method
KR100485759B1 (ko) 2001-01-26 2005-04-28 주식회사 이모시스텍 메신저 기능을 이용한 대금지불 인증 방법
WO2002069325A1 (en) * 2001-02-26 2002-09-06 Startouch International, Ltd. Apparatus and methods for implementing voice enabling applications in a coverged voice and data network environment
US7249094B2 (en) * 2001-02-26 2007-07-24 Paypal, Inc. System and method for depicting on-line transactions
US7895098B2 (en) * 2001-03-01 2011-02-22 Jpmorgan Chase Bank, N.A. System and method for measuring and utilizing pooling analytics
US7181017B1 (en) * 2001-03-23 2007-02-20 David Felsher System and method for secure three-party communications
KR20020083570A (ko) 2001-04-27 2002-11-04 주식회사 한국주택은행 가상계좌와 휴대폰을 이용한 결제 방법
US7046992B2 (en) * 2001-05-11 2006-05-16 Telefonaktiebolaget Lm Ericsson (Publ) Authentication of termination messages in telecommunications system
US20020186845A1 (en) * 2001-06-11 2002-12-12 Santanu Dutta Method and apparatus for remotely disabling and enabling access to secure transaction functions of a mobile terminal
US6960988B2 (en) * 2001-06-14 2005-11-01 Long Range Systems, Inc. Multi-function customer satisfaction survey device
US20030005329A1 (en) * 2001-06-29 2003-01-02 Ari Ikonen System and method for transmitting data via wireless connection in a secure manner
US7119659B2 (en) * 2001-07-10 2006-10-10 American Express Travel Related Services Company, Inc. Systems and methods for providing a RF transaction device for use in a private label transaction
US7225156B2 (en) * 2001-07-11 2007-05-29 Fisher Douglas C Persistent dynamic payment service
US7249256B2 (en) * 2001-07-11 2007-07-24 Anoto Ab Encryption protocol
KR200250912Y1 (ko) * 2001-07-28 2001-11-22 (주)제이브이메디 약자동분포기의 수동분배용 보조트레이
US7191151B1 (en) * 2001-08-23 2007-03-13 Paypal, Inc. Instant availability of electronically transferred funds
RU2004109577A (ru) * 2001-08-31 2005-08-20 Пейсеттер Пте Лтд. (Sg) Система финансовых транзакций и способ использования электронного обмена сообщениями
US7353393B2 (en) * 2001-09-07 2008-04-01 Anoto Aktiebolag (Anoto Ab) Authentication receipt
US7044362B2 (en) * 2001-10-10 2006-05-16 Hewlett-Packard Development Company, L.P. Electronic ticketing system and method
US6983376B2 (en) * 2001-10-16 2006-01-03 Qualcomm Incorporated Method and apparatus for providing privacy of user identity and characteristics in a communication system
US20030078793A1 (en) * 2001-10-24 2003-04-24 Toth Mark E. Enhanced customer-centric restaurant system
US7904360B2 (en) * 2002-02-04 2011-03-08 Alexander William EVANS System and method for verification, authentication, and notification of a transaction
US20040054592A1 (en) * 2002-09-13 2004-03-18 Konrad Hernblad Customer-based wireless ordering and payment system for food service establishments using terminals and mobile devices
US20050182724A1 (en) * 2002-02-23 2005-08-18 Wow! Technologies, Inc. Incremental network access payment system and method utilizing debit cards
AUPS087602A0 (en) * 2002-03-04 2002-03-28 Ong, Yong Kin (Michael) Electronic fund transfer system
AU2003212638A1 (en) * 2002-03-13 2003-09-22 Adjungo Networks Ltd. Accessing cellular networks from non-native local networks
US20030187754A1 (en) * 2002-04-02 2003-10-02 F. Rogers Dixson Working endowment builder
US20030194071A1 (en) * 2002-04-15 2003-10-16 Artoun Ramian Information communication apparatus and method
EP1514211A4 (en) * 2002-05-21 2010-03-10 Tekelec Us METHODS AND SYSTEMS FOR REALIZING A SALES TRANSACTION USING A MOBILE COMMUNICATIONS DEVICE
KR20030090435A (ko) * 2002-05-23 2003-11-28 에스케이 텔레콤주식회사 금융 거래 시스템 및 방법
US20040215507A1 (en) * 2002-07-03 2004-10-28 Levitt Roger A. Fully funded reward program
US20040210518A1 (en) * 2002-08-01 2004-10-21 Tiem Marvin Van Wire transfer system and method
US7822688B2 (en) * 2002-08-08 2010-10-26 Fujitsu Limited Wireless wallet
US8224700B2 (en) * 2002-08-19 2012-07-17 Andrew Silver System and method for managing restaurant customer data elements
US7494055B2 (en) * 2002-09-17 2009-02-24 Vivotech, Inc. Collaborative negotiation techniques for mobile personal trusted device financial transactions
US7496527B2 (en) * 2002-11-05 2009-02-24 Barmonger, Llc Remote purchasing system, method and program
US20050195975A1 (en) * 2003-01-21 2005-09-08 Kevin Kawakita Digital media distribution cryptography using media ticket smart cards
US7003493B2 (en) * 2003-01-22 2006-02-21 First Data Corporation Direct payment with token
US20040215526A1 (en) * 2003-04-08 2004-10-28 Wenjun Luo Interactive shopping and selling via a wireless network
WO2004102879A1 (en) * 2003-05-09 2004-11-25 Arcot Systems, Inc. Method and apparatus for securing pass codes during transmission from capture to delivery
US7374079B2 (en) * 2003-06-24 2008-05-20 Lg Telecom, Ltd. Method for providing banking services by use of mobile communication system
CA2552264A1 (en) * 2003-07-02 2005-01-13 Mobipay International, S.A. Digital mobile telephone transaction and payment system
US20050044040A1 (en) * 2003-08-20 2005-02-24 Frank Howard System and method of mediating business transactions
US7904372B2 (en) * 2003-08-21 2011-03-08 Finistar, Inc. Methods and systems for facilitating transactions between commercial banks and pooled depositor groups
US20050065851A1 (en) * 2003-09-22 2005-03-24 Aronoff Jeffrey M. System, method and computer program product for supplying to and collecting information from individuals
US20050199709A1 (en) * 2003-10-10 2005-09-15 James Linlor Secure money transfer between hand-held devices
JP2005135093A (ja) * 2003-10-29 2005-05-26 Fujitsu Ltd 電子決済支援システムおよび電子決済支援装置
US9191215B2 (en) * 2003-12-30 2015-11-17 Entrust, Inc. Method and apparatus for providing authentication using policy-controlled authentication articles and techniques
US20050246289A1 (en) * 2004-04-13 2005-11-03 Alexander Robert M Iv System and method for processing and for funding a transaction
WO2005104725A2 (en) * 2004-04-26 2005-11-10 Paycenters, Llc Automated financial service system
US20050278222A1 (en) * 2004-05-24 2005-12-15 Nortrup Edward H Systems and methods for performing transactions
US20060015402A1 (en) * 2004-06-10 2006-01-19 Graves Phillip C Using multiple PINs for redemption through multiple distribution channels
CA2570897C (en) * 2004-06-29 2017-05-09 Textura, Llc Construction payment management system and method
US20070005490A1 (en) * 2004-08-31 2007-01-04 Gopalakrishnan Kumar C Methods and System for Distributed E-commerce
US7945489B2 (en) * 2004-09-21 2011-05-17 Sap Ag Flexible cost and revenue allocation for service orders
US7613919B2 (en) * 2004-10-12 2009-11-03 Bagley Brian B Single-use password authentication
US8752125B2 (en) * 2004-10-20 2014-06-10 Salt Group Pty Ltd Authentication method
US10134202B2 (en) * 2004-11-17 2018-11-20 Paypal, Inc. Automatic address validation
US20060143087A1 (en) * 2004-12-28 2006-06-29 Tripp Travis S Restaurant management using network with customer-operated computing devices
US9875491B2 (en) * 2004-12-30 2018-01-23 Paypal, Inc. Systems and methods for facilitating lending between two or more parties
US20060200427A1 (en) * 2005-03-01 2006-09-07 Morrison Robert A Systems and methods for securing transactions with biometric information
US8050991B2 (en) * 2005-04-05 2011-11-01 DXStorm. com Inc. Electronic balance checking and credit approval system for use in conducting electronic transactions
CA2541283A1 (en) * 2005-04-05 2006-10-05 Guy David Fietz Online debit cardless debit transaction system and method
US20060235758A1 (en) * 2005-04-08 2006-10-19 Paypal Inc. Authorization techniques
US20060283935A1 (en) * 2005-05-16 2006-12-21 Henry Scott P Systems and methods for processing commercial transactions
US8719396B2 (en) * 2005-05-20 2014-05-06 Vibrant Media Limited Fraud prevention and detection for online advertising
US20140304155A9 (en) * 2005-05-24 2014-10-09 T. Clay Wilkes Transaction alert messages associated with financial transactions
US7831520B2 (en) * 2005-06-28 2010-11-09 Ebay Inc. Mobile device communication system
JP2009501979A (ja) * 2005-07-15 2009-01-22 レボリューション マネー，インコーポレイテッド 子口座を規定する規約を設定するシステム及び方法
US20070050303A1 (en) * 2005-08-24 2007-03-01 Schroeder Dale W Biometric identification device
US20070055635A1 (en) * 2005-09-08 2007-03-08 Mobitran Llc Method and apparatus for performing mobile transactions
US20070083463A1 (en) * 2005-09-20 2007-04-12 Kraft Harold H Fraud alert switch
KR20080059617A (ko) * 2005-10-05 2008-06-30 프리바스피어 아게 사용자 인증 방법 및 디바이스
US20070106564A1 (en) * 2005-11-04 2007-05-10 Utiba Pte Ltd. Mobile phone as a point of sale (POS) device
US20070125838A1 (en) * 2005-12-06 2007-06-07 Law Eric C W Electronic wallet management
US7657489B2 (en) * 2006-01-18 2010-02-02 Mocapay, Inc. Systems and method for secure wireless payment transactions
US20070255653A1 (en) 2006-03-30 2007-11-01 Obopay Inc. Mobile Person-to-Person Payment System
US20080010194A1 (en) * 2006-07-10 2008-01-10 Automated Payment Highway, Inc. Method and apparatus for financing community expenses
US20080046362A1 (en) * 2006-08-15 2008-02-21 Frank Easterly Method of making secure on-line financial transactions
US8006300B2 (en) * 2006-10-24 2011-08-23 Authernative, Inc. Two-channel challenge-response authentication method in random partial shared secret recognition system
US8429406B2 (en) * 2007-06-04 2013-04-23 Qualcomm Atheros, Inc. Authorizing customer premise equipment into a network
US20090106148A1 (en) * 2007-10-17 2009-04-23 Christian Prada Pre-paid financial system
GB2457445A (en) * 2008-02-12 2009-08-19 Vidicom Ltd Verifying payment transactions

Cited By (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4250220A3 (en) * 2011-11-29 2023-12-06 Zuora, Inc. Configurable billing with subscriptions having conditional components
US11715075B2 (en) 2012-03-07 2023-08-01 Early Warning Services, Llc System and method for transferring funds
US10395223B2 (en) 2012-03-07 2019-08-27 Early Warning Services, Llc System and method for transferring funds
US11373182B2 (en) 2012-03-07 2022-06-28 Early Warning Services, Llc System and method for transferring funds
US10078821B2 (en) 2012-03-07 2018-09-18 Early Warning Services, Llc System and method for securely registering a recipient to a computer-implemented funds transfer payment network
US10970688B2 (en) 2012-03-07 2021-04-06 Early Warning Services, Llc System and method for transferring funds
US10318936B2 (en) 2012-03-07 2019-06-11 Early Warning Services, Llc System and method for transferring funds
US11593800B2 (en) 2012-03-07 2023-02-28 Early Warning Services, Llc System and method for transferring funds
US11605077B2 (en) 2012-03-07 2023-03-14 Early Warning Services, Llc System and method for transferring funds
US11361290B2 (en) 2012-03-07 2022-06-14 Early Warning Services, Llc System and method for securely registering a recipient to a computer-implemented funds transfer payment network
US10395247B2 (en) 2012-03-07 2019-08-27 Early Warning Services, Llc Systems and methods for facilitating a secure transaction at a non-financial institution system
US11948148B2 (en) 2012-03-07 2024-04-02 Early Warning Services, Llc System and method for facilitating transferring funds
US11321682B2 (en) 2012-03-07 2022-05-03 Early Warning Services, Llc System and method for transferring funds
US10832246B2 (en) 2015-03-23 2020-11-10 Early Warning Services, Llc Payment real-time funds availability
US10769606B2 (en) 2015-03-23 2020-09-08 Early Warning Services, Llc Payment real-time funds availability
US10748127B2 (en) 2015-03-23 2020-08-18 Early Warning Services, Llc Payment real-time funds availability
US10878387B2 (en) 2015-03-23 2020-12-29 Early Warning Services, Llc Real-time determination of funds availability for checks and ACH items
US10846662B2 (en) 2015-03-23 2020-11-24 Early Warning Services, Llc Real-time determination of funds availability for checks and ACH items
US10839359B2 (en) 2015-03-23 2020-11-17 Early Warning Services, Llc Payment real-time funds availability
US11037121B2 (en) 2015-07-21 2021-06-15 Early Warning Services, Llc Secure real-time transactions
US10970695B2 (en) 2015-07-21 2021-04-06 Early Warning Services, Llc Secure real-time transactions
US11151522B2 (en) 2015-07-21 2021-10-19 Early Warning Services, Llc Secure transactions with offline device
US11151523B2 (en) 2015-07-21 2021-10-19 Early Warning Services, Llc Secure transactions with offline device
US10438175B2 (en) 2015-07-21 2019-10-08 Early Warning Services, Llc Secure real-time payment transactions
US11157884B2 (en) 2015-07-21 2021-10-26 Early Warning Services, Llc Secure transactions with offline device
US11922387B2 (en) 2015-07-21 2024-03-05 Early Warning Services, Llc Secure real-time transactions
US11062290B2 (en) 2015-07-21 2021-07-13 Early Warning Services, Llc Secure real-time transactions
US11037122B2 (en) 2015-07-21 2021-06-15 Early Warning Services, Llc Secure real-time transactions
US11386410B2 (en) 2015-07-21 2022-07-12 Early Warning Services, Llc Secure transactions with offline device
US10762477B2 (en) 2015-07-21 2020-09-01 Early Warning Services, Llc Secure real-time processing of payment transactions
US10963856B2 (en) 2015-07-21 2021-03-30 Early Warning Services, Llc Secure real-time transactions
US10956888B2 (en) 2015-07-21 2021-03-23 Early Warning Services, Llc Secure real-time transactions
US11151567B2 (en) 2016-09-19 2021-10-19 Early Warning Services, Llc Authentication and fraud prevention in provisioning a mobile wallet
US11144928B2 (en) 2016-09-19 2021-10-12 Early Warning Services, Llc Authentication and fraud prevention in provisioning a mobile wallet
US11151566B2 (en) 2016-09-19 2021-10-19 Early Warning Services, Llc Authentication and fraud prevention in provisioning a mobile wallet

Also Published As

Publication number Publication date
WO2008027621A1 (en) 2008-03-06
BRPI0710021A2 (pt) 2011-08-02
MX2008012504A (es) 2009-05-05
US20070255653A1 (en) 2007-11-01
CA2647602A1 (en) 2008-03-06
EP2013842A1 (en) 2009-01-14
WO2008027620A1 (en) 2008-03-06
MX2008012503A (es) 2008-12-12
EP2407919A1 (en) 2012-01-18
CA2647636A1 (en) 2008-03-06
US20070255652A1 (en) 2007-11-01
EP2008237A1 (en) 2008-12-31
US20070255620A1 (en) 2007-11-01
EP2013842A4 (en) 2009-03-18
EP2008237A4 (en) 2009-03-18
EP2407918A1 (en) 2012-01-18

Similar Documents

Publication Publication Date Title
US7873573B2 (en) Virtual pooled account for mobile banking
US8249965B2 (en) Member-supported mobile payment system
BRPI0710089A2 (pt) sistema de pagamento individualizado móvel
US20070255662A1 (en) Authenticating Wireless Person-to-Person Money Transfers
US20070244811A1 (en) Mobile Client Application for Mobile Payments
KR102634772B1 (ko) 비-금융 기관 시스템에서 안전 거래를 돕기 위한 시스템 및 방법
US10171961B1 (en) Transaction authorization service
WO2009114876A2 (en) Network-based viral payment system
US8352376B2 (en) System and method for authorization of transactions
US10318936B2 (en) System and method for transferring funds
US20090319425A1 (en) Mobile Person-to-Person Payment System
US20110320347A1 (en) Mobile Networked Payment System
US20130006848A1 (en) Method of virtual transaction using mobile electronic devices or fixed electronic devices or a combination of both, for global commercial or noncommercial purposes
CN101454795A (zh) 移动的个人之间支付系统
EP2304678A1 (en) Mobile payment system
US11935066B1 (en) Systems and methods for funds transfers via a token management system
US10970688B2 (en) System and method for transferring funds
WO2007044882A2 (en) System and method for authorization of transactions
Obaid A Novel Mobile Transactional Payment Banking Scheme
CA2645044C (en) System and method for authorization of transactions

Legal Events

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

Free format text: REFERENTE 6A. ANUIDADE(S).

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

Free format text: REFERENTE AO DESPACHO 8.6 PUBLICADO NA RPI 2225 DE 27/08/2013.