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

sistema de pagamento individualizado móvel Download PDF

Info

Publication number
BRPI0710021A2
BRPI0710021A2 BRPI0710021-3A BRPI0710021A BRPI0710021A2 BR PI0710021 A2 BRPI0710021 A2 BR PI0710021A2 BR PI0710021 A BRPI0710021 A BR PI0710021A BR PI0710021 A2 BRPI0710021 A2 BR PI0710021A2
Authority
BR
Brazil
Prior art keywords
account
user
payment
transaction
mobile
Prior art date
Application number
BRPI0710021-3A
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 BRPI0710021A2 publication Critical patent/BRPI0710021A2/pt

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Signal Processing (AREA)
  • Economics (AREA)
  • Computer Security & Cryptography (AREA)
  • Marketing (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Game Theory and Decision Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Meter Arrangements (AREA)
  • Telephonic Communication Services (AREA)

Abstract

<B>SISTEMA DE PAGAMENTO INDIVIDUALIZADO MóVEL<D> A presente invenção refere-se a uma plataforma e serviço de pagamento móvel que proveem 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-mau, 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 direitos0dos 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, de forma geral, asistemas de transferência de moeda eletrônica, e mais particularmente sereferem a sistemas de transferência de moeda operando substancialmenteem tempo real e capaz de transferências de moeda de pessoa para pessoae pessoa para comerciante. Modalidades do sistema de pagamento da pre-sente invenção são particularmente adaptáveis a implementações onde umdispositivo sem fio, tal como um telefone celular, é uma das interfaces deconsumidor para efetuar tais transferências de moeda.
Historicamente, uma pessoa que desejava concluir uma transa-ção financeira - por exemplo, para comprar um item - contava com váriosinstrumentos financeiros tais como dinheiro, cheques, cartões de crédito oucartões de débito. Infelizmente, cada um desses instrumentos financeirostêm preocupações de segurança Quando o dinheiro é perdido ou roubado,geralmente não existe recurso a não ser aceitar a perda. Com outros instru-mentos financeiros, a perda não é uma preocupação principal, mas a fraudecausa perdas significativas para a indústria de pagamento. Na realidade, afraude do cartão de crédito, cartão de débito e do cheque tem sido e conti-nua como um problema principal para a indústria e um esgotamento signifi-cativo na utilidade da indústria de pagamento.
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, ou o que é algumas vezes chamadocomo "fundos certos". Mais propriamente, o cheque é meramente um peda-ço de papel onde a validade do banco de onde ele é sacado deve ser verifi-cada junto com a conta que é usada, a assinatura usada para autorizar opagamento e o saldo disponível. Com um cartão de crédito ou débito, o usu-ário pode não ser autorizado, mas pode extorquir despesas consideráveisantes que 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 que ele está recebendo fundos certos. Além do que, o que énecessário é uma maneira mais segura para acessar cartões de crédito edébito para concluir as transações financeiras.
Embora cada um dos instrumentos financeiros acima listadostenha sido usado extensivamente no passado, é evidente que os consumido-res desejam um método seguro, simples, para concluir as transações finan-ceiras. O uso crescente de cartões de crédito provê ampla evidência que osconsumidores, bem como os comerciantes, preferem usar sistemas de pa-gamento eletrônico ao invés de manipular grandes quantias de dinheiro ousofrer a inconveniência de negociar cheques para pequenas compras. Entre-tanto, os custos das transações com cartão de crédito tornam o seu uso pro-ibitivamente caro para pequenas transações. Mesmo com a adoção difundi-da dos sistemas de pagamento eletrônico, é evidente que existe uma neces-sidade crescente por sistemas de pagamento eletrônico mais rápidos, maisbaratos e mais convenientes para completar as transações financeiras. Alémdo que, existe uma necessidade de um sistema de pagamento eletrônicoque seja mais individualizado tal que as transações financeiras sejam fácil-mente concluí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. Issolevou ao uso crescente de cartões de débito pré-pagos. Infelizmente, cartõesde débito são na melhor das hipóteses, uma substituição limitada para di-nheiro porque eles são primariamente projetados para uso com comercian-tes que investiram em um terminal de transação de ponto de vendas (POS).Se um indivíduo deseja transferir fundos para alguém sem um terminal dePOS, por exemplo, um outro indivíduo, uma tal transação é difícil ou impos-sível sem envolver uma ida inconveniente a um banco ou para um comerci-ante cooperador com um terminal de POS. O que é necessário é um sistemade pagamento eletrônico que possibilite que as transações financeiras sejamconcluídas entre indivíduos e sem a necessidade de envolver diretamenteuma instituição financeira de terceiros ou uma instituição financeira 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, por exemplo, um telefone celular (ou celular) ou outro dispositivomóvel.
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 existem 2,14 bilhões de assinantes de telefone móvel. Uma es-timativa de 80 por cento da população mundial tem cobertura de telefonemóvel. Portanto, existe uma grande necessidade de um sistema que permitaque os telefones móveis enviem pagamentos e verifiquem a recepção, simi-lar a dinheiro, e permitam outras transações bancárias financeiras e móveis.Tentativas para criar um sistema de pagamento móvel usandodispositivos celulares encontraram sucesso limitado em parte porque muitostais sistemas requerem que o telefone celular tenha um dispositivo de circui-to adicional (ou "circuito integrado") para armazenar saldos de conta e infor-mação de conta. Quando a pessoa que controla o telefone deseja transferirfundos, os fundos são deduzidos no ponto de vendas do circuito integrado etransferido para a instituição financeira em um momento posterior a ser gra-vado pela instituição financeira. Claramente, esse atraso entre o tempo quea venda é feita e o tempo que a venda é gravada é ineficiente e arrisca a perda da venda caso o equipamento de POS do comerciante falhe antes quea venda seja registrada. Além do que, se o telefone é perdido, o saldo daconta pode ser usado por qualquer pessoa que controle o telefone. Emboraesse sistema proveja melhor proteção contra a perda de fundos e seja supe-rior para transportar dinheiro, o sistema carece de segurança adequada paraproteger o dono da conta do uso impróprio por outros.
Cartões de crédito também têm limitações significativas. Um car-tão de crédito indica que o dono tem concessão de uma linha de crédito deum banco ou outro emissor e isso possibilita que o dono faça compras ouretire dinheiro até uma quantia preestabelecida. Uma participação é cobradacom base nos termos do acordo do cartão de crédito e o dono é, algumasvezes, cobrado com uma anuidade. Tradicionalmente, um cartão plásticoque transporta um número de conta é atribuído para 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, bem como a susceptibilida-de das transações de cartão de crédito à fraude, 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 (TÉCNICA ANTERIOR) mostra um exemplo de umarede proprietária que inclui um terminal de ponto de vendas (POS) 3401 parainiciar as transações na localização de um comerciante e um processador depagamento 3402 conectado com o terminal de POS 3401 por uma rede pro-prietária 3403. Em alguns casos, a rede proprietária não é nada mais do queuma conexão com a Internet. O processador de pagamento 3402, por suavez, é conectado por uma rede proprietária 3404 em um intercâmbio de car-tão de crédito 3408.
Para iniciar a transação, um consumidor apresenta um cartão decrédito 3406 ou alternativamente um berloque de chave RFID 3407 no ter-minal do POS. Um berloque de chave RFID é um tipo de prova de seguran-ça: um pequeno dispositivo de hardware com mecanismo de armazenamen-to incorporado. 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.
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 incorreem 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 é menos significativa, mas ainda é uma erosão indesejada nas suasmargens 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 notado 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 um ladrão ativo não é detido pela solicitação de informação adicionalpara completar a transação. O dono, entretanto, é incomodado por ter que
inserir-ta! 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.Em um sistema baseado em cartão de crédito, a taxa de intercâmbio sozinhatornaria a transação suficientemente cara para desencorajar o uso. Além doque, é improvável que qualquer estudante concorde em pagar a taxa mensale outras despesas associadas com a conta de um comerciante a fim de a -cessar o intercâmbio do cartão de crédito. Dessa maneira, o sistema de cir-cuito aberto desenvolvido e operado pelos emissores de cartão de crédito étotalmente inadequado para transações financeiras de pessoa para pessoa.
Portanto, o que é necessário é um sistema de pagamento ele-trônico de custo efetivo que proporcione a um dono de conta a flexibilidade para conduzir suas transações financeiras a qualquer momento em qualquerlugar com fundos equivalentes ao dinheiro. O que é também necessário éuma "carteira móvel" que as pessoas possam acessar como uma fonte dedinheiro de, entre outros lugares, um dispositivo móvel, tal como um telefonecelular. Além do que, o que é necessário é uma aplicação de software e ser- viços gerenciados para pagamentos que opere como uma carteira móvel,por exemplo, em uma plataforma de telefone móvel. Essa carteira móvel de-ve ser segura, fácil de usar e fácil de adquirir de modo que a capacidade defazer pagamentos móveis fique disponível para qualquer dono de conta. A-lém do mais, o que é necessário é um sistema de transação financeira de circuito fechado que facilite os pagamentos sem as despesas substanciaisassociadas com os sistemas financeiros de circuito aberto e tenha um altonível de segurança para o dono, o comerciante e outros envolvidos nas tran-sações financeiras. Dessa maneira, as modalidades seguintes e as descri-ções exemplares das invenções são reveladas. Sumário da Invenção
A presente invenção substancialmente supera as limitações a-cima- mencionadas-da técnica anterior provendo um sistema de pagamentoeletrônico facilmente acessível, simples de usar, que permite a troca fácil defundos certos para ambas as transações de par para par e transações de comerciante-consumidor sem, em pelo menos algumas modalidades, reque-rer a infra-estrutura e a despesa de um sistema bancário comercial tal comoesse associado com cartões de crédito e débito convencionais. Em muitasmodalidades, o sistema de pagamento eletrônico fica acessível para o usuá-rio através de um dispositivo sem fio, tal como um telefone celular, de modo que os fundos podem ser transferidos e sua recepção verificada substanci-almente em tempo real, enquanto ao mesmo tempo provendo garantia ade-quada para garantir que as transações fraudulentas sejam minimizadas.Uma plataforma e serviço de pagamento móvel, de acordo comalgumas modalidades da presente invenção, proveem uma maneira rápida,fácil, de fazer e verificar pagamentos por usuários dos dispositivos móveis. Aplataforma também faz interface com canais não móveis e dispositivos taiscomo e-mail, mensageiro instantâneo e Web. Em uma implementação, osfundos são acessados a partir do dispositivo móvel do dono de uma conta talcomo um telefone móvel ou um assistente digital pessoal para fazer ou re-ceber pagamentos. As transações financeiras podem ser conduzidas emuma base de pessoa para pessoa (P2P) ou pessoa para comerciante (P2M)onde cada parte é identificada por um indicador único, tal como um númerode telefone, código de barras ou quaisquer outros indícios adequados. Astransações podem ser efetuadas através de qualquer número de recursosincluindo troca de mensagens SMS, Web, e-mail, mensageiro instantâneo,uma aplicação de cliente móvel, uma aplicação de arquivo complementar detroca de mensagem instantânea ou "widget". Em algumas modalidades, umaaplicação do cliente móvel, residente no dispositivo móvel, simplifica o aces-so e executa as transações financeiras em uma maneira rápida, segura.
A invenção provê um sistema de pagamento móvel (MPS) ousistema de pagamento móvel de pessoa para pessoa que permite transfe-rências de moeda rápidas e fáceis. Através do sistema de pagamento móvele um dispositivo de acesso tal como seu telefone celular, os usuários sãocapazes de enviar, solicitar e verificar a recepção do dinheiro, pagar por ser-viços, pagar as contas, pagar por ingressos de cinema, pagar armazéns,pagar uma babá, pagar por café e um jornal, pagar de volta um amigo, dividiruma conta de jantar, enviar dinheiro para as crianças, obter dinheiro dospais, obter dinheiro rápido ou de emergência, enviar dinheiro de emergência,pagar ou coletar uma aposta amigável, pagar por futebol de fantasia, pagarpor serviços de jardinagem, pagar por quotas de associação, rastrear com-pras, verificar o saldo e mais. Além disso, em pelo menos algumas modali-dades, cada uma dessas transações é efetuada substancialmente em temporeal, com fundos certos que ficam imediatamente disponíveis para o recebe-dor.Em uma modalidade, a presente invenção permite acesso àsredes ATM, por exemplo, a rede NYCE, para efetuar transações.
A presente invenção trata muitas das limitações acima mencio-nadas dos instrumentos financeiros da técnica anterior, incluindo o seguinte:dinheiro 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 ou quase instantaneamente utilizável demoeda, tal como, por exemplo, um cartão de débito pré-pago da companhiaou através de uma ligação na conta de depósitos sob demanda (DDA) dousuário em um banco. Necessidade que os pagamentos eletrônicos fiquemacessíveis para consumidores com ou sem contas bancárias. Necessidadeque os pagamentos eletrônicos possam ser ligados em instrumentos finan-ceiros existentes tais como crédito, débito, pré-pago, folha de pagamento eoutros. Necessidade de poder carregar e descarregar de instrumentos finan-ceiros existentes em tempo real ou em tempo quase real. Necessidade queos pagamentos eletrônicos funcionem através dos bancos. Necessidade queos pagamentos eletrônicos sejam acessíveis via dispositivos móveis. Neces-sidade que os pagamentos eletrônicos fiquem acessíveis via dispositivos demídia do consumidor tais como PCs, terminais de pagamento de POS, con-versores de freqüência de TV, DVRs, conversores de satélite e outros. Ne-cessidade que os pagamentos eletrônicos fiquem acessíveis via dispositivosde pessoa para máquina tais como máquinas de vendas, parquímetros, qui-osques e outros. Necessidade que os pagamentos eletrônicos funcionematravés de redes eletrônicas tais como portadoras móveis, portadoras a ca-bo, portadoras via satélite e outros.
Alguns dos benefícios do MPS da presente invenção incluem osseguintes: que os pagamentos eletrônicos MPS encorajam que o dinheiropermaneça no banco ao invés de nos bolsos do consumidor. Pagamentoseletrônicos MPS são seguros e podem ser rastreados. Pagamentos eletrôni-cos MPS ocorrem em tempo quase real. Pagamentos eletrônicos MPS ficamacessíveis para qualquer um, a qualquer tempo e em qualquer lugar. O MPSpode prover um cartão de débito pré-pago da companhia opcional ou nãorequerido (por exemplo, MasterCard, Visa ou outro) para a acessibilidade defundos instantânea. Pagamentos eletrônicos MPS podem ser alavancadospara transações de pessoa-2-pessoa (P2P), bem como pessoa-2-comerciante (P2M). Os fundos MPS são armazenados dentro das contasbancárias de parceiros em fundo comum distribuído. Os registros "T" para osfundos do consumidor MPS são gerenciados dentro do sistema de paga-mento MPS do registro, resultando em transferência P2P e P2M de customuito baixo, tal que pequenas transferências de moeda são economicamen-te viáveis. MPS facilita a funcionalidade de carga manual ou automática deinstrumentos financeiros existentes (por exemplo, crédito, débito, outros).MPS facilita a funcionalidade de descarga manual ou automática para ins-trumentos financeiros existentes (por exemplo, crédito, débito, outros). MPSpode otimizar o processamento de carga ou descarga (isto é, executandocarga ou descarga dentro do banco quando possível). MPS facilita os paga-mentos eletrônicos em uma maneira de banco mútuo. MPS facilita os paga-mentos eletrônicos em uma maneira de portador mútuo ou rede mútua. MPSfacilita os pagamentos eletrônicos em uma-maneira de dispositivo mútuo oucanal mútuo (isto é, móvel, e-mail, Web, mensageiro instantâneo). Os fundosMPS são eletrônicos, protegidos por PIN e "vivem" no banco.
Em uma modalidade, o sistema de transação financeira de cir-cuito fechado da presente invenção é baseado, em parte, no uso de um dis-positivo sem fio tal como um telefone celular ou um PDA para fazer ou rece-ber pagamentos. As transações financeiras podem ser conduzidas em umabase de pessoa para pessoa onde cada parte é identificada por um indicadorúnico tais como um número de telefone, endereço de e-mail, identificador detroca de mensagens instantânea ou código de barras ou em uma base deconsumidor para comerciante.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.
Em uma modalidade, a interface do consumidor pode incluir umainterface de resposta de voz interativa para tratar de solicitações provenien-tes de um canal de voz de telefone. Uma modalidade do sistema pode incluiruma conta em fundo comum para usuários recentemente registrados, ondeos usuários recentemente registrados podem conduzir as transações com osusuários registrados imediatamente depois do registro. A interface de aplica-ção do cliente móvel pode, em pelo menos algumas modalidades, permitiruma transação de "envio de dinheiro", transação de "solicitação de dinheiro",uma transação de "carga de conta", uma transação de "descarga de conta" etransação de "pesquisa de saldo". A interface do consumidor pode tambémincluir uma interface de mensageiro instantâneo para tratar de solicitaçõesprovenientes de-um-cliente de-mensageiro instantâneo.
Uma modalidade do sistema pode incluir: uma interface de par-ceiro financeiro, uma interface comercial, onde os usuários através da inter-face do consumidor podem acessar o seu dinheiro em um banco conectadoao sistema através da interface do parceiro financeiro e transferir dinheiropara comerciantes conectados à interface comercial. Uma modalidade dosistema inclui um sistema de registros gerenciado pelo sistema de transaçãofinanceira, registrando a transação executada através da interface do con-sumidor. Em algumas modalidades, o sistema pode incluir uma conta emfundo comum gerenciada pelo sistema de transação financeira, onde umnúmero dos clientes acessando o sistema através da interface do consumi-dor tem uma conta na conta em fundo comum. Um número dos clientes po-de não ter uma conta na conta em fundo comum, mas ao invés disso, teruma conta em uma instituição financeira, que tem acesso ao sistema.
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 as eta-pas-de exibir-uma primeira tela em-um mostrador de um telefone móvel paramostrar um número de opções incluindo uma primeira opção para pagar di-nheiro para um outro e uma segunda opção para solicitar informação de sal-do, com o usuário selecionando a primeira opção, exibir uma segunda telaonde o usuário insere um número de telefone alvo ou outros indícios para oqual enviar o pagamento, depois que o usuário insere o número do telefonealvo, exibir uma terceira tela onde o usuário insere uma quantia de transa-ção, depois que o usuário insere o número do telefone, exibir uma quartatela onde o usuário insere um código PIN e depois que o usuário insere ocódigo PIN, enviar de modo sem fio a informação da transação incluindo onúmero do telefone alvo, a quantia da transação e o código PIN para umservidor para processamento.
O método pode incluir as etapas de, depois que o usuário insereo número do telefone alvo, exibir uma quinta tela onde o usuário insere umamensagem opcional. O método pode incluir: com o usuário selecionando asegunda opção, enviar de modo sem-fim uma solicitação por informação desaldo para o servidor, receber informação de saldo proveniente do servidor eexibir a informação de saldo em uma quinta tela. O método pode incluir ondea primeira tela também provê uma terceira opção para solicitar pagamentode um outro. O método pode incluir onde a segunda tela tem uma terceiraopção que, com a seleção pelo usuário, provê ao usuário o acesso a um li-vro de endereços do qual o usuário pode selecionar uma entrada para usarcomo o número de telefone alvo. A informação de transação pode incluir umnúmero de seqüência gerado pelo telefone móvel para autenticar uma tran-sação. Em uma implementação, os fundos eletrônicos do usuário são manti-dos 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-Ihantes-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 de
circuito 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 deacordo 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-Iidades da presente invenção.
A figura 57 mostra um exemplo da autenticação do número deseqüê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 deacordo 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 seqüenciais de seqüência detela e de inicialização de aplicação (MCA) de acordo com uma modalidadeda presente invençã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.
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 de pessoa para pessoa, tran-sações de pagamento de pessoa para comerciante e outras transações ban-cárias. Um servidor de aplicações 107 é conectado em uma rede 109. Em-bora somente um servidor de aplicações seja mostrado, pode existir qual-quer número de servidores de aplicações em um sistema da invenção, e taisservidores podem ser distribuídos geograficamente. Tais servidores de apli-cações podem estar funcionando em uma máquina de servidor única ou umnúmero de máquinas de servidor. À medida que a carga em um servidor deaplicações aumenta, tipicamente mais máquinas serão usadas para lidarcom 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), ISDN, 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 do consumidor pode serimplementada através de uma variedade de dispositivos incluindo dispositi-vos móveis ou sem fio tais como telefones celulares ou PDA's, ou através deligações de linha ou transmitidas por fiação fixas usando, por exemplo, umnavegador conectado na Internet. A interface do consumidor pode operaratravés de qualquer protocolo adequado incluindo troca de mensagens SMS,uma aplicação IVR ou outra aplicação móvel. A interface comercial é tam-bém conectada no servidor de aplicações. Similar a interface do consumidor,pode existir qualquer número de comerciantes que se conectam no servidorde aplicação, usando qualquer dispositivo e protocolo adequados.
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 pode também ser conectada no banco de dados. O bancode dados pode incluir um sistema de registro 130 e contas em fundo comumvirtuais 134, tipicamente gerenciados pelo servidor de aplicações 107. A ins-tituição financeira pode controlar as contas em fundo comum 138. Portanto,o sistema de registro e as contas em fundo comum virtuais podem ser con-trolados separadamente das contas em fundo comum na instituição financei-ra.
Em operação, o sistema da presente invenção fica residente noservidor de aplicações 107. Um consumidor acessa o sistema através darede 109 via o seu dispositivo escolhido e seu protocolo associado. Em umamodalidade, o sistema mantém uma conta para o consumidor e o consumi-dor depositou uma soma de dinheiro na sua conta por qualquer recurso ade-quado, tais como um depósito direto, uma ligação para uma conta de bancotal como uma conta corrente ou de poupança ou um cartão de crédito. Asquantias depositadas por cada consumidor são todas mantidas em contasem fundo comum 138 na(s) instituição(ões) financeira(s), e o sistema de re-gistro mantém um registro de cada conta de consumidor individual, mesmoembora os fundos estejam em fundo comum na instituição financeira. Damesma forma, os comerciantes mantêm uma conta onde os seus fundosficam residentes na conta em fundo comum e acompanhados pelo sistemade registro. Onde as contas em fundo comum 138 são mantidas em múlti-plas instituições financeiras, contas em fundo comum virtuais 134 efetuamuma representação em tempo real dos saldos nessas contas virtuais diferen-tes 138, para permitir que consumidores e comerciantes realizem os benefí-cios das transações em tempo real e em tempo quase real, enquanto man-tendo as eficiências bancárias de permitir reconciliações menos regularmen-te, por exemplo, em uma base periódica tal como diária ou semanal. Seráreconhecido por aqueles versados na técnica que as contas em fundo co-mum não são necessárias para todas as modalidades, e ao invés disso, con-tas individuais podem ser implementadas na instituição financeira, embora osistema, de outra forma, opere substancialmente da mesma forma como pa-ra contas em fundo comum.
Se o consumidor deseja enviar dinheiro para uma outra pessoaou um comerciante, ele provê a informação apropriada via o seu dispositivode acesso, por exemplo, seu telefone celular e um registro da transação éfeito pelo sistema. Como parte da transação, a conta do consumidor é debi-tada e a conta do recebedor é creditada. Pelo fato de que os fundos são, narealidade, mantidos em uma única conta em fundo comum, não existe trans-ferência externa de fundos. No lugar disso, a única mudança é o débito e ocrédito das contas respectivas refletidos no sistema de registro, que ocorresubstancialmente em tempo real. Mesmo onde os fundos do remetente e dorecebedor são mantidos em contas em fundo comum diferentes mantidasem instituições diferentes, o sistema de registro gerencia a transferência dosfundos de modo que, da perspectiva do remetente e recebedor, a transaçãoocorreu substancialmente em tempo real. Assim, não existe uso de ACH ououtra infra-estrutura onerosa, tal como os sistemas proprietários associadoscom os cartões de crédito convencionais. Isso, por sua vez, possibilita queos usuários do sistema negociem trocas de moeda em quantias muito pe-quenas sem custos indevidos.Além disso, pelo fato de que o sistema da presente invençãotem um registro corrente dos fundos disponíveis do remetente, o recebedortem garantia de fundos certos que podem ser imediatamente acessados. Oresultado é um sistema conveniente, de custo efetivo, para transferências defundos de P2P e P2M substancialmente em tempo real em uma maneira queé equivalente a dinheiro em termos de facilidade de uso e aceitação, en-quanto provendo a verificação e a manutenção do registro dos cheques ecartões de créditos sem os retardos e incerteza associados com a reconcili-ação e outros aspectos das transferências convencionais de fundos.
As contas em fundo comum virtuais 134 podem também ser u-sadas para equilibrar os fundos mantidos nas várias contas em fundo co-mum 138, para garantir que fundos suficientes fiquem disponíveis para qual-quer transação e também para prover retorno apropriado para as instituiçõesfinanceiras parceiras que estão hospedando as contas em fundo comum138.
Um sistema da invenção pode incluir alguns ou todos os elemen-tos mostrados na figura, e pode incluir outros elementos não mostrados. Al-guns elementos podem ser divididos em blocos separados ou alguns ele-mentos podem ser incorporados ou combinados com outros elementos (porexemplo, dois blocos combinados em um único bloco). Adicionalmente, al-guns elementos podem ser substituídos por outros elementos nã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 indivíduos 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 para essastransações financeiras pode ser o dono ou o operador do servidor de aplica-ções (que é citado algumas vezes como um servidor de pagamento móvelou serviço de pagamento móvel). A seguir, consumidores (e comerciantes)sã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 para um comerciante, onde as partes têm dinheiroem instituições financeiras diferentes. O sistema de pagamento móvel facili-tará a transferê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 107. As camadas incluem um recipiente de aplicação da web doconsumidor 203, um recipiente do sistema de pagamento 206, uma camadade persistência 209 e uma camada do sistema de gerenciamento do bancode dados 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 fazer interface com tipos diferentes de clientes.Alguns exemplos das interfaces providas incluem porta SMS, porta de apli-cação de telefone, porta dos serviços da web, porta de páginas de aplicaçãoda web e porta de estrutura de aplicação da web. O codec de troca de men-sagens de telefone converte as solicitações que chegam ou que saem, ouambas, tal como SMS ou mensagens específicas do cliente ou de telefonepara o sistema. Uma arquitetura da invenção pode incluir qualquer númerodessas 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 é citada aqui por conveniência como o "siste-ma Obopay". O sistema Obopay é meramente um exemplo de uma imple-mentação de um sistema de pagamento móvel e é discutido para descrevermais facilmente vários aspectos da invenção. A invenção abrange muitasimplementações do sistema de pagamento móvel e não é limitada às imple-mentações especificas 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 302 pode ser imple-mentada como uma pluralidade de centros de dados para prover equilíbriode carga 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. Em uma modalidade, a pla-taforma 302 é implementada usando um sistema operacional com base noLinux que suporta aplicações de cliente magro incluindo navegadores taiscomo Microsoft® Internet Explorer, Netscape, Opera e Mozilla Firefox. O sis-tema operacional também suporta aplicações de cliente gordo. Em uma im-plementação, Java 2 Platform, Micro Edition (J2ME) e Microsoft.NET sãousados na plataforma do cliente móvel, bem como outras aplicações de cli-ente gordo quando necessário.
Exemplos de clientes que podem fazer interface com o sistemaincluem telefones móveis, telefones inteligentes, dispositivos de assistentedigital 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 de
computador 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 assimpor 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η, para citarapenas 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.
Software de computador, de acordo com a presente invenção,podem ser escritos em qualquer uma de várias linguagens de programaçãoadequadas tais como C, C++, C#, Pascal, Fortran, Perl, SAS, SPSS, JavaS-cript, AJAX e Java. O produto de software do computador pode ser uma a-plicação independente com módulos de entrada de dados e exibição de da-dos. Alternativamente, os produtos de software do computador podem serclasses que podem ser instanciadas como objetos distribuídos. Os produtosde software do computador podem também ser software de componente taiscomo Java Beans (de Sun Microsystems) ou Enterprise Java Beans (EJB deSun 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, XML1 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ção. O servi-dor 308 também provê a ligação para os serviços de valor adicionado provi-dos 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 faz a quitação em uma base de tempo realou tempo quase real. Com a ocorrência de uma transação P2M, a conta dousuário e a conta do comerciante são atualizadas substancialmente de ma-neira simultânea. Pelo fato de que a maior parte dos comerciantes podetambém servir como agentes de carga, os comerciantes transportam umsaldo na sua conta. O mecanismo de quitação pode ser usado para vascu-lhar uma quantia em dólar pré-estabelecida ou uma quantia em dólar acimade um mínimo para uma conta externa do banco controlada pelo comercian-te.
O mecanismo de quitação também facilita as transações de pes-soa para pessoa (P2P) por causa da capacidade de transferir fundos de umdono de conta 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 entre-ga cupons ou descontos para donos de conta provenientes dos comercian-tes participantes. Esse mecanismo também controla o uso de créditos deconta instantâ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 usado paracontrolar a exposição do câmbio estrangeiro.
O mecanismo viral 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 ele e ficarão disponíveis para ele depois que ele se inscrever.
Um aspecto de perambulação provê um ambiente de transaçãode par para comerciante onde o comerciante usa um telefone móvel paraverificar a recepção dos fundos onde o comerciante não tem acesso a umterminal que tipicamente seria usado para aceitação de cartão de crédito oudébito. Uma vantagem da presente invenção surge da segurança de nãoaceitar dinheiro e fundos garantidos contra um cheque e também provê averificação instantânea que não é possível com uma compra por cartão decrédito sem um terminal.
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. Será verifi-cado que mais do que um banco parceiro pode ser configurado tal que cadaconta pode ser vinculada a uma conta de banco em fundo comum em maisdo que um banco. Desde que a plataforma 302 sabe o saldo disponível paracada conta (a despeito do número de parceiros do banco e contas em fundocomum 306), não existe risco de fundos não estarem disponíveis quando asquitaçõ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.
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.
Além disso, os donos de conta podem pagar suas contas ou mi-nutos "top-off" através da sua conta de débito pré-paga. Isso é especialmen-te útil para donos de conta que não tem outros serviços financeiros disponí-veis para eles.
Parceiros comerciais
Vários comerciantes que tradicionalmente aceitam cartões decrédito, cartões de débito, cheques e dinheiro são motivados a aceitar a in-fra-estrutura de transferência de pagamento individualizada da presente in-venção por causa do seu baixo custo de adoção. Os comerciantes tambémtêm a oportunidade de ganhar comissões para manipular transações de con-ta pré-paga tal como ajudando os donos de conta a adicionar fundos nassuas contas. A maior parte dos comerciantes pode também prover pequenasquantias de dinheiro de troco, similar ao modelo de cartão de débito em usoatualmente.
Parceiros bancários
Através do sistema da presente invenção, os bancos podem
"mobilizar" sua base de consumidores existente com acesso instantâneo assuas contas e a capacidade de fazer pagamentos de dono de conta paradono de conta. Com essa parceria, os bancos podem também alcançar con-sumidores previamente muito caros para servir. Ao invés de incorrer na des-pesa de estabelecer um banco e aderir a um regime regulador pesado, umamodalidade da presente invenção é implementada usando as contas emfundo comum nos bancos participantes, onde os sistemas lidam com as co-berturas de frente e relatam posições líquidas para ou em nome dos seusbancos parceiros, mas permitem que os bancos conduzam a quitação final.Isso possibilita a concordância com as regulamentações governamentais epermitir a coexistência ativa com o ambiente bancário. Pelo uso de bancosparceiros e contas de banco associado, a infra-estrutura do sistema de pa-gamento é projetada para aumentar as contas bancárias existentes dos do-nos de conta sempre que possível, porém agir como uma conta discretaquando necessário. Todos os fundos representados por contas de débitopré-pagas individuais são mantidos em contas de banco comercial mantidasem crédito para os donos da conta. No fim de cada dia de negócios, o saldoagregado de todas as contas iguala o saldo bancário. Em uma modalidade,todas as transações criadas dentro de um período de vinte e quatro horasserão quitadas dentro desse período, embora em outras modalidades, o pe-ríodo de quitação possa variar e possa, por exemplo, ser semanal, mensalou qualquer período regular ou irregular. As contas funcionam como umacarteira com dinheiro onde o saldo muda imediatamente. Em outras pala-vras, a presente invenção não funciona como um depósito por demanda noqual os instrumentos podem ser apresentados por um terceiro. Em pelo me-nos algumas modalidades, os donos de conta não são capazes de emitirinstrumentos por demanda tal como cheques. Como um resultado, não exis-tem transações pendentes que quitam em uma data futura, o que novamenteassegura que fundos certos sejam providos para o recebedor em qualquertransação.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. O 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. Alternativamente, o códigode barras pode ser impresso no dispositivo ou pode ser de outra forma presono 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, um 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. Alternativamente, o usuário carrega a aplicação a-vançando para um URL específico usando o navegador de Internet móvel dousuário (por exemplo, get.obopay.com) que começará o processo de carre-gamento 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, pela ligação com a rede de ATM, tal como a rede NYCE, os donos daconta podem obter dinheiro da sua conta de débito pré-paga usando umATM.
Para os donos da conta, concluir uma transação financeira éperfeitamente coerente. Em uma implementação na qual o dispositivo dousuário é um telefone celular, os fundos são transferidos simplesmente envi-ando uma mensagem do telefone móvel equipado com a aplicação do clien-te móvel para um servidor. O servidor de pagamento valida cada transação etransfere 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 PDAs, SMS expõe senhas não criptografadas ounúmeros de identificação pessoal (PINs), bem como a informação de saldoou 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, modalidades dapresente invenção não usam troca de mensagens SMS para enviar PINs.Dessa maneira, em uma modalidade, provê a iniciação da transação finan-ceira por meio da mensagem de texto SMS. A mensagem SMS começa comuma palavra-chave que provê o tipo de transação solicitada - PAGAMENTO,SOLICITAR PAGAMENTO, SALDO, TRANSFERENCIA ou AJUDA. Em umaimplementação, "PAGAMENTO" é citado como "ENVIAR" e "SOLICITARPAGAMENTO" é citado como "OBTER".
Onde a mensagem SMS contém a palavra chave que indica odesejo de transferir fundos de um dono de conta para um outro dono de con-ta, a palavra-chave pode ser pagamento ou solicitar pagamento (ou enviarou obter). Depois da palavra-chave, a quantia é inserida com ou sem umponto decimal. Depois da quantia, o número do telefone alvo (ou código cur-to, endereço de e-mail, número de licença ou outra informação de identifica-dispositivo móvel. Depois do número de telefone, o dono da conta pode inse-rir uma 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ódigoalfanumé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 outra modalidade alternativa, quando um canal de vozestá disponível, a aplicação do cliente móvel invoca um módulo para codifi-car o PIN na forma DTMF. O DTMF é então enviado pela aplicação do clien-te móvel para o servidor de pagamento junto com uma conexão de canal devoz estabelecida pela aplicação do cliente móvel. O módulo pode ser umaAPI Java 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, em uma tal modali-dade, esse problema é controlado enviando uma mensagem para o dono daconta deletar a mensagem enviada da pasta de registro de SMS. Alternati-vãmente, tais instruções podem ser providas para o usuário através de ajudae informação do FAQ. Essas instruções podem também sugerir que o donoda conta desative o registro de mensagens das mensagens SMS que saemquando 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 convideuma outra pessoa a se unir ao sistema. A pessoa que faz a referência ou oreferido, ou ambos, pode obter uma bonificação de referência. O dono daconta insere a palavra-chave junto com a informação adicional no corpo damensagem de texto para construir um comando que é então enviado para oservidor de pagamento. O acesso para o servidor de pagamento pode serpor meio de um número de telefone isento de cobrança, um código curto ouum endereço de e-mail, todos os quais identificam o servidor de pagamentopara o sistema de troca de mensagens de texto SMS. Um exemplo de umcódigo curto é 62729 que é usado como o número de telefone alvo para oscomandos de mensagem de texto do dono da conta para o servidor de pa-gamento. Um exemplo de um endereço de e-mail é sms@obopay.com que éo alvo de e-mail para comandos de mensagem de texto SMS enviados parao servidor de pagamento.
Para enviar um pagamento para uma outra pessoa ou um co-merciante usando o método SMS, o dono da conta insere a seqüência decomando mostrada na tabela A.
Tabela A
<table>table see original document page 42</column></row><table>
Em alguns arranjos, cada item tem um espaço entre ele e o itemprévio. Em uma implementação, a palavra-chave não é sensível ao caso. Onúmero móvel pode incluir o código de área mais o número móvel sem es-paços presentes no número móvel. O dono da conta pode inserir um 1 nafrente ou não no número de telefone. Um sinal de dólar não precisa ser inse-rido com a quantia, mas é permitido. Opcionalmente, o usuário pode incluiruma 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 42</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 têm sistemas para processar as transações financeiras. Cada centro dedados contém uma combinação de tecnologia PBX/ACD/VRU para permitirmúltiplos processamentos simultâneos de chamada. A tecnologia VRU podeser usada para prover suporte DTMF que chega e que sai programável. OVRU pode ser conectado em um sistema J2EE empreendedor que represen-ta a lógica de negócios atual e sistema de registro para as transações finan-ceiras. O sistema J2EE pode então integrar com bancos atuais para quita-ção das transações. Em uma implementação, existe uma opção de senha deuma vez para segurança SMS como uma opção que funciona, por exemplo,com o usuário enviando a transação sem um PIN e a seguir o sistema enviaao 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 parapessoa)
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 receptorse registra para sua própria conta de débito pré-paga. Essa troca de mensa-gens viral torna fácil para os usuários sem conta se tornarem por eles pró-prios donos de conta registrados. Se o dispositivo móvel usado pelo usuáriosem conta suporta um navegador WAP ou da Internet móvel, então o alista-mento pode ocorrer imediatamente através do telefone. O usuário tambémtem a opção de se alistar no serviço usando a web, um quiosque, em pessoaem um parceiro comercial ou através de um outro dispositivo.
A flexibilidade da presente invenção possibilita novos métodosde seleção e identificação de partes para uma transação. Em uma modali-dade, o pagador digita um número de telefone ou outro código de identifica-ção no teclado do seu dispositivo móvel. Um código de identificação podeser um "código curto" especial de três, quatro ou cinco dígitos que é transla-dado para uma conta específica pelo provedor de serviços móveis. Por e-xemplo, se um dono de conta deseja carregar um programa de televisãodisponível por uma rede de televisão, o dono da conta digita um código curtode 227 para pagar a rede pelo conteúdo desejado. O código curto pode usarqualquer seqüência de caractere alfanumérico. Em um tal arranjo, é desejá-vel que os recebedores adquiram 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 deendereç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çodo 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 usa afunção de câmera do dispositivo móvel para adquirir uma imagem que identi-fica o recebedor. Um exemplo de uma imagem seria um código de barras.
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 um
comerciante 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óvel
ou
(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 e assim por diante) e o dono da conta pode transferir fundos emtempo real de uma conta para uma outra sem qualquer acesso a um centrode serviços e sem qualquer acesso da Internet ou computador. Vantajosa-mente, o dono da conta pode selecionar a conta da qual os fundos são obti-dos para fazer uma compra em tempo real.
Em uma outra modalidade da invenção, os donos da conta con-tribuem para uma conta mestre mantida por um parceiro do banco. Em qual-quer tempo o dono da conta pode sacar a sua contribuição completa semqualquer penalidade. Em alguns arranjos, a conta mestre é de suporte departicipação e o parceiro bancário é compensado por gerenciar o sistema depagamento com a participação que acumula na conta.
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 acessar certos serviços. Dessa maneira, a renda é ge-rada cobrando uma pequena taxa por transação para enviar dinheiro. Emuma modalidade exemplar, a taxa por transação varia de uns poucos centa-vos por transações sob uma quantia selecionada tal como $25. Para ilustrarmais, a taxa "por transação" pode variar de $0,05 a aproximadamente $0,10por transação em modalidades alternativas, embora qualquer taxa possa 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 algumas ou todasas transações, por exemplo, para pequenas quantias de transação. Assim,não existiria taxa "por transação" quando pequenas compras são feitas u-sando a infra-estrutura de transferência de pagamento.
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, modalidades da presente invenção considerammúltiplos modelos diferentes de geração de renda, especificamente, (1) umataxa "por transação" é tributada contra uma ou ambas as partes em umatransação financeira. De preferência, a quantia da taxa é nominal variandode aproximadamente um centavo a aproximadamente $0,15, (2) plano depreço mensal de taxa fixa onde cada dono de conta pagaria uma despesa deserviço mensal, (3) taxa de transação para valor alto para transações acimade uma quantia selecionada, tal como por meio de ilustração, $50, a taxadesconsiderada para todas as outras transações e (4) serviços de valor adi-cionado, tal como vinculando a um serviço de contabilidade para automati-camente gravar detalhes da transação ou ajudar a preparar declarações deimposto de arquivamento. Alternativamente ou adicionalmente, a renda podeser gerada pela coleta de participação nas contas em fundo comum.
A figura 4 mostra uma outra implementação de um sistema dainvenção. A figura 4 mostra uma modalidade onde os serviços de valor adi-cionado são usados entre dois donos de conta. Por meio de exemplo, se umdono de conta associado com o dispositivo móvel 401 inicia uma transferên-cia para o dispositivo móvel 402, a solicitação de pagamento é transferidapara a plataforma do servidor 403 como indicado pela seta de referência404. A solicitação de pagamento pode incluir uma descrição opcional do pa-gamento. Por exemplo, o dono da conta pode anotar o pagamento para re-presentar que ele foi um item da conta de despesa. A descrição pode serselecionada de um menu exibido no dispositivo móvel 401. Alternativamente,a descrição pode ser uma mensagem de voz ou texto associada com a soli-citação de pagamento.
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 acessa a informação descre-vendo as suas compras que é armazenada e organizada pelo serviço demanutenção de conta e registro 411 via o dispositivo móvel 401 ou por umaoutra conexão da Internet (não mostrada).
O presente sistema também facilita os processos mais automati-zados de faturamento e contabilidade. Na técnica anterior, um pequeno ne-gócio usa um programa de contabilidade (que pode ser armazenado em umcomputador pessoal) para imprimir uma fatura em papel que ele envia para oseu consumidor. O consumidor deve então pagar Ό pequeno negócio, o queé, na técnica anterior, freqüentemente feito por cheque. Depois que o che-que é recebido, o pequeno negócio precisa associar o número da conta como cheque. Se o número da conta não está escrito no cheque, e uma cópia dafatura não é enviada com o cheque, tempo é desperdiçado tentando combi-nar o pagamento com uma cópia da fatura. Depois de combinado, o peque-no negócio deposita o cheque no seu banco e manualmente insere os dadosno seu programa de contabilidade recebível de contas. Claramente esseprocesso antiquado é lento, trabalhoso e caro para suportar.
Entretanto, com a presente invenção, o pequeno negócio precisasomente selecionar uma opção de fatura que exporta a fatura do programade contabilidade para, por exemplo, um formato OFX ou outro formato deimportação/exportação legível por um programa de contabilidade. Essa fatu-ra eletrônica é então enviada para a plataforma de pagamento (ver figura 3).A plataforma de pagamento cria uma mensagem de "solicitação de paga-mento" que é enviada para o consumidor. Quando o consumidor aprova opagamento 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 Verizon, Cin-gular (AT&T), Sprint, Nextel, Alltel, Virgin Mobile, Amp'd Mobile, U.S. Celluar,T-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, possibilita uma solução de pagamento"fora da nota" que ajudará a aliviar o problema da surpresa da "grande con-ta".
O sistema de pagamento móvel possibilita 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 incluem carga e descarga pela rede decaixa eletrônico (ATM) tal como através do sistema NYCE, PLUS ou STARATM. O sistema pode também incluir integração de pagamento de conta,onde um usuário pode pagar contas tais como uma conta a cabo, conta deeletricidade, conta de serviço da Internet, conta de telefone, conta do serviçode manutenção de casa e outras contas via sua interface selecionada, porexemplo, seu telefone celular.
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 por um parceiro financeiro ou contro-lada 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 ou diretamente para odono da conta via, por exemplo, a rede de ATM. Por exemplo, um usuáriopode descarregar fundos da conta do sistema de pagamento móvel do usuá-rio para uma conta corrente ou cartão de crédito.
O carregamento e o descarregamento podem ser executadosem qualquer uma das maneiras discutidas nesse pedido incluindo através deAGH, 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 dos parceiros e ser-viços discutidos acima. Por exemplo, um sistema pode não ter parceiro, so-mente um único parceiro, dois parceiros, três parceiros ou mais do que trêsparceiros. Um sistema pode incluir um parceiro bancário único provendo umcartão de débito somente (isto é, sem cartão de crédito) para acesso pelosclientes móveis. Um sistema pode incluir um único parceiro bancário pro-vendo um cartão de débito e um cartão de crédito para acesso pelos clientesmóveis. Um sistema pode incluir dois ou mais parceiros bancários, um pro-vendo um cartão de débito e um outro provendo um cartão de débito diferen-te para acesso pelos clientes móveis. Um sistema pode incluir dois ou maisparceiros bancários, um provendo um cartão de débito e um outro provendoum cartão de débito diferente e um cartão de crédito para acesso pelos cli-entes móveis. Um sistema pode incluir um único parceiro bancário provendoum cartão de crédito somente para acesso pelos clientes móveis. Um siste-ma pode incluir um único parceiro bancário provendo um cartão de créditosomente 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 incluem (1) um nível de participação, (2) qualprocessador (por exemplo, qual parceiro financeiro), (3) definições de veloci-dade, (4) contas vinculadas ou qualquer combinação desses. O sistema po-de incluir qualquer número de definições de parâmetro em um perfil do usuá-rio, e 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 é basea-do em uma série de fatores tal como qual informação foi provida quando ousuário fez o alistamento, quanto dinheiro o usuário tem na conta do usuário,quantas referências o usuário fez, quantas transações o usuário fez ou ototal de dólares negociados. Essa definição de perfil é atualizada periodica-mente à medida que nova informação é coletada. Alguns exemplos de no-mes de nível de participação para um usuário podem ser níveis "bronze","ouro", "prata" e "platina". O nível de participação pode ser visível para o u-suário e pode ser usado para construir a lealdade do consumidor. Em outrasmodalidades da invenção, o nível de participação pode ficar oculto ou deoutra 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. Em pelo menosalgumas modalidades, isso é o mínimo requerido para abrir a conta. Ao usu-ário é dada a opção de prover outras informações, tais como endereço de e-mail, número do cartão de crédito, número do seguro social (por exemplo,para uma verificação de crédito), número da conta corrente e assim por dian-te. Em uma implementação da invenção, quanto mais informação o usuárioescolhe revelar, tanto maior o nível de participação com o qual o usuário épremiado.
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 oudinheiro viral foi enviado. Viral se refere ao envio ou recepção de dinheiroonde um dos usuários não havia previamente se registrado com o sistema.Um usuário viral pode também ser citado como um usuário não membro ouusuário não registrado. Viral se refere a uma característica do sistema depagamento móvel da invenção que encoraja ou permite que usuários atuaisnegociem com usuários não membros. À medida que mais usuários se regis-tram e usam o sistema, os usuários ajudarão a espalhar as notícias e trazerusuários adicionais. Por exemplo, a fim de que um usuário não membro re-ceba o dinheiro, o não membro é encorajado ou obrigado a se alistar comoum membro.
Para o estado inscrito, o usuário inseriu informação básica, talcomo um telefone confirmado. O telefone pode ser confirmado pelo sistemaem qualquer maneira adequada, incluindo chamando o número de telefoneprovido pelo usuário no alistamento. Essa chamada pode ser uma chamadaautomática ou do tipo IVR. Pode existir um incentivo para o usuário se alis-tar, tal como o usuário recebendo dinheiro (por exemplo, $5) que é colocadona conta do usuário. O incentivo pode ser referido como uma bonificação dereferência e pode ser qualquer quantia. A bonificação de referência pode serpaga somente para quem fez a referência, somente para o referido ou paraambos. Depois de inscrito, o usuário pode receber 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 se aliste com umparceiro bancário particular para receber um cartão, tal como um cartão dedébito pré-pago. Em outras modalidades, o cartão pode ser um cartão decrédito. Nessa implementação, o usuário no estado avançado será capaz defazer qualquer coisa que um usuário verificado pode mais ser capaz de ins-tantaneamente gastar dinheiro sempre que o cartão for aceito. Dependendoda instituição que emite o cartão, o cartão pode ser aceito ou utilizável atra-vés de uma ou mais redes incluindo Visa, MasterCard, American Express,NYCE, PLUS ou STAR, ou qualquer combinação desses. O cartão é vincu-lado à conta do usuário. Um usuário sem um cartão é um usuário "sem car-tão", enquanto um usuário com um cartão é um usuá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. Contas de banco vinculadas podem ser verificadas usan-do depósitos de desafio. Por exemplo, o sistema pode fazer um número depequenos depósitos na conta do usuário. O usuário informa ao sistema aquantia desses depósitos como verificação que eles são autorizados a usara conta vinculada. Alternativamente, o usuário pode verificar através de umaverificação de conta instantânea em linha, onde um usuário provê um nomee senha na tela em linha. A adição de um cartão de crédito ou débito podetambém ser verificada usando depósitos de desafio. Alguns cartões tais co-mo Visa e MasterCard podem ser alternativamente verificados usando códi-gos de seguranç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. Limites rígidos elimites flexíveis podem ser usados, onde 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 a ou saberá a velocida-de da definição da participação. Entretanto, em certas implementações, ousuário é informado com a velocidade da informação de participação, talcomo 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. Em um arranjo típico,existe uma âncora (por exemplo, tal como um número de conta) para o usu-ário e quaisquer identidades adicionais são associadas com essa âncora.Essas identidades podem incluir múltiplos números de telefone, endereço dee-mail, identificadores de mensageiro instantâneo e assim por diante. O u-suário não precisaria saber o número da conta ou âncora para acessar aconta. O usuário é capaz de acessar a conta do usuário através de qualqueruma das identidades associadas.
Além do mais, em uma implementação, para adicionar identida-des a uma conta, o usuário valida cada uma das novas identidades. Issopode ser feito através de uma chamada de autenticação IVR ou responden-do a uma mensagem SMS no caso de um número de telefone. Para um e-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 pode 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 enviada por qualquer uma das maneiras discu-tidas nessa patente. (2) O sistema de pagamento móvel atualiza os registros"T" 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 uma implementação de um pagamento depessoa para pessoa de banco mútuo. Essa figura mostra um consumidor Aenviando dinheiro para o consumidor B, onde os consumidores são mem-bros de parceiros bancários diferentes. O consumidor A tem fundos em umaconta gerenciada pelo banco Aeo consumidor B tem fundos em uma contagerenciada pelo parceiro bancário Β. O sistema de pagamento móvel da in-vençã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 do banco Apara a conta de giro do banco A. (3) O sistema de pagamento móvel transfe-re fundos da conta de giro do banco B para a conta em fundo comum dobanco B. (4) O sistema de pagamento móvel atualiza os registros T no sis-tema de registro do sistema de pagamento móvel para debitar a conta doconsumidor A e creditar a conta do consumidor B. (5) O sistema de paga-mento móvel notifica o consumidor B sobre o pagamento. (6) O sistema depagamento móvel periodicamente faz a quitação entre os bancos parceirosAeB. Essa quitação pode ocorrer em qualquer período de tempo periódico.Ao invés de tempo real, a quitação pode ser executada em um modo de lote.Por exemplo, ela pode ser executada uma vez a cada 24 horas. Os períodosnão têm necessariamente que ser períodos de tempo iguais, mas podem serperíodos de tempo diferentes. Também será verificado que a seqüência po-de variar, particularmente com relação às etapas de débito, crédito e notifi-cação. Por exemplo, em um arranjo alternativo, um controle pode ser colo-cado nos fundos na conta do consumidor A, o consumidor B é notificado eentão as transferências de fundos ocorrem. A seqüência particular não écrítica contanto que a existência de fundos certos pode ser garantida emcada etapa.
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 fundos para a conta do sistema de pagamento móvel dousuário de uma conta corrente ou cartão de crédito.
Um fluxo básico dessa transação é: (1) o consumidor A enviauma solicitação de "carga" para o sistema de pagamento móvel indicandoque os fundos devem ser retirados de um instrumento de crédito ou débitovinculado. (2) (a/b) o sistema de pagamento móvel submete a transação docartão de crédito em tempo real (CC)/DDA (fundos certos). (3) O sistema depagamento móvel transfere os fundos da conta de giro para a conta em fun-do comum. (4) O sistema de pagamento móvel atualiza os registros T para oconsumidor A no sistema de registro do sistema de pagamento móvel. (5) Osistema de pagamento móvel periodicamente executa o gerenciamento decaixa. Esse gerenciamento pode ocorrer em qualquer período de tempo pe-riódico. Por exemplo, ele pode ser executado uma vez a cada 24 horas. Co-mo declarado acima, os períodos não têm necessariamente que ser perío-dos de tempo iguais.
Um exemplo específico de uma carga de cartão de crédito étambém mostrado na figura 8. Da web, um usuário insere um número decartão de crédito para carregar $300 no cartão MPS do usuário. O MPS ob-tém uma autorização de $300, por exemplo, do Pay-By-Touch (PBT) para atransação do cartão de crédito. O MPS envia uma mensagem para o parcei-ro financeiro suportando o cartão MPS iniciando um pagamento de $300 depessoa para pessoa da conta do cartão de crédito MPS para a conta do car-tão de débito do usuário. A conta do usuário é imediatamente creditada comfundos. PBT quita a transação do cartão de crédito e envia uma transferên-cia por ACH dos $300 para a conta de quitação do MPS no banco do MPStratando da conta de quitação. O MPS envia uma transferência por ACH dos$300 para a conta mestre do cartão de crédito MSP para reabastecer osfundos.
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 um instru-mento de crédito vinculado como o destino. (2) O sistema de pagamentomóvel submete a transação DDA em tempo real (fundos certos). (3) O sis-tema de pagamento móvel transfere os fundos da conta em fundo comumpara a conta de giro. (4) O sistema de pagamento móvel atualiza os registrosT para o consumidor A no sistema de registro do sistema de pagamento mó-vel. (5) O sistema periodicamente executa 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.
Como discutido previamente, em pelo menos algumas modali-dades do presente sistema de pagamento de pessoa para pessoa, membrosexistentes do sistema de pagamento podem enviar fundos para não mem-bros (que podem também ser citados como usuários não registrados) com aintenção que o não membro se torne um membro. Essa capacidade de umsistema de pagamento pode ser citada como "viral" porque ela estimula asinscrições de novo membro. Alguns elementos da capacidade viral incluem oseguinte, que não são listados em qualquer ordem particular.
(1) Um sistema de pagamento permite que membros existentesenviem fundos para não membros via algum identificador único ou "id". Esse
identificador ú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 Iicen-ça, nome de usuário do mensageiro instantâneo e outros. O identificadorpode ser selecionável 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.
(3) Na eventualidade que o membro existente escolha enviar osfundos para um não membro, o sistema de pagamento notifica o não mem-bro que fundos foram enviados para ele. A notificação pode ser feita porqualquer um dos mecanismos de comunicação geralmente disponíveis, taiscomo e-mail, telefone, SMS, IM e outros.
(4) O sistema de pagamento permite que o não membro "convi-dado" aceite ou recuse os fundos que o membro existente tentou enviar.
(5) Se o não membro convidado decide aceitar os fundos domembro existente, então o sistema de pagamento provê a capacidade donão membro se registrar, novamente usando mecanismos de comunicaçãogeralmente disponíveis, tais como e-mail, telefone, SMS, IM e outros.
(6) Para completar a transação viral, o sistema de pagamentofinalmente facilita uma transferência de fundos da conta do membro existen-te para a conta do novo membro.
Abaixo estão várias modalidades das técnicas para execução detransferências de fundos virais dentro de um sistema de pagamento. Nosexemplos abaixo, Obopay é usado como um exemplo de um sistema de pa-gamento específico, mas outros sistemas de pagamento podem ser usados.Um sistema de pagamento pode ser chamado ou conhecido por qualquernome. O sítio da web obopay.com é especificamente identificado, mas qual-quer sítio da web apropriado, nome de sítio da web ou endereço IP pode serusado. Também, a invenção pode ser usada no contexto de outras infra-estruturas de rede, não apenas a Internet. Esses exemplos são além dosexemplos discutidos previamente.
Modalidade 1A - financiamento automático
A conta do usuário B não registrado é automaticamente financi-ada com o alistamento como o resultado das etapas abaixo:
1. O membro existente usuário A decide convidar o usuário nãomembro B a se unir enviando dinheiro para o usuário B, onde o usuário Btem que se inscrever como um membro para reivindicar os fundos.
2. O usuário A envia um pagamento para o usuário B inserindo onúmero de telefone móvel do usuário Bea 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 o usuário B é debitado da contade A e é mantido em suspense da inscrição pendente do usuário B.
6. O usuário B recebe uma mensagem dizendo que o usuário Aenviou dinheiro para ele e que o usuário B pode obter o dinheiro fazendo ainscrição.
7. O usuário B se inscreve no sítio da web do sistema de paga-mento ou outra interface.
8. Depois que o usuário B se inscreve com sucesso, a conta dousuário B é automaticamente financiada com o pagamento do usuário A.
Modalidade 1B - solicitação de pagamento
A figura 10 mostra um sistema de pagamento e um pagamentode pessoa para pessoa, onde o usuário não membro deve solicitar o paga-mento oferecido com o alistamento como descrito pelas etapas seguintes.
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 o usuá-rio B inserindo o número de telefone móvel e a quantia em dólar do usuárioΒ. O sistema não distingue inicialmente entre pagamentos enviados paramembros e não membros.
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 o usuário Aconvidou o usuário B para se unir ao sistema de modo que o usuário A pos-sa enviar dinheiro para o usuário B.
7. O usuário B se inscreve no sítio da web do sistema ou outrainterface.
8. Depois que o usuário B se inscreve com sucesso, o usuário Bé notificado que o usuário A deseja enviar dinheiro para ele e que o usuárioB pode fazer uma "solicitação de pagamento" pelo pagamento. Se o usuárioB concorda, uma transação de "solicitação de pagamento" pré-preenchida éexibida para o usuário B com o número do telefone de A e a quantia de pa-gamento 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 do usuário A e creditado naconta do usuário Β. O usuário B é notificado.
Modalidade 2 - Fundos reservados pessoais virais - membrosexistentes podem separar fundos que são reservados para pagamentos vi-rais. Por exemplo, um usuário pode reservar um certo número de dólares naconta do usuário para quitar as transações virais. Esses fundos não ficarãodisponíveis, de outra forma, para o usuário para uso em transações não vi-rais (por exemplo, gasto pelo cartão de débito). Em uma implementação, ousuário pode mudar a quantia reservada através de uma função de manu-tenção de conta do usuário.
Modalidade 3 - Viral coloquial - O ciclo de vida viral completoocorre em tempo real com ambas as partes sendo notificadas das "etapas"do outro ao longo do caminho. A transferência de fundos final é então sim-plesmente uma transferência entre dois membros.
Modalidade 4 - Viral promissor - O membro existente prometepagar o membro convidado se e quando ele se registrar. Os fundos domembro existente são reservados para o pagamento de seguimento depoisque o membro convidado se registra.
Modalidade 5 - Fundos divididos virais - O sistema de pagamen-to incentiva membros existentes a fazerem pagamentos virais oferecendouma divisão de fundos onde o sistema de pagamento iguala a quantia depagamento via quantias fixas ou de porcentagem.
Modalidade 6 - Solicitação de fundos virais - Ao invés do mem-bro existente enviar fundos para um não membro, o membro existente solici-ta fundos de um não membro.
Modalidade 7 - Negociação - o usuário existente A deseja envi-ar fundos para o usuário não membro Β. O usuário A solicita enviar os fun-dos usando um identificador adequado para o usuário Β. O usuário B é noti-ficado do pagamento pendente e convidado a se registrar como um membro.Além disso, é dada ao usuário B a opção de negociar um ou mais termos datransação com o usuário A. Os termos negociáveis podem incluir a quantiada transferência, o banco no qual a conta será estabelecida, uma divisãodas taxas de referência e assim por diante. Em um arranjo alternativo, épermitido que o usuário A selecione quais termos ele estaria desejando ne-gociar com o usuário B, em parte para encorajar o usuário B a se registrar.
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 uma modalidade de um sistema da inven-ção, o usuário A envia fundos para o usuário B via um identificador único ouID. O identificador único pode ser comumente disponível. Exemplos incluemnúmeros de telefone (por exemplo, linha terrestre, voz através de IP, telefo-ne móvel, paginador ou fax), endereço de e-mail, número do seguro social,número da conta, número da placa de licença, nome de usuário do mensa-geiro instantâneo e outros. Esse identificador pode ser usado para contatarum usuário independentemente de passar através do sistema da invenção(por exemplo, um número de telefone ou endereço de e-mail onde um usuá-rio pode ser contatado diretamente, sem envolver o sistema).
Cada identificador único pode ser associado com somente 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, em algu-mas implementações, verifica o número do PIN, valida a conta e verifica osaldo para a conta do usuário A. Na eventualidade que a conta do usuário Acareça de fundos suficientes para a transação financeira, o sistema enviauma notificação eletrônica para o usuário A avisando dos fundos insuficien-tes. Se a conta do usuário A tem fundos suficientes para a transação, o sis-tema também notifica o usuário B da transação pendente via qualquer liga-ção adequada, incluindo tecnologia móvel. Devido às notificações eletrôni-cas imediatas que os usuários AeB receberam, eles perceberão que a tran-sação financeira ocorreu quase instantaneamente, ou em tempo real outempo quase real.
Em uma modalidade, o sistema pode permitir que os usuáriosestabeleçam preferências com relação à aceitação das transações. Se ousuário B selecionou uma definição de aceitação automática (selecionadaquando um usuário se registra no sistema) para automaticamente aceitar ospagamentos, os fundos são transferidos da conta do usuário A para a contado usuário B imediatamente. Se o usuário B selecionou uma definição deaceitação manual, os fundos são transferidos somente depois que o usuárioB aprova a transação. O sistema pode também incluir uma definição parausuários ditarem que eles somente aceitarão transações de membros espe-cificados, ou ao contrário, eles não aceitarão pagamentos de membros es-pecificados.
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, pelo me-nos algumas modalidades do sistema podem ser configuradas para automa-ticamente cancelar a transação. Em um tal arranjo, o sistema então envianotificações eletrônicas para ambos o usuário Aeo usuário B notificando-osda transação cancelada. O usuário B também tem a opção de rejeitar a tran-sação, em cujo caso o usuário A é notificado do pagamento recusado atra-vé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. Em algumas modalidades, dependendo damaneira na qual as contas são mantidas, a conclusão da transação pode serretardada devido aos retardos inerentes no sistema de transação financeiraeletrônico.
Alguns exemplos específicos de fluxos são apresentados nessepedido. Entretanto, deve ser entendido que a invenção não é limitada ao flu-25 xo e etapas específicas apresentadas aqui. Um fluxo da invenção pode teretapas adicionais, que não são necessariamente descritas nesse pedido, ouetapas diferentes que substituem algumas das etapas apresentadas, ou me-nos etapas ou um subconjunto das etapas apresentadas ou etapas em umaordem diferente do que apresentado ou qualquer combinação desses.
Além do que, as etapas em outras implementações da invençãonão precisam ser exatamente as mesmas que as etapas apresentadas. Co-mo um exemplo específico, o identificador único ou eletrônico (ID) é descritocomo o número móvel do usuário B por conveniência de ilustração. Em ou-tras modalidades da invenção, o identificador não é limitado ao número detelefone do usuário B. Alternativamente, o identificador pode ser o nome deusuário do mensageiro instantâneo do usuário B, endereço de e-mail ouqualquer outro identificador adequado.
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áriosAeB 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 não serão enviadas ecombinações desses.
A figura 11 mostra uma modalidade de um método para executaruma transação entre um membro com um cartão e um usuário não registra-do. Esse fluxo inclui as seguintes etapas: (1) membro A envia uma solicita-ção de "pagamento" para o servidor do serviço de pagamento móvel com onão membro B como alvo. (2) O serviço de pagamento móvel identifica aorigem como membro, valida a conta do membro A, verifica o saldo e verificao PIN. (3) O serviço de pagamento móvel identifica o alvo como um nãomembro. (4) O serviço de pagamento móvel notifica o membro de origem Ado pagamento. (5) O serviço de pagamento móvel notifica o não membroalvo B do pagamento. (6) (a/b) O serviço de pagamento móvel debita a contade cartão do membro e credita a conta em fundo comum viral. (7) (a/b) Oserviço de pagamento móvel registra a transação de débito do membro deorigem e registra a transação de crédito viral do alvo. As etapas 6 e 7 podemser encadeamentos secundários assíncronos do servidor. Isso significa queessas ações em uma modalidade ocorrem de maneira assíncrona. O servi-dor solicita as ações, mas elas não são necessariamente executadas pelopróprio servidor, então a conclusão das ações é independente do processodo servidor que chama.
A figura 12 mostra um método alternativo para executar umatransação entre um membro sem um cartão e um usuário não registrado.Essa modalidade inclui as seguintes etapas: (1) membro A envia uma solici-tação de "pagamento" para o servidor do serviço de pagamento móvel com onão membro B como o alvo. (2) O serviço de pagamento móvel identifica omembro A como um membro, valida a sua conta, verifica o seu saldo e veri-fica o seu PIN. (3) O serviço de pagamento móvel identifica o alvo como nãomembro. (4) O serviço de pagamento móvel notifica o membro de origem Ado pagamento. (5) O serviço de pagamento móvel notifica o não membroalvo B do pagamento. (6) (a/b) O serviço de pagamento móvel debita a contaem fundo comum 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 do mem-bro de origem e registra a transação de crédito viral do alvo. As etapas 6 e 7podem 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 paraessa modalidade inclui: (1) membro A envia a solicitação de "pagamento"para o membro B. (2) O serviço de pagamento móvel identifica a origem Acomo membro, valida a conta, verifica o saldo e verifica o PIN. (3) O serviçode pagamento móvel identifica o alvo B como membro e valida a conta. (4) Oserviço de pagamento móvel notifica o membro de origem A do pagamento.(5) O serviço de pagamento móvel notifica o membro alvo B do pagamento.(6) (a/b) O serviço de pagamento móvel registra a transação de débito domembro A e registra a transação de crédito do membro Β. A etapa 6 podeocorrer usando um encadeamento 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 paraessa modalidade inclui: (1) membro A envia a solicitação de "pagamento"para o servidor do serviço de pagamento móvel com o membro B como alvo.(2) O serviço de pagamento móvel identifica a origem A como membro, vali-da a conta, verifica o saldo e verifica o PIN. (3) O serviço de pagamento mó-vel identifica o alvo B como membro e valida a conta. (4) O serviço de pa-gamento móvel notifica o membro de origem A do pagamento. (5) O serviçode pagamento móvel notifica o membro alvo B do pagamento. (6) (a/b) Oserviço de pagamento móvel debita a conta de cartão do membro A e creditaa conta de cartão do membro B. (7) (a/b) O serviço de pagamento móvelregistra a transação de débito do membro A e registra a transação de créditodo membro B. As etapas 6 e 7 podem ser encadeamentos secundários as-sí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 para essamodalidade inclui: (1) membro A envia a solicitação de "pagamento" para oservidor do serviço de pagamento móvel com o membro B como alvo. (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 debita a conta de cartão do membro A e credita a con-ta em fundo comum do membro. (7) (a/b) O serviço de pagamento móvelregistra a transação de débito do membro A e registra a transação de créditodo membro B. As etapas 6 e 7 podem ser encadeamentos secundários as-sí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 para essamodalidade inclui: (1) membro A envia a solicitação de "pagamento" para oservidor do serviço de pagamento móvel com o membro B como alvo. (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 debita a conta em fundo comum do membro e credita aconta de cartão do membro B. (7) (a/b) O serviço de pagamento móvel regis-tra a transação de débito do membro A e registra a transação de crédito domembro B. As etapas 6 e 7 podem ser encadeamentos secundários assín-cronos do servidor.A figura 17 mostra um método para registro de 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 para ativar um cartão emitido naconta do membro. O fluxo inclui: (1) o membro A recebe o cartão no correioe chama o serviço de pagamento móvel IVR para ativar. (2) Durante a inte-ração IVR, o serviço de pagamento móvel fecha a conta sem cartão. (3) (a/b)O serviço de pagamento móvel debita a conta em fundo comum do membroe credita a conta de cartão individual do novo membro A. (4) (a/b) O serviçode pagamento móvel registra a transação de débito em conta comum domembro A e registra a transação de crédito do membro A. (5) O sistema deserviço de pagamento móvel envia a declaração de fechamento da atividadesem cartão para o membro A. As etapas 3 e 4 podem ser encadeamentossecundários assíncronos do servidor.
Em uma implementação, o sistema manipula pagamentos ele-trônicos em proximidade, tal como através do uso de NFC, Bluetooth, RFID,feixe de infravermelho, feixe de LED ou outras tecnologias em proximidade.Por exemplo, os membros AeB estão fisicamente perto um do outro e dese-jam executar um pagamento eletrônico. Esse pode ser um cenário de con-sumidor para consumidor ou consumidor para comerciante. Da mesma for-ma, a transação pode ser um envio de fundos, obtenção de fundos ou qual-quer outro cenário de transferência de dinheiro.Um fluxo básico de uma tal transação é: (1) usuários AeB con-cordam com uma transação de pagamento eletrônico em proximidade. (2)usuário B seleciona "ficar pronto para recepção em proximidade". Dispositivoquestiona PIN, usuário B insere PIN, dispositivo ativa o modo de recepção.
(3) usuário A seleciona "ficar pronto para envio em proximidade." O disposi-tivo questiona o PIN, usuário A insere PIN, dispositivo ativa o modo de envio.(4) usuários AeB colocam os dispositivos dentro da faixa de proximidadeadequada. Usuários AeB tem permissão de uma duração limitada de tempopara executar essa etapa, de outra forma os dispositivos desativarão. (5) os dispositivos dos usuários A e B se reconhecem e transmitem a informaçãode pagamento um para o outro. (6) usuários AeB revisam o diálogo de con-firmação nos dispositivos e selecionam "confirmar". (7) A transação de pa-gamento 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 pode solicitar 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 outra combinaçã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 o mensageiro 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.Em uma implementação específica, o sistema de pagamentomóvel não permite que um usuário registrado existente solicite pagamentode um usuário não registrado. Em uma outra modalidade, é permitido queum usuário solicite pagamento de um usuário não registrado.
O fluxo A abaixo mostra uma implementação para executar umatransaçã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 73</column></row><table><table>table see original document page 74</column></row><table><table>table see original document page 75</column></row><table>
Na etapa 1, acima, o usuário A identifica o usuário B para o sis-tema de pagamento móvel via o número de telefone móvel do usuário B. Emoutras implementações da invenção, o usuário A pode identificar o usuário Batravés de outros modos, tal como o endereço de e-mail do usuário B, nomedo mensageiro instantâneo ou outros identificadores únicos. Esses identifi-cadores podem ser identificadores de identificação eletrônica ou podem seridentificadores que podem ser usados para identificar o usuário B mesmofora do contexto do sistema de pagamento móvel. Em outras palavras, o i-dentificador não é necessariamente único para o sistema de pagamento mó-vel (por exemplo, número da conta).
Na etapa 2, o sistema de pagamento móvel verifica se a contade A tem fundos suficientes para cobrir a transação. O sistema de pagamen-to móvel pode também executar uma validação de PIN e conta ou outrasetapas de validação para garantir que a conta de A não foi suspensa, tenhafundos suficientes e assim por diante. Essas etapas foram omitidas do fluxoacima para melhorar a clareza.
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 recebe essa mensagem via outras téc-nicas, tais como e-mail, troca de mensagens SMS ou outras formas de co-municação móvel. Em algumas modalidades da invenção, o usuário nãoprecisa receber essa mensagem absolutamente, tal como o caso quando ousuário A decidiu e indicou para o sistema não receber tais mensagens. Ofluxo pode também ser aplicado no sistema de pagamento por e-mail ou ou-tros sistemas de pagamento, móveis, não móveis (isto é, onde um telefonemóvel nã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 sistema pode tam-bém ser configurado tal que o pagamento é automaticamente anulado semais do que 30 dias decorreram depois que o usuário A enviou o pagamentoe antes que o usuário B tenha aceitado o pagamento. O número de dias de-pois dos quais uma transação é automaticamente cancelada pode variar.Por exemplo, o número de dias pode ser qualquer número tal como 5, 10,14, 15, 16, 21 ou mais ou menos dias do que 30. Dependendo da implemen-tação, os usuários AeB não precisam receber uma mensagem os notifican-do 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 nãorequer que o usuário B se registre com o sistema e ao invés disso automati-camente vincula o sistema a uma das contas bancárias do usuário B.
Na etapa 9, o usuário B recebe uma mensagem com relação asolicitação do usuário A para enviar pagamento somente depois que o usuá-rio B se registra com o sistema. Em uma outra modalidade da invenção, ousuário B recebe a mensagem com relação ao pagamento do usuário A semter 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 envia ao usuário A uma men-sagem diferente, que pode ser enviada via outras formas de comunicaçãomóvel.
Na etapa 11, é dada a B a opção para mudar ou modificar atransação em alguma forma. Em uma implementação, o usuário B é providocom um botão "sim", um botão "não" e um botão de "solicitar mudança". Alrternativamente, o botão de solicitar mudança pode ser citado como um botãode negociação, porque é dada ao usuário B a oportunidade para negociarcom o usuário A sendo oferecida a oportunidade de mudar um ou mais ter-mos da transação. Alguns termos da transação que o usuário B pode buscarmudar incluem a quantia, a conta para a qual o dinheiro será creditado, divi-dir as taxas de referência e qual banco controlará a conta.
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 o usuário B a oportunidade de aceitar a transação origi-nal. Essas etapas podem ser repetidas quando necessário até que o acordoseja alcançado, ou a transação cancelada. Se o acordo é alcançado, o pro-cesso avança para a etapa 13.
Na etapa 13, o sistema de pagamento móvel verifica a conta dousuário A novamente para verificar os fundos, e, se apropriado, notifica ousuário A sobre os fundos insuficientes através de troca de mensagensSMS. Em uma outra modalidade da invenção, o usuário A pode receber es-sa mensagem em outras formas, tais como e-mail, troca de mensagensMMS ou outras formas de comunicação móvel ou pode não receber essamensagem absolutamente. Se a conta do usuário A tem fundos suficientes,o processo avança para a etapa 14.
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 recebe uma notificação em outras formas, talcomo através de e-mail, mensageiro instantâneo, troca de mensagens MMSou outras formas de comunicação móvel. Algumas modalidades do sistematambém enviam para o usuário B uma notificação que a transação foi con-cluída, embora em algumas modalidades, nenhuma notificação de conclusãoprecise ser enviada.
Na etapa 15, a transferência do dinheiro acontece. Dependendoda implementação, as transações de crédito e débito podem, mas não preci-sam ocorrer em tempo real. A transação pode levar aproximadamente ses-senta segundos ou mais para completar depois que um processo é iniciadodevido aos retardos inerentes nos sistemas de financiamento eletrônico.
Dependendo das preferências de projeto para uma implementa-ção particular, qualquer número das etapas no fluxo A, em qualquer combi-nação, pode ser combinado com qualquer outro fluxo do sistema de paga-mento móvel incluindo os outros fluxos discutidos nesse pedido.
O fluxo B abaixo mostra uma outra implementação de um méto-do para executar uma transação entre um membro usuário registrado (usuá-rio A) e um usuário não registrado (usuário B).
Fluxo B
<table>table see original document page 78</column></row><table><table>table see original document page 79</column></row><table><table>table see original document page 80</column></row><table>
Durante a ativação, em tempo real, enquanto B está conectadono sistema IVR, o dinheiro é transferido da conta em fundo comum sem car-tão para a conta individual de B.
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 é transferido. Dependendo da implemen-tação, tais transações podem ser encadeamentos assíncronos que duramaproximadamente sessenta segundos ou mais para completar depois queum processo é iniciado devido aos retardos inerentes nos sistemas de finan-ciamento eletrônico. A duração do retardo é indeterminada desde que váriosfatores influenciam o retardo. De forma geral, o retardo é de cerca de 60 se-gundos, mas se a grade de potência cai, por exemplo, o retardo será muitomaior.
Em particular, o processamento de pagamento de um sistemanão precisa ser executado em uma maneira síncrona. Uma certa duração devalidação de solicitação positiva é feita. Em uma implementação, as notifica-ções enviadas para o consumidor indicam que a solicitação foi aceita e seráprocessada em breve. O encadeamento secundário assíncrono do servidor éiniciado para realmente processar a solicitação de pagamento. Em uma im-plementação, o encadeamento assíncrono é executado depois que as notifi-cações são enviadas para o usuário. Isso proporciona ao usuário respostamais rápida com relação à transação. É possível que a parte assíncrona doprocessamento de pagamento possa falhar. Por exemplo, isso pode ser porcausa dos fundos insuficientes devido ao uso do cartão simultâneo. Na e-ventualidade de falha 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 sã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, o dinheiro de A é mantido, em vez disso, na conta emjundocomum sem cartão. Em uma outra implementação da invenção, existe umaconta em fundo comum única para ambas as contas em fundo comum deusuário não registrado e em fundo comum sem cartão. Em uma outra moda-lidade da invenção, as contas de A e B são creditadas e debitadas na contaem fundo comum e as transações bancárias do 'quarto dos fundos' gerenci-adas no parceiro bancário (parceiro manipulando o cartão de débito) ocor-rem no fim do dia (ou um outro tempo específico), tipicamente de forma cole-tiva em lote com outras transações do sistema.
Em uma outra implementação da invenção, existe um único tipode conta em fundo comum, onde ambos os usuários não registrados e osusuários sem cartão residem. Para transferências de dinheiro entre tais usu-ários, o dinheiro permanecerá dentro da mesma conta de fundo comum. Emuma implementação ainda adicional da invenção, existem mais do que doistipos 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 recebe um outro tipo de cartão,tal como um cartão de crédito ou pode escolher não receber cartão absolu-tamente.
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 de um méto-do para executar uma transação entre um membro usuário registrado (usuá-rio A) e um usuário não registrado (usuário B).
Fluxo C
<table>table see original document page 82</column></row><table><table>table see original document page 83</column></row><table><table>table see original document page 84</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 tem permissão para cancelar o pagamento e B será apropriada-mente notificado. Na etapa 8, no caso onde existem múltiplos pagamentospendentes, B pode ter acesso a uma lista de pagamentos pendentes e serinduzido a indicar a aceitação ou rejeição de cada pagamento pendente. Seo encadeamento secundário assíncrono do servidor (por exemplo, etapa 12)falha, ambas as partes serão notificadas.
O fluxo D abaixo mostra uma implementação de um método pa-ra executar uma transação entre um usuário sem cartão (usuário A) e umusuário sem cartão (usuário B).
FluxoD
<table>table see original document page 84</column></row><table><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 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.
Em algumas modalidades, o usuário B pode ter uma configura-ção de lista branca ou de lista negra. A lista branca declara que B aceitarápagamentos somente de usuários especificados (que podem ficar armaze-nados no perfil do usuário). A lista negra declara que B não aceitará paga-mentos de membros especificados (que podem também ficar armazenadosno perfil do usuário). Várias implementações da invenção podem ter somen-te uma lista branca, somente uma lista negra, ou ambas, uma lista branca euma negra. Remetentes não autorizados ou bloqueados, por causa da listabranca ou negra, serão notificados do erro depois que sua tentativa de pa-gamento 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 87</column></row><table><table>table see original document page 88</column></row><table>
Os comentários providos acima se aplicam ao fluxo E quando apropriado.
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 88</column></row><table><table>table see original document page 89</column></row><table><table>table see original document page 90</column></row><table>
Os comentários providos acima se aplicam ao fluxo F quando apropriado. O fluxo G abaixo mostra uma implementação da execução da transação entre um usuário com cartão (usuário A) e um usuário com cartão (usuário B).
Fluxo G
<table>table see original document page 90</column></row><table><table>table see original document page 91</column></row><table>
Os comentários providos acima se aplicam ao fluxo G quandoapropriado.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ãoregistrado._
<table>table see original document page 92</column></row><table><table>table see original document page 93</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 ocorrer 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 o usuário B se registra, odinheiro do usuário A pode ser automaticamente transferido para o usuário Bsem a necessidade do usuário A enviar novamente uma transação de pa-gamento. Em uma outra modalidade, o fluxo é: (1) usuário A (membro) enviapara o usuário B (um não membro) $X. (2) O sistema verifica o usuário B,descobre que o usuário B não é um membro. (3) $X é rotulado como umapendência na conta de A. (4) B é notificado que B é convidado por A a seunir ao sistema. Um incentivo de $Y + dinheiro enviado por A estão aguar-dando para ser coletados. (5) B escolhe se alistar como um membro e rece-be o incentivo de $Y imediatamente (já na conta). (6) B então recebe umamensagem indicando que um pagamento de $X foi recebido de A. (7) $X édeduzido da conta de A. (8) A pendência viral pode ser cancelada por A, po-rém o convite pode ainda ser processado. (9) Se B não aceita o convite emcerto período, a quantia pendente é então liberada de 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 uma modalidade, um aspecto da invenção é um método in-cluindo: receber uma instrução de pagamento de um primeiro usuário parapagar um segundo usuário uma quantia especificada, onde o primeiro usuá-rio é um usuário registrado e o segundo usuário é identificado por um núme-ro de telefone para o segundo usuário; com base no número de telefone,determinar que o segundo usuário não é um usuário registrado, e enviaruma primeira mensagem eletrônica para um dispositivo associado com onúmero de telefone notificando o segundo usuário do pagamento pendenteproveniente do primeiro usuário. O método inclui: depois de enviar a primeiramensagem eletrônica, registrar o segundo usuário e apresentar ao segundousuário uma primeira opção para aceitar o pagamento pendente do primeirousuário e uma segunda opção para rejeitar o pagamento pendente do pri-meiro usuário; quando o segundo usuário seleciona a primeira opção, debi-tar a quantia em dinheiro de uma primeira conta associada com o primeirousuário e creditar a quantia em dinheiro em uma segunda conta associadacom o segundo usuário; e quando o segundo usuário seleciona a segundaopção, enviar uma segunda mensagem eletrônica para o primeiro usuárioque o pagamento foi rejeitado.
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, onde o pe-ríodo de tempo é geralmente estabelecido para garantir que um número deseqüência não seja reutilizado enquanto a ocorrência anterior desse númerode seqüência está ainda viável dentro do sistema.
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. Se um certo número de dias decorre do tem-po que a instrução do pagamento foi recebida, e o segundo usuário não seregistrou, o controle é removido na quantia em dinheiro na primeira conta.
Em uma implementação, o dispositivo é pelo menos um de umtelefone inteligente, dispositivo de telefonia móvel, dispositivo de e-mail por- tátil, assistente digital pessoal ou computador.
Em uma modalidade, um aspecto da invenção é um método in-cluindo: receber uma instrução de pagamento de um primeiro usuário parapagar ao segundo usuário uma quantia em dinheiro, onde o primeiro usuárioé um usuário registrado e o segundo usuário é identificado por um númerode telefone para o segundo usuário; com base no número de telefone, de-terminar que o segundo usuário não é um usuário registrado, e enviar umaprimeira mensagem eletrônica para um dispositivo associado com o númerodo telefone notificando o segundo usuário de uma tentativa de pagamentodo primeiro usuário. O método inclui: depois de enviar a primeira mensagemeletrônica, registrar o segundo usuário, enviar ao primeiro usuário uma se-gunda mensagem eletrônica para o primeiro usuário que o segundo usuáriose registrou e apresentar ao primeiro usuário uma primeira opção para pagaro segundo usuário a quantia em dinheiro, e quando o primeiro usuário sele-ciona a primeira opção, debitar a quantia em dinheiro de uma primeira contaassociada com o primeiro usuário e creditar a quantia em dinheiro em umasegunda conta 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-cial 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 paga-mento.
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 O1 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 O1 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, porexemplo, ocorrer 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 O1 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 O1 inicia uma transa-ção ACH de $100 para o seu DDA. (2) O "saldo disponível" do usuário O1 é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) podem ter custo para ambos consumidores e comerciantes. Os con-sumidores podem ser cobrados com taxas de assinaturas anuais. Os comer-ciantes são cobrados pesadamente com taxas de intercâmbio. O que é ne-cessário é um sistema de pagamento disponível para consumidores e co-merciantes que não tenha taxas de alistamento, sem taxas de assinatura esem taxas de transação para o consumidor ou o comerciante. Ainda, aomesmo tempo, o "processador" que movimenta um tal sistema deve sercompensado adequadamente.
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á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. Dependendo da implementação, as comissões são obtidaspelos comerciantes quando os 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 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 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 as contas são abertas. Vantajosamente, o presente sis-tema de circuito fechado faz interface com o sistema de intercâmbio de car-tão de crédito para acessar linhas de crédito disponíveis sob uma conta decartão de crédito. Alternativamente, ou adicionalmente em algumas modali-dades, o presente sistema de circuito fechado também faz interface com vá-rias redes de ATM, como mencionado previamente.
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. 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 algumas modalidades, essa abordagem é menos preferida devidoao risco envolvido, embora esses riscos possam ser minimizados pelo en-volvimento de uma portadora que possa entregar alguns dados de seguro econsumidores 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 ban-co Bancorp opera o banco, porém todos os sítios da web, cheques e decla-rações do consumidor transportarão uma marcação de afinidade. Essa a-bordagem nos permitirá prover a marcação de afinidade com uma conta debanco associada (a conta será grátis para o usuário) em um ambiente fir-memente 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 e com segurança com pouco ou nenhum custo de transação.
Esse exemplo de um sistema de transação financeira de circuitofechado utiliza uma conta de débito pré-financiada e por essa razão podecompreender um terminal de ponto de vendas (POS) 3612 onde cartões dedébito tradicionais 3606 podem ser usados como no sistema da técnica an-terior - passando o cartão na leitora magnética 3613 associada com o termi-nal de POS 3612. O cartão 3606 provê uma segunda visão para dentro dascontas do dono da conta.
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. É 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 com algumas modalidades da pre-sente invenção é que ambos o telefone celular 3618 ou 3619 e o cartão3406 compartilham um PIN comum. Assim, o dono da conta não tem o in-conveniente 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, por exemplo, HTTPS e a ligação pode ser uma rede particular vir-tual ou VPN. O servidor de pagamento 3630 é também conectado nas con-tas de depósito vinculadas 3635 através da rede pública 3625 (não ilustrada)ou através de uma 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, bem como outras transaçõesfinanceiras tais como pagamento de conta e semelhantes. Em algumas mo-dalidades, essa flexibilidade é provida em parte pela interface de um telefonecelular 3702 de um consumidor com um terminal de POS 3612. Em umamodalidade, o consumidor insere o seu número de telefone em um tecladoassociado com o terminal de POS e quando o total da transação fica dispo-nível, o comerciante envia uma SOLICITAÇÃO DE PAGAMENTO para otelefone celular 3702 por meio de uma conexão da Internet 3706 e servidorde pagamento 3704. Em um tal arranjo, o servidor de pagamento 3704 cha-ma o telefone celular 3702 e solicita que o consumidor autorize a transferên-cia de fundos. O consumidor então insere seu PIN ou outra identificação bi-ométrica e confirma a quantia para autorizar o pagamento. O servidor depagamento 3704 transfere os fundos (mais quaisquer taxas de transação) daconta de débito pré-financiada do consumidor e adiciona na conta do comer-ciante a quantia do pagamento (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).
A figura 40 mostra uma estrutura de taxa exemplar para umamodalidade de um sistema financeiro de circuito fechado de acordo comuma modalidade da invenção. Deve ser entendido que a estrutura de taxapode variar e que a ilustração apresenta somente um exemplo de uma estru-tura para gerar renda de operação. Devido à natureza ubíqua da presenteinvenção, as taxas de transação podem ser muito baixas ou grátis. Assim,como indicado em 4001, para transações sob uma certa quantia de dólar, ataxa de transação é abandonada. Para ilustrar, considere uma transaçãofinanceira de $1 transferida em uma base de pessoa para pessoa. Poderianão existir taxa de transação. Enquanto a quantia em dólar onde uma taxade transação é cobrada pode ser ajustada arbitrariamente, tipicamente aquantia em dólar será uma quantia que é menor do que $25. Donos de contaseriam autorizados com um número ilimitado de tais transações em uma ba-se mensal.
Para taxas de transação acima do máximo selecionado em taismodalidades, o envio pelo dono da conta (iniciando uma transação de pa-gamento) incorre em certas taxas como indicado em 4002. Para ilustrar, pa-ra quantias de transações que estão entre $50 e $100, o dono da conta in-corre em uma taxa de transação de $1,00, por meio de exemplo. Para quan-tias acima de uma quantia selecionada (tal como acima de $100), uma taxamais alta pode ser cobrada ou negociada. Essas taxas são consideravel-mente menores do que a taxa por transação cobrada por pelo menos algunsemissores de cartão de crédito. Em uma modalidade alternativa, a taxa detransaçã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, para tais modalidades, é cobrada do comerciante uma taxa adicionalpara receber os fundos. Novamente, a quantia real da taxa de transação docomerciante pode variar, mas em uma modalidade, ela é um nominal de onepor 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 comerciantes3. 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édito).
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íficade um aspecto da invenção, para evitar manter razões gerais para cadabanco, o sistema de pagamento móvel é configurado para manter uma razãogeral para a conta em fundo comum virtual para cada país. Isso reduz oscustos de quitação e operacionais do sistema. Alternativamente, contas emfundo comum virtuais podem ser configuradas para ser uma representaçãode um grupo de contas em fundo comum onde a seleção dessas contas emfundo comum para inclusão em uma conta em fundo comum virtual específi-ca está de acordo com qualquer parâmetro conveniente ou grupo de parâ-metros, tais como parceiros bancários, geografia, país, tamanho e assim pordiante. Em algumas modalidades, uma única conta em fundo comum virtualé implementada, ou alternativamente séries de contas em fundo comum vir-tuais são implementadas. Será verificado que a conta em fundo comum vir-tual é essencialmente um grande banco de dados onde os registros transa-cionais são mantidos para as contas em fundo comum agregadas nessaconta em fundo comum virtual.
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). Uma modalidadede um método para distribuir os fundos flutuantes é como segue:
(1) 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". Em uma tal modalidade, para cada registro de usuário (discuti-do em outro lugar nesse pedido), existe um campo indicando de qual origemesse usuário particular foi recrutado. Alguns exemplos de origens possíveisincluem o serviço de pagamento móvel diretamente, o banco parceiro, a ins-tituição financeira parceira 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 diretamente pelo serviço do sistema de pagamento móvel oupelos parceiros sem banco. Na figura 45, isso é representado pelo númerode telefone 6508622730 que é indicado como sendo recrutado pelo MSPSdo segundo banco (o provedor do serviço do sistema de pagamento móvel).
(3) A cada dia, por exemplo, em uma hora determinada, o servi-ço do sistema de pagamento móvel calculará os fundos apropriados a seremmantidos em um banco parceiro. Por exemplo, isso pode ser de acordo coma segunda fórmula: X-banco parceiro mais uma porcentagem de Υ. A por-centagem será negociada no momento em que a parceria do banco é esta-belecida e dependerá do nível de gasto de mercadologia. Por exemplo, paraC1, 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.
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 6503, 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 momentos a alguns dias, o pro-duto pedido 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 NF detecta a informação da conta no telefone e envia a quantia datransação para o servidor de pagamento que enviaria uma confirmação devolta para o comerciante sem ter que aguardar que o consumidor verifique eespecificamente autorize a transação financeira como indicado em 4704.Esse aspecto é também um método importante para acelerar o processo decompra para transações financeiras com tempo crítico, tal como quando umtrabalhador deseja comprar um bilhete de metrô usando o seu telefone celu-lar à medida que ele anda através de uma borboleta. A quantia pré-autorizada pode ser deduzida em tempo real ou processada como uma tran-sação financeira em lote, por exemplo, em uma base horária.
Para minimizar o tempo de processamento da verificação, emalgumas modalidades, o comerciante pode ser notificado da pré-autorizaçãoantes do uso esperado. Com a recepção da pré-autorização, o número dotelefone pode ser colocado em uma "lista verde" que indica que o comerci-ante pode aceitar pagamento sem verificação do servidor de pagamento. Alista verde é armazenada nos terminais de POS ou fica acessível para osterminais de POS a partir de um servidor local ao invés de a partir do servi-dor 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, se alguma, para receber os fundos para recarga da conta do donoda 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 técnica "precisa edireta" para transmissão de mensagens para e dos móveis. A mensagem(texto somente) do móvel emissor é armazenada em um servidor associadocom o sistema de transporte SMS que então a envia para o móvel de destinoem um momento posterior. Isso significa que se o receptor não está disponí-vel, a mensagem é armazenada e enviada mais tarde. Desde que o SMSusa canal de sinalização em oposição a canais dedicados, essas mensa-gens podem ser enviadas/recebidas simultaneamente com o serviço de vozatravés da rede móvel. Com as redes móveis baseadas em todas as trêstecnologias celulares, com GSM, CDMA e TDMA suportando SMS, SMS éagora um 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 MCA utiliza a função dos serviços de dadospara enviar mensagens SMS binárias. Em uma outra modalidade onde aMCA não está disponível, mensagens SMS de texto simples são usadas pa-ra conduzir transações financeiras com arranjos especiais sendo adotadospara proteger a integridade do PIN. Será também ainda verificado que a ca-rência da MCA também limita as capacidades da Ul, então o usuário podeobter satisfação limitada da presente invenção, mas, de outra forma, entre-tanto, aproveitaria os aspectos e benefícios completos do sistema de transa-ção financeira atual.
Com a presente invenção, a MCA seleciona o modo para trans-mitir a transação financeira para o servidor 4804 (também citado como oprocessador de transação). Por exemplo, se uma conexão da Internet estádisponível, a transação é conduzida usando uma ligação HTTPS, que é umprotocolo da web que criptografa e decriptografa solicitações de página dousuário bem como as páginas que são retornadas pelo servidor 4804. Parausar a Internet, o dono da conta meramente insere os detalhes da transaçãoem uma página da web e seleciona "enviar" para iniciar a transação. Se umaoutra parte está envolvida e essa parte tem um dispositivo habilitado na web,os detalhes da transação são providos em uma página da web. Nessa mo-dalidade, o servidor 4804 funciona como um servidor 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 5206 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 4906, 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 ou AJUDA. 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 inserir uma 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 /-/ 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) dedicádo 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, 4081234567. Alternativamente, o número da conta pode ser de-terminado usando o ID do chamador.
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 1006 é suficientemente configuradocom uma MCA, é possível criptografar a senha antes de incluí-la na mensa-gem SMS. A MCA usará serviços de dados. O aspecto negativo do uso damensagem SMS para transportar o PIN é que esse número secreto ficarávisível para qualquer um que tenha acesso ao telefone e poderia levar aouso desautorizado por um dono sem conta.
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, 6263456789) e o númerodo telefone associado com a sua conta (novamente, por exemplo,4081234567). Se o telefone do dono da conta suporta a MCA, então todasas mensagens SMS trocadas entre o telefone celular 4806 e o servidor 4804podem 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 IP, 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 MCA instalada,a MCA pode criptografar as suas mensagens antes de enviá-las para o ser-vidor 4804 e receber a mensagem criptografada do servidor 4804.
Se o recebedor 4808 é um dono de conta, mas o telefone celularnão suporta o carregamento e a execução da MCA no telefone celular, entãoas mensagens do servidor 4804 serão em texto simples. O aspecto negativodo uso da mensagem SMS de texto simples para transportar o PIN é queesse número secreto ficará visível para qualquer um que subseqüentementeobtenha acesso ao telefone. Isso poderia levar ao uso desautorizado por umdono sem conta a menos que o dono da conta perca tempo excluindo asmensagens SMS da sua caixa de correio do telefone celular. Se o recebedor4808 não é um dono de conta, então as mensagens SMS também será umamensagem 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 MCA comoum módulo de software pré-existente. Alternativamente, a MCA é preferivel-mente carregável do provedor de serviço para telefones celulares que nãoeram originalmente equipados com a MCA. A MCA possibilita melhoras sig-nificativas ao uso do sistema de transação financeira. A MCA é invocada,diretamente pelo dono da conta ou em resposta à ativação do aspecto datroca de mensagens de texto SMS no dispositivo mó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 MCA 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>
Em alguns arranjos, cada item tem um espaço entre ele e o itemprévio. Em uma implementação, a palavra-chave não é sensível ao caso. Onúmero móvel pode incluir o código de área mais o número móvel sem es-paços presentes no número móvel. O dono da conta pode inserir um 1 nafrente ou não do número de telefone. Um sinal de dólar não precisa ser inse-rido com a quantia, mas é permitido. Opcionalmente, o usuário pode incluiruma mensagem com o seu pagamento. A MCA criptografa a mensagem eenvia como uma mensagem SMS dos serviços de dados em texto binário aoinvés de simples.
Em um exemplo alternativo, o PIN é enviado em uma segunda mensagempor meio de uma chamada de voz. Para enviar um pagamento para umaoutra pessoa ou um comerciante usando o método combinado de SMS maiscanal de voz, o dono da conta inseriria a seqüência de comando mostradana tabela D.
Tabela D
<table>table see original document page 130</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-15 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, ele20 pode 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últiplos25 processamentos 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 MCA determina o melhor método para enviaro PIN tal como pela aplicação SMS (serviços de dados) onde a mensagemSMS é criptografada e convertida para binária (isto é, a mensagem não étransmitida em texto simples) ou por canal de voz usando DTMF para man-ter a segurança. Em outras modalidades, o PIN pode ser falado pelo donoda conta e convertido por um módulo de software de reconhecimento de vozinterativo operando no servidor ou um outro servidor (não mostrado) dedica-do para lidar com as chamadas de voz.
Em uma modalidade alternativa, o PIN é criptografado pela MCAe incluído em uma mensagem SMS subseqüente que é enviada para o ser-vidor 4804. O servidor 4804 correlaciona as mensagens comparando o nú-mero de telefone e o tempo que cada mensagem foi enviada. Se o PIN foienviado em uma mensagem que estava distante no tempo comparada coma mensagem SMS, a transação pode ser rejeitada. Se somente uma dasduas mensagens é recebida, a transação pode ser rejeitada. Se, entretanto,ambos a mensagem SMS com os detalhes da transação financeira (mínimode em uma palavra-chave) e o código PIN são adequadamente recebidos esão verificados, então a transação financeira prossegue.
Em uma modalidade alternativa, quando um canal de voz estádisponível, a MCA pode invocar um módulo para codificar o PIN na formaDTMF. O DTMF é então enviado pela MCA para o servidor de pagamentojunto com uma conexão de canal de voz estabelecida pela MCA. O módulopode ser uma API Java que gera os tons apropriados com base na entrada do teclado. DTMF se refere à múltipla freqüência de tom duplo, o sinal queuma companhia de telefone recebe quando as teclas de toque do telefonesão pressionadas.
Em ainda uma outra modalidade alternativa, a MCA provê umainterface do usuário (UI) na tela de exibição do dispositivo móvel para guiar odono da conta para concluir a transação financeira. Nessa modalidade, odono da conta é guiado através do processo de construção da mensagemde texto SMS pela inserção automática da palavra-chave, quantia, númerode 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-Ietar 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 7104. 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 provê 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 provê 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 MCA no telefone envolve a inser-ção física de uma pequena placa de circuitos, citada como o gerador do nú-mero de transação e criptografia ou simplesmente como gerador 4902, parainterceptar 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 MCA decriptografando a mensagem do serviço de dadosSMS e apresentando uma mensagem de texto simples para o dono da con-ta.
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 MCA adicionando um número de tran-sação em cada transação e criptografa a mensagem SMS. Pelo fato de queo gerador 4902 contém um módulo de software embutido, ele pode enviar amensagem SMS como uma mensagem SMS do serviço de dados ao invésde 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 MCA residenteno telefone celular. Em outras modalidades, o SIM 4903 inclui o gerador4902 como um circuito a bordo e é provido para o usuário pelo provedor deserviç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.
Referência é agora feita à 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 1203. 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, onde tais relató-rios são aplicáveis. "OFAC" se refere ao Escritório de controle de bens es-trangeiros do departamento do tesouro dos Estados Unidos que administra efaz cumprir as sanções econômicas e de comércio com base na estratégiade ação estrangeira e metas de segurança nacionais dos E.U. contra paísesestrangeiros almejados, terroristas, traficantes de narcóticos internacionaisnão aprovados e esses engajados em atividades relacionadas com a prolife-ração não aprovada de armas de destruiçã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-cotes 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 taiscasos, 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 em uma outra maneira.
Se os fundos para todos os donos de conta são mantidos naconta 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 naconta 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 gratuitopara 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 dedé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 4502 inclui componentes proprietários que nãoficam acessíveis ou visíveis para os donos de conta.
Os componentes selecionados pelo usuário podem incluir, porexemplo, a capacidade do dono da conta personalizar a segurança para suaconta. 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 7103. 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 PlN. 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 MCA e é enviado como parteda seqüência de comando para o servidor de pagamento. No servidor depagamento, uma história de números de seqüência usados é mantida, entãoas transações com números de seqüência previamente usados não serãoprocessadas. Depois de cada transação e antes da próxima transação, odispositivo móvel atualiza o número de seqüência com um novo número deseqüência. Por exemplo, a nova seqüência pode ser o número de seqüênciaantigo incrementado por 1. Em uma implementação alternativa, os númerosde seqüência podem ser qualquer número, incluindo um número aleatório.Além do mais, um algoritmo pode ser usado que cria uma seqüência de nú-meros previsível ou pseudoaleatória. 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 MCA. Nessa modalidade, o código PIN ocorre em uma primeira instânciapara abrir a MCA e iniciar a sua operação. O mesmo código PIN ou, preferi-velmente, um código PIN separado é usado para a autorização das transa-ções através da rede. Esse processo de código PIN duplo não está disponí-vel nos cartões de crédito, cheques 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 aimbos 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 atransaçã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ãoestá 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 tecladodo 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 indicadoem 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 o 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 e/ou é o número de seqüência esperado, a transação serápermitida. O número de seqüência pode também ser usado como um identi-ficador de transação único.
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 em5624.
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-pio, 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-cial, 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
30 (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 inteirotal 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 umapropriedade 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 repitapode 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 por1 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, ICQ, Yahoo! Messenger,Microsoft Windows Live Messenger, Google Talk ou Skype), existirá umaopção para enviar para um outro usuário um pagamento. A opção para envi-ar um pagamento pode ficar acessível usando um clique no lado direito deum mouse ou através de um menu suspenso ou em cascata. O recebedorpode ser identificado através do nome de usuário, nome de membro, númerode telefone, número de membro, número de conta ou um outro identificador.O pagamento será processado através do servidor do serviço de pagamentomó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-quê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 enviar tipos 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 sisrtema 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 ou equaçã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 umafunçã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 deusuá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çãomó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 MCA para enviar dinheiro ou solicitar dinheiro de qualquerpessoa com um dispositivo móvel que suporta a troca de mensagem de tex-to. Eles podem também ver o saldo e a história da sua conta de débito pré-paga em tempo real.
A MCA suporta os seguintes aspectos: pagamento, saldo, histó-ria, solicitação de pagamento, definições, ajuda. A MCA pode ser usada paraenviar dinheiro de uma conta de dono de conta para qualquer assinante mó-vel cujo dispositivo suporta troca de mensagem de texto. O dono da contaenviando o dinheiro precisa ser um dono de conta; entretanto, a pessoa oucomerciante 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 eta-pas:
(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,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 OK1 ele será trazidopara a tela do PIN onde ele inserirá o seu PIN e selecionará OK. Quandoinserindo o PIN1 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 existenteMensagem
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 de débito pré-paga exis-tente, então uma mensagem tal como: Nota: O recebedor que você pagounão é um dono de conta registrado. O recebedor recebeu uma mensagemcom instruções sobre 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 de débito pré-paga existente, o recebedor receberá uma mensagem de texto que diz "vocêtem dinheiro" e que o instrui a acessar um sítio da web, tal comowww.obopay.com para se tornar um dono de conta e receber o seu dinheiro.O processo para o registro de novo dono de conta é detalhado mais tardenesse 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 de débitopré-paga, o dono da conta passa através de uma seqüência similar de eta-pas:
(1) Abrir a MCA no dispositivo móvel do dono da conta. Isso levará o donoda conta para uma tela de exibição que exibe um logotipo e slogan. O donoda conta então pressiona "entrar" para continuar. Isso levará o dono da con-ta para a tela do menu principal que exibe um menu dos aspectos da MCAincluindo pagamento, saldo, história, solicitação de pagamento, definições eajuda.
(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 OK, 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 OK, 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 le-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:SSQuantia: (+/-)$.$$
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. Para usar a MCA parasolicitar um pagamento de um dono de conta, o dono da conta solicitantepassará através das etapas seguintes. Abrir a MCA no dispositivo móvel dodono da conta solicitante. Isso levará o dono da conta para a tela de exibiçãoque exibe o logotipo e slogan. O dono da conta então pressiona entrar paracontinuar. Isso levará o dono da conta para a tela do menu principal que exi-be um menu dos aspectos da MCA incluindo pagamento, saldo, história, so-licitação de pagamento, definiçõ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:mm
Trans: xxxxSolicitado:
O solicitado receberá uma mensagem que ele tem um novo itemdo servidor de pagamento. Quando o dono da conta abre o item, ele abrirá a MCA 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 do pagamento. Se o recebedor aceita a solicitação, ele selecionará a tecla pro-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 OK1 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)QuantiaSaldo:
Data DD/MM/AAAA HH:MM
Trans: (ID da transação)
Depois que o recebedor seleciona OK, 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 DD/MM/AAAA HH:MM:SSTrans:
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, 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 donoda 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-cimais - 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-8OBOPAY.
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 sobre
versão de softwareTamanho 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 MCA
Visã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 simplista dos conceitos básicos. Favor con-sultar documentos arquitetônicos de MCAP para componentes adicionaisenvolvidos na infra-estrutura que não são ilustrados aqui.
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 é:public PaymentSummary payP2P(
String srcDevKey,
String srcPin,
StringtgtDevKey,
StringtransactionAmount,
String paymenMemo) throws Exception;
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.
public BalanceSummary retrieveBalance(
String devKey,
String pin) throws Exception;
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.public TransactionSummary[] retrieveHistory(
String devKey,String pin) throws Exception;
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.
public PayReqiiestSummary requestPay(
String srcDevKey,
String srcPin,
StringtgtDevKey,
String transactionAmount,
Boolean tipRequest,
String memoText) throws Exception;
A função payRequestPay é usada em resposta à chamada re-questPay, essa chamada aprova o pagamento solicitado,
public PayRequestSummary payRequestPay(
StringpayerDevKey,
String payerPin,
StringtgtDevKey
StrmgpaymentAmount,
String tipAmount,
BooleanacceptRequest,
String transaetionRef,
String memoText) throws Exception;
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.
public String whoAmI(Strmg deviceNumber) throws Exception;
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 pagamentorequestPay - 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 pagamentoOMAP 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 origem.
As figura 79 e 80 mostram os fluxos de tela do sistema ΟΜΑΡ.
Especificamente, a figura 84 mostra o fluxo de tela para o OMAP para um IDmóvel desconhecido. A figura 85 mostra o fluxo de tela de exceção do sis-tema OMAP onde uma solicitação falha.
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.services
Classe.
public interface PaymentServicetoterface
public class PaymentServiceTmplemenation implements
PaymentServicelnterface
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 pagamentoDetalhes 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ólaresxcentavos>. 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.public PaymentSummaiy payP2P (
String srcDevKey,
String srcPin,
String tgtDevKey,
String transactionAinount,
Stting paymentMemo)
throws Exception
Input Parameters:
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 PavmentSummary 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 para
o telefone móvel do membro que chama,public BalanceSummary retrieveBalance (
String devKey,
String pin)
throws Exception
Parâmetros de entrada:
devKey - Valor de seqüência que é geralmente o número de te-lefone da conta 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 BaIanceSummary 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,public TransactionSummaxy[] retrieveHistory (
String devKey,
String pin)
throws Exception
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-Summarv 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.public PayRequestSummaiy payRequestPayMobile(
StringpayerDevKey,String payerPin,String tgtDevKey,String paymentAmount,String tip AmountjBoolean acceptRequest,Slring transactionRef,String requestText,String memoText)throws Exception
Parâmetros de entrada:
payerDevKey - Valor de seqüência que é geralmente o número15 de 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 da20 conta 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 saldo disponível. Ver descrição de classe PavRequestSummarvpara 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.
public PayRequestSummaty requestPay(
String srcDevKey,
String srcPin,
String tgtDevKey,
String transactionAmount,
Boolean tipRequest,
String requestText)
throws Exception
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 dopagamento 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 PavRequestSummarvpara 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:public interface RegistrationServiceInterfacepublic class RegistrationServicelmplemenation implementspaymentServicelnterface
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,public ArrayList addRegistrationInfo(
ArrayList regC ontainerList,
String dsName)
throws Throwable
Parâmetros de entrada:
regContainerList - objeto do recipiente RegistrationContainer que contém demodo 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 Transferinterface, que é um dono de lu-gar para as necessidades comuns potenciais da interface bem como pro-vendo um tipo de base.
BalanceSummaryO objeto do recipiente retornado da API paymentService Interfa-ce.retrieveBalanceMobile().
Pacote:
com.ewp.transferobjects
Classe:
public class BaIanceSummary
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, O = 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.ewp.transferobjects
Classe:
public class TransactionSummaryimplementa 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, POS, ATM, CARGA, SALIocationName - 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 = Ostatus - Valor da seqüência que indica se um erro ocorreu ou
não durante a execução do serviço: 1 = OK1 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 mo-netá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 é solicitadorequesterDeviceKey - Valor da seqüência que é o número de
telefone 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 recebedorClasses de exceção
EW PSe rvice Exception
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.exceptions
Classe:
classe pública EWPException estende Throwable
Atributos:
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.exceptions
Classe:
classe pública InternaIException estende EWPException
Atributos: herdados da classe pai.
BusinessExceptionEssa 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.exceptions
Classe:
classe pública BusinessException estende EWPException
Atributos: 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 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><table>table see original document page 200</column></row><table><table>table see original document page 201</column></row><table>
(*) 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 da interface aser usada pelos serviços executando os métodos ajudantescom.ewp.integration.paymentProcessor - para serviços executando o méto-do ajudante
Classe:
classe pública PaymentProcessorHelper
As interfaces de programação da aplicação (APIs) definidas para o ajudantesã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: saldo
Class:
public class BalanceSummary
Assinatura do método: história
Attributes:
currentBalanceAmoimt · String value that is the monetary amount of funds currently available foruse
errorCode · String value that indicates the nature of the error; set only ifstatus=0Assinatura do método: p2p
requestDate ♦ String value that is the audit time stamp for the balance requestPaymentSummary
The container object returned from the PaymentServiceInterface.payP2PMobileG APL Thisobject is also passed in notifícation callbacks to the mobile device interface with values for display.
Package:
com.ewp.transferobjects
Serviços de valor adicionadoMuitos pequenos negócios usam um serviço de contabilidade
comercial 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.
As figuras 81 a 86 mostram telas do usuário e fluxos para umaaplicação de telefone móvel para executar pagamentos de pessoa para pes-soa. Em uma implementação, esse pedido é uma aplicação independenteque funciona em um telefone móvel que possibilita que usuários enviem pa-gamentos para outros usuários, solicitem pagamento de outros usuários,verifiquem a informação de saldo, verifiquem a história da transação e exe-cutem outras funções.
O usuário pode mudar definições tal como o tamanho da fonte(por exemplo, pequena, média ou grande). Um protocolo para comunicaçãocom o sistema pode ser selecionado, tais como HTTPS, HTTP ou SMS. Ousuário pode solicitar que exista uma notificação por som ou luz, ou ambos,quando recebendo um pagamento. Existe uma alternação de gorjeta de mo-do que o usuário pode ter uma tela de gorjeta mostrada ou não mostrada 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 selecionou 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 memorando onde um usuário pode inserir umamensagem junto com a solicitação de envio de pagamento ou solicitação depagamento. Por exemplo, o usuário pode dizer ao alvo, "dinheiro p/ almoço".Existe 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 a oportunidade para confirmar a transaçãoantes do envio. Se existe um erro, o usuário pode selecionar editar a transa-ção antes do envio.
A aplicação pode também incluir um breve guia do usuário ou deajuda para auxiliar o usuário e responder a pergunta do usuário quanto aouso do sistema.
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.
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 (1)

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.
BRPI0710021-3A 2006-03-30 2007-03-30 sistema de pagamento individualizado móvel BRPI0710021A2 (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/065725 WO2008027621A1 (en) 2006-03-30 2007-03-30 Mobile person-to-person payment system

Publications (1)

Publication Number Publication Date
BRPI0710021A2 true BRPI0710021A2 (pt) 2011-08-02

Family

ID=38532095

Family Applications (2)

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

Family Applications After (1)

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

Country Status (6)

Country Link
US (3) US20070255653A1 (pt)
EP (4) EP2013842A4 (pt)
BR (2) BRPI0710021A2 (pt)
CA (2) CA2647602A1 (pt)
MX (2) MX2008012503A (pt)
WO (2) WO2008027620A1 (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
US10970688B2 (en) 2012-03-07 2021-04-06 Early Warning Services, Llc System and method for transferring funds
US10970695B2 (en) 2015-07-21 2021-04-06 Early Warning Services, Llc Secure real-time transactions
US11037122B2 (en) 2015-07-21 2021-06-15 Early Warning Services, Llc Secure real-time transactions
US11037121B2 (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
US11151523B2 (en) 2015-07-21 2021-10-19 Early Warning Services, Llc Secure transactions with offline device
US11151522B2 (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
US12499427B2 (en) 2021-08-31 2025-12-16 Early Warning Services, Llc Direct electronic bill payment with real-time funds availability

Families Citing this family (919)

* 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
CN1261498A (zh) 1997-05-21 2000-07-26 E·S·P·通讯股份有限公司 呼叫者产生记费的“仅由呼叫者”启动的双向无线通信的系统、方法和装置
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
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
US9286635B2 (en) 2002-02-05 2016-03-15 Square, Inc. Method of transmitting information from efficient communication protocol card readers to mobile devices
US8302860B2 (en) 2010-10-13 2012-11-06 Square, Inc. Read head device with narrow card reading slot
US8870070B2 (en) 2010-10-13 2014-10-28 Square, Inc. Card reader 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
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
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
US9305314B2 (en) 2002-02-05 2016-04-05 Square, Inc. Methods of transmitting information to mobile devices using cost effective card readers
US8235287B2 (en) 2010-10-13 2012-08-07 Square, Inc. Read head device with slot configured to reduce torque
US8870071B2 (en) 2010-10-13 2014-10-28 Square, Inc. Read head device with selected sampling rate
US9324100B2 (en) 2002-02-05 2016-04-26 Square, Inc. Card reader with asymmetric spring
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
US9495675B2 (en) 2002-02-05 2016-11-15 Square, Inc. Small card reader configured to be coupled to a mobile device
US9495676B2 (en) 2002-02-05 2016-11-15 Square, Inc. Method of transmitting information from a power efficient card to a mobile device
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
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
US9016572B2 (en) 2010-10-13 2015-04-28 Square, Inc. Systems and methods for financial transaction through miniaturized card with ASIC
US7979348B2 (en) 2002-04-23 2011-07-12 Clearing House Payments Co Llc Payment identification code and payment system using the same
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
WO2006133141A2 (en) * 2005-06-06 2006-12-14 Sms.Ac, Inc. Billing system and method for micro-transactions
CA2621108A1 (en) * 2005-09-07 2007-03-15 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
US8205791B2 (en) 2005-10-11 2012-06-26 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
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
CA2874887A1 (en) 2006-01-09 2007-07-19 Rent A Toll, Ltd. Billing a rented third party transport including an on-board unit
US8662384B2 (en) * 2006-02-28 2014-03-04 Google Inc. Text message payment
US7826421B2 (en) * 2006-03-20 2010-11-02 Sms.Ac, Inc. Application pod integration with automated mobile phone billing and distribution platform
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
CA2647602A1 (en) 2006-03-30 2008-03-06 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
US8965416B2 (en) * 2006-05-25 2015-02-24 Celltrust Corporation Distribution of lottery tickets through mobile devices
US8225380B2 (en) 2006-05-25 2012-07-17 Celltrust Corporation Methods to authenticate access and alarm as to proximity to location
US9572033B2 (en) 2006-05-25 2017-02-14 Celltrust Corporation Systems and methods for encrypted mobile voice communications
US8260274B2 (en) * 2006-05-25 2012-09-04 Celltrust Corporation Extraction of information from e-mails and delivery to mobile phones, system and method
US9848081B2 (en) 2006-05-25 2017-12-19 Celltrust Corporation Dissemination of real estate information through text messaging
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
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
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
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
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
US8510220B2 (en) * 2006-07-06 2013-08-13 Qualcomm Incorporated Methods and systems for viewing aggregated payment obligations 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
US8145568B2 (en) * 2006-07-06 2012-03-27 Firethorn Mobile, Inc. Methods and systems for indicating a payment in a mobile environment
US8467766B2 (en) 2006-07-06 2013-06-18 Qualcomm Incorporated Methods and systems for managing payment sources 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
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
US10115112B2 (en) 2006-08-31 2018-10-30 Visa U.S.A. Inc. Transaction evaluation for providing rewards
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
US7885451B1 (en) 2006-10-31 2011-02-08 United Services Automobile Association (Usaa) Systems and methods for displaying negotiable instruments derived from various sources
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
US8351677B1 (en) 2006-10-31 2013-01-08 United Services Automobile Association (Usaa) Systems and methods for remote deposit of checks
US7876949B1 (en) 2006-10-31 2011-01-25 United Services Automobile Association 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
WO2008086439A1 (en) 2007-01-09 2008-07-17 Visa U.S.A. Inc. Contactless 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
US8959033B1 (en) 2007-03-15 2015-02-17 United Services Automobile Association (Usaa) Systems and methods for verification of remotely deposited checks
US20080228582A1 (en) * 2007-03-15 2008-09-18 Fordyce Edward W Loyalty program for merchant inventory
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
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
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
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
US9111189B2 (en) 2007-10-31 2015-08-18 Location Based Technologies, Inc. Apparatus and method for manufacturing an electronic package
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
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 楽天株式会社 情報処理装置、情報処理方法、及び情報処理プログラム
US20080288376A1 (en) 2007-04-27 2008-11-20 Cashedge, Inc. Centralized payment hub method and system
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
US8620260B2 (en) 2007-04-27 2013-12-31 American Express Travel Related Services Company, Inc. Payment application download to mobile phone and phone personalization
US8543496B2 (en) * 2007-04-27 2013-09-24 American Express Travel Related Services Company, Inc. User experience on mobile phone
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
US8538124B1 (en) 2007-05-10 2013-09-17 United Services Auto Association (USAA) Systems and methods for real-time validation of check image quality
US8433127B1 (en) 2007-05-10 2013-04-30 United Services Automobile 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
US10163092B2 (en) 2007-08-18 2018-12-25 Expensify, Inc. System and method for establishing a payment mechanism with a plurality of merchants
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
US10423896B2 (en) 2007-08-18 2019-09-24 Expensify, Inc. Computer system implementing a network transaction service
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
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
US8915447B2 (en) 2007-09-12 2014-12-23 Devicefidelity, Inc. Amplifying radio frequency signals
US20090070263A1 (en) * 2007-09-12 2009-03-12 Wachovia Corporation Peer to peer fund transfer
US9304555B2 (en) 2007-09-12 2016-04-05 Devicefidelity, Inc. Magnetically coupling radio frequency antennas
US7729989B1 (en) 2007-09-19 2010-06-01 Amazon Technologies, Inc. Method and apparatus for message correction in a transaction authorization service
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
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
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
US7996316B1 (en) 2007-10-30 2011-08-09 United Services Automobile Association 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
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
US7996314B1 (en) 2007-10-30 2011-08-09 United Services Automobile Association (Usaa) Systems and methods to modify 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
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
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 北京飞天诚信科技有限公司 一种自助充值的系统和方法
US9098844B2 (en) 2007-11-20 2015-08-04 Wells Fargo Bank, N.A. Mobile electronic wallet
US7689508B2 (en) * 2007-11-20 2010-03-30 Wells Fargo Bank N.A. Mobile device credit account
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
US10380562B1 (en) 2008-02-07 2019-08-13 United Services Automobile Association (Usaa) Systems and methods for mobile deposit of negotiable instruments
US20090204503A1 (en) * 2008-02-07 2009-08-13 First Data Corporation Methods and systems for establishing investment accounts associated with presentation instruments
WO2009100477A1 (en) * 2008-02-15 2009-08-20 Rubik Financial Limited An interface
US9852426B2 (en) 2008-02-20 2017-12-26 Collective Dynamics LLC Method and system for secure transactions
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
US8141780B2 (en) 2008-02-23 2012-03-27 Cedar Ridge Research Llc System and method for data card emulation
US20140250001A1 (en) * 2010-12-14 2014-09-04 Giftya Llc System and method for processing gifts between different payment account types
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
US20120150600A1 (en) * 2010-12-14 2012-06-14 Moneyhoney Llc System and method for confirming application of a gift to a transaction
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
US20120150732A1 (en) * 2010-12-14 2012-06-14 Moneyhoney Llc System and method for processing gift cards according to a communication context
US8676704B2 (en) 2008-03-13 2014-03-18 Giftya Llc Method for transferring funds
US20120150730A1 (en) * 2010-12-14 2012-06-14 Moneyhoney Llc System and method for processing group gift cards
US20120150728A1 (en) * 2010-12-14 2012-06-14 Isaacson Thomas M System and method for splitting a transaction
US20140207662A1 (en) 2008-03-13 2014-07-24 Giftya Llc System and method for managing gifts
US20140249902A1 (en) 2008-03-13 2014-09-04 Giftya Llc System and method for providing a customer survey
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
EP2266083A4 (en) 2008-03-14 2012-01-25 Obopay Inc VIRAL PAYMENT SYSTEM ON NETWORK BASE
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
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
US7966200B1 (en) 2008-03-18 2011-06-21 United Services Automobile Association Systems and methods for modeling insurance coverage
US7983937B1 (en) 2008-03-18 2011-07-19 United Services Automobile Association Systems and methods for modeling recommended insurance coverage
US8117100B1 (en) 2008-03-19 2012-02-14 Unites Services Automobile Association (USAA) Systems and methods for managing consolidated purchasing, billing and payment information
US8249961B1 (en) 2008-03-19 2012-08-21 United States Automobile Association Systems and methods for managing consolidated purchasing, billing and payment information
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
US8620826B2 (en) 2008-03-27 2013-12-31 Amazon Technologies, Inc. System and method for receiving requests for tasks from unregistered devices
KR20100126850A (ko) 2008-03-28 2010-12-02 셀트러스트 코포레이션 보안형 단문 메시징 서비스 및 멀티미디어 메시징 서비스를 위한 시스템 및 방법
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
US9280769B2 (en) * 2008-05-14 2016-03-08 Visa Cape Town (Pty) Ltd. Mobile commerce payment system
US20090287603A1 (en) * 2008-05-15 2009-11-19 Bank Of America Corporation Actionable Alerts in Corporate Mobile Banking
US20090287599A1 (en) * 2008-05-15 2009-11-19 Bank Of America Corporation Monetary Transfer Approval Via Mobile Device
AU2009249272B2 (en) 2008-05-18 2014-11-20 Google Llc Secured electronic transaction system
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
GB0809381D0 (en) 2008-05-23 2008-07-02 Vidicom Ltd Funds transfer electronically
GB0809386D0 (en) * 2008-05-23 2008-07-02 Vidicom Ltd Transferring funds electronically
WO2009155058A2 (en) 2008-05-28 2009-12-23 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
US8458363B2 (en) 2008-06-08 2013-06-04 Apple Inc. System and method for simplified data transfer
US9626363B2 (en) 2008-06-08 2017-04-18 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
WO2009152184A1 (en) * 2008-06-09 2009-12-17 Obopay, Inc. Mobile payment system
US8351678B1 (en) 2008-06-11 2013-01-08 United Services Automobile Association (Usaa) Duplicate check detection
US8655341B2 (en) * 2008-06-24 2014-02-18 Haim Boukai Methods for mobile phone applications
RU2520417C2 (ru) * 2008-06-24 2014-06-27 Хайм Боукай Способ использования мобильных телефонов
EP2304679A4 (en) * 2008-06-24 2011-11-23 Hsbc Technologies Inc METHODS AND SYSTEMS FOR VERIFYING FINANCIAL ACCOUNT INFORMATION PROVIDED BY A CUSTOMER USING FLOW AND CREDIT TRANSACTIONS
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
US20090321522A1 (en) * 2008-06-30 2009-12-31 Jonathan Charles Lohr Utilizing data from purchases made with mobile communications device for financial recordkeeping
KR100988230B1 (ko) * 2008-06-30 2010-10-18 주식회사 티모넷 휴대폰을 이용한 전자지불수단의 충전금액 이전시스템 및그 방법
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
WO2010022109A1 (en) * 2008-08-18 2010-02-25 Cashedge, Inc. 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
US8215546B2 (en) * 2008-09-30 2012-07-10 Apple Inc. System and method for transportation check-in
US8060627B2 (en) * 2008-09-30 2011-11-15 Apple Inc. Device-to-device workflows
US7974899B1 (en) 2008-09-30 2011-07-05 United Services Automobile Association (Usaa) Atomic deposit transaction
US8131645B2 (en) * 2008-09-30 2012-03-06 Apple Inc. System and method for processing media gifts
US20100082485A1 (en) * 2008-09-30 2010-04-01 Apple Inc. Portable point of purchase devices and methods
US8275710B1 (en) 2008-09-30 2012-09-25 United Services Automobile Association (Usaa) Systems and methods for automatic bill pay enrollment
US20100078472A1 (en) 2008-09-30 2010-04-01 Apple Inc. Group peer-to-peer financial transactions
US8850052B2 (en) * 2008-09-30 2014-09-30 Apple Inc. System and method for simplified resource sharing
US7962411B1 (en) * 2008-09-30 2011-06-14 United Services Automobile Association (Usaa) Atomic deposit transaction
US9070149B2 (en) 2008-09-30 2015-06-30 Apple Inc. Media gifting devices and methods
US20100078471A1 (en) * 2008-09-30 2010-04-01 Apple Inc. System and method for processing peer-to-peer financial transactions
US8239276B2 (en) * 2008-09-30 2012-08-07 Apple Inc. On-the-go shopping list
US20100082455A1 (en) * 2008-09-30 2010-04-01 Apple Inc. Real-time bargain hunting
US9037513B2 (en) * 2008-09-30 2015-05-19 Apple Inc. System and method for providing electronic event tickets
US20100082490A1 (en) * 2008-09-30 2010-04-01 Apple Inc. Systems and methods for secure wireless transactions
US10380573B2 (en) * 2008-09-30 2019-08-13 Apple Inc. Peer-to-peer financial transaction devices and methods
US7885880B1 (en) 2008-09-30 2011-02-08 United Services Automobile Association (Usaa) Atomic deposit transaction
US9026462B2 (en) * 2008-09-30 2015-05-05 Apple Inc. Portable point of purchase user interfaces
WO2010037204A1 (en) 2008-10-03 2010-04-08 Consumer Mt 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
US7970677B1 (en) * 2008-10-24 2011-06-28 United Services Automobile Association (Usaa) Systems and methods for financial deposits by electronic message
US7949587B1 (en) 2008-10-24 2011-05-24 United States 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
EP2187363B1 (en) * 2008-11-12 2012-04-11 Oberthur Technologies Denmark A/S Personal identification number distribution device and method
US20100125492A1 (en) * 2008-11-14 2010-05-20 Apple Inc. System and method for providing contextual advertisements according to dynamic pricing scheme
US11797953B2 (en) * 2008-11-24 2023-10-24 Malikie Innovations Limited Electronic payment system including merchant server 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 北京握奇数据系统有限公司 实现安全移动支付的方法及装置
US8527987B2 (en) 2008-12-29 2013-09-03 Telefonaktiebolaget L M Ericsson (Publ) Method and device for installing applications on NFC-enabled devices
US20100169182A1 (en) * 2008-12-30 2010-07-01 Masih Madani Mobile payment method and system using the same
US8060449B1 (en) 2009-01-05 2011-11-15 Sprint Communications Company L.P. Partially delegated over-the-air provisioning of a secure element
US8200582B1 (en) 2009-01-05 2012-06-12 Sprint Communications Company L.P. Mobile device password system
US9928490B1 (en) 2009-01-16 2018-03-27 Wells Fargo Bank, N.A. System and method for transferring funds
US9652761B2 (en) 2009-01-23 2017-05-16 Boku, Inc. Systems and methods to facilitate electronic payments
US8116730B2 (en) * 2009-01-23 2012-02-14 Vidicom Limited Systems and methods to control online transactions
US8041639B2 (en) * 2009-01-23 2011-10-18 Vidicom Limited Systems and methods to facilitate online transactions
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
US7983951B2 (en) 2009-03-02 2011-07-19 Kabbage, Inc. Apparatus to provide liquid funds in the online auction and marketplace environment
US10430873B2 (en) 2009-03-02 2019-10-01 Kabbage, Inc. Method and apparatus to evaluate and provide funds in online environments
US9990623B2 (en) 2009-03-02 2018-06-05 Boku, Inc. Systems and methods to provide information
US11257149B2 (en) 2009-03-02 2022-02-22 American Express 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
US20100228683A1 (en) * 2009-03-06 2010-09-09 TxVia, Inc. Issuing systems, acquiring systems, and payment networks/systems development
US20100235275A1 (en) * 2009-03-06 2010-09-16 Carl Ansley Card Processing
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
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
US20100274626A1 (en) * 2009-04-22 2010-10-28 Mark Carlson Receipt of communications from announcement recipients of consumer data
US9235831B2 (en) 2009-04-22 2016-01-12 Gofigure Payments, Llc Mobile payment systems and methods
US8543468B2 (en) * 2009-04-22 2013-09-24 Visa U.S.A. Inc. Bidding to receive data after a consumer is in a zone
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
US8032413B2 (en) 2009-04-22 2011-10-04 Visa U.S.A. Inc. Auctioning of announcements
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
US20100274625A1 (en) * 2009-04-22 2010-10-28 Mark Carlson Targeting merchant announcements triggered by consumer activity relative to a surrogate merchant
US8160934B2 (en) * 2009-04-22 2012-04-17 Visa U.S.A. Inc. Notification of resources of interest to members of a consumer group
US8706626B2 (en) 2009-05-26 2014-04-22 Bradley Wilkes Systems and methods for provisionally transferring an electronic currency
US9721261B2 (en) 2009-05-26 2017-08-01 CapitalWill, LLC Systems and methods for electronically circulating a conditional 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
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 阿里巴巴集团控股有限公司 移动终端中实现支付的方法及移动设备
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
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
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
BR112012007946A2 (pt) * 2009-10-19 2016-03-22 Faber Financial Llc método para realizar transação entre cormeciante e cliente
US11990005B2 (en) 2009-11-12 2024-05-21 Aristocrat Technologies, Inc. (ATI) Gaming system supporting data distribution to gaming devices
US8864586B2 (en) 2009-11-12 2014-10-21 Nguyen Gaming Llc Gaming systems including viral gaming events
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
US9741077B2 (en) * 2010-01-22 2017-08-22 Verient, Inc. Systems and methods for controlling payment processing
US20110191238A1 (en) * 2010-01-29 2011-08-04 Bank Of America Corporation Variable merchant settlement options
US20110191157A1 (en) * 2010-01-29 2011-08-04 Bank Of America Corporation Integrated merchant offer program and customer shopping
US20110191184A1 (en) * 2010-01-29 2011-08-04 Bank Of America Corporation Mobile location integrated merchant offer program and customer shopping
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
US20110191177A1 (en) * 2010-01-29 2011-08-04 Bank Of America Corporation Pre-population of merchant check-out entry fields
US20110191181A1 (en) * 2010-01-29 2011-08-04 Bank Of America Corporation Wish list for integrated merchant offer program and customer shopping
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
US20110191149A1 (en) * 2010-01-29 2011-08-04 Bank Of America Corporation Customer-selected payment clearinghouse
US8442894B2 (en) * 2010-01-29 2013-05-14 Bank Of America Corporation Guaranteed merchant payment in a card-not-present transaction
US20110191150A1 (en) * 2010-01-29 2011-08-04 Bank Of America Corporation Mobile integrated merchant offer program and customer shopping using product level information
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
TWI567664B (zh) * 2010-03-08 2017-01-21 阿里巴巴集團控股有限公司 移動式終端中實現支付的方法及移動式設備
MX2012010196A (es) * 2010-03-08 2012-10-03 Telefonica Sa Procedimiento y sistema para realizar una transaccion.
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
US10445723B2 (en) * 2010-04-09 2019-10-15 Paypal, Inc. NFC-transaction processing systems and methods
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
US8696470B2 (en) 2010-04-09 2014-04-15 Nguyen Gaming Llc Spontaneous player preferences
US8632000B2 (en) 2010-12-23 2014-01-21 Paydiant, Inc. Mobile phone ATM processing methods and systems
US11887105B2 (en) 2010-04-09 2024-01-30 Paypal, Inc. Transaction token issuing authorities
WO2011133958A2 (en) * 2010-04-22 2011-10-27 Cashedge, Inc. Inter-network invoice and 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
AU2011289300B2 (en) 2010-08-11 2014-11-13 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
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
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
US10121133B2 (en) * 2010-10-13 2018-11-06 Walmart Apollo, Llc Method for self-checkout with a mobile device
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
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
EP2628140A4 (en) * 2010-10-13 2014-05-21 Square Inc PAYMENT METHOD WITH A PAYMENT SERVICE AND A TABS OPENED BY A FIRST PARTY AND OPENED BY A SECOND PARTY AT ANY POSITION OF A MOBILE DEVICE OF THE FIRST PARTY
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
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
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
US9852457B2 (en) 2010-10-15 2017-12-26 League Sports Services Llc Method and system to facilitate transactions between organization registrants and merchandise suppliers
WO2012054786A1 (en) 2010-10-20 2012-04-26 Playspan Inc. Flexible monetization service apparatuses, methods and systems
US9235952B2 (en) 2010-11-14 2016-01-12 Nguyen Gaming Llc Peripheral management device for virtual game interaction
US10052551B2 (en) 2010-11-14 2018-08-21 Nguyen Gaming Llc Multi-functional peripheral device
US9595161B2 (en) 2010-11-14 2017-03-14 Nguyen Gaming Llc Social gaming
US12100260B2 (en) 2010-11-14 2024-09-24 Aristocrat Technologies, Inc. (ATI) Multi-functional peripheral device
US9486704B2 (en) 2010-11-14 2016-11-08 Nguyen Gaming Llc Social gaming
US9564018B2 (en) 2010-11-14 2017-02-07 Nguyen Gaming Llc Temporary grant of real-time bonus feature
US10176477B2 (en) 2010-11-16 2019-01-08 Mastercard International Incorporated Methods and systems for universal payment account translation
CN102467678B (zh) * 2010-11-16 2015-04-22 北京中电华大电子设计有限责任公司 一种具有双频通讯机制的射频sim卡
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
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
CN102568124A (zh) * 2010-12-24 2012-07-11 汉斯·杰里·乌尔本·彼得森 一种在现有计费设备与移动支付系统间通信的方法
US20120173413A1 (en) * 2010-12-29 2012-07-05 Boku, Inc. Pan charging to account established with an msisdn
US8583496B2 (en) 2010-12-29 2013-11-12 Boku, Inc. Systems and methods to process payments via account identifiers and phone numbers
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
JP2014505305A (ja) * 2011-01-28 2014-02-27 ロイヤル カナディアン ミント 電子取引リスク管理
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
US8775263B2 (en) 2011-03-29 2014-07-08 @Pay Ip Holdings Llc System and method for email-based e-commerce
US9058591B2 (en) 2011-03-29 2015-06-16 @Pay Ip Holdings Llc System and method for email-based donations
US9292840B1 (en) 2011-04-07 2016-03-22 Wells Fargo Bank, N.A. ATM customer messaging systems and methods
US9589256B1 (en) 2011-04-07 2017-03-07 Wells Fargo Bank, N.A. Smart chaining
US9087428B1 (en) 2011-04-07 2015-07-21 Wells Fargo Bank, N.A. System and method for generating a customized user interface
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
US8543087B2 (en) 2011-04-26 2013-09-24 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
CA2832204C (en) * 2011-05-03 2019-10-01 Panther Payments, LLC Method and system for facilitating person-to-person payments
US9785935B2 (en) 2011-05-11 2017-10-10 Riavera Corp. Split mobile payment system
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
US10223674B2 (en) 2011-05-11 2019-03-05 Riavera Corp. Customized transaction flow for multiple transaction types using encoded image representation of transaction information
CA2835733A1 (en) 2011-05-11 2012-11-15 Mark Itwaru Mobile image payment system using short codes
US20120290415A1 (en) * 2011-05-11 2012-11-15 Riavera Corp. Mobile image payment system
US9734498B2 (en) * 2011-05-11 2017-08-15 Riavera Corp Mobile image payment system using short codes
US9715704B2 (en) 2011-05-11 2017-07-25 Riavera Corp Merchant ordering system using optical machine readable image representation of invoice information
US9721243B2 (en) 2011-05-11 2017-08-01 Riavera Corp. Mobile payment system using subaccounts of account holder
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
US9098850B2 (en) 2011-05-17 2015-08-04 Ping Identity Corporation System and method for transaction security responsive to a signed authentication
AU2012257312A1 (en) 2011-05-17 2014-01-16 Ping Identity Corporation System and method for performing a secure transaction
CN102810154B (zh) * 2011-06-02 2016-05-11 国民技术股份有限公司 一种基于可信模块的生物特征采集融合方法和系统
US8538845B2 (en) * 2011-06-03 2013-09-17 Mozido, Llc Monetary transaction system
KR20140045497A (ko) * 2011-06-09 2014-04-16 엑셀스 테크놀로지스 (2009), 엘티디. 무선 단말기와 함께 사용하기 위한 트랜잭션 시스템 및 방법
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
US20130046652A1 (en) 2011-08-18 2013-02-21 EasyGive LLC System and method for selectively providing information to internet users
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
JP2014529964A (ja) 2011-08-31 2014-11-13 ピング アイデンティティ コーポレーション モバイル機器経由の安全なトランザクション処理のシステムおよび方法
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
AU2011378113A1 (en) * 2011-09-30 2014-04-17 BPAY Group Limited Payment requests
US20130232084A1 (en) * 2011-09-30 2013-09-05 Turkcell Teknoloji Arastirma Ve Gelistirme Anonim Sirketi Mobile Financial Transaction System and Method
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
US9208488B2 (en) 2011-11-21 2015-12-08 Mozido, Inc. Using a mobile wallet infrastructure to support multiple mobile wallet providers
US10438196B2 (en) 2011-11-21 2019-10-08 Mozido, Inc. Using a mobile wallet infrastructure to support multiple mobile wallet providers
DE202012100620U1 (de) 2011-11-22 2012-06-13 Square, Inc. System zur Bearbeitung von kartenlosen Bezahlungstransaktionen
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
WO2013082154A1 (en) * 2011-11-29 2013-06-06 Zuora, Inc. Configurable billing with subscriptions having conditional components
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
US9953378B2 (en) * 2012-04-27 2018-04-24 Visa International Service Association Social checkout widget generation and integration apparatuses, methods and systems
WO2013090611A2 (en) * 2011-12-13 2013-06-20 Visa International Service Association Dynamic widget generator 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
US9165187B2 (en) 2012-01-12 2015-10-20 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
US20130275296A1 (en) * 2012-03-16 2013-10-17 esdatanetworks INC Proximal Customer Transaction Incented By Donation of Auto-Boarded Merchant
US9373112B1 (en) 2012-03-16 2016-06-21 Square, Inc. Ranking of merchants for cardless payment transactions
US20130246296A1 (en) 2012-03-19 2013-09-19 @Pay LLC Method for processing multimodal mobile donations via text message and email communication
CA2865936A1 (en) * 2012-03-19 2013-09-26 Royal Canadian Mint/Monnaie Royale Canadienne Using bar-codes in an asset storage and transfer system
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
US10614480B2 (en) * 2012-08-13 2020-04-07 Groupon, Inc. Method and apparatus for return on investment impact reporting
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
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
US11961075B2 (en) 2014-10-10 2024-04-16 Royal Bank Of Canada Systems for processing electronic transactions
US9082119B2 (en) 2012-10-17 2015-07-14 Royal Bank of Canada. Virtualization and secure processing of data
US11449854B1 (en) 2012-10-29 2022-09-20 Block, Inc. Establishing consent for cardless transactions using short-range transmission
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
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
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
US9704190B2 (en) 2013-02-01 2017-07-11 @Pay Ip Holdings Llc Email checkout system for completing website cart checkout
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
US9208536B2 (en) 2013-09-27 2015-12-08 Kofax, Inc. Systems and methods for three dimensional geometric reconstruction of captured image data
US9355312B2 (en) 2013-03-13 2016-05-31 Kofax, Inc. Systems and methods for classifying objects in digital images captured using mobile devices
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
US20140279424A1 (en) * 2013-03-15 2014-09-18 Elwha Llc Devices, methods, and systems for technologically shifting options and modalities
US20140279553A1 (en) 2013-03-15 2014-09-18 @Pay Ip Holdings Llc Vendor token generator
US9536232B2 (en) 2013-03-15 2017-01-03 Square, Inc. Transferring money using email
US12347267B2 (en) 2013-03-15 2025-07-01 Aristocrat Technologies, Inc. Game management for mobile and remote gaming devices
US9600976B2 (en) 2013-03-15 2017-03-21 Nguyen Gaming Llc Adaptive mobile device gaming system
US20140279425A1 (en) * 2013-03-15 2014-09-18 Elwha Llc Methods, systems, and devices for handling multiple disparate systems
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
US12347268B2 (en) 2013-03-15 2025-07-01 Aristocrat Technologies, Inc. Adaptive mobile device gaming system
US9449321B2 (en) 2013-03-15 2016-09-20 Square, Inc. Transferring money using email
US9022286B2 (en) 2013-03-15 2015-05-05 Virtual Electric, Inc. Multi-functional credit card type portable electronic device
US9814970B2 (en) 2013-03-15 2017-11-14 Nguyen Gaming Llc Authentication of mobile servers
US10421010B2 (en) 2013-03-15 2019-09-24 Nguyen Gaming Llc Determination of advertisement based on player physiology
US9483901B2 (en) 2013-03-15 2016-11-01 Nguyen Gaming Llc Gaming device docking station
US11030851B2 (en) 2013-03-15 2021-06-08 Nguyen Gaming Llc Method and system for localized mobile gaming
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
US20140279458A1 (en) * 2013-03-15 2014-09-18 Elwha Llc Devices, methods, and systems for assisting multiple discrete devices
US9495679B2 (en) 2013-03-15 2016-11-15 @Pay Ip Holdings Llc Automated application programming interface (API) system and method
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
US10102512B1 (en) * 2013-03-19 2018-10-16 Wilmington Savings Fund Society, Fsb Systems and methods for financial data transfer
US10339506B2 (en) 2013-03-25 2019-07-02 Swoop Ip Holdings Llc Method and system for a secure registration
WO2014160582A1 (en) 2013-03-28 2014-10-02 Robert Andrew Eckel System and method for transaction authentication
WO2014165974A1 (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
KR101639548B1 (ko) 2013-04-28 2016-07-13 텐센트 테크놀로지(센젠) 컴퍼니 리미티드 객체 처리 시스템 및 방법
US20140337235A1 (en) 2013-05-08 2014-11-13 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
US10387874B1 (en) 2013-05-30 2019-08-20 Google Llc Mobile transactions with merchant identification codes
EP2983120A4 (en) * 2013-05-31 2016-05-25 Huawei Tech Co Ltd METHOD AND DEVICE FOR PROCESSING TRANSMISSION INFORMATION
CA2914629C (en) 2013-06-05 2022-10-04 Morphotrust Usa Inc. 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
US20160098706A1 (en) * 2013-08-08 2016-04-07 Marvin T. Ling Method and apparatus for conducting fund transfer between two entities and its application as a cell phone wallet
CN110033359B (zh) 2013-08-15 2020-08-07 斯吾普知识产权控股有限责任公司 使用由spf/dkim流程验证的smtp电子邮件提高安全性的系统及方法
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
US9727866B2 (en) 2013-10-15 2017-08-08 Intuit Inc. Methods systems and computer program products for verifying consumer identity during transaction
US9165291B1 (en) 2013-10-15 2015-10-20 Square, Inc. Payment transaction by email
US9286514B1 (en) 2013-10-17 2016-03-15 United Services Automobile Association (Usaa) Character count determination for a digital image
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
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
US9412135B2 (en) 2013-10-29 2016-08-09 Bank Of America Corporation Check data lift for online accounts
US9317745B2 (en) 2013-10-29 2016-04-19 Bank Of America Corporation Data lifting for exception processing
US9384393B2 (en) 2013-10-29 2016-07-05 Bank Of America Corporation Check data lift for error detection
US9589276B2 (en) * 2013-11-04 2017-03-07 Mastercard International Incorporated System and method for card-linked services
US10832278B2 (en) 2013-11-04 2020-11-10 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
US9754275B2 (en) * 2013-11-04 2017-09-05 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
WO2015073920A1 (en) 2013-11-15 2015-05-21 Kofax, Inc. Systems and methods for generating composite images of long documents using mobile video data
US8910868B1 (en) 2013-11-27 2014-12-16 Square, Inc. Firmware management
US10068276B2 (en) 2013-12-05 2018-09-04 Walmart Apollo, Llc System and method for coupling a mobile device and point of sale device to transmit mobile shopping cart and provide shopping recommendations
US8931699B1 (en) 2013-12-11 2015-01-13 Square, Inc. Bidirectional audio communication in reader devices
US9633236B1 (en) 2013-12-11 2017-04-25 Square, Inc. Power harvesting in reader devices
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
US12548018B2 (en) 2013-12-18 2026-02-10 Payrange Llc Device and method for providing external access to multi-drop bus peripheral 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
US9659296B2 (en) 2013-12-18 2017-05-23 PayRange Inc. Method and system for presenting representations of payment accepting unit events
US8856045B1 (en) 2013-12-18 2014-10-07 PayRange Inc. Mobile-device-to-machine payment systems
US11983692B2 (en) * 2013-12-18 2024-05-14 PayRange Inc. Mobile payment module with dual function radio transmitter
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
US11074580B2 (en) 2013-12-18 2021-07-27 PayRange Inc. Device and method for providing external access to multi-drop bus peripheral devices
US10019724B2 (en) 2015-01-30 2018-07-10 PayRange Inc. Method and system for providing offers for automated retail machines via mobile devices
US11481781B2 (en) 2013-12-18 2022-10-25 PayRange Inc. Processing interrupted transaction over non-persistent network connections
US11475454B2 (en) 2013-12-18 2022-10-18 PayRange Inc. Intermediary communications over non-persistent network connections
US12086811B2 (en) 2013-12-18 2024-09-10 PayRange Inc. Processing interrupted transactions over non-persistent network connections
US11966895B2 (en) 2013-12-18 2024-04-23 PayRange Inc. Refund centers for processing and dispensing vending machine refunds via an MDB router
US12093962B2 (en) 2013-12-18 2024-09-17 PayRange Inc. Intermediary communications over non-persistent network connections
US20150170133A1 (en) * 2013-12-18 2015-06-18 Mozido, Inc. System, apparatus and method for proximity recognition and transfer
US9875473B2 (en) 2013-12-18 2018-01-23 PayRange Inc. Method and system for retrofitting an offline-payment operated machine to accept electronic payments
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
US20150178819A1 (en) 2013-12-23 2015-06-25 @Pay Ip Holdings Llc Alternative email-based website checkouts
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 腾讯科技（深圳）有限公司 基于即时通信或社交应用的数据处理方法和装置
US10250535B2 (en) 2014-01-08 2019-04-02 Swoop Ip Holdings Llc Email based e-commerce using embedded forms
WO2015105688A1 (en) 2014-01-09 2015-07-16 @Pay Ip Holdings, Llc Email based e-commerce with qr code barcode, image recognition alternative payment method and biometrics
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
US11037129B1 (en) * 2014-02-24 2021-06-15 Groupon, Inc. Consumer device presence-based transaction session
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
US9864986B1 (en) 2014-03-25 2018-01-09 Square, Inc. Associating a monetary value card with a payment object
US9619792B1 (en) 2014-03-25 2017-04-11 Square, Inc. Associating an account with a card based on a photo
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
US10026083B1 (en) 2014-05-11 2018-07-17 Square, Inc. Tab for a venue
US20150332223A1 (en) 2014-05-19 2015-11-19 Square, Inc. Transaction information collection for mobile payment experience
US10869170B2 (en) 2014-05-19 2020-12-15 Swoop Ip Holdings Llc Email based e-commerce with SMS and social media
US10304043B1 (en) 2014-05-21 2019-05-28 Square, Inc. Multi-peripheral host device
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
US10445826B1 (en) 2014-05-26 2019-10-15 Square, Inc. Merchant financing system
US9984412B1 (en) * 2014-05-26 2018-05-29 Square, Inc. Approaches to location based merchant financing
US10614445B1 (en) * 2014-06-04 2020-04-07 Square, Inc. Proximity-based payments
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
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
US12248939B2 (en) 2014-06-30 2025-03-11 Payrange Llc Intermediary communications over non-persistent network connections
US12548032B2 (en) 2014-06-30 2026-02-10 Payrange Llc Processing interrupted transactions over non-persistent network connections
US9256770B1 (en) 2014-07-02 2016-02-09 Square, Inc. Terminal case with integrated reader and shortened base
US20160005035A1 (en) * 2014-07-02 2016-01-07 Mistral Mobile Secure financial transaction using plain text sms
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 浪潮软件集团有限公司 一种智能数据分析比对推送方法
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
US20160125371A1 (en) 2014-10-31 2016-05-05 Square, Inc. Money transfer using canonical url
US9836786B1 (en) 2014-11-13 2017-12-05 Square, Inc. Intelligent division of funds across merchant accounts
WO2016089993A1 (en) * 2014-12-03 2016-06-09 D Alisa Albert Proprietary token-based universal payment processing system
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 阿里巴巴集团控股有限公司 基于计算机系统的业务处理方法及其装置
CN104376455A (zh) * 2014-12-04 2015-02-25 苏州海博智能系统有限公司 一种银行卡转账支付的方法
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
EP3248159A4 (en) 2015-01-19 2018-08-01 Royal Bank Of Canada Secure processing of electronic payments
US11354651B2 (en) 2015-01-19 2022-06-07 Royal Bank Of Canada System and method for location-based token transaction processing
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
US10019698B1 (en) 2015-02-13 2018-07-10 Square, Inc. Merchant cash advance payment deferrals
US9825959B2 (en) * 2015-02-13 2017-11-21 Ebay Inc. Portable electronic device with user-configurable API data endpoint
US10664836B2 (en) * 2015-02-17 2020-05-26 Dave's Slingshot, LLC Payment system and method
US11068866B1 (en) * 2015-02-17 2021-07-20 Wells Fargo Bank, N.A. Real-time interbank transactions systems and methods
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
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
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
US10621567B2 (en) 2015-07-01 2020-04-14 Mastercard International Incorporation Electronic grace period billing
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
US11599879B2 (en) 2015-07-02 2023-03-07 Royal Bank Of Canada Processing of electronic transactions
US10387845B2 (en) 2015-07-10 2019-08-20 Bank Of America Corporation System for facilitating appointment calendaring based on perceived customer requirements
US10387846B2 (en) 2015-07-10 2019-08-20 Bank Of America Corporation System for affecting appointment calendaring on a mobile device based on dependencies
CN106357589B (zh) * 2015-07-13 2019-12-27 腾讯科技（深圳）有限公司 一种可支配对象处理方法及装置
US11416829B2 (en) 2015-07-13 2022-08-16 Swoop Ip Holdings Llc Myriad of payment methods with alternate payment controls
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
US10410194B1 (en) 2015-08-19 2019-09-10 Square, Inc. Customized tipping flow
US10127532B1 (en) 2015-08-19 2018-11-13 Square, Inc. Customized transaction 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 广东亿迅科技有限公司 一种客户信息管理系统及方法
US11983696B2 (en) 2015-11-25 2024-05-14 Swoop Ip Holdings Llc Web-based checkout and alternate login based on secure identifiers and alternate link formats
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
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
US10853784B2 (en) 2016-01-04 2020-12-01 Bank Of America Corporation Real-time determination of resource availability for usage
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
KR102752339B1 (ko) * 2016-01-25 2025-01-10 애플 인크. 비-네이티브 크리덴셜들과 함께 전자 디바이스들을 사용하는 거래들의 수행
US10410200B2 (en) 2016-03-15 2019-09-10 Square, Inc. Cloud-based generation of receipts using transaction information
US10628811B2 (en) 2016-03-15 2020-04-21 Square, Inc. System-based detection of card sharing and fraud
CN108885670B (zh) * 2016-03-15 2022-04-08 维萨国际服务协会 用于交互的验证密码
US10080132B2 (en) 2016-03-28 2018-09-18 Bank Of America Corporation System for adaptation of multiple digital signatures in a distributed network
US10135817B2 (en) 2016-03-28 2018-11-20 Bank Of America Corporation Enhancing authentication and source of proof through a dynamically updatable biometrics database
US10039113B2 (en) 2016-03-28 2018-07-31 Bank Of America Corporation Intelligent resource procurement system based on physical proximity to related resources
US9507984B1 (en) 2016-03-28 2016-11-29 Bank Of America Corporation Resource tag generation and deployment for resource valuation and distribution
US9743272B1 (en) 2016-03-28 2017-08-22 Bank Of America Corporation Security implementation for resource distribution
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
US10038607B2 (en) 2016-06-17 2018-07-31 Bank Of America Corporation System for aggregated machine-initiated resource distribution
US10796253B2 (en) 2016-06-17 2020-10-06 Bank Of America Corporation System for resource use allocation and 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
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
US12130937B1 (en) 2016-07-01 2024-10-29 Wells Fargo Bank, N.A. Control tower for prospective transactions
US11386223B1 (en) 2016-07-01 2022-07-12 Wells Fargo Bank, N.A. Access control tower
US11615402B1 (en) 2016-07-01 2023-03-28 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
US10992679B1 (en) 2016-07-01 2021-04-27 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
US9881296B1 (en) 2016-09-12 2018-01-30 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 苹果公司 促进用户帐户之间的资金转移
US11138595B2 (en) * 2017-05-30 2021-10-05 Visa International Service Association System, method, and computer program product for maintaining transaction integrity over public networks
CN110832491A (zh) * 2017-06-13 2020-02-21 维萨国际服务协会 用于控制交易速度限制的方法、系统和计算机程序产品
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
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
US20190043037A1 (en) 2017-08-02 2019-02-07 Marco Andres Guirola Martin System and method for providing secured services
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
US11979390B2 (en) 2017-09-20 2024-05-07 Swoop Ip Holdings Llc Email-based authentication for account login, account creation and security for passwordless transactions
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
US10692140B1 (en) 2017-11-15 2020-06-23 Square, Inc. Customized financing based on transaction information
US10796363B1 (en) 2017-11-15 2020-10-06 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
US20190180363A1 (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
AU2019209146A1 (en) * 2018-01-22 2020-06-11 Mastercard International Incorporated Provisioning of payment acceptance to payment account holders
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
US11488195B1 (en) 2018-04-27 2022-11-01 Block, Inc. Reward offer redemption for payment cards
US11030752B1 (en) 2018-04-27 2021-06-08 United Services Automobile Association (Usaa) System, computing device, and method for document detection
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
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
US11769147B2 (en) * 2018-08-30 2023-09-26 International Business Machines Corporation Secure smart note
US11893554B2 (en) 2018-08-30 2024-02-06 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
US12200165B1 (en) 2018-09-27 2025-01-14 Iqx Corp. Automated silent network authentication protocol security, verification, and access control for cellular handheld devices
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
US11210730B1 (en) 2018-10-31 2021-12-28 Square, Inc. Computer-implemented methods and system for customized interactive image collection based on customer data
US11244382B1 (en) 2018-10-31 2022-02-08 Square, Inc. Computer-implemented method and system for auto-generation of multi-merchant interactive image collection
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
CN109858902A (zh) * 2019-02-25 2019-06-07 上海风汇网络科技有限公司 一种基于http协议的服务器、用户终端收款系统及收款方法
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
WO2021062513A1 (en) * 2019-09-30 2021-04-08 PANDA Communications Corp. Peer-to-peer cash ubering
US11367067B2 (en) * 2019-10-04 2022-06-21 Bank Of America Corporation System for secure distribution of peer requests for resources
PT115852A (pt) * 2019-10-20 2021-04-20 Jose Antonio Gomes Ferreira Neto Método para a interoperabilidade de aplicações de dinheiro móvel utilizando o iban
US11232440B2 (en) * 2019-10-29 2022-01-25 Clover Network, Llc Dual device point of sale system using short-range wireless connection
US11328294B2 (en) * 2019-11-14 2022-05-10 Horus Foster, Inc. Anonymous peer-to-peer near-field communication 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
US12399958B2 (en) 2020-07-21 2025-08-26 Payrange Llc Systems and methods for tool activation and display cabinet locking
US12592134B2 (en) 2020-07-21 2026-03-31 Payrange Llc Systems and methods for tool activation and display cabinet locking
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
US11100490B1 (en) * 2020-09-10 2021-08-24 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
US11699157B1 (en) * 2020-09-30 2023-07-11 Chime Financial, Inc. Dynamic generation of digital messages with unique links for direct-to-merchant payments
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
WO2022178172A1 (en) * 2021-02-19 2022-08-25 Highline Technologies Inc. A 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
KR20260036049A (ko) 2021-06-02 2026-03-13 페이멘터스 코포레이션 사용자 계정 연계 결제 및 청구, 통합 디지털 청구인 결제 지갑을 위한 방법, 장치 및 시스템
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
US12238108B2 (en) 2021-07-30 2025-02-25 Ramp Business Corporation Communication platform server integration
US20230038555A1 (en) * 2021-08-06 2023-02-09 Bank Of America Corporation Value Exchange and Intelligent Recommendation Engine
WO2023069097A1 (en) * 2021-10-21 2023-04-27 Visa International Service Association System, method, and computer program product for real-time transactions
US12367467B2 (en) 2021-12-20 2025-07-22 Block, Inc. Integrated interactive elements for multi-user transactions
US20230267444A1 (en) * 2022-02-18 2023-08-24 Bank Of America Corporation Proximity-based device pairing system via acoustic communication for secure resource transfer
US11836690B1 (en) 2022-04-12 2023-12-05 Wells Fargo Bank, N.A. Systems and methods for private network issuance of digital currency
US12155641B1 (en) 2022-04-15 2024-11-26 Wells Fargo Bank, N.A. Network access tokens and meta-application programming interfaces for enhanced inter-enterprise system data promulgation and profiling
CN117557263A (zh) * 2022-08-05 2024-02-13 中国人民银行数字货币研究所 基于数字货币钱包系统的结算方法和装置及钱包系统
US20240054471A1 (en) * 2022-08-12 2024-02-15 Mastercard International Incorporated System and method for providing push payment transaction processing in a card-present environment
US12340351B2 (en) * 2022-09-16 2025-06-24 Vocalink International Limited Systems and methods for use in cancellation of or closure of network requests
JP2024066776A (ja) * 2022-11-02 2024-05-16 コグニティブリサーチラボ株式会社 データ送受信システム及びデータ送受信方法
US20240320651A1 (en) * 2023-03-20 2024-09-26 Kakao Corp. Method and apparatus for payment service
US20240370835A1 (en) * 2023-05-02 2024-11-07 Meir Dahan Method and system for enabling credit card owners to allocate money to recipients to make cardless payments by credit card terminals
US12250225B2 (en) 2023-07-18 2025-03-11 Bank Of America Corporation System and method for the validation of electronic data transfers in a distributed network via self-directed image data
KR102667060B1 (ko) * 2023-09-15 2024-05-20 주식회사 트래블월렛 분할 결제를 지원하는 결제 시스템 및 그의 분할 결제 수행 방법
US12578977B2 (en) 2023-11-27 2026-03-17 Wells Fargo Bank, N.A. Omni-channel micro frontend control plane
US20250200550A1 (en) * 2023-12-18 2025-06-19 Michelle T Fisher Using a non-browser based application for mobile banking
US12211095B1 (en) 2024-03-01 2025-01-28 United Services Automobile Association (Usaa) System and method for mobile check deposit enabling auto-capture functionality via video frame processing
US12524747B2 (en) 2024-03-08 2026-01-13 Wells Fargo Bank, N.A. Systems and methods for proximity-based transaction limit threshold override
US20260017699A1 (en) * 2024-07-12 2026-01-15 Wells Fargo Bank, N.A. Systems and methods for secure and monitored peer-to-peer item exchange

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 Novatel Communications Ltd. 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
EP0599244B1 (en) * 1992-11-27 1999-04-14 Denso Corporation Portable electronic device
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 (en) * 1995-07-06 1997-01-23 Hitachi, Ltd. Electronic money sending system
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
WO1997045814A1 (en) * 1996-05-24 1997-12-04 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
US5937396A (en) * 1996-12-04 1999-08-10 Konya; Arpad System for ATM/ATM transfers
US6175922B1 (en) * 1996-12-04 2001-01-16 Esign, Inc. Electronic transaction systems and methods therefor
EP0917327B1 (en) * 1996-12-13 2002-07-24 TELEFONAKTIEBOLAGET L M ERICSSON (publ) Method and system for performing electronic money transactions
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
US6601761B1 (en) * 1998-09-15 2003-08-05 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
AU784041B2 (en) * 1999-11-30 2006-01-19 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 정상훈 통신 단말 번호를 이용한 송금 시스템 및 송금 방법
ATE321402T1 (de) * 2000-05-17 2006-04-15 Symstream Technology Holdings Opd (octave pulse data) - verfahren und vorrichtung
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
AU2002226941A1 (en) * 2000-11-20 2002-06-03 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
KR100485759B1 (ko) 2001-01-26 2005-04-28 주식회사 이모시스텍 메신저 기능을 이용한 대금지불 인증 방법
CA2332656A1 (en) 2001-01-26 2002-07-26 Certapay Inc. Online payment transfer and identity management system and method
US7249094B2 (en) * 2001-02-26 2007-07-24 Paypal, Inc. System and method for depicting on-line transactions
US7805310B2 (en) * 2001-02-26 2010-09-28 Rohwer Elizabeth A Apparatus and methods for implementing voice enabling applications in a converged voice and data network environment
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
US7249256B2 (en) * 2001-07-11 2007-07-24 Anoto Ab Encryption protocol
US7225156B2 (en) * 2001-07-11 2007-05-29 Fisher Douglas C Persistent dynamic payment service
KR200250912Y1 (ko) * 2001-07-28 2001-11-22 (주)제이브이메디 약자동분포기의 수동분배용 보조트레이
US7191151B1 (en) * 2001-08-23 2007-03-13 Paypal, Inc. Instant availability of electronically transferred funds
US20050044042A1 (en) * 2001-08-31 2005-02-24 Dennis Mendiola Financial transaction system and method using electronic messaging
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
WO2003077572A1 (en) * 2002-03-13 2003-09-18 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
AU2003247394A1 (en) * 2002-05-21 2003-12-12 Tekelec Methods and systems for performing 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
CA2505030A1 (en) * 2002-11-05 2004-05-21 Aaron Whiteman Remote purchasing system and method
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
EP1492068A3 (en) * 2003-06-24 2009-08-05 LG TeleCom, Ltd. Method for providing banking services by use of mobile communication system
EP1654712A1 (en) * 2003-07-02 2006-05-10 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
US20050240526A1 (en) * 2004-04-26 2005-10-27 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
EA011312B1 (ru) * 2004-06-29 2009-02-27 Текстура Корпорейшн Система и способ управления платежом в строительстве
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
EP1807966B1 (en) * 2004-10-20 2020-05-27 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
CA2541283A1 (en) * 2005-04-05 2006-10-05 Guy David Fietz Online debit cardless debit transaction system and method
CA2542068C (en) * 2005-04-05 2016-01-26 Dxstorm.Com Inc. Electronic balance checking and credit approval system for use in conducting electronic transactions
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
WO2007011840A2 (en) * 2005-07-15 2007-01-25 Revolution Money, Inc. System and method for new execution and management of financial and data transactions
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
EP1941698B1 (en) * 2005-10-05 2011-10-05 Privasphere AG Method and devices for user authentication
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
CA2647602A1 (en) 2006-03-30 2008-03-06 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 (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
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
US12511627B2 (en) 2012-03-07 2025-12-30 Early Warning Services, Llc System and method for transferring funds
US11948148B2 (en) 2012-03-07 2024-04-02 Early Warning Services, Llc System and method for facilitating transferring funds
US11715075B2 (en) 2012-03-07 2023-08-01 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
US11593800B2 (en) 2012-03-07 2023-02-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
US11373182B2 (en) 2012-03-07 2022-06-28 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
US11321682B2 (en) 2012-03-07 2022-05-03 Early Warning Services, Llc System and method for transferring funds
US10839359B2 (en) 2015-03-23 2020-11-17 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
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
US10846662B2 (en) 2015-03-23 2020-11-24 Early Warning Services, Llc Real-time determination of funds availability for checks and ACH items
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
US11151523B2 (en) 2015-07-21 2021-10-19 Early Warning Services, Llc Secure transactions with offline device
US11151522B2 (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
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
US12299658B2 (en) 2015-07-21 2025-05-13 Early Warning Services, Llc Secure real-time transactions
US11062290B2 (en) 2015-07-21 2021-07-13 Early Warning Services, Llc Secure real-time transactions
US10970695B2 (en) 2015-07-21 2021-04-06 Early Warning Services, Llc Secure real-time transactions
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
US10762477B2 (en) 2015-07-21 2020-09-01 Early Warning Services, Llc Secure real-time processing of payment transactions
US11922387B2 (en) 2015-07-21 2024-03-05 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
US12499427B2 (en) 2021-08-31 2025-12-16 Early Warning Services, Llc Direct electronic bill payment with real-time funds availability

Also Published As

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

Similar Documents

Publication Publication Date Title
US7873573B2 (en) Virtual pooled account for mobile banking
US8249965B2 (en) Member-supported mobile payment system
BRPI0710021A2 (pt) sistema de pagamento individualizado móvel
US20070255662A1 (en) Authenticating Wireless Person-to-Person Money Transfers
US20070244811A1 (en) Mobile Client Application for Mobile Payments
US10171961B1 (en) Transaction authorization service
EP2266083A2 (en) Network-based viral payment system
US8352376B2 (en) System and method for authorization of transactions
US12518285B2 (en) Systems and methods for funds transfers via a token management system
CN101454794A (zh) 移动的个人之间支付系统
US20110320347A1 (en) Mobile Networked Payment System
US20090319425A1 (en) Mobile Person-to-Person Payment System
US20130218769A1 (en) Mobile Funding Method and 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
EP2304678A1 (en) Mobile payment system
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
B11A Dismissal acc. art.33 of ipl - examination not requested within 36 months of filing
B11Y Definitive dismissal - extension of time limit for request of examination expired [chapter 11.1.1 patent gazette]