MX2008012503A - Sistema movil de pago de persona a persona. - Google Patents

Sistema movil de pago de persona a persona.

Info

Publication number
MX2008012503A
MX2008012503A MX2008012503A MX2008012503A MX2008012503A MX 2008012503 A MX2008012503 A MX 2008012503A MX 2008012503 A MX2008012503 A MX 2008012503A MX 2008012503 A MX2008012503 A MX 2008012503A MX 2008012503 A MX2008012503 A MX 2008012503A
Authority
MX
Mexico
Prior art keywords
user
account
transaction
payment
mobile
Prior art date
Application number
MX2008012503A
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 MX2008012503A publication Critical patent/MX2008012503A/es

Links

Classifications

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

Abstract

Una plataforma móvil y servicio de pago proporciona una forma fácil y rápida para realizar pagos por usuarios de dispositivos móviles. La plataforma también se interconecta con canales no móviles y dispositivos tales como correo electrónico, correo instantáneo, y la Web. En una implementación, se acceden a fondos del dispositivo móvil del titular de una cuenta tal como un teléfono móvil o un asistente digital personal para realizar o recibir pagos. Pueden llevarse a cabo transacciones financieras en una base de persona a persona (P2P) o de persona a comerciante (P2M), donde cada parte es identificada por un indicador único tal como un número telefónico o código de barras. Las transacciones pueden ser solicitadas a través de cualquier cantidad de medios que incluyen mensajería SMS, Web, correo electrónico, correo instantáneo, una aplicación de cliente móvil, una aplicación insertable de mensaje instantáneo o elemento de construcción fundamental para interfaces gráficas. La aplicación de cliente móvil, residente en el dispositivo móvil, simplifica el acceso y realiza transacciones financieras en una forma rápida y segura.

Description

SISTEMA MÓVIL DE PAGO DE PERSONA A PERSONA DESCRIPCIÓN DE LA INVENCIÓN Una parte de la descripción de este documento de patente contiene material que está sujeto a protección de derechos de autor. El titular de los derechos de autor no tiene objeción a la reproducción por facsímil por cualquiera del documento de patente o de la descripción de patente, como aparece en el archivo y registros de la Oficina de Patentes y Marcas de los Estados Unidos aunque, por otro lado, reserva todos los derechos de derechos de autor cualquiera que fueren . Esta solicitud de patente reclama el beneficio de las solicitudes de patentes Norteamericanas 60/744,013, presentada el 30 de marzo de 2006; 60/744,930, presentada el 15 de abril de 2006; y 60/870, 484, presentada el 18 de diciembre, de 2006, las cuales se incorporan para referencia junto con todas las demás referencias mencionadas en esta solicitud . Las modalidades de la presente invención se refieren a sistemas y técnicas para efectuar transacciones financieras a través de dispositivos móviles, tales como teléfonos móviles , o celulares, y en particular, a una infraestructura móvil y método de transferencia de pago individualizado para transferir pagos. Además, las modalidades de la presente invención se refieren a un sistema de transacción financiera y, en particular, a un sistema de transacción financiera de bucle cerrado para transacciones de persona a persona y de consumidor a comercio y métodos para utilizar el sistema de transacción financiera. Históricamente, el titular de una cuenta que deseara concluir una transacción financiera para comprar un artículo dependía de diversos instrumentos financieros tal como la divisa, cheques, tarjetas de crédito o tarjetas de débito. Desafortunadamente, estos tipos de instrumentos financieros tienen ciertos problemas de seguridad y la prevención de fraudes es un gasto importante de la rentabilidad de la industria de pagos. Cuando se pierde o se es robado dinero en efectivo, por lo general no existe otro recurso que aceptar la pérdida Con otros instrumentos financieros, la pérdida no es el problema principal, sino que el fraude ocasiona pérdidas importantes para la industria de pagos. De hecho, el fraude de tarjetas de crédito, tarjetas de débito y cheques han sido y continúa siendo el problema principal para la industria. Una razón de que el fraude de cheques sea tan común surge debido a la necesidad de presentar físicamente un cheque al banco del pagador. Por lo tanto, cuando se acepta un cheque en una transacción financiera, no se garantiza que el cheque tenga fondos. En cambio, el cheque es solamente una pieza de papel donde la comprobación de validez del banco de que éste se extienda debe verificarse junto con la cuenta que se utiliza y la firma utilizada para autorizar el pago. Con una tarjeta de crédito o de débito, puede ser que el usuario no esté autorizado, pero puede acumular cargos considerables antes de que el emisor pueda desactivar la cuenta. Claramente, lo que se necesita es un sistema de pago en el que el receptor de fondos en una transacción financiera pueda verificar fácilmente la validez de la entidad que posee los fondos, la cuenta y el saldo y la identidad de la persona con el teléfono. Además, lo que se necesita es una forma más segura de ' tener acceso a las tarjetas de crédito y de débito para concluir transacciones financieras . Aunque cada uno de los instrumentos financieros mencionados en lo anterior ha funcionado bien en el pasado, está claro que los consumidores desean un método más seguro y simple para concluir transacciones financieras. El uso cada vez mayor de tarjetas de crédito proporciona una amplia evidencia de que los consumidores prefieren utilizar sistemas de pago electrónico en lugar de llevar grandes cantidades de dinero en efectivo o experimentar la molestia de extender múltiples cheques para compras pequeñas. Aun con la adopción generalizada de sistemas de pago electrónico, está claro que existe una necesidad cada vez mayor de sistemas de pago electrónico rápidos, más baratos y más convenientes para finalizar transacciones financieras. Además, existe la necesidad de un sistema de pago electrónico que sea más individualizado, de tal modo que las transacciones financieras se concluyan fácilmente en una forma similar a las transacciones en efectivo. A pesar del uso en aumento de tarjetas de crédito, aún existe una gran población global de personas que dependen principalmente de transacciones en efectivo y que aún necesitan un sistema de pago electrónico conveniente y económico para enviar y recibir dinero. Esta necesidad ha conducido al uso cada vez mayor de tarjetas de débito prepagadas . Desafortunadamente, las tarjetas de débito están diseñadas principalmente para que un consumidor pueda cobrar la tarjeta de débito en un comercio que ha invertido en una terminal de transacción de punto de venta. Es difícil que una persona transfiera una parte de la cantidad acumulada en una tarjeta de crédito prepagada a otra persona sin implicar el desplazamiento hacia un banco o un comercio con una terminal de POS. Lo que se necesita es un sistema de pago electrónico que permita que las transacciones financieras se concluyan entre personas y sin la necesidad de implicar directamente a una institución financiera de tercera parte o a una institución financiera externa. Aunque muchas personas no tienen acceso a terminales de POS, la mayoría tiene acceso a un dispositivo de comunicación inalámbrica portátil, por lo general referido como celular (o móvil) o dispositivos móviles. De hecho, actualmente las personas habitualmente aprovechan las características adicionales proporcionadas por un teléfono móvil típico tales como mensajería de textos, fotografía y escuchar música, ya que los dispositivos móviles han evolucionado para incluir capacidades integradas de PDA, MP3, buscapersonas , reproductor y correo-electrónico. Ha existido un crecimiento explosivo en dispositivos de telefonía móvil y otros dispositivos portátiles que manejan comunicaciones ya sea a través de voz, correo-electrónico, mensajería de textos del SMS, mensajería instantánea y la Internet. Por lo general las personas recordarán llevar sus teléfonos celular o móvil con ellos aun si olvidan llevar su billetera o llaves del coche. Los teléfonos móviles son comunes en los Estados Unidos y en muchos países en todo el mundo. En 2005, se calculaban 2.14 billones de suscritores de teléfonos móviles. Aproximadamente el 80% de la población mundial tiene cobertura de telefonía móvil. Por lo tanto, existe una gran necesidad de que un sistema permita que los teléfonos móviles envíen y reciban pagos, al igual que con efectivo, y permita otras transacciones bancarias móviles y financieras. Intentos por crear un sistema de pago móvil que utiliza dispositivos celulares han tenido un éxito combinado principalmente debido a que el teléfono celular debe tener un dispositivo de circuito adicional (o "chip") que se utiliza para acumular saldos de cuenta e información de cuenta. Cuando la persona que posee el teléfono desea transferir fondos, los fondos se deducen en el punto de venta desde el chip y se transfieren después a la institución financiera para que la institución financiera los registre. Claramente, este retardo entre el momento en que se realiza la venta y el momento en que se registra la venta es ineficaz y riesgoso de perder las ventas si el equipo de POS del comercio funciona mal antes de que se registre la venta. Además, si el teléfono se pierde, el saldo de cuenta puede utilizarse por quienquiera que tenga el teléfono. Aunque este sistema proporciona una mejor protección contra la pérdida de fondos y es superior para llevar dinero en efectivo, el sistema carece de una seguridad adecuada para proteger al titular de una cuenta contra el uso inapropiado por otros. Además, una tarjeta de crédito indica que al titular se le ha otorgado una línea de crédito de un banco u otro emisor y le permite al titular realizar compras o retirar dinero en efectivo hasta una cantidad preestablecida. Los intereses se cobran con base en los términos del acuerdo de la tarjeta de crédito y, algunas veces, al titular se le cobra una cuota anual. Tradicionalmente, al titular se le asigna una tarjeta de plástico que porta un número de cuenta.
Las transacciones con la tarjeta de crédito utilizan redes de propiedad exclusiva por las que los comercios pagan para establecer transacciones. Debido a la naturaleza de propiedad exclusiva del sistema de pago, tales costos de los sistemas son elevados. Asimismo, debido a que múltiples partes están implicadas en una transacción con tarjeta de crédito, por lo general tales sistemas son referidos como sistemas financieros de "bucle abierto" . La Figura 34 muestra un ejemplo de una red de propiedad exclusiva que incluye una terminal 3401 de punto de venta (POS) para iniciar transacciones en una ubicación del comercio y un procesador 3402 de pagos conectado con la terminal 3401 de POS mediante una red 3403 de propiedad exclusiva. En algunos casos, la red de propiedad exclusiva no es más que una conexión a la Internet. El procesador 3402 de pagos se conecta, a su vez, mediante una red 3404 de propiedad exclusiva a un intercambio 3408 de tarjetas de crédito. Para iniciar la transacción, un consumidor puede presentar una tarjeta 3406 de crédito o, de manera alterna, un llavero 3407 de RFID en la terminal de POS. Un llavero es un tipo de ficha de seguridad: un dispositivo pequeño de hardware con mecanismo de almacenamiento integrado. Tanto la tarjeta 3406 de crédito y el llavero 3407 incluyen información codificada que la terminal de POS detecta y reenvía al procesador 3402 de transacciones a través de la red 3403 de propiedad exclusiva. Desafortunadamente, tanto la tarjeta de crédito como el llavero no pueden funcionar sin el acceso a la terminal de POS, ya sea en proximidad o a través del teléfono. El procesador 3402 de transacciones envía la transacción al intercambio de tarjetas de crédito (una red de entidades financieras que se comunican para gestionar el procesamiento, compensación bancaria y establecimiento de transacciones con tarjeta de crédito) a través de la red 3404 privada. El intercambio de tarjetas de crédito enruta la transacción hacia el emisor 3409 de la tarjeta de crédito del cliente. El emisor identifica al cliente con base en el número de cuenta detectado y determina el límite de crédito disponible antes de aprobar o de rechazar la transacción. Si se aprueba la transacción, la cantidad se reenvía al procesador 3405 bancario del comercio a través del intercambio de tarjetas de crédito agregando la cantidad a la cuenta de crédito que el banco mantiene para el comercio. Puesto que la información para la transacción se transporta en redes de propiedad exclusiva, los comercios pagan por un servicio mensual excesivo por el privilegio de aceptar tarjetas de crédito y para tener acceso a estas redes de propiedad exclusiva. Los comercios además pagan un cargo sustancial por transacción para cada transacción. Por ejemplo, para manejar una transacción sencilla para comprar una botella de agua en un minisúper por $1.00, el comercio puede incurrir en un cargo por transacción de aproximadamente $0.25 y 3 por ciento de la cantidad de transacción aunque cargos mucho más altos son típicos si el comercio incurre en demasiados contracargos. Después de dar cuenta de sus gastos generales, el cargo por transacción puede ser una parte sustancialmente de los gastos generales y, en algunos casos, puede ser más que el margen de ganancias en un artículo particular. Desafortunadamente, para muchos pequeños comercios, la combinación del cargo mensual por el servicio y el cargo por intercambio por transacción puede exceder sus ganancias totales en ventas con tarjeta de crédito durante el mes. Para comercios más grandes, la cuota de intercambio es menor que una traba importante en la rentabilidad, pero aún así una erosión no deseada de sus márgenes de ganancia. Las tarjetas de crédito no sólo son un artículo de gasto de "costo elevado" para la mayoría de los comercios, sino que también son objeto de fraude y abuso sustancial. Por ejemplo, si una tarjeta de crédito es robada, cualquiera puede utilizarla en una terminal de POS aún si no es el titular. Para evitar tal uso, en la actualidad muchas terminales de POS incluyen una solicitud de que el consumidor ingrese el código postal al que se envía el recibo de la tarjeta de crédito para autenticar que el consumidor es el titular. Desafortunadamente, la información postal es fácil de conseguir en la Internet, por lo que la solicitud de información adicional no disuade al ladrón hábil de completar la transacción. Sin embargo, el titular se molesta por tener que ingresar tal información superflua. Finalmente, el sistema de tarjeta de crédito de bucle abierto simplemente no se adapta a transacciones de persona a persona en la que una parte no es un comercio. Por ejemplo, si dos estudiantes quieren compartir los gastos para un par de boletos de cine, puede ser que un estudiante desee transferir fondos en forma electrónica al otro estudiante. Sin embargo, la cuota de intercambio por sí sola puede hacer que la transacción sea suficientemente costosa para disuadir su uso. Además, no es probable que cualquiera de los estudiantes esté de acuerdo en pagar la cuota mensual y otros cargos asociados con la cuenta de un comercio con el fin de tener acceso al intercambio de tarjetas de crédito. Por consiguiente, el sistema de bucle cerrado utilizado y operado por los usuarios de la tarjeta de crédito es totalmente inadecuado para transacciones financieras de persona a persona . Por lo tanto, lo que se necesita es un sistema de pago móvil, económico, que permita al titular de una cuenta la flexibilidad de llevar a cabo sus transacciones financieras en cualquier momento y en cualquier lugar. Lo que también se necesita es una "billetera móvil" que las personas puedan llevar consigo como una fuente de dinero en efectivo a la que se tenga acceso desde un teléfono móvil. Además, lo que se necesita es una aplicación de software y servicio gestionado para pagos móviles del consumidor que opere como una billetera móvil en una plataforma de telefonía móvil. Esta billetera móvil debe ser segura, fácil de utilizar y fácil de adquirir para que la capacidad de realizar pagos móviles se encuentre disponible para cualquier titular de una cuenta móvil. Además, lo que se necesita es un sistema de transacciones financieras de bucle cerrado que facilite los pagos sin los cargos de pago sustanciales asociados con los sistemas financieros de bucle cerrado y que tenga un alto nivel de seguridad para el titular, el comercio y otros implicados en las transacciones financieras. Por consiguiente, se describen las siguientes modalidades y descripciones ejemplares de las invenciones. Una plataforma y servicio de pago móvil proporciona una forma fácil y rápida de que los usuarios de dispositivos móviles realicen pagos. La plataforma también se interconecta con canales y dispositivos no móviles tales como correo electrónico, mensajería instantánea y la Web. En una aplicación, se tiene acceso a los fondos desde un dispositivo móvil del titular de una cuenta, tal como un teléfono móvil o un asistente digital personal, para realizar o recibir pagos.
Las transacciones financieras pueden llevarse a cabo en forma de persona a persona (P2P) o persona a comercio (P2M) , donde cada parte se identifica mediante un indicador único tal como un número telefónico o código de barras. Las transacciones pueden solicitarse a través de cualquier número de medios, incluyendo mensajería del SMS, Web, correo electrónico, mensajería instantánea, una aplicación de cliente móvil, una aplicación de conexión a mensajería instantánea o "widget" . La aplicación de cliente móvil, residente en el dispositivo móvil, simplifica el acceso y la realización de transacciones financieras en una forma rápida y segura. La invención proporciona un sistema de pago móvil (MPS) o sistema de pago móvil de persona a persona que permita transacciones de dinero fáciles y rápidas. El teléfono móvil se está volviendo más y más común en todo el mundo. Muchas personas llevan consigo un teléfono móvil o dispositivo de comunicación portátil similar, aún si no llevan consigo una billetera mientras llevan a cabo su vida cotidiana. A través del sistema de pago móvil y de sus teléfonos, los usuarios podrán realizar lo que pueden con una billetera normal y mucho, mucho más. Los usuarios podrán enviar y recibir dinero, pagar servicios, pagar recibos, pagar boletos del cine, pagar comestibles, pagar una niñera, pagar un café y un periódico, pagar en forma instantánea a un amigo, dividir la cuenta de una cena, enviar dinero a los niños, obtener dinero de los padres, obtener dinero en efectivo rápida o de manera inmediata, enviar dinero en efectivo de manera inmediata, pagar o cobrar una apuesta amistosa, pagar fútbol de fantasía, pagar servicios de guardería, pagar derechos de afiliación, rastrear compras, revisar el saldo y más. Como puede apreciarse, el sistema de la invención proporciona muchos beneficios. Los problemas y necesidades que la invención atiende incluyen: El dinero en efectivo puede ser robado y las transacciones en efectivo no pueden rastrearse. Necesidad de alentar a que el dinero en efecto resida en bancos y no en los bolsillos del consumidor. Necesidad de acumulamiento de efectivo barato o depósito pequeño. Necesidad de pagos electrónicos baratos. Necesidad de que pagos electrónicos se encuentren disponibles para todos, en cualquier lugar, en cualquier momento y casi en tiempo real. Necesidad de que los pagos electrónicos den como resultado una forma que pueda emplearse al instante (por ejemplo, tarjeta de débito prepagada para acompañante o a través de un enlace en tiempo real a la cuenta corriente (DDA) del usuario en un banco) . Necesidad de que consumidores con cuenta bancaria y sin cuenta bancaria tengan acceso a los pagos electrónicos. Necesidad de que los pagos electrónicos puedan asociarse con instrumentos financieros existentes tales como de crédito, de débito, de prepago, de nómina y otros. Necesidad de poder cargar a y descargar de instrumentos financieros existentes en tiempo real o casi en tiempo real. Necesidad de que los pagos electrónicos funcionen a través de bancos. Necesidad de que se tenga acceso a los pagos electrónicos a través dispositivos móviles. Necesidad de que se tenga acceso a los pagos electrónicos a través de dispositivos de medios del consumidor tales como PCs, terminales de pago POS, cajas de TV por cable, videograbadoras . digitales (DV s) , cajas satelitales y otros. Necesidad de que se tenga acceso a los pagos electrónicos a través de dispositivos de persona a máquina tales como máquinas expendedoras, parquímetro, quioscos y otros. Necesidad de que los pagos electrónicos funcionen a través de redes electrónicas tales como portadores móviles, portadores de cable, portadores satelitales y otros. Algunos de los beneficios de la invención incluyen que los pagos electrónicos por MPS animen a que el dinero en efectivo permanezca en el banco (y no en los bolsillos del consumidor) . Los pagos electrónicos por MPS son seguros y pueden rastrearse. Los pagos electrónicos por MPS ocurren en tiempo casi real. Los pagos electrónicos por MPS son accesibles para todos, en cualquier momento y en cualquier lugar. El MPS puede proporcionar una tarjeta de débito prepagada para acompañante opcional o no requerida (por ejemplo, MasterCard, Visa u otra) para capacidad de acceso instantáneo a los fondos. Los pagos electrónicos por MPS pueden utilizarse para transacciones de persona a persona (P2P) , así como de persona a comercio (P2M) . Los fondos del MPS se acumulan en cuentas comunes distribuidas del banco corresponsal. Los registros "T" para los fondos del consumidor del MPS se gestionan en el sistema de registro de pago del MPS (para transferencias baratas de P2P y de P2M) . El MPS facilita la funcionalidad de carga manual o automatizada a partir de instrumentos financieros existentes (por ejemplo, de crédito, de débito u otros) . El MPS facilita la funcionalidad de descarga manual o automatizada a partir de instrumentos financieros existentes (por ejemplo de crédito, de débito u otros) . El MPS puede optimizar el procesamiento de carga o descarga (es decir, realización de la carga o descarga en el banco cuando sea posible) . El MPS facilita los pagos electrónicos en una forma interbancaria . El MPS facilita los pagos electrónicos en una forma de ínter-portadora o de ínter-red. El MPS facilita los pagos electrónicos en una forma de ínter-dispositivo o de ínter-canal (es decir, móvil, correo electrónico, Web, mensajería instantánea). Los fondos del MPS son electrónicos, protegidos con un PIN y "en vivo" en el banco. Además, un sistema de transacción financiera de bucle cerrado basado, en parte, en el uso de un teléfono celular o un PDA para realizar o recibir pagos. Las transacciones financieras pueden llevarse a cabo en forma de persona a persona cuando cada parte se identifica mediante un indicador único tal como un número telefónico, dirección de correo electrónico, identificador de mensajería instantánea o código de barras o en forma de consumidor a comercio. Se describen estructuras de cuotas para facilitar la adopción generalizada y para evitar que las personas tengan que llevar consigo dinero en efectivo. En una modalidad, la invención es un sistema de transacciones financieras que incluye una interfaz de consumidor, conectada a una red, que incluye: una interfaz de Web para manejar solicitudes de transacciones de un cliente de explorador web; una interfaz de buscador de Internet móvil para manejar solicitudes de transacciones de un buscador de Internet móvil en un cliente de teléfono móvil; una interfaz del SMS para manejar solicitudes de transacciones mediante el uso de mensajería de textos del SMS; y una interfaz de aplicación de cliente móvil para manejar solicitudes de una aplicación de cliente móvil que se ejecuta en el cliente de teléfono móvil. La interfaz del consumidor puede incluir una interfaz de respuesta de voz interactiva para manejar solicitudes de un canal de voz del teléfono. El sistema puede incluir una cuenta común para usuarios recién registrados, donde los usuarios recién registrados pueden llevar a cabo transacciones de usuarios registrados inmediatamente después del registro. La interfaz de aplicación de cliente móvil puede permitir una transacción de envío de dinero, transacción de carga de cuenta, transacción de descarga de cuenta y transacción de consulta de saldo. La interfaz del consumidor además puede incluir una interfaz de mensajería instantánea para manejar solicitudes de un cliente de mensajería instantánea. El sistema puede incluir: una interfaz de socio financiero; una interfaz del comercio, donde los usuarios a través de la interfaz del consumidor pueden tener acceso a su dinero en un banco conectado al sistema a través de la interfaz de socio financiero y transferir el dinero a los comercios conectados a la interfaz del comercio. El sistema puede incluir un sistema de registro gestionado mediante el sistema de transacción financiera, que registra las transacciones ejecutadas a través de la interfaz del consumidor. El sistema puede incluir una cuenta común gestionada mediante el sistema de transacción financiera, donde una serie de clientes que tienen acceso al sistema a través de la interfaz del consumidor tienen una cuenta en la cuenta común. Puede ser que una serie de clientes no tenga una cuenta en la cuenta común, sino que tengan, en cambio, una cuenta en una institución financiera que tiene acceso al sistema.
En una modalidad, la invención es un método que incluye: proporcionar una interfaz del programa de aplicación para llevar a cabo transacciones con un primer socio financiero; proporcionar una interfaz de mensajería del SMS para recibir solicitudes para llevar a cabo transacciones; y proporcionar una interfaz de aplicación de cliente móvil para recibir solicitudes para llevar a cabo transacciones, donde a través de la interfaz de mensajería del SMS o de la interfaz de cliente móvil, un cliente puede solicitar una transferencia de dinero de una primera cuenta en el primer socio financiero a una segunda cuenta en el segundo socio financiero . El método además puede incluir proporcionar una interfaz del programa de aplicaciones para llevar a cabo transacciones con un segundo socio financiero, donde a través de la interfaz de mensajería del SMS o de la interfaz de cliente móvil, un cliente puede solicitar una transferencia de dinero de una cuenta en el primer socio financiero a una cuenta en el segundo socio financiero. El método puede incluir proporcionar un sistema de registro para registrar las transacciones solicitadas a través de las interfaces de mensajería del SMS y de cliente móvil. En una modalidad, la invención es un método que incluye: presentar una primera pantalla en un panel de visualización de un teléfono móvil para mostrar una serie de opciones que incluyen una primera opción para pagar dinero a otro y una segunda opción para solicitar información de saldo; cuando el usuario seleccione la primera opción, presentar una segunda pantalla en la que el usuario ingresa un número telefónico objetivo al cual enviar el pago; después de que el usuario ingresa el número telefónico objetivo, presentar una tercera pantalla en la que el usuario ingresa una cantidad de transacción; después de que el usuario ingresa el número telefónico, presentar una cuarta pantalla en la que el usuario ingresa un código de PIN; y después de que el usuario ingresa el código de PIN, enviar en forma inalámbrica la información de transacción que incluye el número telefónico objetivo, la cantidad de transacción y el código de PIN a un servidor para su procesamiento. El método puede incluir, después de que el usuario ingresa el número telefónico objetivo, presentar una quinta pantalla en la que el usuario ingresa un mensaje opcional. El método puede incluir: cuando el usuario selecciona la segunda opción, enviar en forma inalámbrica una solicitud de información de saldo al servidor, recibir la información de saldo del servidor; y presentar la información de saldo en una quinta pantalla. El método puede incluir el caso en el que la primera pantalla además proporciona una tercera opción para solicitar el pago de otro. El método puede incluir el caso en el que la segunda pantalla tiene una tercera opción que, con la selección del usuario, proporciona el acceso al usuario a una libreta de direcciones de la cual el usuario puede seleccionar una entrada para utilizarla como el número telefónico objetivo. La información de transacción puede incluir un número de secuencia generado mediante el teléfono móvil. En una aplicación, los fondos del usuario se mantienen • en el servidor y no en el teléfono móvil. En una aplicación, el método incluye: después de recibir una solicitud de pago requerida en el teléfono móvil, presentar una quinta pantalla en la que el usuario puede ingresar una cantidad de gratificación. Otros objetos, características y ventajas de la presente invención se harán aparentes a partir de la consideración de la siguiente descripción detallada y de los dibujos anexos, en los cuales designaciones de referencia similares representan características similares a lo largo de las figuras. BREVE DESCRIPCIÓN DE LOS DIBUJOS La Figura 1 muestra un diagrama de bloques de un sistema de la invención. La Figura 2 muestra una arquitectura de software para una modalidad específica de la invención. La Figura 3 muestra un ambiente para aplicar una modalidad de la invención. La Figura 4 muestra una modalidad de la invención en la que se proporcionan servicios de valor agregado junto con servicios de pago. La Figura 5 muestra una topología del sistema para pagos móviles de persona a persona. La Figura 6 muestra un pago interbancario de persona a persona. La Figura 7 muestra un pago interbancario de persona a persona. La Figura 8 muestra una carga de cuenta asociada. La Figura 9 muestra una descarga de cuenta asociada . La Figura 10 muestra un sistema de pago y un pago de persona a persona de acuerdo con una técnica de la invención. La Figura 11 muestra un método para realizar una transacción entre un miembro con una tarjeta y un usuario sin registrar . La Figura 12 muestra un método para realizar una transacción entre un miembro sin una tarjeta y un usuario sin registrar . La Figura 13 muestra un método para realizar una transacción entre un miembro sin tarjeta y otro miembro sin tarj eta . La Figura 14 muestra un método para realizar una transacción entre un miembro con tarjeta y otro miembro con ta j eta . La Figura 15 muestra un método para realizar una transacción entre un miembro con tarjeta y un miembro sin tarjeta . La Figura 16 muestra un método para realizar una transacción entre un miembro sin tarjeta y un miembro con tarj eta . La Figura 17 muestra un método de registro para un usuario sin registrar. La Figura 18 muestra un método para activar una tarj eta . La Figura 19 muestra un diagrama general del sistema de una modalidad específica de la invención. La Figura 20 muestra un pago de persona a persona entre dos cuentas de tarjeta individuales. La Figura 21 muestra un pago de persona a persona entre una cuenta con tarjeta y una cuenta no miembro. La Figura 22 muestra un pago de persona a persona entre una cuenta con tarjeta y una cuenta sin tarjeta. La Figura 23 muestra un pago de persona a persona para una cuenta sin tarjeta con una cuenta sin tarjeta. La Figura 24 muestra una carga de tarjeta de crédito. La Figura 25 muestra un diagrama general del sistema de otra modalidad específica de la invención.
La Figura 26 muestra un pago de persona a persona entre una cuenta sin tarjeta y una cuenta sin tarjeta. La Figura 27 muestra un pago de persona a persona entre una cuenta sin tarjeta y una cuenta con tarjeta. La Figura 28 muestra un pago de persona a persona escalonado para una transacción viral con un no miembro. La Figura 29 muestra una financiación de incentivos. La Figura 30 muestra una carga de tarjeta de crédito. La Figura 31 muestra una carga de la ACH. La Figura 32 muestra una descarga de la ACH. La Figura 33 muestra una carga de ATM. La Figura 34 muestra un ambiente de la técnica anterior para aplicar una transacción de tarjeta de crédito mediante el uso de la red de intercambio "cerrada" . La Figura 35 muestra un sistema de transacción de pagos de bucle cerrado de acuerdo con una modalidad de la presente invención. La Figura 36 muestra el ambiente para aplicar un sistema de transacción financiera de bucle cerrado con cuotas bajas y seguridad mejorada de acuerdo con una modalidad de la invención . La Figura 37 es un diagrama de bloques de un sistema financiero de bucle cerrado de acuerdo con una modalidad de la invención. La Figura 38 es un diagrama de bloques de la aplicación de cliente móvil (MCA) de acuerdo con una modalidad de la invención. La Figura 39 muestra un sistema de transacción de pagos de bucle cerrado de acuerdo con una modalidad de la presente invención. La Figura 40 muestra una estructura de cuotas ejemplar para el sistema financiero de' bucle cerrado de acuerdo con una modalidad de la invención. La Figura 41 muestra una operación confiable de carga en una aplicación del sistema de pago soportado por miembro de la invención. La Figura 42 muestra un registro del consumidor en el sistema de pago soportado por miembro. La Figura 43 muestra operaciones de carga y de descarga en el sistema de pago soportado por miembro. La Figura 44 muestra una transacción de compra en el sistema de pago soportado por miembro. La Figura 45 muestra un sistema que utiliza una cuenta común virtual . La Figura 46 muestra una característica de compra rápida de acuerdo con una modalidad de la presente invención. La Figura 47 muestra otra característica de compra rápida de acuerdo con una modalidad de la presente invención.
La Figura 48 es una ilustración de nivel del sistema de una transacción financiera realizada mediante por lo menos un mecanismo de mensajería del SMS de acuerdo con una modalidad de la presente invención. La Figura 49 muestra un método para asegurar las transacciones financieras basadas en SMS de acuerdo con una modalidad de la presente invención. La Figura 50 muestra el uso de un servidor de adición del SMS seguro de acuerdo con una modalidad de la presente invención. La Figura 51 muestra un proceso de registro para un nuevo titular de una cuenta acuerdo con una modalidad de la presente invención. La Figura 52 muestra un sistema de detección de fraude escalonado de acuerdo con una modalidad de la presente invención . La Figura 53 muestra una estructura de cuenta común de acuerdo con una modalidad de la presente invención. Las Figuras 54, 55 y 56 muestran un método para evitar fraudes y duplicados de múltiples solicitudes de transacción de acuerdo con modalidades de la presente invención . La Figura 57 muestra un ejemplo de la autenticación del número de secuencia. La Figura 58 muestra otro ejemplo de la autenticación del número de secuencia. La Figura 59 muestra el protocolo alámbrico que específica el formato de datos en serie pasados entre los dispositivos y el centro de datos de acuerdo con una modalidad de la invención. La Figura 60 muestra una invocación exitosa de la llamada de servicio de acuerdo con una modalidad de la invención. La Figura 61 muestra una respuesta a una llamada de servicio en la que se genera una excepción como resultado de la llamada de servicio de acuerdo con una modalidad de la invención . La Figura 62 muestra una invocación exitosa de otra llamada de servicio de acuerdo con una modalidad de la invención. La Figura 63 muestra Capas de Diseño de OMAP de Nivel Elevado para un dispositivo móvil de acuerdo con una modalidad de la invención. La Figura 64 es un diagrama de estados que muestra el Diseño de Comunicación de OMAP de acuerdo con una modalidad de la invención. La Figura 65 es un diagrama de estados que muestra el Diseño de Persistencia de OMAP de acuerdo con una modalidad de la invención y el diagrama de estados que muestra el Diseño de Notificación de Usuario de OMAP de acuerdo con una modalidad de la invención. La Figura 66 muestra la Paleta de colores en Pantalla de OMAP de acuerdo con una modalidad de la invención . La Figura 67 es un diagrama de estados que muestra las Transiciones en Pantalla de OMAP de acuerdo con una modalidad de la invención. La Figura 68 muestra la distribución para el Menú Principal de OMAP de acuerdo con una modalidad de la invención. La Figura 69 muestra el Flujo en Pantalla del Pago de OMAP desde el punto de vista de la fuente de acuerdo con una modalidad de la invención. La Figura 70 muestra el Flujo en Pantalla del Pago de OMAP desde el punto de vista del objetivo de acuerdo con una modalidad de la invención. La Figura 71 muestra el Flujo en Pantalla del Pago de solicitud de OMAP desde el punto de vista de la Fuente-Solicitud de acuerdo con una modalidad de la invención. La Figura 72 muestra el Flujo en Pantalla del Pago de Solicitud de OMAP desde el punto de vista del Objetivo-Aceptar de acuerdo con una modalidad de la invención. La Figura 73 muestra el Flujo en Pantalla del Pago de Solicitud de OMAP donde el objetivo niega una solicitud de acuerdo con una modalidad de la invención.
La Figura 74 muestra el Flujo en Pantalla del Pago de Solicitud de OMAP en el que tanto la Fuente como el Objetivo aceptan una solicitud de acuerdo con una modalidad de la invención. La Figura 75 muestra el Flujo en Pantalla del Pago de Solicitud de OMAP en el que tanto la Fuente como el Objetivo niegan una solicitud de acuerdo con una modalidad de la invención. La Figura 76 muestra el Flujo en Pantalla del Saldo de OMAP de acuerdo con una modalidad de la invención. La Figura 77 muestra el Flujo en Pantalla de la Historia de OMAP de acuerdo con una modalidad de la invención . La Figura 78 muestra el Flujo en Pantalla de las Configuraciones de OMAP en la fuente de acuerdo con una modalidad de la invención. La Figura 79 muestra el Flujo en Pantalla para la OMAP para una ID Móvil Desconocida de acuerdo con una modalidad de la invención. La Figura 80 muestra el Flujo en Pantalla de la Excepción del Sistema de OMAP donde una solicitud fracasa de acuerdo con una modalidad de la invención. La Figura 81 a 86 muestran pantallas de usuario y flujos para una aplicación de teléfono móvil para realizar pagos de persona a persona.
Las Figuras 87 y 88 muestran una arquitectura para proporcionar un sistema de pago fuera de línea de acuerdo con una modalidad de la presente invención. La Figura 89 es un diagrama de bloques de componentes de un dispositivo móvil para llevar a cabo transacciones financieras tanto en tiempo real como fuera de línea en un dispositivo móvil de acuerdo con una modalidad de la presente invención. La Figura 90 muestra la Infraestructura de Aplicación J2ME para la MCA de acuerdo con una modalidad de la presente invención. La Figura 91 muestra los diagramas de secuencia de pantalla e inicialización de aplicación (MCA) de acuerdo con una modalidad de la presente invención. La Figura 92 muestra clases de secuencia de pantalla de acuerdo con una modalidad de' la presente invención . La Figura 93 muestra la invocación de servicio sincrónico EWP J2ME de acuerdo con una modalidad de la presente invención. La Figura 94 muestra una interacción asincrona con el servidor o notificación no solicitada de acuerdo con una modalidad de la presente invención. La Figura 95 es una representación de un dispositivo de comunicación del consumidor móvil típico, un teléfono celular, el cual opera con un módulo de identificación. La Figura 96 es un diagrama de bloques de una disposición de un adaptador de IM conectado a un IM y a una unidad de procesamiento programable, de acuerdo con una modalidad de la presente invención. La Figura 97 ilustra cómo el adaptador de IM de la disposición de la figura 96 puede conectarse al receptáculo de IM de un teléfono celular. La Figura 98 ilustra cómo la disposición de la figura 96 se bascula para que pueda almacenarse en el teléfono celular. La Figura 99 es un diagrama de bloques que ilustra las conexiones eléctricas de la disposición de la figura 96 de acuerdo con una modalidad de la presente invención. La Figura 100 es un diagrama de bloques de la disposición de la figura 96 con una conexión USB para computadoras portátiles para comunicarse con una red de comunicación inalámbrica con las ventajas de la presente invención. La Figura 101 es una representación de algunos de los elementos de software en la unidad de procesamiento programable en la disposición de la figura 96 de acuerdo con una modalidad de la presente invención. La Figura 102 es una representación en diagrama de bloques de la comunicación por canal de voz entre un dispositivo de comunicación del consumidor móvil y un servidor de red, de acuerdo con una modalidad de la presente invención. En esta descripción de las modalidades de la presente invención se proporcionan numerosos detalles específicos, tales como ejemplos de componentes o métodos, o ambos, para proporcionar un entendimiento profundo de las modalidades de la presente invención. Sin embargo, alguien con experiencia en la técnica relevante reconocerá que una modalidad de la invención puede practicarse sin uno o más de los detalles específicos o con otros aparatos, sistemas, ensambles, métodos, componentes, partes o similares, y combinaciones de los mismos . En otros casos no se muestran o describen específicamente en detalle estructuras, materiales u operaciones conocidas para evitar aspectos confusos de las modalidades de la presente invención. En una aplicación específica, la presente invención se refiere a una plataforma y servicio de pago móvil. Una modalidad de la presente invención abarca una plataforma de pagos que proporciona una forma fácil y rápida de que las personas y comercios realicen pagos mediante el uso de sus dispositivos móviles para tener acceso a una cuenta, tal como una cuenta de débito. Interfaces adicionales incluyen IM, Web y widgets de aplicación. Otras cuentas pueden incluir una DDA o cuenta de tarjeta de crédito. La cuenta también puede ser una cuenta de valor acumulado sin una tarjeta asociada a la misma. Modalidades adicionales de la presente invención abarcan una diversidad de socios que incluyen operadores de teléfonos móviles, comercios de marca nacional y proveedores de servicios financieros junto con una plataforma de pagos que proporciona una forma fácil y rápida de que las personas realicen pagos mediante el uso de sus dispositivos móviles. La Figura 1 muestra un diagrama de bloques de un sistema de la invención para llevar a cabo transacciones de intercambio de valores que incluyen, en aplicaciones específicas, pagos y transacciones móviles de persona a persona, transacciones de pagos de persona a comercio y actividades bancarias móviles. Un servidor 107 de aplicaciones se conecta a una red 109. Aunque sólo se muestra el servidor de aplicaciones, puede existir cualquier número de servidores de aplicaciones en un sistema de la invención. Tales servidores de aplicaciones pueden ejecutarse en una máquina sencilla del servidor o en un número de máquinas del servidor. A medida que aumenta la carga en un servidor de aplicaciones, típicamente se utilizarán más máquinas para manejar y responder a la carga aumentada. Una interfaz 112 de comercio y una interfaz 116 de cliente también se conectan a la red. Esta red puede ser cualquier red para transportar datos que incluyen, sin limitación a, la Internet, Ethernet, línea de servicio de conexión telefónica elemental (POTS) , red telefónica conmutada pública (PSTN) , ISDN, DSL, cable coaxial, fibra óptica, satelital, celular, alámbrica, inalámbrica, línea fija, serial, paralela y muchas otras y combinaciones de las mismas. La interfaz de cliente puede manejar cualquier número de clientes tales como cliente A, cliente B y hasta cliente n, donde n es cualquier número entero positivo. La interfaz de comercio también se conecta al servidor de aplicaciones. Al igual que la interfaz de cliente, puede existir cualquier número de comercios que se conecten al servidor de aplicación. En el servidor de aplicaciones se encuentra un procesador 119 de pagos, que puede conectarse a la interfaz de comercio. Una interfaz 123 de institución financiera se conecta al servidor de aplicaciones y al procesador de pagos. Puede existir cualquier número de instituciones financieras conectadas al servidor de aplicaciones. El servidor de aplicaciones también puede incluir una base de datos 127. De manera alterna, la base de datos puede estar en un servidor separado del servidor de aplicaciones y que tiene acceso al servidor de aplicaciones a través de una red u otra conexión. La institución financiera también se conecta a la base de datos. La base de datos puede incluir un sistema de registro 130 y cuentas 134 comunes virtuales que el servidor de aplicaciones puede manejar. La institución financiera puede manejar las cuentas 138 comunes. Por lo tanto, el sistema de registro y las cuentas comunes virtuales pueden manejarse en forma separada de las cuentas comunes en la institución financiera. Un sistema de la invención puede incluir cualquier número de los elementos mostrados en la figura. El sistema puede incluir otros elementos no mostrados. Algunos elementos pueden dividirse en bloques separados o algunos elementos pueden incorporarse o combinarse con otros elementos (por ejemplo, dos bloques combinados en un solo bloque) . Además, algunos elementos pueden sustituirse con otros elementos no mostrados (por ejemplo, sustituir un bloque con un bloque diferente) . En operación, el sistema de la invención facilita las transacciones financieras entre los clientes y entre un cliente y un comercio. En una aplicación, el cliente que inicia una transacción puede ser mediante el uso de un dispositivo móvil, tal como un teléfono móvil o teléfono inteligente. Asimismo, el objetivo de una transacción puede ser una persona que tiene un dispositivo móvil, que puede acceder al sistema de pago móvil. En una aplicación, la fuente de financiación de estas transacciones financieras puede ser el propietario u operador del servidor de aplicaciones (el cual puede ser referido, algunas veces, como servidor de pago móvil o servicio de pago móvil) . Por lo tanto, los clientes (y comercios) podrán cargar y descargar fondos desde el servicio de pago móvil. Estos fondos pueden ser de cualquier fuente, incluyendo dinero en efectivo, cheque, liquidez, solución de pago en línea, transferencia electrónica de fondos, cuenta de cheques, cuenta de ahorros, certificados de depósito, cuenta de hipoteca invertida, cuenta de corretaje, dividendos, bonos, cuenta de fondos de inversión libre, tarjeta de crédito, tarjeta de débito o cualquier instrumento financiero o cualquier combinación de los mismos. En otras aplicaciones, la fuente de financiación es una institución financiera a la que el usuario tiene accesp a través del servidor de pago móvil . Los fondos pueden transferirse entre instituciones financieras, si es necesario. Por ejemplo, el cliente A puede enviar dinero al cliente B o a un comercio, donde las partes tienen dinero en diferentes instituciones financieras. El sistema de pago móvil facilitará la transferencia entre las instituciones y notificará a las partes adecuadamente. La Figura 2 muestra una arquitectura de software para una modalidad específica de la invención. Este diagrama de bloques muestra las capas para una arquitectura específica que puede implantarse en el servidor de aplicaciones. Las capas incluyen un contenedor 203 de aplicación de web de consumidor, contenedor 206 de sistema de pago, capa 209 de persistencia y capa 212 de sistema de gestión de base de datos relaciónales (RDBMS) . En una aplicación específica, el contenedor de aplicación de web de consumidor y el contenedor de sistema de pago pueden estar basados en WebLogic por BEA Systems, Inc. La capa de persistencia puede estar basada en Hibernate. El sistema de gestión de bases de datos relaciónales puede utilizar una base de datos de Oracle. Sin embargo, en otras aplicaciones específicas se pueden utilizar otros proveedores, abastecedores o sistemas. Por ejemplo, un sistema de la invención puede incorporar un código de fuente abierta . En el contenedor de aplicación de web de consumidor se encuentra una capa de presentación para interconexión para diferentes tipos de clientes. Algunos ejemplos de las interfaces proporcionadas incluyen una puerta de acceso del SMS, puerta de acceso de aplicación telefónica, puerta de acceso de servicios web, puerta de acceso de páginas de aplicación web y puerta de acceso de entramado de aplicación web. El codificador-descodificador de mensajería del teléfono convierte las solicitudes entrantes o salientes, o ambas, tales como del SMS o Telefónicas en mensajes específicos de sistema o de cliente. Una arquitectura de la invención puede incluir cualquier número de estas interfaces.
El contenedor de sistema de pago incluye conectores para sistemas de seguridad o financieros externos, servidores de correo y servicios de mensajería. También existe una interfaz lógica empresarial y lógica empresarial de sistema de pago. Los clientes del servicio pueden solicitar los servicios empresariales a través de la puerta de acceso de servicio empresarial. La aplicación de la puerta de acceso puede utilizar tecnologías de EJB u otras. Un sistema de la invención puede incluir cualquier número de los elementos mostrados en la figura. El sistema puede incluir otros elementos no mostrados. Algunos elementos pueden dividirse en bloques separados o algunos elementos pueden incorporarse o combinarse con otros elementos (por ejemplo, dos bloques combinados en un solo bloque) . Además, algunos elementos pueden sustituirse con otros elementos no mostrados (por ejemplo, sustituir un bloque con un bloque diferente) . Ambiente de Tecnología- Infraestructura del Sistema de Pago Un aspecto de la invención es un sistema o servicio de pago móvil. Esta aplicación discute muchas modalidades e implantaciones específicas de componentes y elementos individuales, variaciones y modificaciones de las mismas y combinaciones de las mismas. Un sistema de la invención puede incluir cualquiera de las variaciones o implantaciones específicas discutidas, en forma individual o en cualquier combinación. En esta aplicación, se proporciona, un ejemplo de una implantación específica de un sistema de pago móvil y esta implantación específica es el sistema de Obopay. El sistema de Obopay es únicamente un ejemplo de una implantación de un sistema de pago móvil y se discute para describir más fácilmente diversos aspectos de la invención. La invención abarca muchas implantaciones del sistema de pago móvil y no se limita a las implantaciones específicas descritas. La Figura 3 muestra una implantación específica de la invención. La Figura 3 muestra un ambiente 300 de tecnología robusta de acuerdo con una modalidad de la presente invención que comprende una plataforma 302 de servidor de cliente móvil, un ambiente 304 de hardware escalable e integración 306 bancaria. La plataforma 302 es el corazón de la infraestructura de sistema de pago que ofrece seguridad, comunicación, libro mayor, divisa, fraude y presentación de informes, y administración. Una aplicación de cliente móvil (MCA) se ejecuta en un servidor de pagos J2EE, la tecnología favorecida por muchos bancos. Las solicitudes de transacción entrantes y salientes se procesan mediante comandos de Servicios de HTTP o Web. La detección de fraudes, bases de datos de transacciones y la integración bancaria completan la imagen. Se apreciará que en vista de que la naturaleza general de la presente invención, la plataforma 302 comprende muchas aplicaciones diferentes. Por ejemplo, la plataforma 302 puede comprender una torre de servidores con una pluralidad de servidores acoplados a una red de dispositivos de almacenamiento. En otras modalidades, la plataforma puede aplicarse como una pluralidad de centros de datos para proporcionar distribución compensada de carga y redundancia. Infraestructura del Sistema de Pago-Ambiente de Hardware de la Plataforma 302 La infraestructura del sistema de pago se basa en un ambiente de hardware escalable, horizontalmente ampliable, agrupado que proporciona una capacidad robusta de paso a unidad sustitutoria. El sistema operativo basado en Linux soporta aplicaciones de cliente fino, más notablemente exploradores tales como Microsoft® Internet Explorer, Netscape, Opera, y Mozilla Firefox. El sistema operativo también soporta aplicaciones de cliente solvente. En una aplicación, la Plataforma Java 2, Micro Edition (J2ME) y Microsoft.NET se utilizan en la Plataforma de Cliente Móvil. La arquitectura puede configurarse con facilidad para permitir otras aplicaciones de cliente solvente según sea necesario . Ejemplos de clientes que pueden interconectarse con el sistema incluyen teléfonos móviles, teléfonos inteligentes, dispositivos de asistente digital personal, computadoras portátiles, computadoras de escritorio y muchos otros. Los clientes pueden conectarse al sistema a través de una red de comunicación. Esta red puede ser inalámbrica o alámbrica. En una aplicación específica, la red es inalámbrica y los dispositivos cliente son dispositivos móviles . La red de comunicación puede confeccionarse de muchos sistemas de computadoras interconectados y enlaces de comunicación. Los enlaces de comunicación pueden ser enlaces de cableado, enlaces ópticos, satelitales u otros enlaces de comunicación inalámbricos, enlaces de propagación de ondas o cualquier otro mecanismo para la comunicación de información. Se pueden utilizar diversos protocolos de comunicación para facilitar la comunicación entre los diversos sistemas. Estos protocolos de comunicación pueden incluir protocolos de TCP/IP, HTTP, protocolo de aplicación inalámbrica (WAP) , protocolos específicos del proveedor, protocolos adaptados y otros. Aunque en una modalidad la red de comunicación es la Internet, en otras modalidades la red de comunicación puede ser cualquier red de comunicación adecuada, incluyendo una red de área local (LAN) , una red de área amplia (WAN) , una red inalámbrica, una intranet, una red privada, una red pública, una red conmutada, red de mensajería del SMS, red telefónica móvil, red telefónica celular, Ethernet y combinaciones de las mismas y similares. La red puede ser una red alámbrica (por ejemplo, que utilice cobre) , red telefónica, red de paquetes, una red óptica (por ejemplo, que utilice fibra óptica) o una red inalámbrica o cualquier combinación de las mismas. Por ejemplo, los datos y otra información pueden hacerse pasar entre la computadora y los componentes (o etapas) de un sistema de la invención mediante el uso de una red inalámbrica que utiliza un protocolo tal como Wi-Fi (estándares 802.11, 802.11a, 802.11b, 802. lie, 802. llg, 802. lli y 802.11? de IEEE sólo por nombrar algunos). En una modalidad, un usuario se interconecta con el sistema a través de un dispositivo informático portátil tal como un teléfono inteligente o teléfono móvil. Un sistema de computadora puede incluir una pantalla, caja protectora, teclado y dispositivo de indicación. Dentro de la caja protectora pueden existir componentes de computadora familiares tales como un procesador, memoria, dispositivos de almacenamiento masivo y similares. Puede existir un solo procesador o múltiples procesadores. El procesador puede ser un procesador de múltiples núcleos. Algunos ejemplos de dispositivos de almacenamiento masivo que pueden interconectarse con un dispositivo informático incluyen almacenamiento de memoria flash y otros de memoria no volátil, unidades de memoria flash, tarjeta flash (por ejemplo, tarjetas SD) , unidades de disco masivo, discos flexibles, discos magnéticos, discos ópticos, discos magneto-óptico, discos fijos, discos duros, CD-ROMs, CDs grabables, DVDs, DVDs grabables (por ejemplo, DVD-R, DVD+R. DVD-RW, DVD+RW, HD-DVD o Disco Blu-ray) , memoria volátil que funciona con batería, almacenamiento de cinta, lector y otros medios similares y combinaciones de los mismos. En una modalidad, la invención es un software de computadora que se ejecuta mediante un dispositivo informático. El dispositivo informático puede ser un dispositivo de cliente u otro dispositivo de servidor o una combinación de los mismos. Una versión ejecutable por computadora o aplicada por computadora de la invención puede representarse mediante el uso, almacenado en, o asociado con un medio legible por computadora. Un medio legible por computadora puede incluir cualquier medio que participe en el suministro de instrucciones a uno o más procesadores para su ejecución. Tal medio puede adoptar muchas formas, incluyendo, sin limitación, medios de transmisión, volátiles y no volátiles. El medio no volátil incluye, por ejemplo, memoria flash o discos ópticos o magnéticos. El medio volátil incluye memorias estáticas o dinámicas tales como memoria caché o RAM. El medio de transmisión incluye cables coaxiales, cable de cobre, líneas de fibra óptica y cables dispuestos en un bus. El medio de transmisión también puede adoptar la forma de ondas electromagnéticas, de radio frecuencia, acústicas o de luz, tales como las que se generan durante la comunicación de ondas de radio y datos infrarrojos. Por ejemplo, una versión binaria, ejecutable por máquina, del software de la presente invención puede almacenarse o residir en la RAM o memoria caché o en el dispositivo de almacenamiento masivo. El código de origen del software de la presente invención también puede almacenarse o residir en el dispositivo de almacenamiento masivo (por ejemplo, disco duro, disco magnético, cinta o CD-ROM) . Como ejemplo adicional, el código de la invención puede transmitirse a través de cables, ondas de radio o a través de una red tal como la Internet. Por ejemplo, un programa de aplicación de la invención puede descargarse e instalarse en un teléfono. Después de la instalación, el usuario del teléfono puede ejecutar la aplicación y enviar dinero a otro usuario . Los productos para software de computadora pueden escribirse en cualquiera de diversos lenguajes de programación adecuados tales como C, C++, C#, Pascal, Fortran, Perl, SAS, SPSS, JavaScript, AJAX y Java. El producto para software de computadora puede ser una aplicación independiente con módulos de presentación de datos y de ingreso de datos. De manera alterna, los productos para software de computadora pueden ser clases que pueden ejemplificarse como objetos distribuidos. Los productos para software de computadora también pueden ser un software de componente tal como Java Beans (de Sun Microsystems) o Enterprise Java Beans (EJB de Sun Microsystems) . Un sistema operativo para el sistema puede ser uno de la familia de Microsoft Windows® de sistemas operativos (por ejemplo, Windows 95, 98, Me, Windows NT, Windows 2000, Windows XP, Windows XP x64 Edition, Windows Vista, Windows CE, Windows Mobile) , Linux, HP-UX, UNIX, Sun OS, Solaris, Mac OS X, Alpha OS, AIX, IRIX32, o IRIX64. Se pueden utilizar otros sistemas operativos. Microsoft Windows es una marca registrada de Microsoft Corporation. En una modalidad, con un explorador de Web que se ejecuta en un dispositivo, un usuario tiene acceso a un sistema en la red mundial (WWW) a través de una red tal como la Internet. El explorador de Web se utiliza para descargar páginas web u otro contenido en diversos formatos, incluyendo HTML, XML, texto, PDF y postscript, y pueden utilizarse para cargar información en otras partes del sistema. El explorador de web puede utilizar identificadores uniformes de recursos (URLs) para identificar recursos en la web y el protocolo de transferencia de hipertexto (HTTP) al transferir archivos en la web . La plataforma 302 comprende un servidor 308 que maneja la interacción con los titulares de una cuenta y mantiene registros de las transacciones. El servidor 308 también proporciona el enlace para servicios de valor agregado proporcionados por los socios del comercio. El servidor 308 utiliza una base de datos 309 de transacciones que de preferencia comprende una red de almacenamiento de datos. El servidor 308 utiliza información (tal como números de cuenta, información de saldo, etc.) obtenida de la base de datos 309 de transacciones para gestionar un procesador 310 de pagos que se comunica con las terminales 311 de punto de venta (POS) del comercio. Los comercios pueden utilizar las terminales 311 de POS para transacciones financieras tales como agregar fondos a una tarjeta de débito para el titular de una cuenta. Los comercios también pueden establecer un enlace separado con el servidor 302 de pagos para propósitos de contabilidad. Un procesador de establecimiento maneja las transacciones en el sistema de bucle cerrado, el cual se establecerá en un modo de tiempo real. La cuenta del usuario y la cuenta del comercio se actualizarán en forma simultánea. Debido a que la mayoría de los comercios también pueden actuar de agentes de carga, los comercios llevarán un saldo en su cuenta. El procesador de establecimiento se. utilizará principalmente para barrer una cantidad de dólares preestablecida o una cantidad de dólares en un mínimo hacia una cuenta bancaria externa que el comercio posea. El procesador de establecimiento facilita las transacciones de persona a persona (P2P) debido a la capacidad de transferir fondos de un titular de una cuenta inscrito a otro titular de una cuenta inscrito. La plataforma 302 además comprende un sistema 312 de detección de fraudes para rastrear la información extraída de cada transacción financiera. Tales sistemas de detección de fraudes son conocidos y por lo general se utilizan para monitorear fraudes cuando se utilizan tarjetas de crédito. El riesgo se controla mediante un procesador de reglas generales (véase Figura 3) que aplica límites y determina la aceptabilidad de las transacciones solicitadas desde una perspectiva de riesgo. La información recopilada para cada transacción financiera puede extraerse para su uso mediante aplicaciones de valor agregado del consumidor y del comercio, mediante aplicaciones de monitoreo de negocios, mediante aplicaciones de operaciones del sistema y aplicaciones de monitoreo de seguridad, como se indica en 313. Para ilustrar, un procesador de mercadotecnia envía cupones o descuentos a titulares de una cuenta desde comercios participantes. Este procesador también controla el uso de créditos de cuenta instantáneos para estimular la inscripción.
Un módulo de conversión de divisas facilita la operación de cambio en la que el cálculo del valor en el sistema de pago de bucle cerrado necesita convertirse a otras divisas. El módulo también se utilizará para controlar la exposición al cambio de moneda. El procesador viral proporciona la capacidad de enviar fondos a un usuario no inscrito. Este módulo permite que el titular de una cuenta envíe los fondos, el cual enviará un mensaje al receptor de que los fondos se están reteniendo para ellos siempre y cuando se inscriban. Una característica de itinerancia proporciona un ambiente de transacción de Colega a Comercio en el que el comercio utilizará un teléfono móvil para recibir los fondos donde el comercio no tiene acceso a una terminal que típicamente se utilizaría para la aceptación de una tarjeta de crédito o de débito. Una ventaja de la presente invención surge de la seguridad de no aceptar dinero en efectivo y fondos garantizados frente a un cheque y también permite una verificación instantánea que no es factible con una compra con tarjeta de crédito sin una terminal. Integración de Socios bancarios Las bases de datos 308 de operaciones se integran directamente con una cuenta 306 bancaria común mantenida en un banco corresponsal . Todos los fondos permanecen en esta cuenta aunque los comercios tienen la opción de transferir sus fondos de sus cuentas de débito prepagadas a otras cuentas a través de transferencias de la ACH o integración directa de DDA a través de una API directa con su banco o a través de la red de ATM. Se apreciará que se puede crear más de un banco corresponsal, de tal manera que cada cuenta puede asociarse con una cuenta bancaria común en más de un banco. Puesto que la plataforma 302 conoce el saldo disponible para cada cuenta (independientemente del número de socios bancarios) , no existe ningún riesgo de que los fondos no se encuentren disponibles cuando ocurran establecimientos interbancarios . Al trabajar con socios comerciales, incluyendo operadores móviles, comercios de marca nacional y proveedores de servicios financieros, tal como los bancos más importantes y uniones crediticias, la infraestructura del sistema de pago aprovecha la infraestructura móvil y tecnología de mensajería existentes para ofrecer servicios financieros universalmente accesibles y baratos. En una aplicación, el sistema de la invención proporciona la capacidad de interoperación entre bancos. También existe la capacidad de interoperación entre cuentas comunes y cualquier cuenta del titular de una tarjeta que se mantenga como cuenta individual . Socios de Proveedores del Servicio Móvil Los proveedores del servicio móvil obtienen ingresos increméntales, así como tráfico adicional de datos y una ventaja competitiva, al ofrecer a sus suscriptores una solución de pago digital. A diferencia de otros sistemas de pago, la presente invención puede ofrecerse a toda una base de clientes del proveedor, ya que puede utilizar un servicio de Internet móvil o del SMS (por ejemplo, WAP) además de una aplicación que puede descargarse. Además, los titulares de una cuenta pueden pagar sus recibos o complementar en minutos a través de su cuenta de servicio. Esto es especialmente útil para los titulares de una cuenta que no tienen otros servicios financieros disponibles para ellos. Socios del Comercio Diversos . comercios que tradicionalmente aceptan tarjetas de crédito, tarjetas de débito, cheques y dinero en efectivo aceptarán la infraestructura de transferencia de pago móvil individualizado debido al bajo costo de adopción. Los comercios también tienen una oportunidad de ganar comisiones por manejar transacciones de cuenta prepagada tales como ayudar a los titulares de una cuenta a agregar fondos a sus cuentas.. La mayoría de los comercios también devuelven cantidades pequeñas de dinero en efectivo, al igual que el modelo de tarjeta de débito actualmente en uso. Una modalidad específica del servicio de pago móvil de la invención tiene extensiones móviles de P2M y servicios web. Éstas permiten que un comercio acepte fácilmente un pago de un usuario ya sea desde un teléfono móvil o desde un sitio web. También pueden ayudar al comercio a disminuir sus costos de aceptación de la transacción y a aumentar su alcance a sus clientes. Socios Bancarios En la actualidad los bancos pueden "movilizar" su base de clientes existente con un acceso instantáneo a sus cuentas y con la capacidad de realizar pagos de titular de una cuenta a titular de una cuenta. Transacciones interbancarias también son posibles. Con esta colaboración, los bancos también pueden llegar a consumidores a los que anteriormente resultaba demasiado costoso proporcionar el servicio. En lugar de incurrir en el gasto de establecer un banco y apegarse a un pesado régimen normativo, las cuentas comunes en bancos participantes manejan los libros mayores, reportan las posiciones netas a o en nombre de sus bancos corresponsales y permiten que los bancos lleven a cabo el establecimiento final. Esto es para permitir el cumplimiento de las normas gubernamentales y permitir la coexistencia activa con el ambiente bancario. Al utilizar bancos corresponsales y cuentas bancarias para acompañante, la infraestructura del sistema de pago se diseña para mejorar las cuentas bancarias existentes de los titulares de una cuenta siempre que sea posible y aún actuar como una cuenta discreta cuando sea necesario. Todos los fondos representados por cuentas de débito prepagadas individuales se mantendrán en cuentas bancarias comerciales guardadas en depósito para los titulares de una cuenta. Al final de cada día hábil, el saldo total de todas las cuentas será igual al saldo del banco. Todas las transacciones creadas en un periodo de veinticuatro horas se establecerán en ese periodo. Las cuentas funcionan como una cartera con dinero en efectivo, donde el saldo cambia de forma inmediata. En otras palabras, la presente invención no funciona como un depósito a la vista en el que los instrumentos pueden presentarse por una tercera parte. Por ejemplo, los titulares de una cuenta no podrán emitir instrumentos a la vista tales como cheques. Como resultado, no existirá ninguna transacción pendiente que se establezca en una fecha futura. En una aplicación específica de la invención, las cuentas de tarjeta débito no se mantienen en una cuenta común por el proveedor del servicio de pago móvil, sino en cuentas de tarjeta de débito individuales en un socio bancario directo. El proveedor del servicio de pago móvil guarda dinero en una cuenta común para los clientes sin tarjetas y se guarda en depósito en el banco. Método de Operación En una modalidad de la presente invención, un titular de una cuenta agrega dinero a una cuenta de débito prepagada antes de las compras. El dinero puede agregarse a una cuenta de débito prepagada en una ubicación del socio, por medio de la respuesta de voz interactiva (IVR) mediante el uso de su teléfono móvil u otro teléfono, a través de un sitio web al que se tiene acceso a través de la Internet o al contactar un representante de servicio al cliente. En una modalidad, un usuario puede crear un enlace de depósito directo o asociar una cuenta con una cuenta bancaria a través de las redes de la ACH o de ATM. El dinero puede transferirse desde una cuenta existente en un socio del proveedor del servicio financiero (tal como una institución bancaria) o al depositar dinero en efectivo o un cheque a la cuenta de débito prepagada (en un comercio participante u otra tercera parte). Por lo tanto,' los titulares de una cuenta tienen acceso a estos fondos a través de sus dispositivos móviles para realizar pagos y pueden recibir pagos en su actividad de cuenta de otros. En otras modalidades, los fondos pueden transferirse de una tarjeta de crédito designada a la cuenta de débito prepagada. En otra modalidad, los fondos de cada titular de una cuenta se combinan en una sola institución financiera y cada titular de una cuenta tiene un interés en la cuenta común igual a los fondos depositados, menos los fondos transferidos a otra cuenta más los fondos recibidos de otros. Los titulares de una cuenta pueden retirar parte o todos sus fondos disponibles de la cuenta común.
En otra modalidad, cada titular de una cuenta puede crear una cuenta de débito prepagada en cualquier institución financiera y tener acceso a la cuenta en forma indirecta para transferir fondos. De este modo, los titulares de una cuenta no se limitan a una tarjeta de débito con fondos mantenidos en la cuenta común en una institución financiera particular. En cambio, los titulares de una cuenta pueden tener acceso a una cuenta de tarjeta de débito en una institución financiera de su elección. En otra modalidad, se designa una cuenta de tarjeta de crédito como la cuenta principal y un anticipo en efectivo se transfiere a una cuenta de tarjeta de débito prepagada siempre que los fondos en la cuenta de tarjeta de débito desciendan hasta, o por debajo de una cantidad seleccionada. En aún otra modalidad, las transacciones financieras se llevan a cabo en un modo de persona a persona, donde cada parte se identifica mediante un número telefónico y una contraseña (por ejemplo, un número de identificación personal dé PIN. De manera alterna, la transacción financiera puede identificarse mediante el nombre de un usuario y una contraseña. En otras modalidades, se identifica por lo menos una parte para una transacción mediante un código de barras. El código de barras puede presentarse en un panel de visualización, tal como la pantalla de un teléfono móvil y detectarse mediante la cámara que se encuentra presente en la mayoría de los dispositivos móviles modernos. El código de barras puede imprimirse en el dispositivo o puede unirse de otro modo al dispositivo móvil. En una modalidad específica, una aplicación de software, referida como aplicación de cliente móvil (MCA) , residente en el teléfono móvil sólo requiere que los titulares de una cuenta tengan un número de teléfono móvil y la cuenta de débito prepagada. De manera opcional, se puede tener acceso a una tarjeta de crédito o una cuenta de cheques como una fuente de financiación. De manera favorable, no se requiere ningún hardware adicional tal como una terminal de punto de venta o acceso a Internet. Una vez registrado, el titular de una cuenta crea un número de identificación (PIN) de titular de una cuenta única para verificar todas las transacciones. Después de registrarse, el titular de una cuenta ingresa su número de teléfono móvil y un servidor agrega la aplicación de cliente móvil a su teléfono. Una vez que se instala la aplicación de cliente móvil, el titular de una cuenta puede comenzar a utilizar el teléfono móvil para concluir transacciones financieras. Otra opción es que el usuario descargue la aplicación al dirigirse a un URL específico mediante el uso del explorador de Internet móvil del usuario (por ejemplo, get.obopay.com), el cual iniciará el proceso de descarga para la aplicación móvil. Los titulares de una cuenta también pueden elegir asociar su cuenta con una tarjeta de débito o una tarjeta de crédito ofrecida por una institución financiera y que puede utilizarse en millones de ubicaciones de comercios en todo el mundo. Además, permite que los titulares de una cuenta obtengan dinero en efectivo de la cuenta de débito prepagada mediante el uso de una ATM si surge la necesidad. Para los titulares de una cuenta, concluir una transacción financiera es sin contratiempos. Al sólo enviar un mensaje desde el teléfono móvil equipado con la aplicación de cliente móvil hacia un servidor. El servidor de pagos valida cada transacción y transfiere fondos o responde a la solicitud de información de cuenta del titular de una cuenta. Envío de Solicitudes de Transacciones al Servidor Cuando el titular de una cuenta realiza una solicitud de transacción desde su teléfono móvil, la información se enruta al operador móvil, tal como Cingular o Verizon u otro proveedor del servicio de telefonía móvil. La información se enruta entonces al servidor de pagos a través de una conexión segura a Internet. En modalidades alternas, la información se enruta a través de redes alternas, tales como redes inalámbricas, POTS u otra red disponible. Esta redundancia es importante debido a que el titular de una cuenta no se limita a una sola trayectoria de acceso para controlar su cuenta y llevar a cabo transacciones financieras. Dependiendo de la ubicación del titular de una cuenta o de otras circunstancias, puede ser que una o más rutas de comunicación no se encuentren disponibles. Sin embargo, debido a la redundancia del sistema, probablemente existirá por lo menos una ruta de comunicación disponible y, por lo tanto, se permitirá la transmisión financiera. Las solicitudes de transacciones financieras se transmiten en una de las dos vías, dependiendo del teléfono móvil del titular de una cuenta. Si el titular de una cuenta tiene un teléfono activo por aplicación, el cual permite la transmisión de la solicitud financiera a través de una aplicación basada en Web (HTTP o HTTPS) o de una aplicación móvil, tales como J2ME, . ET, . ET CF, WAP, o SMS, o cualquier combinación de las mismas, la transmisión se dirige directamente al servidor. Un mensaje de solicitud se envía una vez que la MCA establece una conexión con el servidor de pagos . Puesto que los dispositivos activados por aplicación constituyen actualmente una parte relativamente pequeña de los dispositivos que se utilizan en la actualidad, el servidor de pagos también transmite y recibe a través del Servicio de Mensaje Corto, también referido como mensajería de textos del SMS o simplemente SMS, debido a que casi todos los dispositivos soportan el SMS. En este caso, los datos financieros se enrutan al operador móvil y después a un agregador del SMS que transmite mensajes al servidor de pagos en tiempo real . Un sistema de pago móvil del SMS evita el gasto y los problemas asociados con tener un chip agregado al teléfono celular. Cuando el sistema del SMS está en operación, la información financiera se envía mediante el uso de mensajería de textos del SMS. Aunque la mensajería de textos del SMS funciona bien con todos los tipos de dispositivos celulares y algunos otros tipos de dispositivos de comunicación móvil, tales como asistentes digitales portátiles o PDAs, el SMS expone contraseñas descodificadas o números de identificación personales (PINs) , así como información de saldo o detalles acerca de la transacción más reciente. Puesto que cualquiera en posesión del teléfono puede leer el archivo de mensajes del SMS y saber de inmediato cómo acceder a la cuenta de otro, de la presente invención. Por consiguiente, en una modalidad, la presente invención permite el inicio de la transacción financiera por medio del mensaje de texto del SMS. El mensaje del SMS inicia con una palabra clave que proporciona el tipo de transacción solicitada - PAGAR, SOLICITAR PAGO, SALDO, TRANSFERIR O AYUDA. En una aplicación, "PAGAR" es referida como "ENVIAR" y "PAGAR SOLICITUD" es referida como "OBTENER" . En los casos en los que el mensaje del SMS contiene la palabra clave que indica el deseo de transferir fondos del titular de una cuenta al titular de otra cuenta, la palabra clave puede ser ya sea pagar o solicitar pago (o enviar u obtener) . Después de la palabra clave, se ingresa la cantidad con o sin un punto decimal. Después de la cantidad, se ingresa el número telefónico objetivo (o código corto, dirección de correo electrónico, número de licencia u otra información de identificación) . Esta información puede obtenerse del directorio telefónico o del dispositivo móvil. Después del número telefónico, el titular de una cuenta puede ingresar un mensaje para su presentación a la otra parte. En algunos casos, este mensaje puede ser un mensaje nulo. En algunas modalidades, el titular de una cuenta puede ingresar un mensaje complementario para propósitos de conservación de registro . Una vez que el mensaje del SMS se envía al servidor de pagos, el titular de una cuenta ingresa el PIN y lo envía a través de una conexión de canal de voz al servidor de pagos para verificar el mensaje del SMS. El PIN se ingresa a través del teclado y puede ser cualquier código alfanumérico . Después, el PIN se envía al servidor de pagos como un mensaje codificado de DTMF, donde DTMF se refiere a un tono dual de multifrecuencia, la compañía telefónica recibe una señal cuando se presiona las teclas 'pulsadoras de un teléfono. En el servidor, el servidor de pagos recibe el mensaje del SMS a través de la trayectoria de comunicación de mensajes de texto del SMS y el PIN a través del canal de voz.
El titular de una cuenta puede realizar la llamada al servidor de pagos o el servidor de pagos puede iniciarla como una característica de "llamada de respuesta" en respuesta a la recepción del mensaje del SMS. El PIN puede enviarse como un mensaje codificado de DTMF para mantener la seguridad, sin embargo, en otras modalidades el titular de una cuenta puede pronunciar el PIN y ser convertido mediante un módulo de software de reconocimiento de voz interactivo que opera en el servidor de pagos o en otro servidor (no mostrado) dedicado al manejo de llamadas de voz. En una modalidad, el dispositivo móvil incluye la aplicación de cliente móvil. La aplicación de cliente móvil se selecciona, ya sea directamente por el titular de una cuenta o en respuesta a la activación de la característica de mensajería de textos del SMS en el dispositivo móvil. La MCA determina el mejor método para enviar el PIN. En una modalidad alterna, el PIN se codifica mediante la aplicación de cliente móvil y se incluye en un mensaje del SMS posterior que se envía al servidor de pagos. El servidor de pagos correlaciona los mensajes al hacer corresponder el número telefónico y la hora en la que se envío cada mensaje. Si el PIN se envió en un mensaje que estaba distante en tiempo en comparación con el mensaje del SMS, la transacción puede rechazarse. Si se recibe sólo uno de los dos mensajes, la transacción puede rechazarse. Sin embargo, si se reciben tanto el mensaje del SMS con los detalles de la transacción financiera (mínimo de en un teclado) como el código de PIN y se verifican, entonces se concluye la transacción financiera. En una modalidad alternativa, cuando se encuentra disponible un canal de voz, la aplicación de cliente móvil selecciona un módulo para codificar el PIN en una forma de DTMF. La aplicación de cliente móvil envía entonces el DTMF al servidor de pagos a lo largo de una conexión del canal de voz establecida mediante la aplicación de cliente móvil. El módulo puede ser una API de Java que genera los tonos adecuados con base en las entradas del teclado. En aún otra modalidad alternativa, la aplicación de cliente móvil permite que una interfaz de usuario (UI) en la pantalla de visualización del dispositivo móvil guíe al titular de una cuenta para concluir la transacción financiera. En esta modalidad, el titular de una cuenta es guiado a través del proceso de construcción del mensaje de texto del SMS mediante la introducción automática de la palabra clave, cantidad, número telefónico objetivo, contraseña y mensajes, si existe alguno. En aún otra modalidad alternativa, el mensaje del SMS puede incluir la palabra clave, la cantidad, el número telefónico objetivo y la contraseña. Un inconveniente de esta aplicación es que la contraseña puede estar visible para cualquiera que controle el dispositivo móvil. Sin embargo, la presente invención soluciona este problema al enviar un mensaje, o al guiar al usuario a través de la información de FAQ y de ayuda, al titular de una cuenta para eliminar el mensaje enviado del fólder de registros del SMS. Estas instrucciones también pueden sugerir que el titular de una cuenta apagó el mensaje de conexión de los mensajes del SMS salientes al llevar a cabo las transacciones financieras. La siguiente descripción ilustra el uso de la mensajería de textos del SMS para permitir a los titulares de una cuenta el acceso al servidor de pagos desde cualquier teléfono móvil apto del SMS u otro dispositivo activado por el SMS. No se requiere que la aplicación de cliente móvil resida en el dispositivo móvil aunque, como se ha discutido, existen ventajes de cargar la aplicación de cliente móvil en el dispositivo móvil. En operación, el titular de una cuenta envía un mensaje de texto al servidor de pagos mediante el uso de la capacidad de mensajes de texto existente en su teléfono. La funcionalidad incluye Pagar (o Enviar) , Pagar (o Obtener) Solicitud, Saldo, Historia y Ayuda solicitada al utilizar cualquiera de estas características como una palabra clave. También puede existir una opción de referir o invitar para permitir que el usuario invite a otra persona a unirse al sistema. Se puede proporcionar al referente o al referenciado, o a ambos, un bono de recomendación. El titular de una cuenta ingresa la palabra clave junto con información adicional en el cuerpo del mensaje de texto para construir un comando que se envía después al servidor de pagos . El acceso al servidor de pagos puede ser por medio de un número telefónico gratuito, un código corto o una dirección de correo electrónico, de los cuales todos identifican el servidor de pagos con el sistema de mensajería de textos del SMS. Un ejemplo de un código corto es 62729, el cual se utiliza como el número telefónico objetivo para sus comandos de mensaje de texto para el servidor de pagos. Un ejemplo de una dirección de correo electrónico es sms@obopay.com, la cual es el correo electrónico objetivo para los comandos de mensaje de texto del SMS enviados al servidor de pagos. Para enviar un pago a otra persona o a un comercio que utiliza el método del SMS, el titular de una cuenta puede ingresar la cadena de comandos mostrada en la tabla A. Tabla A Cada elemento debe tener un espacio entre el mismo y el elemento anterior. En una aplicación, la palabra clave no distingue mayúsculas de minúsculas. El número móvil debe incluir un código de área más un número móvil sin ningún espacio presente en el número móvil. El titular de una cuenta puede ingresar o no un 1 inicial en el número telefónico. No se requiere que se ingrese un símbolo de dólar con la cantidad, pero se permite. El usuario debe ser capaz de incluir, de manera opcional, un mensaje con su pago. En un ejemplo alternativo, el PIN se envía en un segundo mensaje por medio de una llamada de voz. Para enviar un pago a otra persona o a un comercio que utiliza la combinación del método canal de voz más el SMS , el titular de una cuenta puede ingresar la cadena de comandos mostrada en la tabla B. Tabla B El PIN se envía al servidor de pagos a través del canal de comunicación de voz, es decir, la red celular, la Internet o el POTS . Cuando se realiza una solicitud de pago para el titular de una cuenta mediante el uso ya sea del método del SMS o de la combinación del SMS más el método de voz, estos pueden aceptar o rechazar la solicitud mediante el uso del sistema de mensajería de texto del SMS manual. Del lado del servidor de pagos, uno o más centros de datos pueden tener sistemas para procesar las transacciones financieras. Cada uno de los centros de datos puede contener una combinación de tecnología de PBX/ACD/VRU para permitir el procesamiento de múltiples llamadas simultáneas. La tecnología de VRU puede utilizarse para proporcionar soporte de DTMF entrante y saliente programable. La VRU puede conectarse a un sistema J2EE empresarial que representa la lógica de negocio y sistema de registro existentes para las transacciones financieras. Por lo tanto, el sistema J2EE puede integrarse con bancos existentes para el establecimiento de las transacciones. En una aplicación, existe una opción de contraseña para una sola vez para seguridad del SMS como una opción. Esto puede funcionar cuando el usuario envía la transacción sin un PIN y después el sistema puede enviar al usuario una serie de preguntas que él responde. Realización de Transacciones Mediante el Uso de una Aplicación de Cliente Móvil (MCA) El envío de dinero al titular de otra cuenta o a un comercio es rápido y sencillo. El presente sistema simplifica los pagos masivos, tal como recaudar dinero para un evento de caridad de muchos titulares de una cuenta o enviar múltiples transacciones del mismo titular de una cuenta al mismo tiempo . Transacciones de titular de una cuenta a Titular de una Cuenta (Persona a Persona) En envío de dinero del titular de una cuenta a otro a través de un sitio, a través de la ciudad o a través del país es° fácil, conveniente y económico. El titular de una cuenta de débito prepagada puede enviar dinero a cualquier titular de una cuenta con microteléfono activado por el SMS, aun si estos no tienen la aplicación de cliente móvil instalada en su dispositivo móvil o una cuenta de débito prepagada. Si el destinatario no es todavía titular de una cuenta, el destinatario recibe un mensaje de texto del SMS que indica que los fondos se han transferido a su nombre. Para tener un acceso oportuno a estos fondos, el destinatario puede registrarse para su propia cuenta de débito prepagada. Esta mensajería viral facilita a los usuarios sin una cuenta a volverse ellos mismos titulares de una cuenta registrada. Si el dispositivo móvil utilizado por el usuario sin una cuenta soporta un WAP o explorador móvil de Internet, entonces la inscripción puede tener lugar de manera inmediata vía telefónica. El usuario también tiene la opción de registrarse para el servicio mediante el uso de la web, un servicio de quiosco, en persona en un socio del comercio o a través de otro dispositivo. La flexibilidad de la presente invención permite métodos novedosos de selección e identificación de partes para una transacción. En una modalidad, el pagador puede teclear un número telefónico u otro código de identificación en el teclado de su dispositivo móvil. Un código de identificación puede ser un "código corto" especial de tres, cuatro, cinco dígitos que el proveedor de servicios móviles transfiere a una cuenta específica. Por ejemplo, si el titular de una cuenta desea descargar un programa de televisión disponible en una red de televisión, tal como la red de televisión CBS, el titular de una cuenta puede teclear un código corto de 227 para pagar a la red por el contenido deseado. El código corto puede incluir cualquier carácter alfanumérico . Esta modalidad requiere que ciertas partes dispongan la adquisición de un código corto para animar a los usuarios a acceder a sus servicios. En una modalidad alternativa, el destinatario de los fondos puede ser identificado mediante un número telefónico seleccionado de la función de directorio en el dispositivo móvil. De este modo, no es necesario ingresar el número telefónico en forma separada. En una aplicación, un directorio contenido se utiliza en los casos en el que el usuario puede crear su directorio con el servicio y, después, ese directorio puede estar disponible para el mismo a través de cualquier dispositivo que utilice. Para formar inicialmente el directorio contenido, el sistema puede proporcionar interfaces en directorios de terceras partes, tal como Outlook, un directorio de administrador de información personal (PIM) o servicios para tercera parte, tal como Plaxo . En aún otra modalidad alternativa, el pagador puede utilizar la función de cámara en el dispositivo móvil para obtener una imagen que identifique al beneficiario. Un ejemplo de una imagen puede ser un código de barras. En aún otra modalidad alterna, el beneficiario identifica al pagador a través de una imagen obtenida. Una imagen tal obtenida es un código de barras presentado ya sea en una pantalla o fijada en forma visible en una parte exterior del dispositivo móvil. En aún otra modalidad, el pagador o el beneficiario son identificados a través de un dispositivo de proximidad tal como un dispositivo de identificación por radiofrecuencia (RFID) o un dispositivo de comunicación de campo cercano (NFC) . Titular de una Cuenta a Comercio El titular de una cuenta puede retirar fondos o realizar compras en un comercio corresponsal en múltiples formas : (1) de teléfono móvil a teléfono móvil del comercio; (2) de teléfono móvil a la aplicación web del punto de venta del comercio; (3) tarjeta de débito prepagada para acompañante; (4) mediante código de texto al servicio que identifica el producto y al comercio al que un usuario desea comprar; (5) al seleccionar una operación para pagar con el servicio de con una canasta de compras electrónica del comercio o web o aplicación móvil; o (6) al seleccionar un producto de un catálogo en una web o aplicación telefónica del servicio. En una modalidad de la invención, un dispositivo móvil se asocia con una o más cuentas bancarias (de cheques, de ahorros, de crédito, prepagada o una cuenta común y similares) y el titular de una cuenta puede transferir fondos en tiempo real de una cuenta a otra sin ningún acceso a un centro de servicios y sin ningún acceso a Internet o computadora. De manera favorable, el titular de una cuenta puede seleccionar la cuenta de la que se obtienen los fondos para realizar una compra en tiempo real. En otra modalidad de la invención, los titulares de una cuenta contribuyen a una cuenta maestra productiva de intereses que un socio bancario mantiene. El titular de una cuenta puede retirar en cualquier momento su contribución total sin ninguna penalización. El socio bancario gestiona el sistema de pagos y es remunerado con los intereses que se acumulan . En otra modalidad, la NFC se utiliza para comunicarse entre dispositivos móviles para concluir transacciones financieras mediante el uso de la infraestructura de la presente invención. En aún otra modalidad, la NFC se utiliza para comunicarse desde un dispositivo móvil hasta una terminar de POS para concluir las transacciones financieras. Existen muchos productos y, potencialmente, una gran cantidad de productos nuevos que se beneficiarán de la presente invención. Por ejemplo, cualquier dispositivo telefónico activado por Internet, tal como un teléfono de VOIP, puede utilizarse para practicar la presente invención aunque éste pueda estar fijado en una ubicación específica y que no necesariamente sea móvil. En otras modalidades, las direcciones de correo electrónico se utilizan además de o en lugar de números telefónicos para identificar una o más partes para una transacción financiera. Además, se apreciará que uno o más de los elementos representados en las figuras/dibujos también pueden implantarse en una forma más separada o integrada, o incluso eliminarse o presentarse como inoperables en ciertos casos, según sea útil, de acuerdo con una aplicación particular. Operación de Modelos de Ingresos para Infraestructura de Transferencia de Pagos Móviles, Individualizados La operación de la infraestructura de transferencia de pagos móviles, individualizados proporciona la oportunidad de generar una fuente de ingresos sin cobrar un recargo en transacciones en las que un comercio es una de las partes. Se reconoce que en el mundo móvil o inalámbrico los usuarios de teléfonos celulares por lo general están dispuestos a invertir una pequeña cuota mensual para tener acceso a ciertos servicios. Por consiguiente, los ingresos se generan al cobrar una pequeña cuota por transacción para enviar dinero. En una modalidad ejemplar, la cuota por transacción varia de algunos centavos para transacciones menores a una cantidad seleccionada, tal como de $25. Para ilustrar aún más, la cuota "por transacción" puede variar de $0.05 a aproximadamente $0.10 por transacción en modalidades alternas . Se puede cobrar cualquier cuota desde menos de un centavo por transacción hasta varios dólares por transacción. Por ejemplo, la cuota puede ser de $0.00001 a $10 por transacción . La cuota puede cobrarse tanto en la parte que recibe el pago como en la parte que envía el pago. De manera alterna, la cuota puede cobrarse al titular de una cuenta que envía el dinero. En aún otras modalidades, un porcentaje de la cantidad de la transacción se cobra para concluir la transacción. En esta modalidad, la cuota se cobra para transacciones con un valor más elevado, tal como, a modo de ilustración, de $25. Un aviso sobre la cuota, si existe alguna, de preferencia se presenta en la pantalla de aprobación antes de la aprobación y autorización final del titular de una cuenta para enviar el pago. En aún otras modalidades, la cuota puede anularse para transacciones por cantidades pequeñas. De este modo, no habrá ninguna cuota "por transacción" cuando se realicen compras pequeñas mediante el uso de la infraestructura de transferencia de pagos. Otro modelo de operación es cobrar por suscripción. En lugar de pagar una cuota "por transacción" , los titulares de una cuenta pueden elegir pagar una tasa fija mensual para enviar y recibir pagos. En esta modalidad, no existen cuotas "por transacción" . La tasa mensual puede variar con comercios que pagan una cuota mayor (o menor en algunos casos) que los usuarios individuales. Por consiguiente, la presente invención contempla tres diferentes modelos de generación de ingresos. Específicamente, (1) una cuota "por transacción" se cobra contra una o ambas partes para una transacción financiera. De preferencia, la cuota es nominal y varía de aproximadamente un centavo a aproximadamente $0.15; (2) un plan de costo mensual de tarifa única en el que cada titular de una cuenta pagaría una tasa por el servicio mensual; (3) una cuota por transacciones de valor elevado para transacciones en una cantidad seleccionada, tal como, a modo de ilustración, de $50, la cuota se anula para todas las otras transacciones; y (4) servicios de valor agregado, tal como enlazarse a un servicio de contabilidad para registrar en forma automática los detalles de las transacciones o para ayudar a prepararse para el llenado de declaraciones fiscales. El servicio puede obtener efectivo en caja para mantener fondos o ingresos de publicidad y estos pueden aplicarse a cuotas del comercio (por ejemplo, intercambio) . La Figura 4 muestra otra aplicación de un sistema de la invención. La Figura 4 muestra una modalidad en la que el servicio de valor agregado se utiliza entre dos titulares de una cuenta. A modo de ejemplo, si el titular de una cuenta asociado con un dispositivo 401 móvil inicia una transferencia a un dispositivo 402 móvil, la solicitud de pago se transfiere a la plataforma 403 del servidor como se indica mediante la flecha 404 de referencia. La solicitud de pago puede incluir una descripción opcional del pago. Por ejemplo, el titular de una cuenta puede anotar el pago para indicar que era un elemento de la cuenta de gastos.. La descripción puede seleccionarse de un menú presentado en el dispositivo 401 móvil. De manera alterna, la descripción puede ser un mensaje de texto o de voz asociada con la solicitud de pago. Con la recepción de la solicitud de pago, el servidor 403 transfiere los fondos de la cuenta del pagador a una cuenta para el titular de una cuenta asociado con el dispositivo 402 móvil. Se avisa a la institución financiera que maneja la cuenta 405 común acerca de la transacción, como se indica mediante la flecha 406. de referencia. De esta manera, se agrega dinero a la cuenta asociada con el dispositivo 402 móvil y se cobra de la cuenta asociado con el dispositivo 401 móvil. La institución financiera envía entonces una confirmación, como se indica mediante la flecha 407 de referencia. La plataforma 403 del servidor también envía un aviso del pago al dispositivo 402 móvil, como se indica mediante la flecha 408 de referencia. Se envía un segundo mensaje que indica que se ha realizado el pago al teléfono 401 móvil, como se indica mediante la flecha 409 de referencia. Si el usuario del dispositivo 402 móvil no es el titular de una cuenta, se puede abrir una nueva cuenta, como se indica mediante la flecha 410 de referencia. De manera alterna, el usuario puede retirar fondos de una ATM designada o de otra instalación asociada con la institución financiera que maneja los fondos comunes. La plataforma 403 del servidor documenta entonces la transacción al enviar la cantidad de la transacción y la descripción de la transacción a un servicio 411 de contabilidad y gestión de registros, como se indica mediante la flecha 412 de referencia. Después, el ' titular de una cuenta puede acceder a la información que describe sus compras que el servicio 411 de contabilidad y gestión de registros almacena y organiza, ya sea a través del dispositivo 401 móvil o mediante otra conexión a Internet (no mostrada) . Para mostrar además cómo un pago de cuentas entra al sistema de cuentas por cobrar, se considera un pequeño negocio que utiliza un programa de contabilidad (el cual puede almacenarse en una computadora personal) para imprimir una factura que envía a su cliente. El cliente debe entonces pagar al pequeño negocio, lo cual por lo general se realiza con cheque. Debido a que la factura no pueda enviarse con el cheque, el pequeño negocio debe asociar el número de cuenta con el cheque. Si no fuera así, el número de cuenta no se escribe en el cheque, se pierde tiempo tratando de ubicar la correspondencia del pago con una copia de la factura. El pequeño negocio deposita entonces el cheque en su banco e ingresa en forma manual los datos en su programa de contabilidad de cuentas por cobrar. Claramente, este proceso obsoleto es lento y costoso de soportar. Sin embargo, con la presente invención, el pequeño negocio sólo necesita seleccionar una opción de facturación que ponga la factura del programa de contabilidad en un formato OFX, a modo de ejemplo, u otro formato de importación/exportación legible mediante un programa de contabilidad. Esta factura electrónica se envía entonces a la plataforma de pagos (véase figura 3) . La plataforma de pagos crea un mensaje de "Solicitar Pago" que se envía al cliente. Cuando el cliente aprueba el pago de la factura, los datos del pago se envían nuevamente a la cuenta en el programa de contabilidad a través de OFX y deposita el dinero en la cuenta del pequeño negocio. El mensaje de OFX coloca el elemento en el programa de contabilidad. Puesto que la identificación de cuentas por pagar del cliente es su número telefónico, el rastreo y la gestión de registros se simplifican en gran medida. Debe observarse que los fondos están siempre garantizados y no existen cheques sin fondos u otros problemas semejantes. Para transacciones de cuentas por cobrar, y el servicio 411 de contabilidad y gestión de registros envía un mensaje de OFX con, a modo de ilustración, un pago de reintegro de gastos del empleado (T&E) . El dinero se transfiere a la cuenta del empleado y se envía una notificación a su dispositivo móvil. De manera ventajosa, la presente invención elimina el proceso manual de ingreso de cada transacción en el programa de contabilidad. La Figura 5 además muestra una aplicación del sistema para pagos móviles de persona a persona. Como se discute en lo anterior, una modalidad específica de la invención permite que los usuarios o clientes se interconecten con el sistema de pago móvil a través de la Web (por ejemplo, a través de un explorador de Internet) WAP (por ejemplo, a través de un explorador móvil de Internet en un teléfono móvil, teléfono inteligente, dispositivo de asistente digital personal) , SMS (por ejemplo, mensajería de texto a través de un teléfono móvil) , IVR (por ejemplo, sistema de respuesta de voz interactiva que entienda las respuestas o tonos de voz de un usuario a partir de presionar una tecla del teléfono) , WSDL (por ejemplo, servicio de Web al que se puede tener acceso a través de un dispositivo móvil, tal como un teléfono inteligente) . El sistema puede interconectarse con teléfonos inalámbricos manejados por cualquiera de múltiples portadores, tales como Verizon, Cingular (AT&T) , Sprint, Nextel, Alltel, Virgin Mobile, Am 1 d Mobile, U.S. Cellular, T-Mobile, y otros. El servicio también puede interconectarse con teléfonos prepagados. Algunos beneficios para el portador móvil incluyen: una forma de transmisión o suscripción basada en el modelo de participación de ingresos. Promueve la descarga/compra de la aplicación. Promueve el uso de la red o de datos. Promueve el uso del SMS Solución de pagos de "recibos improvisados" que ayudará a disminuir la sorpresa del problema del "recibo excesivo" . El sistema de pago móvil permite muchos servicios financieros diferentes para el usuario. Ejemplos de algunos servicios incluyen carga de tarjeta de crédito, carga de tarjeta de débito, carga de la Cámara de Compensación Automatizada (ACH) , descarga de la ACH, pago de persona a persona (P2P) , pago remoto (RPAY) , viral, de persona a comercio (P2M) y remisiones. Otros servicios pueden incluir la carga y descarga de red de cajeros automáticos (ATM) tal como a través del sistema de NYCE, PLUS, o STAR ATM. El sistema también puede incluir la integración de pago de cuentas en la que un usuario puede pagar cuentas tales como una cuenta de cable, cuenta de luz, cuenta del servicio de Internet, cuenta del teléfono, cuenta del servicio de cuidado de la casa y otras cuentas . La carga de una cuenta se refiere a la transferencia de fondos a una cuenta en el sistema de pago móvil en el que pueden tramitar los fondos. Por ejemplo, un usuario puede cargar fondos de una cuenta de cheques o tarjeta de crédito a la cuenta del sistema de pago móvil del usuario, los cuales pueden administrarse por el socio financiero o administrarse por el operador del sistema de pago móvil. La descarga de una cuenta se refiere a la transferencia de fondos del sistema de pago móvil a otra cuenta. Por ejemplo, un usuario puede descargar fondos de la cuenta del sistema de pago móvil del usuario, los cuales pueden administrarse por el socio financiero o administrarse por el operador del sistema de pago móvil, a una cuenta de cheques o tarjeta de crédito. La carga y descarga puede realizarse en cualquiera de las formas discutidas en esta solicitud, incluyendo a través de la ACH, ATM o tarjeta de crédito o intercambio. La ACH por lo general es el menos costoso, pero la ACH por lo general no es en tiempo real debido a que los fondos se establecen en una modalidad por lotes al final del día. Por lo tanto, cuando se solicita una transferencia de fondos de la ACH, los fondos existentes no se transferirán no estarán disponibles en el sistema de pago móvil hasta típicamente el final del día. Para tarjetas de crédito y de ATM, la transferencia de dinero es en tiempo real. ATM típicamente es más costoso que la ACH, pero menos costoso de utilizar que las tarjetas de crédito. Obsérvese que puede utilizarse tanto ATM como la ACH para acceder a una cuenta de cheques de un usuario. De los tres, las tarjetas de crédito por lo general son las más costosas de utilizar. En una aplicación, el sistema de la invención permite la carga y descarga desde cualquiera de estas redes. En otra aplicación, el sistema permite la carga y descarga desde sólo una o más de éstas, tal como desde la ACH solamente, ACH y ATM solamente, tarjeta de crédito solamente, ATM solamente, ATM y tarjeta de crédito solamente o la ACH y tarjeta de crédito solamente. El sistema de pago móvil de persona a persona además proporciona una plataforma para uno o más socios financieros. Estos socios pueden incluir un socio adquiriente tal como Pay by Touch (PBT) , Verisign u otro; socio de un banco u otra institución financiera tal como un banco de la Ciudad de Nueva York, San Francisco, San José (California) , Londres, Shanghai, Hong Kong o Tokyo, banco electrónico, NYCE; socio directo (tal como tarjetas prepagadas comercializadas conjuntamente) ; socio de procesamiento prepagado; y un socio de la ACH. El sistema de pago móvil también puede interconectarse con sistemas de punto de venta (POS) . Puede existir cualquier número y combinación de socios y servicios discutidos. Por ejemplo, un sistema puede tener únicamente un solo socio, puede tener dos socios, tres socios o más de tres socios. Un sistema puede incluir un solo socio bancario que proporciona una tarjeta de débito solamente (es decir, ninguna tarjeta de crédito) para su acceso por parte de los clientes móviles. Un sistema puede incluir un solo socio bancario que proporciona una tarjeta de débito y una tarjeta de crédito para su acceso por parte de los clientes móviles. Un sistema puede incluir dos o más socios bancarios, uno que proporciona una tarjeta de débito y otro que proporciona una tarjeta de débito diferente para su acceso por parte de los clientes móviles. Un sistema puede incluir dos o más socios bancarios, uno que proporciona una tarjeta de débito y otro que proporciona una tarjeta de débito diferente y una tarjeta de crédito para su acceso por parte de los clientes móviles. Un sistema puede incluir un solo socio bancario que proporciona solamente una tarjeta de crédito para su acceso por parte de los clientes móviles. Un sistema puede incluir un solo socio bancario que proporciona solamente una tarjeta de crédito para su acceso por parte de los clientes móviles. Para cada tipo de socio (por ejemplo, tarjeta de débito) , pueden existir múltiples entidades asociadas tales que se interconectan con el sistema o red de pago móvil. Por ejemplo,, el sistema puede interconectarse con dos bancos, banco A y banco B, o cualquier número de socios bancarios . El sistema puede tener cualquier combinación de los socios descritos en esta solicitud. Por ejemplo, el sistema puede tener un socio directo y socio bancario, pero no un socio de procesamiento prepagado. El sistema puede tener solamente un socio de procesamiento prepagado. El sistema puede tener solamente un socio directo. El sistema puede tener múltiples socios bancarios. El sistema de cada socio puede tener un esquema de interconexión electrónica diferente, y el sistema de pago móvil se comunicará mediante el uso de la interfaz para programa de aplicaciones (API) adecuada para cada socio. Un sistema de la invención permite una fácil integración de los socios financieros (por ejemplo, socios bancarios, socios de tarjetas) con socios móviles y otros socios consumidores (por ejemplo, portadores de teléfonos móviles) . En una aplicación particular del sistema, el socio adquiriente tiene una cuenta de establecimiento. El socio bancario tiene cuentas comunes y cuentas de explotación. El socio directo tiene cuentas comunes y cuentas de explotación. El socio de procesamiento prepagado tiene cuentas comunes y cuentas de explotación. Del socio de la ACH tiene una cuenta de establecimiento. El sistema de pago móvil puede proporcionar una o más de administración' de cuenta común, establecimiento interbancario y administración de la tesorería, e integración bancaria móvil. Los fondos de los sistemas se representan mediante la concentración de todas las cuentas comunes del banco corresponsal. A modo de relación comercial con el sistema de pago móvil, el sistema de pago móvil facilita un proceso periódico de administración de la tesorería, de tal modo que las cuentas comunes del banco corresponsal retienen saldos que representan su contribución a la base de clientes del sistema de pago móvil más un porcentaje convenido de "otros" fondos del sistema de pago móvil. Una "trayectoria de adquisición de un cliente dicta el saldo de la cuenta común para un banco corresponsal dado (es decir, entre más clientes obtenga un banco corresponsal a través de "sus" trayectorias, mayor será el saldo de su cuenta común asociada. Los usuarios típicamente se asocian con socios financieros específicos, tal como un banco particular. En el sistema de pago móvil, cada usuario tendrá un perfil de usuario que tenga configuraciones para ese usuario. Estos parámetros pueden incluir (1) un nivel de participación, (2) cuál procesador (por ejemplo, cuál socio financiero), (3) parámetros de velocidad, (4) cuentas asociadas o cualquier combinación de los mismos. El sistema puede incluir cualquier número de configuraciones de parámetro en un perfil de usuario, más o menos de los que se describen en esta solicitud de patente. El sistema de la invención opera cualquier número de diferentes socios financieros (por ejemplo, 1, 2, 3, 4, 5, 6, 7, 8, 507, 1001, 2054, 3096, o más), cada uno de los cuales puede tener una interfaz de API diferente. En cada perfil de usuario, la configuración para la cuál el procesador indicará con cuál socio financiero está asociado un usuario. Cuando se lleva a cabo un negocio para ese usuario, el sistema sabrá entonces adonde (cuál banco) dirigir las transacciones y cuál API utilizar para que las transacciones de valor de cambio del usuario (las cuales típicamente son cambios de divisas) se realicen en forma adecuada. La configuración para nivel de participación serán los privilegios o nivel de servicio que el usuario tendrá. La configuración para nivel de participación puede basarse en un número de factores tales como qué información se proporciona cuando el usuario se registre, cuánto dinero tiene el usuario en la cuenta de usuario, cuántas remisiones ha realizado el usuario, cuántas transacciones ha realizado el usuario o total de dólares tramitados. Esta configuración de perfil puede actualizarse en forma periódica a medida que se recopila nueva información. Algunos ejemplos de nombres del nivel de participación para un usuario pueden ser niveles de "bronce" , "oro" y "platino" . El nivel de participación puede hacerse visible para el usuario y puede utilizarse para aumentar la lealtad de cliente. En otras modalidades de la invención, el nivel de participación puede ocultarse o de otro modo ponerse a disposición del usuario. Cuando se registra con el sistema, el sistema proporcionará al usuario una opción de cuánta información desea revelar el usuario. Por ejemplo, el usuario puede elegir revelar el número del teléfono móvil del usuario y después proveer de fondos la cuenta del usuario con dinero en efectivo. Esto puede ser el mínimo requerido para abrir una cuenta. Al usuario se le dará la opción de proporcionar otra información, tal como dirección de correo electrónico, número de tarjeta de crédito, número de seguro social (por ejemplo, para una comprobación de crédito) , número de cuenta de cheques, etcétera. En una aplicación de la invención, entre más información desee revelar el usuario, mayor será el nivel de participación que alcance el usuario. En una aplicación, para la configuración de nivel de participación, el usuario puede ser uno de cuatro estados de usuario: (1) invitado, (2) inscrito, (3) confirmado y (4) avanzado. En otras aplicaciones, pueden existir estados adicionales. Para el estado de invitado, al usuario se le ha remitido o enviado dinero viral. Viral se refiere al envío o recepción de dinero, donde uno de los usuarios es un usuario que no se ha registrado previamente con el sistema. Un usuario viral también puede ser referido como un usuario no miembro o usuario sin registrar. Viral se refiere a una característica del sistema de pago móvil de la invención que anima o permite que los usuarios actuales realicen transacciones con usuarios no miembros . A medida que más usuarios se registren y utilicen el sistema, los usuarios ayudarán a difundir noticias y atraer más usuarios, un poco en forma similar a como se transmiten los virus. Por ejemplo, para que un usuario no miembro reciba el dinero, se animará al no miembro a registrarse como miembro. Para el estado de inscrito, el usuario ha ingresado información básica, tal como un número telefónico confirmado. El teléfono puede ser confirmado por el sistema al llamar al número telefónico proporcionado por el usuario cuando se registra. Esta llamada puede ser una llamada automatizada o tipo IVR. Puede existir un incentivo para que el usuario se registre, como por ejemplo que el usuario reciba dinero (por ejemplo, $5) que se deposita en la cuenta del usuario. El incentivo puede ser referido como un bono de recomendación y puede ser por cualquier cantidad. El bono de recomendación sólo puede ser pagado al referente, sólo al referenciado o a ambos. En este estado, el usuario puede recibir y solicitar dinero. Para el estado de confirmado, se conoce la identidad del usuario. El usuario proporciona el domicilio u otra información de contacto relacionada. Un usuario en el estado de confirmado puede recibir, solicitar, agregar (es decir, cargar) o retirar (es decir, descargar) dinero. Para el estado de avanzado, el usuario ha proporcionado el número de seguro social del usuario. En este estado, por ejemplo, el usuario puede registrarse con un socio bancario particular para recibir una tarjeta. Esta tarjeta puede ser una tarjeta de débito prepagada. En otras modalidades, la tarjeta puede ser una tarjeta de crédito. El usuario podrá realizar todo lo que un usuario confirmado puede hacer, además de poder gastar el dinero en forma inmediata en cualquier lugar en el que se acepte la tarjeta. La tarjeta puede aceptarse o utilizarse a través de una o más redes, incluyendo Visa, MasterCard, American Express, NYCE, PLUS, o STAR, o cualquier combinación de las mismas. La tarjeta se asocia con la cuenta del usuario. Un usuario sin una tarjeta puede denominarse como usuario sin tarjeta mientras que un usuario con una tarjeta puede denominarse como usuario con tarjeta. Algunas de las formas en las que se puede confirmar una persona cuando se registra incluyen: Para los datos de la persona, el sistema puede solicitar el domicilio y número de licencia del conductor. Una alternativa es solicitar el domicilio y el número de seguro social. La información puede cotejarse con una base de datos de un buró de informes crediticios tal como la base de datos de Equifax. Para una cuenta bancaria asociada, esto puede confirmarse mediante el uso de depósitos rechazados. Por ejemplo, el sistema puede realizar cualquier número de depósitos pequeños en la cuenta del usuario. El usuario indica al sistema la cantidad de los depósitos para obtener la confirmación. De manera alterna, se puede confirmar al usuario a través de una confirmación de cuenta instantánea en línea en la que el usuario proporciona un nombre y contraseña de pantalla en línea. Para agregar una tarjeta de crédito o de débito, esto puede confirmarse mediante el uso de depósitos rechazados. Algunas tarjetas tales como Visa y MasterCard pueden confirmarse, de manera alterna, mediante el uso de códigos de seguridad y similares. La velocidad de participación es una configuración que establece ciertas restricciones o límites en la cuenta. Algunos ejemplos de límites de una cuenta son cuántas transacciones al día puede realizar un usuario o cantidad de dinero que puede transferirse en una transacción. Existen algunos límites rígidos y límites flexibles. Los límites rígidos no cambiarán con la intervención de una tercera parte, como por ejemplo que una persona cambie el límite. Los límites flexibles pueden cambiar dependiendo de las acciones del usuario. Por ejemplo, después de que el usuario ha sido un miembro durante seis meses, al usuario se le permite, en forma automática, realizar cinco transacciones al día cuando el límite anterior del usuario era algún número menor a cinco . Típicamente, el usuario no tendrá acceso o conocerá la configuración de velocidad de participación. Sin embargo, en cierta aplicación, se le proporcionará al usuario información de velocidad de participación, tal como límites de crédito o de transacción. Las cuentas asociadas son otra característica que puede guardarse en el perfil de un usuario. Sin embargo, cualquiera de las configuraciones de usuario discutidas en esta solicitud, o combinación de las mismas, pueden mantenerse en una ubicación separada, no necesariamente en el perfil del usuario. Las cuentas asociadas son una característica del sistema en la que múltiples identidades de un usuario se concentran o unifican en una sola cuenta. Puede existir una pieza clave (por ejemplo, tal como un número de cuenta) para el usuario y múltiples identidades pueden asociarse con esta pieza clave. Estas identidades pueden incluir múltiples números telefónicos, direcciones de correo electrónico, identificadores de mensajería instantánea, etcétera. Puede ser que el usuario no necesite conocer el número de cuenta o pieza clave para acceder a la cuenta. El usuario puede ser capaz de acceder a la cuenta del usuario a través de cualquiera de las identidades asociadas. Además, en una aplicación, para agregar identidades a una cuenta, el usuario puede validar cada una de las nuevas identidades. Esto puede realizarse a través de una llamada de respuesta de IVR o al responder a un mensaje del SMS en el caso de un número telefónico. Para un correo electrónico, esto puede realizarse a través del envío de un correo electrónico con un URL único o una clave con la que el usuario puede responder en la página web. Y con una ID de mensajería instantánea, esto puede realizarse al responder con un IM. Otras opciones disponibles en el perfil de un usuario pueden incluir configuraciones de preferencia para ciertas características. El usuario puede configurar o modificar tales opciones en cualquier momento al acceder a una pantalla de conservación de cuenta. Asimismo, se le puede preguntar al usuario si se activan o desactivan las opciones durante el flujo de registro (véase más abajo) . Una característica es una característica de aceptación automática y de aceptación manual. Cuando se activa la aceptación automática, los pagos enviados a este miembro se aceptarán en forma automática. Cuando se activa la aceptación manual, los pagos enviados a este miembro deberán aceptarse o rechazarse en forma manual . Flujos del Sistema La Figura 6 muestra un pago interbancario de persona a persona. Esta figura muestra un consumidor A que envía dinero a otro consumidor B, donde ambos consumidores son miembros del mismo socio bancario, A. El sistema de pago móvil de la invención manejará la transacción. Un flujo básico de la transacción es: (1) El consumidor A envía al sistema de pago móvil una solicitud de pago. Esta solicitud de pago puede proporcionarse mediante cualquiera de las formas discutidas en esta patente. (2) El sistema de pago móvil actualiza los registros T o de transacción en el sistema de registro (SOR) del sistema de pago móvil para reflejar la transacción. Estos registros de transacciones se gestionan mediante el sistema de pago móvil. (3) El sistema (por ejemplo, Obopay) notifica al consumidor B acerca del pago. Esto pude ser por medio de una notificación electrónica, correo electrónico, mensaje instantáneo, mensaje del SMS u otra notificación. La Figura 7 muestra un pago interbancario de persona a persona. Esta figura muestra un consumidor A que envía dinero a otro consumidor B, donde los consumidores son miembros de diferentes socios bancarios . El consumidor A tiene el banco A, y el consumidor B tiene el socio B bancario. El sistema de pago móvil de la invención manejará la transacción. Un flujo básico de la transacción es: (1) El consumidor A envía al sistema de pago móvil una solicitud de pago. (2) El sistema de pago móvil transfiere los fondos de la cuenta común a la cuenta de explotación. (3) El sistema de pago móvil transfiere los fondos de la cuenta de explotación a la cuenta común. (4) El sistema de pago móvil actualiza los registros T en el sistema de registro del sistema de pago móvil. (5) El sistema de pago móvil notifica al consumidor B acerca del pago. (6) El sistema de pago móvil se establece en forma periódica entre bancos corresponsales. Este establecimiento puede ocurrir en cualquier periodo de tiempo periódico. En vez de un tiempo real, el establecimiento puede realizare en un modo por lotes. Por ejemplo, esto puede realizarse una vez cada 24 horas. Los periodos no necesariamente tienen que ser periodos de tiempo iguales, sino que pueden ser periodos de tiempo diferentes. La Figura 8 muestra una carga de cuenta asociada. Esta figura muestra un consumidor que carga la cuenta del sistema de pago móvil del usuario con fondos de otra fuente. Por ejemplo, puede ser que un usuario desee transferir parte de los fondos a la cuenta del sistema de pago móvil del usuario desde una cuenta de cheques o tarjeta de crédito. Un flujo básico de esta transacción es: (1) El consumidor A envía al sistema de pago móvil una solicitud de "carga" que indica el crédito o instrumento de débito asociado. (2) El sistema de pago móvil (a/b) envía transacciones en tiempo real de (CO/DDA de tarjeta de crédito (fondos válidos) . (3) El sistema de pago móvil transfiere los fondos de la cuenta de explotación a la cuenta común. (4) El sistema de pago móvil actualiza los registros T en el sistema de registro del sistema de pago móvil. (5) El sistema de pago móvil realiza en forma periódica la administración de la tesorería. Esta administración puede ocurrir en cualquier periodo de tiempo periódico. Por ejemplo, esto puede realizarse una vez cada 24 horas. Los periodos no necesariamente tienen que ser periodos de tiempo iguales, sino que pueden ser periodos de tiempo diferentes. Un ejemplo específico de una carga de tarjeta de crédito. Desde la web, un usuario ingresa un número de tarjeta de crédito para cargar $300 en la tarjeta de MPS del usuario. El MPS obtiene una autorización por $300 de Pay-By-Touch (PBT) para la transacción de la tarjeta de crédito. El MPS envía un mensaje al socio financiero que soporta la tarjeta de MPS que inicia un pago de persona a persona de $300 de la cuenta de tarjeta de crédito de MPS a la cuenta de tarjeta de débito del usuario. La cuenta del usuario se abona en forma inmediata con los fondos . El PBT establece la transacción de tarjeta de crédito y envía una ACH de $300 a la cuenta de establecimiento de MPS en el banco de MPS que maneja la cuenta de establecimiento. El MPS envía una ACH de $300 a la cuenta maestra de la tarjeta de crédito de MPS para reponer los fondos . La Figura 9 muestra una descarga de cuenta asociada. Esta figura muestra un consumidor que descarga fondos de la cuenta del sistema de pago móvil del usuario a otra cuenta. Por ejemplo, puede ser que un usuario desee transferir parte de los fondos de la cuenta del sistema de pago móvil del usuario a la cuenta de cheques, tarjeta de crédito u otra cuenta del usuario. Un flujo básico de esta transacción es : (1) El consumidor A envía al sistema de pago móvil una solicitud de carga que indica el instrumento de crédito asociado. (2) El sistema de pago móvil envía la transacción en tiempo real de DDA (fondos válidos) . (3) El sistema de pago móvil transfiere los fondos de la cuenta común a la cuenta de explotación. (4) El sistema de pago móvil actualiza los registros T en el sistema de registro del sistema de pago móvil. (5) El sistema realiza en forma periódica la administración de la tesorería. En una modalidad específica, esta invención se refiere a un sistema de pago y, en particular, en una modalidad específica, a un sistema en línea para realizar transacciones de pagos mediante el uso de teléfonos móviles. Existe la necesidad de un sistema en línea que permita el intercambio y otras transacciones de dinero u otro valor mediante el uso de teléfonos móviles. En un sistema de pago de persona a persona, los miembros existentes de un sistema de pago pueden enviar fondos a no miembros (quienes también pueden ser referidos como usuarios no registrados) con el objetivo de que el no miembro se vuelva un miembro. Esta capacidad de un sistema de pagos puede ser referida como "viral" debido a que promueve nuevos registros de miembros en una forma de propagación exponencial . Con respecto a un sistema de pagos de persona a persona, esta invención aborda la capacidad de los miembros existentes de un sistema de pagos de enviar fondos a no miembros con el objetivo de que el no miembro se vuelva un miembro. Esta capacidad de un sistema de pagos puede ser referida como "viral" debido a que promueve nuevos registros de miembros en una forma de propagación exponencial. Algunos elementos de la capacidad viral incluyen lo siguiente, lo cual no se menciona en un orden particular. (1) Un sistema de pagos que permite que los miembros existentes envíen fondos a no miembros a través de algún identificador único o "id" . Este identificador único normalmente puede estar disponible. Algunos ejemplos de tales identificadores incluyen correo electrónico, números telefónicos (por ejemplo, línea terrestre, voz sobre IP, teléfono móvil, buscapersonas o fax), números de seguro social, números de cuenta, números de matrícula, nombre de usuario de mensajería instantánea y otros. Un usuario puede seleccionar el identificador, tal como la elección de un no miembro de un número telefónico o de una dirección de correo electrónico . (2) El sistema de pago notifica al miembro existente que la transacción de "enviar fondos" que están a punto de realizar es para un no miembro y proporciona al miembro existente una oportunidad de cancelar esta transacción como resultado. (3) En caso de que el miembro existente elija enviar los fondos a un no miembro, el sistema de pagos debe notificar al no miembro, a través de diversos mecanismos de comunicación normalmente disponibles (tales como correo electrónico, teléfono y otros) , que se le han enviado los fondos. (4) El sistema de pagos debe permitir que el no miembro "invitado" acepte o rechace los fondos que el miembro existente intenta enviar. (5) Si el no miembro invitado decide aceptar los fondos del miembro existente, entonces el sistema de pagos debe permitir la capacidad de que el no miembro se registre a través de diversos mecanismos de comunicación normalmente disponibles (tales como correo electrónico, teléfono y otros) . (6) Para completar una transacción viral, el sistema de pagos facilitara, finalmente, una transferencia de fondos de la cuenta de los miembros existentes a la cuenta de los nuevos miembros . A continuación se encuentran varias modalidades de técnicas para realizar la transferencia de fondos viral en un sistema de pagos. Modalidad 1A Recordatorio del Pago complementario. Se le recuerda a un miembro existente acerca del pago después del registro de un nuevo miembro. En los siguientes ejemplos se utiliza Obopay como un ejemplo de un sistema de pagos específico; sin embargo, se pueden utilizar otros sistemas de pago. Un sistema de pago puede denominarse o conocerse por cualquier nombre. El sitio web obopay.com se identifica en forma específica; sin embargo, se puede utilizar cualquier sitio web, nombre de sitio web o dirección de IP apropiado. Asimismo, la invención puede utilizarse en el contexto de otras infraestructuras de red, no sólo en la Internet. 1. El usuario A miembro existente decide invitar a un usuario B no miembro a unirse al enviar dinero a B, con lo cual B tiene que afirmar al inscribirse como un miembro. 2. El usuario A envía una transacción de pago a B al introducir el número del teléfono móvil de B y la cantidad de dinero. El sistema no distingue inicialmente entre pagos enviados a miembros y a no miembros . 3. Si el número del teléfono móvil no es para un miembro actual, el usuario A recibe el siguiente mensaje "Aviso: Su pago a un no miembro está pendiente". 4. El usuario A también recibe un correo eléctrico redactado como sigue: "Gracias por su remisión". Hemos contactado a su amigo y lo hemos invitado a inscribirse a nuestro sistema" . 5. El pago enviado a B se cobra de la cuenta de A y se mantiene en tránsito hasta la inscripción de B. 6. El usuario B recibe un mensaje que dice que A le ha enviado dinero y que B puede obtener el dinero al inscribirse en obopay.com. 7. El usuario B se inscribe en el sitio web del sistema (por ejemplo, obopay.com). 8. Después de que el usuario B se escribe en forma satisfactoria, la cuenta de B se provee de fondos en forma automática con el pago de A. Modalidad IB La Figura 10 muestra un sistema de pago y un pago de persona a persona de acuerdo con una técnica como se describe para la modalidad IB de la invención. 1. El usuario A miembro existente decide invitar a un usuario B no miembro a unirse al enviar dinero a B, con lo cual B tiene que afirmar al inscribirse como un miembro. 2. El usuario A envía una transacción de pago a B al introducir el número del teléfono móvil de B y la cantidad de dinero. El sistema no distingue inicialmente entre pagos enviados a miembros y a no miembros . 3. Si el número del teléfono móvil no es para un miembro actual, el usuario A recibe el siguiente mensaje "Aviso: Su pago se ha enviado a un usuario no miembro. ¿Le gustaría que lo hagamos una invitación a que se una? Sí/No" . 4. Si la respuesta a la etapa 3 es sí, el usuario A también recibe un correo electrónico redactado como sigue: "Gracias por su remisión" . Hemos contactado a su amigo y lo hemos invitado a inscribirse a nuestro sistema" . 5. El pago no se cobra de la cuenta del usuario A. 6. El usuario B recibe un mensaje que dice que A ha invitado a B a unirse al sistema para que A pueda enviarle dinero a B. 7. El usuario B se inscribe en el sitio web del sistema (por ejemplo, obopay.com). 8. Después de que B se inscribe en forma satisfactoria, se le notifica a B que A desea enviarle dinero y que B puede realizar una "Solicitud de Pago" para el pago.
Si B acepta, se le muestra a B una transacción prellenada de Solicitud de Pago con el número telefónico de A y la cantidad del pago original indicada. 9. El usuario A recibe una Solicitud de Pago y accede al pago. 10. El dinero se cobra de la cuenta de A y se abona a la cuenta de B. Se notifica a B. Modalidad 2 Viral de Fondos Reservados Personales - Se permite que los miembros existentes repartan los fondos que están reservados para pagos virales. Por ejemplo, un usuario puede repartir una cierta cantidad de dinero de la cuenta del usuario para establecer transacciones virales. Estos fondos no estarán disponibles de otro modo para el usuario para su uso en transacciones no virales (por ejemplo, gasto mediante la tarjeta de crédito) . En una aplicación, el usuario puede cambiar la cantidad reservada a través de la función de conservación de cuenta de un usuario. Modalidad 3 Viral conversacional - El ciclo de vida viral total ocurre en tiempo real con ambas partes siendo notificadas de las otras "etapas" en el trayecto. Por lo tanto, la transferencia de fondos final es únicamente una transferencia entre dos miembros . Modalidad 4 Viral promisoria - El miembro existente promete pagar al miembro invitado si o cuando se registre. Los fondos del miembro existente se reservan para el pago complementario una vez que se registra el miembro invitado. Modalidad 5 Viral de Fondos Divididos - El sistema de pago motiva a los miembros existentes a realizar pagos virales al ofrecer una división de fondos en la que el sistema de pagos iguala la cantidad de pagos a través de cantidades fijas o porcentuales. Modalidad 6 Viral de Fondos Solicitados - En lugar de que los miembros existentes envíen fondos a un no miembro, el miembro existente solicita fondos de un no miembro. Una aplicación de la invención puede incluir cualquiera de las características descritas en lo anterior. En un sistema de la invención, las modalidades anteriores pueden aplicarse en forma individual o en combinación con cualquier otra modalidad o modalidades. Una aplicación específica describe el uso de un número de teléfono móvil como un identificador para un usuario. Sin embargo, se puede utilizar cualquier identificador para cada usuario, tal como cualquier número telefónico (por ejemplo, número telefónico de casa, número telefónico del trabajo, número telefónico de voz sobre IP, fax o buscapersonas) , dirección de correo electrónico, nombre de usuario de mensajería instantánea, número de seguro social, número de licencia del conductor, número de membresía, número de tarjeta de crédito, número de tarjeta de débito u otros. El correo electrónico se ha discutido como una técnica para enviar mensajes entre usuarios; sin embargo, se pueden utilizar otras técnicas de comunicación, incluyendo correo de voz, mensajería automatizada de voz, mensajes instantáneos o mensajes de texto. El usuario A y el usuario B se han discutido simplemente como representantes de dos de los numerosos usuarios que un sistema puede tener. Un sistema de la invención puede tener cualquier número de usuarios. La figura 1 muestra un diagrama de bloques general que representa un sistema de pago móvil entre dos o más personas que utilizan la presente invención. En un sistema de la invención, el usuario A envía fondos al usuario B a través de un identificador o ID único. El identificador único normalmente puede estar disponible. Ejemplos incluyen números telefónicos (por ejemplo, línea terrestre, voz sobre IP, teléfono móvil, buscapersonas o fax) , dirección de correo electrónico, número de seguro social, número de cuenta, número de matrícula, nombre de usuario de mensajería instantánea y otros. Este identificador puede utilizarse para contactar a un usuario independientemente de pasar por el sistema de la invención (por ejemplo, un número telefónico o dirección de correo electrónico, donde se puede contactar directamente a un usuario sin involucrar el sistema) . Cada identificador único puede asociarse sólo con un usuario para asegurar la cuenta y seguridad del sistema. El usuario A también puede proporcionar detalles de la transacción financiera, tal como la cantidad que se va a transferir o la forma de pago, o combinaciones de las mismas, y un número de PIN si se solicita para validar una cuenta. El sistema identifica al usuario A como un miembro y puede verificar el número de PIN, validar la cuenta y verificar el saldo para la cuenta del usuario A. En caso de que la cuenta del usuario A no tenga fondos suficientes para la transacción financiera, el sistema puede enviar una notificación electrónica al usuario A por fondos insuficientes. Si la cuenta del usuario A tiene fondos suficientes para la transacción, el sistema también notifica al usuario B acerca de la transacción pendiente a través de la tecnología móvil. Debido a las notificaciones electrónicas inmediatas que los Usuarios A y B recibieron, parecerá como si la transacción financiera ocurriera casi de manera inmediata . El sistema puede permitir que los usuarios establezcan preferencias con respecto a la aceptación de transacciones. Si el usuario B seleccionó una configuración de aceptación automática (seleccionada cuando un usuario se registra en el sistema) para aceptar pagos en forma automática, los fondos se transfieren de la cuenta del usuario A a la cuenta del usuario B en forma inmediata. Si el usuario B seleccionó una configuración de aceptación manual, los fondos se transfieren sólo después de que el usuario B aprueba la transacción. El sistema también puede incluir una configuración para que los usuarios estipulen que sólo aceptarán transacciones de miembros específicos o, por el contrario, no aceptarán pagos de miembros específicos. Si el usuario B no ha aprobado aún la transacción después de un cierto número de días establecidos por el sistema, tal como treinta días, el sistema puede cancelar la transacción en forma automática. Después, el sistema puede enviar notificaciones electrónicas tanto al usuario A como al usuario B notificándoles acerca de la transacción cancelada. El usuario B también puede tener la opción de rechazar la transacción, en cuyo caso, se puede notificar al usuario A, a través de una notificación electrónica, acerca del pago rechazado. En caso de que el usuario A tenga fondos suficientes y que el usuario B acepte la transacción, la cantidad se cobra de la cuenta del usuario A y se abona a la cuenta del usuario B. Las transacciones pueden retrasarse debido a retardos inherentes en el sistema electrónico de transacción financiera. Algunos ejemplos específicos de flujos se presentan en esta aplicación. Sin embargo, debe entenderse que la invención no se limita al flujo y etapas específicas presentadas. Un flujo de la invención puede tener etapas adicionales que no necesariamente tiene que describirse en esta aplicación, diferentes etapas que sustituyen algunas de las etapas presentadas, menos etapas o un subconjunto de las etapas presentadas, o etapas en un orden diferente al que se presenta, o cualquier combinación de las mismas. Además, las etapas en otras aplicaciones de la invención no tienen que ser exactamente iguales a las etapas presentadas. Como un ejemplo específico, el identificador (ID) único o electrónico se describe como el número del móvil del usuario B. En otras modalidades de la invención, el identificador no se limita al número telefónico del usuario B. El identificador también puede ser el nombre de usuario de mensajería instantánea o dirección electrónica del usuario B en otras aplicaciones de la invención. Otro ejemplo de una variación posible en los flujos, sin apartarse del alcance de la invención, son los mensajes específicos que los usuarios A y B reciben en diversas etapas en los flujos. En otras modalidades de la invención, estos mensajes pueden ser diferentes de aquellos especificados especialmente en esta solicitud o algunos mensajes no tienen que enviarse, y combinaciones de los mismos . La Figura 11 muestra un método para realizar una transacción entre un miembro con una tarjeta y un usuario sin registrar. Este flujo incluye: (1) El miembro A envía una solicitud de "pago" al servidor del servicio de pago móvil con el no miembro B como objetivo. (2) El servicio de pago móvil identifica la fuente como miembro, valida la cuenta, verifica el saldo y verifica el PIN. (3) el servicio de pago móvil identifica el objetivo como no miembro. (4) el servicio de pago móvil notifica al miembro A fuente acerca del pago. (5) el servicio de pago móvil notifica al no miembro B objetivo acerca del pago. (6) (a/b) El servicio de pago móvil cobra a la cuenta de la tarjeta del miembro y abona en la cuenta común viral. (7) (a/b) El servicio de pago móvil registra la transacción de débito del miembro fuente y registra la transacción de crédito viral del objetivo. Las etapas 6 y 7 pueden ser hilos asincronos por parte del servidor. Esto significa que estas acciones en una modalidad ocurren en forma asincrona. El servidor solicita las acciones, pero éstas no necesariamente se realizan por el servidor en sí, por lo que la conclusión de las acciones es independiente del procedimiento del servidor que llama. La Figura 12 muestra un método para realizar una transacción entre un miembro sin una tarjeta y un usuario sin registrar. El flujo incluye: (1) El miembro A envía una solicitud de "pago" al servidor del servicio de pago Móvil con el no miembro B como objetivo. (2) El servicio de pago móvil identifica la fuente como miembro, valida la cuenta, verifica el saldo y verifica el PIN. (3) El servicio de pago móvil identifica el objetivo como no miembro. (4) El servicio de pago móvil notifica al miembro A fuente acerca del pago. (5) El servicio de pago móvil notifica al no miembro B objetivo acerca del pago. (6) (a/b) El servicio de pago móvil cobra a la cuenta común del miembro y abona en la cuenta común viral. (7) (a/b) El servicio de pago móvil registra la transacción de débito del miembro fuente y registra la transacción de crédito viral del objetivo. Las etapas 6 y 7 pueden ser hilos asincronos por parte del servidor. La Figura 13 muestra un método para realizar una transacción entre un miembro sin tarjeta y otro miembro sin tarjeta. El flujo incluye: (1) El Miembro A envía una solicitud de "pago" para el miembro B. (2) El servicio de pago móvil identifica la fuente A como miembro, valida la cuenta, verifica el saldo y verifica el PIN. (3) El servicio de pago móvil identifica el objetivo B como miembro y valida la cuenta. (4) El servicio de pago móvil notifica al miembro A fuente acerca del pago. (5) El servicio de pago móvil notifica al miembro B objetivo acerca del pago. (6) (a/b) El servicio de pago móvil registra la transacción de débito del miembro A y registra la transacción de crédito del miembro B. La etapa 6 puede ocurrir mediante el uso de un hilo asincrono por parte del servidor. La Figura 14 muestra un método para realizar una transacción entre un miembro con tarjeta y otro miembro con tarjeta. El flujo incluye: (1) El miembro A envía una solicitud de "pago" al servidor del servicio de pago móvil con el miembro B como objetivo. (2) El servicio de pago móvil identifica la fuente A como miembro, valida la cuenta, verifica el saldo y verifica el PIN. (3) El servicio de pago móvil identifica el objetivo B como miembro y valida la cuenta. (4) El servicio de pago móvil notifica al miembro A fuente acerca del pago. (5) El servicio de pago móvil notifica al miembro B objetivo acerca del pago. (6) (a/b) El servicio de pago móvil cobra a la cuenta de la tarjeta del miembro A y abona en la cuenta de la tarjeta del miembro B. (7) (a/b) El servicio de pago móvil registra la transacción de débito del miembro A y registra la transacción de crédito del miembro B. Las etapas 6 y 7 pueden ser hilos asincronos por parte del servidor. La Figura 15 muestra un método para realizar una transacción entre un miembro con tarjeta y un miembro sin tarjeta. El flujo incluye: (1) El miembro A envía una solicitud de "pago" al servidor del servicio de pago móvil con el miembro B como objetivo. (2) El servicio de pago móvil identifica la fuente A como miembro, valida la cuenta, verifica el saldo y verifica el PIN. (3) El servicio de pago móvil identifica el objetivo B como miembro y valida la cuenta. (4) El servicio de pago móvil notifica al miembro A fuente acerca del pago. (5) El servicio de pago móvil notifica al miembro B objetivo acerca del pago. (6) (a/b) El servicio de pago móvil cobra a la cuenta de la tarjeta del miembro A y abona en la cuenta común del Miembro. (7) (a/b) El servicio de pago móvil registra la transacción de débito del miembro A y registra la transacción de crédito del miembro B. Las etapas 6 y 7 pueden ser hilos asincronos por parte del servidor. La Figura 16 muestra un método para realizar una transacción entre un miembro sin tarjeta y un miembro con tarjeta. El flujo incluye: (1) El miembro A envía una solicitud de "pago" al servidor del servicio de pago móvil con el miembro B como objetivo. (2) El servicio de pago móvil identifica la fuente A como miembro, valida la cuenta, verifica el saldo y verifica el PIN. (3) El servicio de pago móvil identifica el objetivo B como miembro y valida la cuenta. (4) El servicio de pago móvil notifica al miembro A fuente acerca del pago. (5) El servicio de pago móvil notifica al miembro B objetivo acerca del pago. (6) (a/b) El servicio de pago móvil cobra a la cuenta común del miembro y abona en la cuenta de la tarjeta del miembro B. (7), (a/b) El servicio de pago móvil registra la transacción de débito del miembro A y registra la transacción de crédito del miembro B. Las etapas 6 y 7 pueden ser hilos asincronos por parte del servidor . La Figura 17 muestra un método de registro para un usuario sin registrar. El flujo incluye: (1) El miembro que será A envía la solicitud de registro. (2) Se crea la cuenta del nuevo miembro. (3) Se verifican los controles de riesgo de identidad para el nuevo miembro y la cuenta se actualiza en consecuencia. (4) Buscar registros virales asociados con el Nuevo Miembro. (5) (a/b) El servicio de pago móvil cobra a la cuenta común viral y abona en la cuenta común del miembro. (6) (a/b) El servicio de pago móvil registra el débito viral de la fuente y registra el crédito del miembro objetivo. (7) Buscar incentivos aplicables al nuevo Miembro. (8) (a/b) El servicio de pago móvil cobra a la cuenta de Incentivos y abona en la cuenta común del Miembro. (9) El servicio de pago móvil registra el crédito de incentivos del nuevo miembro. Las etapas 5, 6 y 7 pueden ser hilos asincronos por parte del servidor. La Figura 18 muestra un método para activar una tarjeta. El flujo incluye: (1) El Miembro A recibe una tarjeta en el correo y llama al IVR del servicio de pago móvil para activarla. (2) Durante la interacción de IVR el servicio de pago móvil cierra la cuenta sin tarjeta. (3) (a/b) El servicio de pago móvil cobra a la cuenta común del miembro y abona en la cuenta de la tarjeta individual del nuevo miembro A. (4) (a/b) El servicio de pago móvil registra la transacción de débito común del miembro y registra la transacción de crédito del miembro A. (5) El sistema del servicio de pago móvil envía un correo electrónico de declaración de cierre de actividad sin tarjeta al miembro A. Las etapas 3 y 4 pueden ser hilos asincronos por parte del servidor . En una aplicación, el sistema maneja pagos electrónicos de proximidad cercana, tal como mediante el uso de NFC, Bluetooth, RFID, haz infrarrojo, haz de LED u otras tecnologías de proximidad cercana. Una situación puede ser que los miembros A y B se encuentren físicamente cercanas entre sí y que deseen realizar un pago electrónico. Esto puede ser un escenario de consumidor a consumidor o de consumidor a comercio. Esto puede ser un enviar fondos, obtener ' fondos o cualquier otro escenario de transferencia de dinero . Un flujo básico de tal transacción es: (1) A y B convienen realizar una transacción de pago electrónico de proximidad cercana. (2) B selecciona "prepararse para la recepción de proximidad cercana" . El dispositivo busca el PIN, B ingresa el PIN, el dispositivo activa el modo de recibir. (3) A selecciona "prepararse para el envío de proximidad cercana" . El dispositivo busca el PIN, A ingresa el PIN, el dispositivo activa el modo de enviar. (4) A y B ponen los dispositivos en un margen de proximidad adecuado. A y B tienen una cantidad limitada de tiempo para realizar esta etapa, de otro modo el dispositivo se interrumpirá. (5) Los dispositivos de A y B se reconocen entre sí y se transmiten información de pago entre sí. (6) A y B revisan el dialogo de confirmación en los dispositivos y seleccionan "confirmar" . (7) Se inicia la transacción de pago. El sistema permite transacciones de múltiples canales y de ínter-canal. En particular, los pagos pueden solicitarse desde cualquiera de los canales disponibles (por ejemplo, teléfono móvil, mensajería instantánea, correo electrónico, Web, tarjeta de débito, WAP, mensaje del SMS o aplicación dedicada de teléfono móvil) y la transacción puede llevarse a cabo para cualquiera de los canales disponibles, en cualquier combinación. Por ejemplo, alguien puede solicitar el pago desde la mensajería instantánea hacia el teléfono móvil, desde la web hacia el teléfono móvil, desde el teléfono móvil hacia la mensajería instantánea, desde la WAP hacia la mensajería instantánea, desde la mensajería instantánea hacia el correo electrónico, desde el correo electrónico hacia el teléfono móvil, desde el correo electrónico hacia la mensajería instantánea, desde la Web hacia el SMS, desde el SMS hacia el correo electrónico o cualquier otra combinación. El sistema también puede utilizarse para pagar a través de terminales de pago, sitios web interactivos, pagar servicios o contenido de medios a través de la televisión (por ejemplo, pagar películas solicitadas por un proveedor de cable o satélite) , teléfonos prepagados y muchos otros. Por ejemplo, un usuario puede pagar a un comercia a través de la mensajería instantánea. El sistema puede soportar el pago a o a través de máquinas expendedoras, parquímetros, quiscos, teléfonos públicos, quioscos para boletos de avión y muchos otros. El Flujo A en lo siguiente muestra una aplicación para realizar una transacción entre un miembro usuario registrado (usuario A) y un usuario no registrado (usuario B) .
Flujo A Etapa Acción 1 El usuario A existente decide enviar algún dinero al usuario B, un usuario sin registrar. A envía un mensaje al sistema de pago móvil con el número del teléfono móvil de B y la cantidad de la transacción. 2 El sistema de pago móvil verifica si la cuenta de A tiene fondos suficientes para cubrir la transacción. 3 Si no existen fondos suficientes, se le envía un mensaje a A: "fondos insuficientes. [tel#] , [valor] , [trans#] " B no recibe ningún mensaje Si existen fondos suficientes, proceder a la siguiente etapa.
Etapa Acción Verificar si B es un usuario registrado o no registrado. Si el número del teléfono móvil de B no se reconoce como un usuario registrado, A recibe el siguiente mensaje: "Su solicitud ha sido aceptada y será procesada. [tel#] , [valor] , [trans#] Usuario no registrado pendiente de solicitud" . Colocar una retención sobre la cantidad de la transacción en la cuenta de A. B recibe el siguiente mensaje: "Pago pendiente de [tel#] , [valor] , [trans#] Ir a la página web del sistema para registrarse" . Antes de que B apruebe el pago, A puede cancelar el pago. Si es así, A y B recibirán el mensaje: "Pago cancelado. [tel#] , [valor] , [trans#] " Si pasan más de 30 días después de que A inicia la transacción y antes de que B apruebe el pago, la transacción se cancela automáticamente. Después A y B recibirán el mensaje: "Pago cancelado. [tel#] , [valor] , [trans#] " Después de que pasan 30 días, eliminar retención en la cantidad de transacción en la cuenta de A. 8 B se registra con el sistema de pago móvil. Se crea una cuenta para B en el sistema 9 Después de que B se registra con éxito, se le notifica a B que A desea enviarle dinero a B. B se presenta con una pantalla preguntando si B aceptará el pago de A, rechazará el pago de A o solicitará un cambio en la transacción pendiente de A. 10 Si B rechaza el pago, la transacción se cancela y A recibe un mensaje: "Pago rechazado. [tel#] , [valor] , [trans#] " 11 Si B solicita un cambio, B se presentará con una pantalla en la que B podrá negociar o solicitar un cambio en un término de la transacción de A. Si B no solicita un cambio, proceder a la etapa 13.
Etapa Acción 12 Si B desea cambiar la transacción (por ejemplo, cambiar la cantidad de la transacción) , se le envía un mensaje a A con respecto al cambio propuesto. A podrá aceptar o rechazar el cambio propuesto de B. 13 Si B acepta el pago de A, el sistema verifica si A tiene fondos suficientes para cubrir la transacción. Si no, A y B recibirán el mensaje: "fondos insuficientes. [tel#] , [valor] , [trans#] " 14 Si A tiene fondos suficientes, A recibe el mensaje: "Pago aceptado. [tel#] , [valor], [trans#] " 15 La cantidad de la transacción se cobra de la cuenta de A y se abona a la cuenta de B .
En la etapa 1, el usuario A identifica al usuario B para el sistema de pago móvil a través del número del teléfono móvil de B. En otras aplicaciones de la invención, el usuario A puede identificar al usuario B a través de otros medios, tal como la dirección de correo electrónico de B, nombre de mensajería instantánea u otros identificadores únicos. Estos identificadores pueden ser identificadores de identificación electrónica y pueden ser identificadores que pueden utilizarse para identificar a B aun fuera del contexto del sistema de pago móvil. En otras palabras, el identificador no necesariamente es único para el sistema de pago móvil (por ejemplo, número de cuenta) . En una aplicación específica, el sistema de pago móvil no permite que un usuario registrado existente solicite el pago de un usuario sin registrar. En otra modalidad, un usuario puede solicitar el pago de un usuario sin registrar. En la etapa 2, el sistema de pago móvil verifica si la cuenta de A tiene fondos suficientes para cubrir la transacción. El sistema de pago móvil también puede realizar una validación de cuenta y de PIN u otras etapas de validación para asegurar que la cuenta de A no se ha suspendido, que tiene fondos suficientes, etcétera. Estas etapas se han omitido del flujo anterior para mejorar la claridad . En la etapa 3, el sistema de pago móvil notifica al usuario A de los fondos insuficientes a través de la mensajería del SMS. En otra modalidad de la invención, el usuario A puede recibir este mensaje en otras formas, tal como correo electrónico, mensajería del SMS u otras formas de comunicación móvil. En algunas modalidades de la invención, puede ser que el usuario no reciba este mensaje en absoluto, tal como el caso en el que el usuario A ha decidido e indicado al sistema no recibir tales mensajes. El flujo también puede aplicarse al sistema de pagos por correo electrónico u otros sistemas de pago, móvil, no móvil (es decir, en los casos en los que un teléfono móvil no está implicado en la transacción), o de algún otro modo. En la etapa 4, el sistema de pago móvil determina que el usuario B no está registrado y notifica al usuario A de esto. En otra modalidad de la invención, el sistema puede permitir que el usuario A envíe el pago al usuario B independientemente del estado de no registrado del usuario B y, por lo tanto, puede saltarse esta etapa. En la etapa 5, el sistema de pago móvil coloca una retención en la cuenta de A para la cantidad de la transacción. La cantidad de la transacción no se cobra de la cuenta de A hasta que la cantidad de la transacción se cobra en la etapa 15. En la etapa 6, el sistema de pago móvil envía un mensaje al usuario B sin registrar solicitando el registro del usuario B en el sistema. Este mensaje puede enviarse al teléfono móvil de usuario B a través de mensajería del SMS, correo electrónico, mensajería del SMS, mensajería instantánea u otras formas de comunicación móvil. En la etapa 7, al usuario A se le proporciona la opción de poder cancelar el pago antes de que el usuario B lo acepte. El pago también puede evitarse en forma automática si han pasado más de 30 días después de que el Usuario A envía el pago y antes de que el usuario B acepte el pago. El número de días después de los cuales la transacción se cancela en forma automática puede variar. Por ejemplo, el número de días puede ser cualquier número, tal como 5, 10, 14, 15, 16, 21 o más o menos de 30 días. Asimismo, puede ser que los usuarios A y B no reciban un mensaje que les notifique la transacción cancelada.
En la etapa 8 el sistema crea una cuenta para el usuario B después del registro del usuario B. En otra modalidad de la invención, puede ser que el sistema no requiera que el usuario B se registre en el sistema y que pueda, en cambio, enlazar en forma automática el sistema con una de las cuentas bancarias del usuario B. En la etapa 9 al usuario B sólo se le envía un mensaje con respecto a la solicitud del usuario A de enviar el pago sólo después de que el usuario B se registra en el sistema. En otra modalidad de la invención, el usuario B puede recibir el mensaje con respecto al pago del usuario A sin tener que registrarse en el sistema. En la etapa 10 de la modalidad actual, al usuario A se le envía un mensaje del SMS con respecto a la cancelación de la transacción del usuario B. En otra modalidad de la invención, el sistema puede enviar al usuario A un mensaje diferente, y puede enviarlo en otras formas de comunicación móvil . En la etapa 11, B puede tener opciones para cambiar o modificar la transacción en algún modo. Al usuario B se le puede proporcionar un botón de sí, botón de no y botón de cambio de solicitud. De manera alterna, el botón de cambio de solicitud puede ser referido como botón negociador, ya que a B se le da la oportunidad de negociar con A. B se le puede dar la oportunidad de cambiar cualquier término de la transacción. Algunos términos de la transacción pueden ser que B puede cambiar incluir la cantidad, cantidad, seleccionar de cuál cuenta de dinero se cobrará a, u otra. En la etapa 12, si el usuario B solicita un cambio en la transacción, al usuario A se le envía una notificación con respecto al cambio propuesto. Al usuario A se le proporciona la capacidad de aceptar o rechazar el cambio propuesto del usuario B. En una modalidad de la invención, el usuario A puede haber elegido rechazar en forma automática los cambios propuestos en su configuración inicial con el sistema. Después, se le puede enviar al usuario B un mensaje automático del usuario A rechazando el cambio. Si el usuario A rechaza el cambio, ya sea en forma manual o automática, al usuario B se le puede dar la opción de enviar otro cambio propuesto al usuario A. 0 se le puede dar a B la oportunidad de aceptar la transacción original. En la etapa 13, el sistema de pago móvil notifica al Usuario A de los fondos insuficientes a través de la mensajería del SMS. En otra modalidad de la invención, el Usuario A puede recibir este mensaje en otras formas, tal como correo electrónico, mensajería del SMS u otras formas de comunicación móvil o puede ser que no reciba este mensaje en absoluto . En la etapa 14 al usuario A se le envía una notificación del SMS similar a un acuse de recibo que le notifica que la transacción fue completada. En otra modalidad, al usuario A se le puede enviar una notificación en otras formas, tal como a través de correo electrónico, mensajería instantánea, mensajería del SMS u otras formas de comunicación móvil. El sistema también puede enviar al usuario B una notificación de que la transacción se ha completado. Asimismo, puede ser que el sistema no envíe a los usuarios A o B ningún mensaje con respecto a la terminación de la transacción. En la etapa 15 la transacción de dinero tiene lugar. En una aplicación, las transacciones de crédito y de débito no ocurren en tiempo real. Las transacciones pueden tomar aproximadamente sesenta segundos o más para completarse después de que se inicia un proceso debido a los retardos inherentes en los sistemas de financiación electrónica. Cualquier número de las etapas en el flujo A, en cualquier combinación, puede combinarse con otro flujo del sistema de pago móvil, incluyendo los otros flujos discutidos en esta solicitud. El Flujo B en lo siguiente muestra otra aplicación para realizar una transacción entre un miembro usuario registrado (usuario A) y un usuario no registrado (usuario B) .
Flujo B Etapa Acción 1 El usuario A existente decide enviar algún dinero al usuario B, un usuario sin registrar. A envía un mensaje al sistema de pago móvil con el número del teléfono móvil de B y la cantidad de la transacción. 2 El sistema de pago móvil verifica si la cuenta de A tiene fondos suficientes para cubrir la transacción. 3 Si no existen fondos suficientes, se le envía un mensaje a A: "Fondos insuficientes. [tel#] , [valor] , [trans#] " B no recibe ningún mensaje Si existen fondos suficientes, proceder a la siguiente etapa. 4 Verificar si B es un usuario registrado o no registrado. Si el número del teléfono móvil de B no se reconoce como un usuario registrado, A recibe el siguiente mensaje: "Su pago está pendiente. El usuario no registrado debe abrir una cuenta. [tel#] , [valor] , [trans#] " 5 B recibe el siguiente mensaje: "¡Ha recibido el dinero! [tel#] , [valor] , [trans#] " Ir a la página web del sistema para registrarse" . 6 Iniciar transacción de cobro del dinero de la cuenta individual de A y abonar a B en una cuenta común de usuario sin registrar. 7 Si las transacciones de cobro y de abono fallan, A y B reciben el mensaje: "Pago fallido. tel#] , [valor] , [trans#] " De otro modo, las transacciones de cobro y de abono son exitosas. No se envía ningún mensaje. 8 Si pasan más de 30 días después de que A inicia la transacción y B aún no se ha registrado, la transacción se cancela automáticamente. Después A y B recibirán el mensaje: "Pago cancelado. [tel#] , [valor] , [trans#] " Etapa Acción Las transacciones de crédito y de débito solicitadas en la etapa 6 en lo anterior se invierten. La cuenta individual de A se abona con la cantidad de la transacción, la cual se toma de la cuenta común de usuario sin registrar. 9 B se registra en la página web del sistema y se vuelve un usuario sin tarjeta, registrado. El dinero se transfiere de la cuenta común de usuario sin registrar a la cuenta común sin tarjeta para B. 10 Se genera la tarjeta de débito de plástico para B y se envía por correo a B. 11 Después de que B recibe la tarjeta, B activa la tarjeta al llamar a un sistema de respuesta de voz interactiva (IVR. Durante la activación, en tiempo real mientras B se encuentra conectado al sistema de IVR, el dinero se transfiere de la cuenta común sin tarjeta a la cuenta individual de B.
La aplicación en el flujo B es similar al flujo A anterior. Sin embargo, a diferencia del flujo A, el flujo B no coloca una retención en la cantidad de la transacción en la cuenta de A (etapa 5 del flujo A) . En la etapa 4 del flujo B, puesto que no existe ninguna retención en la cuenta de A y no se cobra a la cuenta de A, el dinero se encuentra disponible para el usuario A para su gasto mediante el pago móvil o pago con tarjeta de débito hasta que la cantidad de la transacción se cobre con éxito de la cuenta del usuario A en la etapa 6. En la etapa 5 al usuario B se le envía un mensaje con respecto a la transacción y se le pide que se registre en el sistema.
En la etapa 6 la transacción de dinero se lleva a cabo. Las transacciones pueden ser hilos asincronos que toman aproximadamente sesenta segundos o más para completarse después de que se inicia un proceso debido a los retardos inherentes en los sistemas de financiación electrónica. La cantidad de retardo es indeterminada puesto que diversos factores influyen en el retardo. En general, el retardo es de aproximadamente 60 segundos, pero si la red eléctrica interrumpe su funcionamiento, por ejemplo, el retardo será mucho mayor. En particular, el procesamiento de pago de un sistema puede no realizarse en una forma sincrónica. Una cierta cantidad de validación de solicitud por adelantado se realiza. Las notificaciones enviadas al consumidor pueden indicar que la solicitud ha sido aceptada y que se procesará en breve. El hilo asincrono de parte del servidor se inicia para en realidad procesar la solicitud de pago. En una aplicación, el hilo asincrono se ejecuta después de que las notificaciones se envían al usuario. Esto proporciona al usuario una respuesta más rápida con respecto a la transacción. Es posible que la parte asincrona del procesamiento de pago pueda fallar. Por ejemplo, esto puede ser por fondos insuficientes debido al uso simultáneo de la tarjeta. En caso de una falla del procesamiento de pago asincrono, el usuario es notificado.
En una aplicación, existen dos tipos de cuentas comunes, una (i) cuenta común de usuario sin registrar y una (ii) cuenta común sin tarjeta. Los fondos de todos los usuarios sin registrar se conservarán juntos en la cuenta común de usuario sin registrar. Si el usuario A es un usuario sin tarjeta que aún no tiene una cuenta individual, A tendrá dinero guardado, en cambio, en la cuenta común sin tarjeta. En otra aplicación de la invención, puede existir una sola cuenta común tanto para la cuenta común de usuario sin registrar como para la cuenta común sin tarjeta. En otra modalidad de la invención, se cobra y se abona a las cuentas de A y B en la cuenta común y las transacciones en el socio bancario (socio que maneja la tarjeta de débito) ocurren al final del día (u otra hora específica) colectivamente por grupos con otras transacciones del sistema. En otra aplicación de la invención, puede existir un solo tipo de cuenta común en el que residan tanto usuarios sin registrar como usuarios sin tarjeta. Para transferencias de dinero entre tales usuarios, el dinero permanecerá en la misma cuenta común. En aún otra aplicación de la invención puede existir más de dos tipos de cuentas comunes. En la etapa 9, después de que B se registra, B se vuelve un usuario sin tarjeta. Como usuario sin tarjeta, B puede enviar y recibir dinero como un usuario registrado. Sin embargo, puesto que B aún no ha recibido su tarjeta, B no puede gastar el dinero a través de la tarjeta. En una aplicación, la cuenta individual del usuario B se crea en un plazo de 24 horas después del registro exitoso del usuario B. Sin embargo, la cuenta no tendrá dinero hasta que ésta se active en la etapa 11 en lo siguiente. En otra modalidad de la invención no se utiliza una cuenta común sin tarjeta y el dinero se transfiere directamente de la cuenta del usuario A a la cuenta del usuario B. En la etapa 10, típicamente toma aproximadamente de 7 a 10 días hábiles generar una nueva tarjeta y que el usuario B la reciba en el correo. En otra modalidad de la invención el usuario B puede recibir otro tipo de tarjeta, tal como una tarjeta de crédito o puede elegir no recibir ninguna tarjeta. En la etapa 11, después de la activación de la tarjeta del usuario B, el usuario B se vuelve un usuario registrado con tarjeta y ya no es un usuario sin tarjeta. En una modalidad en la que no se utiliza ninguna cuenta común sin tarjeta, no habrá necesidad de transferir el saldo después de la activación de la tarjeta. El Flujo C en lo siguiente muestra otra aplicación para realizar una transacción entre un miembro usuario registrado (usuario A) y un usuario no registrado (usuario B) .
Flujo C Etapa Acción El usuario A existente decide enviar algún dinero al usuario B, un usuario sin registrar. A envía un mensaje al sistema de pago móvil con el número del teléfono móvil de B y la cantidad de la transacción.
El sistema de pago móvil verifica si la cuenta de A tiene fondos suficientes para cubrir la transacción.
Si no existen fondos suficientes, se le envía un mensaje a A: "Fondos insuficientes. [tel#] , [valor] , [trans#] " B no recibe ningún mensaje Si existen fondos suficientes, proceder a la siguiente etapa. Verificar si B es un usuario registrado o no registrado. Si el número del teléfono móvil de B no se reconoce como un usuario registrado, A recibe el siguiente mensaje: "Su solicitud ha sido aceptada y será procesada. [tel#] , [valor] , [trans#] Usuario no registrado pendiente de solicitud" . 5 B recibe el siguiente mensaje: "Pago pendiente de [tel#] , [valor] , [trans#] Ir a la página web del sistema para registrarse" . 6 Antes de que B apruebe el pago, A puede cancelar el pago. Si es así, A y B recibirán el mensaje: "Pago cancelado" [tel#] , [valor] , [trans#] " Si pasan más de 30 días después de que A inicia la transacción y antes de que B apruebe el pago, la transacción se cancela automáticamente. Después A y B recibirán el mensaje: "Pago cancelado. [tel#] , [valor] , [trans#] " 7 B se registra en el sistema. Se crea una cuenta para B en el sistema. 8 Después de que B se registra con éxito, se le notifica a B que A desea enviarle dinero a B. B se presenta con una pantalla preguntando si B acepta el pago de A.
Etapa Acción 9 Si B rechaza el pago, la transacción se cancela y A recibe un mensaje: "Pago rechazado. [tel#] , [valor] , [trans#] " 10 Si B acepta el pago de A, el sistema verifica si A tiene fondos suficientes para cubrir la transacción. Si no, A y B recibirán el mensaje: "fondos insuficientes. [tel#] , [valor] , [trans#] " 11 Si A tiene fondos suficientes, A recibe el mensaje: "Pago aceptado. [tel#] , [valor] , [trans#] " 12 La cantidad de la transacción se cobra de la cuenta de A y se abona a la cuenta de B. La aplicación en el flujo C es similar al flujo A anterior. Sin embargo, a diferencia del flujo A, el flujo C no coloca una retención en la cantidad de la transacción en la cuenta de A (etapa 5 del flujo A) . La discusión anterior para los flujos A y B se aplica al flujo C según convenga. En una aplicación, aunque el pago de A está pendiente, A puede cancelar el pago y B será notificado en forma apropiada. En la etapa 8, en el caso en el que existen múltiples pagos pendientes, B puede presentarse con una lista de pagos pendientes y solicitarle que indique la aceptación o rechazo de cada pago pendiente. Si el hilo asincrono por parte del servidor (por ejemplo, etapa 12) fallara, ambas partes serán notificadas. El Flujo D en lo siguiente muestra una aplicación para realizar una transacción entre un usuario sin tarjeta (usuario A) y un usuario sin tarjeta (usuario B) .
Flujo D Etapa Acción 10 Si pasan más de 30 días después de que A inicia la transacción y B aún no ha aprobado, la transacción se cancela automáticamente. Después A y B recibirán el mensaj e : "Pago cancelado. [tel#] , [valor], [trans#] " Si B rechaza el pago, la transacción se cancela y se le envía un mensaje a A: "Pago rechazado. [tel#] , [valor] , [trans#] " 11 Si B acepta la transacción y A y B aún son usuarios sin tarjeta, el dinero se transfiere de A a B en la cuenta común sin tarjeta. Si B acepta la transacción, y A es un usuario sin tarjeta y B es ahora un usuario con tarjeta, el dinero se transfiere de A en la cuenta común sin tarjeta a la cuenta individual de B. Si tanto A como B se han vuelto usuarios con tarjeta, el dinero se transfiere de la cuenta individual de A a la cuenta individual de B. Si A se ha vuelto un usuario con tarjeta, pero b es aún un usuario sin tarjeta, el dinero se transfiere de la cuenta individual de A a B en la cuenta común sin tarjeta.
Los comentarios proporcionados en lo anterior aplican al flujo D según convenga. Por ejemplo, en la etapa 3 , no se coloca ninguna retención en la cuenta de A para la cantidad de la transacción. La cantidad de la transacción no se cobra de la cuenta de A. Hasta que la cantidad de la transacción se cobre con éxito de la cuenta de A en una etapa siguiente, el dinero se encuentra disponible para que A lo gaste mediante el pago móvil o pago con tarjeta de débito.
El usuario B puede crear una lista blanca o lista negra. La lista blanca puede dictar que B aceptará los pagos sólo de usuarios específicos (los cuales pueden almacenarse en el perfil del usuario) . La lista negra puede dictar que B no aceptará los pagos de miembros específicos (los cuales pueden almacenarse en el perfil del usuario) . Diversas aplicaciones de la invención pueden tener sólo una lista blanca, sólo una lista negra o tanto una lista blanca como una negra. Los remitentes no autorizados, debido a la lista blanca o negra, serán notificados del error después de que falle su pago intentado. El Flujo E en lo siguiente muestra una aplicación para realizar una transacción entre un usuario registrado sin tarjeta (usuario A) y un usuario con tarjeta (usuario B) . Flujo E Etapa Acción 1 El usuario A existente, un usuario registrado sin tarjeta, decide enviar algún dinero al usuario B, un usuario con tarjeta. A envía un mensaje al sistema de pago móvil con el número del teléfono móvil de B y la cantidad de la transacción. 2 El sistema de pago móvil verifica si la cuenta de A tiene fondos suficientes para cubrir la transacción. 3 Si no existen fondos suficientes, se le envía un mensaje a A: "fondos insuficientes. [tel#] , [valor] , [trans#] " B no recibe ningún mensaje Si existen fondos suficientes, proceder a la siguiente etapa.
Etapa Acción 4 Verificar si B es un usuario registrado (sin tarjeta o con tarjeta) o un usuario no registrado. Puesto que B es un usuario registrado, enviar el siguiente mensaj e : "¡Ha recibido el dinero! [tel#] , [valor] , [trans#] " 5 Verificar si B es un usuario registrado sin tarjeta o un usuario registrado con tarjeta. Puesto que B es un usuario con tarjeta, iniciar transacción de débito de dinero de A en una cuenta común de usuario sin tarjeta y abonar a una cuenta individual de B. 6 Si las transacciones de débito y de crédito fallan, A y B reciben el mensaje: "Pago fallido. [tel#] , [valor] , [trans#] " 7 Si B tiene aceptación automática activada, el dinero se transfiere de A en la cuenta común sin tarjeta a la cuenta individual de B. No se envía ningún mensaj e . 8 Si B tiene aceptación automática desactivada, las transacciones de débito y de crédito ocurrirán sólo después de que B aprueba la transacción. 9 Si pasan más de 30 días después de que A inicia la transacción y B aún no ha aprobado, la transacción se cancela automáticamente. Después A y B recibirán el mensaje: "Pago cancelado. [tel#] , [valor] , [trans#] " Si B rechaza el pago, la transacción se cancela y se le envía un mensaje a A: "Pago rechazado. [tel#] , [valor] , [trans#] " 10 Si B acepta la transacción y A es aún un usuario sin tarjeta, el dinero se transfiere de A en la cuenta común sin tarjeta a la cuenta individual de B. Si B acepta la transacción y A es ahora un usuario con tarjeta, el dinero se transfiere de la cuenta individual de A a la cuenta individual de B.
Los comentarios proporcionados en lo anterior aplican al flujo E según convenga.
El Flujo F en lo siguiente muestra una aplicación para realizar una transacción entre un usuario con tarjeta (usuario A) y un usuario sin tarjeta (usuario B) . Flujo F Etapa Acción 1 El usuario A existente, un usuario registrado con tarjeta, decide enviar algún dinero al usuario B, un usuario sin tarjeta. A envía un mensaje al sistema de pago móvil con el número del teléfono móvil de B y la cantidad de la transacción. 2 El sistema de pago móvil verifica si la cuenta de A tiene fondos suficientes para cubrir la transacción. 3 Si no existen fondos suficientes, se le envía un mensaje a A: "Fondos insuficientes. [tel#] , [valor] , [transí] " B no recibe ningún mensaje Si existen fondos suficientes, proceder a la siguiente etapa. 4 Verificar si B es un usuario registrado (sin tarjeta o con tarjeta) o un usuario no registrado. Si B es un usuario registrado, enviar el siguiente mensaje: "¡Ha recibido el dinero! [tel#] , [valor] , [trans#] " 5 Verificar si B es un usuario registrado sin tarjeta o un usuario registrado con tarjeta. Si B es un usuario sin tarjeta, iniciar transacción de débito de dinero de la cuenta individual de A y abonar a B en una cuenta común de usuario sin tarjeta. 6 Si las transacciones de débito y de crédito fallan, A y B reciben el mensaje: "Pago fallido. [tel#] , [valor] , [trans#] " 7 Si B tiene aceptación automática activada, el dinero se transfiere de la cuenta de A a la cuenta común sin tarjeta para B. No se envía ningún mensaje. 8 Si B tiene aceptación automática desactivada, las transacciones de débito y de crédito ocurrirán sólo después de que B aprueba la transacción. 9 Si pasan más de 30 días después de que A inicia la transacción y B no lo ha aprobado aún, la transacción se cancela automáticamente. Después A y B recibirán el mensaje: "Pago cancelado. [tel#] , [valor] , [trans#] " Si B rechaza el pago, la transacción se cancela y se le envía un mensaje a A: "Pago rechazado. [tel#] , [valor] , [trans#] " 10 Si B acepta la transacción y B es aún un usuario sin tarjeta, el dinero se transfiere de la cuenta de A a la cuenta común sin tarjeta para B. Si B acepta la transacción y B es ahora un usuario registrado con tarjeta, el dinero se transfiere de la cuenta de A a la cuenta individual de B. Los comentarios proporcionados en lo anterior aplican al flujo F según convenga. El Flujo G en lo siguiente muestra una aplicación para realizar una transacción entre un usuario con tarjeta (usuario A) y un usuario con tarjeta (usuario B) . FLUJO G Etapa Acción 1 El usuario A existente, un usuario registrado con tarjeta, decide enviar algún dinero al usuario B, un usuario registrado con tarjeta. A envía un mensaje al sistema de pago móvil con el número del teléfono móvil de B y la cantidad de la transacción. 2 El sistema de pago móvil verifica si la cuenta de A tiene fondos suficientes para cubrir la transacción. 3 Si no existen fondos suficientes, se le envía un mensaje a A: "Fondos insuficientes. [tel#] , [valor] , [trans#] " Etapa Acción B no recibe ningún mensaje Si existen fondos suficientes, proceder a la siguiente etapa. 4 Verificar si B es un usuario registrado (sin tarjeta o con tarjeta) o un usuario no registrado. Puesto que B es un usuario registrado, enviar el siguiente mensaj e : "¡Ha recibido el dinero! [tel#] , [valor] , [trans#] " 5 Verificar si B es un usuario registrado sin tarjeta o un usuario registrado con tarjeta. Puesto que B es un usuario con tarjeta, iniciar transacción de débito de dinero de la cuenta individual de A y abonar a la cuenta individual de B. 6 Si las transacciones de débito y de crédito fallan, A y B reciben el mensaje: "Pago fallido. [tel#] , [valor] , [trans#] " 7 Si B tiene aceptación automática activada, el dinero se transfiere en forma automática de la cuenta de A a la cuenta común sin tarjeta para B. No se envía ningún mensaje. 8 Si B tiene aceptación automática desactivado, las transacciones de débito y de crédito ocurrirán sólo después de que B aprueba la transacción. 9 Si pasan más de 30 días después de que A inicia la transacción y B no lo ha aprobado aún, la transacción se cancela automáticamente. Después A y B recibirán el mensaje: "Pago cancelado. [tel#] , [valor] , [trans#] " Si B rechaza el pago, la transacción se cancela y se le envía un mensaje a A: "Pago rechazado. [tel#] , [valor] , [trans#] " 10 Si B acepta la transacción, el dinero se transfiere de la cuenta individual de A a la cuenta individual de B. Los comentarios proporcionados en lo anterior aplican al flujo G según convenga.
El Flujo H muestra un flujo de remisión para usuarios sin registrar. El usuario A es un usuario registrado y el usuario B es un usuario sin registrar. Etapa Acción 1 El usuario A existente decide enviar algún dinero al usuario B, un usuario sin registrar. A envía un mensaje al sistema de pago móvil con el número del teléfono móvil de B y la cantidad de la transacción. 2 El sistema de pago móvil verifica si la cuenta de A tiene fondos suficientes para cubrir la transacción. 3 Si no existen fondos suficientes, se le envía un mensaje a A: "Fondos insuficientes. [tel#] , [valor] , [trans#] " B no recibe ningún mensaje Si existen fondos suficientes, proceder a la siguiente etapa. 4 Verificar si B es un usuario registrado o un usuario no registrado. Si el número del teléfono móvil de B no se reconoce como un usuario registrado, A recibe el siguiente mensaje: "B no es un miembro. Hemos invitado a B a unirse al sistema . [tel#] , [valor] , [trans#] " No se deduce dinero de la cuenta de A. 5 B recibe el siguiente mensaje: "A trató de enviarle dinero. [tel#] , [valor] , [trans#] Ir al sitio web del sistema para registrarse" . 6 B se registra en el sistema y se vuelve un usuario sin tarjeta, registrado. 7 A también recibe el siguiente mensaje: "B es ahora un usuario registrado, ¿le gustaría enviar su transacción nuevamente? 8 A recibe un bono de recomendación (por ejemplo, $5) en su cuenta. 9 A reenvía un mensaje al sistema de pago móvil con el número del teléfono móvil de B y la cantidad de la transacción. Si es sí, la transacción se manejará como un usuario registrado para la transacción del usuario registrado.
Los comentarios proporcionados en lo anterior aplican al flujo H según convenga. En este flujo, los fondos no se transfieren en forma automática de A a B después de que B se registra. En cambio, se invita a B a unirse y después de que B se une, se le envía un mensaje a A (etapa 9) preguntando si A desea tratar de enviar dinero a B nuevamente. Si a desea enviar el dinero, entonces el posterior A-a-B se manejará como cualquiera de la transferencia de usuario registrado a usuario registrado. La aplicación puede incluir un bono de recomendación (por ejemplo, $5) . El mensaje en la etapa 4 puede incluir un aviso para A de que A recibirá un bono de recomendación después de la unión de B. Después de que B se registra en la etapa 6, el usuario a tendrá derecho al bono de recomendación que se depositará en la cuenta de A (véase etapa 8) . La etapa 8 viene después de la etapa 6, pero puede estar antes o después de las etapas 7 y 9. En diversas aplicaciones del sistema, los bonos de recomendación pueden pagarse sólo al remitente, sólo al destinatario o tanto al remitente como al destinatario. Además, en una modalidad alternativa de un flujo de remisión, después de que B se registra, el dinero puede transferirse en forma automática a B sin que A tenga que reenviar una transacción de solicitud de pago. En otra modalidad, el flujo es: (1) El usuario A (Miembro) envía al usuario B (no miembro) $X. (2) El sistema verifica a B, descubre que B no es un miembro. (3) $X se le designa un pendiente en la cuenta de A. (4) Se le notifica a B que B invita a A unirse al sistema. Un incentivo de $Y + dinero enviado por A esperan a ser cobrados. (5) B elige inscribirse como un miembro y recibe el incentivo de $Y en forma inmediata (ya en la cuenta) . (6) B recibe entonces un mensaje que indica que se recibió un pago de $X de A. (7) $X se deduce de la cuenta de A. (8) El Viral pendiente puede cancelarse por A; sin embargo, la invitación puede aún procesarse. (9) Si B no acepta la invitación en cierto periodo. La cantidad pendiente se libera nuevamente en la cuenta. En una modalidad adicional de la invención, el sistema de intercambio financiero puede notificar a los usuarios a través de múltiples notificaciones por transacción, tal como con SMS y con correo electrónico en casos específicos. Ejemplos de tales casos incluyen: con el registro de un nuevo usuario, con el registro de la tarjeta del sistema, con el envío o recepción de una remisión, con la carga de crédito/débito, con la carga o descarga por ACH/Depósito Directo, con la carga de pago electrónico (por ejemplo, pago de cuenta) y con el cambio de cuenta o datos de perfil . En un sistema de pago móvil los usuarios o miembros registrados pueden enviar el pago a otro miembro o usuarios no registrados o no miembros. En una aplicación específica, un sistema de pagos de persona a persona permite que los miembros existentes de un sistema de pagos envíen fondos a no miembros con el objetivo de que el no miembro se vuelva un miembro. Esta capacidad de un sistema de pagos puede ser referida como "viral" debido a que promueve nuevos registros de miembros en una forma de propagación exponencial. En una modalidad, la invención es un método que incluye: Recibir una instrucción de pago de un primer usuario para pagar a un segundo usuario una cantidad de dinero, donde el primer usuario es un usuario registrado y el segundo usuario se identifica mediante un número telefónico para el segundo usuario; con base en el número telefónico, determinar que el segundo usuario no es un usuario registrado; y enviar un primer mensaje electrónico a un dispositivo asociado con el número telefónico que notifica al segundo usuario acerca del pago pendiente del primer usuario. El método incluye: después de enviar el primer mensaje electrónico, registrar al segundo usuario y presentar al segundo usuario una primera opción para aceptar el pago pendiente del primer usuario y una segunda opción para rechazar el pago pendiente del primer usuario; cuando el segundo usuario selecciona la primera opción, cobrar la cantidad de dinero de una primera cuenta asociada con el primer usuario y abonar la cantidad de dinero a una segunda cuenta asociad con el segundo usuario; y cuando el segundo usuario selecciona la segunda opción, enviar un segundo mensaje electrónico al primer usuario de que el pago fue rechazado . En una aplicación, la segunda cuenta se encuentra en una cuenta común y cuando el primer usuario es un usuario registrado sin tarjeta, la primera cuenta se encuentra en la cuenta común y el cobro y abono incluye mantener la cantidad de dinero en la cuenta común. En una aplicación, la segunda cuenta se encuentra en una cuenta común y cuando el primer usuario es un usuario registrado sin tarjeta, la primera cuenta se encuentra en la cuenta común y el cobro y abono incluye no transferir la cantidad de dinero fuera de la cuenta común. En una aplicación, cuando el primer usuario es un usuario registrado sin tarjeta, la primera cuenta se encuentra en una primera cuenta común y la segunda cuenta se encuentra en una segunda cuenta común diferente de la primera cuenta común, y el cobro y abono incluye transferir la cantidad de dinero de la primera cuenta común a la segunda cuenta común . En una aplicación, el primer usuario es un usuario registrado con tarjeta y la segunda cuenta se encuentra en una cuenta común y el cobro y abono incluye transferir la cantidad de dinero de la primera cuenta a la segunda cuenta común en la cuenta común, con lo cual se aumenta la cantidad de dinero de la cuenta común. La tarjeta asociada con una registrada puede ser una tarjeta de débito, tarjeta de crédito, tarjeta de cajero automático o cualquier otra tarjeta física que muestre un número de cuenta. Con el uso de tal tarjeta, el primer usuario puede llevar a cabo transacciones independientes del dispositivo electrónico desde el cual se envió la instrucción de pago. En una aplicación, el método incluye: recibir, además de la instrucción de pago, un número de secuencia generado por un dispositivo que envió la instrucción de pago; y después de recibir el número de secuencia, generar un número de transacción para la instrucción de pago. En una aplicación, el procesamiento de la instrucción de pago ocurre sólo si el número de secuencia no corresponde con ningún número de secuencia recibido con anterioridad y almacenado en una base de datos. La base de datos puede incluir números de secuencia recibidos para un periodo de tiempo de sucesivo, tal como la última semana, las últimas dos semanas, el último mes, los seis meses anteriores o cualquier otro periodo de tiempo . En una aplicación, después de recibir el número de secuencia, se genera un número de secuencia esperado. Después, la instrucción de pago se procesa sólo si el número de secuencia corresponde con el número de secuencia esperado. En una modalidad, la invención es un método que incluye: recibir una instrucción de pago de un primer usuario para pagar a un segundo usuario una cantidad de dinero, donde el primer usuario es un usuario registrado y el segundo usuario se identifica mediante un número telefónico para el segundo usuario; con base en el número telefónico, determinar que el segundo usuario no es un usuario registrado; y enviar un primer mensaje electrónico a un dispositivo asociado con el número telefónico que notifica al segundo usuario acerca del pago pendiente del primer usuario. El método incluye: después de enviar el primer mensaje electrónico, registrar al segundo usuario y presentar al segundo usuario una primera opción para aceptar el pago pendiente del primer usuario y una segunda opción para rechazar el pago pendiente del primer usuario y una tercera opción para solicitar un cambio al pago pendiente del primer usuario; cuando el segundo usuario selecciona la primera opción, cobrar la cantidad de dinero de una primera cuenta asociada con el primer usuario y abonar la cantidad de dinero a una segunda cuenta asociada con el segundo usuario,- cuando el segundo usuario selecciona la segunda opción, enviar un segundo mensaje electrónico al primer usuario de que el pago fue rechazado. En la aplicación, el método incluye, cuando el segundo usuario selecciona la tercera opción, enviar un tercer mensaje electrónico al primer usuario de que el segundo usuario ha solicitado un cambio en el pago pendiente. En una aplicación, el método incluye, cuando el segundo usuario selecciona la tercera opción, recibir una solicitud del segundo usuario para cambiar el pago pendiente para tener una cantidad de dinero diferente, enviar un tercer mensaje electrónico al primer usuario que notifica al primer usuario del cambio al pago pendiente, presentar al primer usuario una cuarta opción para aceptar el cambio al pago pendiente o una quinta opción para rechazar el cambio al pago pendiente y, cuando el primer usuario selecciona la cuarta opción, cobrar la cantidad de dinero diferente de una cuenta del primer usuario y abonar la cantidad de dinero diferente a una cuenta asociada con el segundo usuario. El método además puede incluir, después de determinar que el segundo usuario no es un usuario registrado, colocar una retención en la cantidad de dinero en la primera cuenta. El método puede incluir: después de determinar que el segundo usuario no es un usuario registrado, colocar una retención en la cantidad de dinero en la primera cuenta; y después de que transcurre un cierto número de días a partir del momento en que ser recibió la instrucción de pago y el segundo usuario no se haya registrado, eliminar la retención en la cantidad de dinero en la primera cuenta. El dispositivo puede ser por lo menos uno de un teléfono inteligente, dispositivo móvil, dispositivo de correo electrónico portátil, asistente digital personal o computadora . En una modalidad, la invención es un método que incluye: recibir una instrucción de pago de un primer usuario para pagar a un segundo usuario una cantidad de dinero, donde el primer usuario es un usuario registrado y el segundo usuario se identifica mediante un número telefónico para el segundo usuario; con base en el número telefónico, determinar que el segundo usuario no es un usuario registrado; y enviar un primer mensaje electrónico a un dispositivo asociado con el número telefónico que notifica al segundo usuario acerca de un pago intentado del primer usuario. El método incluye: después de enviar el primer mensaje electrónico, registrar al segundo usuario, enviar al primer usuario un segundo mensaje electrónico al primer usuario de que el segundo usuario se ha registrado, y presentar al primer usuario una primera opción para pagar al segundo usuario la cantidad de dinero; y cuando el primer usuario selecciona la primera opción, cobrar la cantidad de dinero de una primera cuenta asociado con el primer usuario y abonar la cantidad de dinero a una segunda cuenta asociada con el segundo usuario. En una aplicación, después de que el segundo usuario se registra, la primera cuenta se abona con una cantidad de un bono de recomendación. La cantidad del bono de recomendación puede ser cualquier cantidad de dinero, tal como $5. En una aplicación, después de que el segundo usuario se registra, la segunda cuenta se abona con una cantidad de un bono de recomendación. Además, tanto el primero como el segundo usuario pueden recibir bonos de recomendación. En una aplicación, el método incluye enviar un segundo mensaje electrónico al primer usuario de que el segundo usuario no es un usuario registrado. En una aplicación, el método incluye: recibir, además de la instrucción de pago, un número de secuencia generado por un dispositivo que envió la instrucción de pago; y después de recibir el número de secuencia, generar un número de transacción para la instrucción de pago. La Figura 19 muestra un diagrama general del sistema de una modalidad específica de la invención. Ésta es una vista esquemática de una aplicación específica de un sistema de pago móvil (es decir, Obopay) . Como se menciona en lo anterior, Obopay se proporciona únicamente como un ejemplo para ilustrar las características de la invención, y la invención no debe limitarse a este ejemplo. El sistema de Obopay tiene una red principal de tarjeta de débito. Un socio, Diamond Financial Products, es un socio. A través de Diamond, Obopay emite tarjetas de débito y se comunica con ECL y First Premiere Bank para proporcionar a los usuarios de Obopay la capacidad de enviar y recibir dinero entre tarjetas de débito. PBT (Pay By Touch) maneja transacciones de ACH y transacciones con tarjetas de crédito. Bancorp Bank proporciona cuentas de liquidación y tiene una relación con PBT. La Figura 20 muestra un pago de persona a persona entre dos cuentas con tarjetas individuales. "Tarjeta" se refiere a un miembro de Obopay que posee una tarjeta de débito de Diamond Financial Products . Éste es un "usuario de tarjeta" o "usuario con tarjeta" que está en contraste con un usuario sin tarjeta. Este flujo específico incluye: (1) Del teléfono del Ul, un pago de P2P de $5 al U2 se inicia. (2) Obopay envía la solicitud de P2P a Diamond (quien, a su vez, la envía a ECL y a First Premier) . (3) La cantidad de $5 se cobra de la cuenta de tarjeta de débito del Ul y se abona a la cuenta de tarjeta de débito del U2. (4) Una cuota de $0.10 se deduce de la cuenta del Ul y se abona a la cuenta bancaria de Diamond Financial Products en el First Premier Bank. La Figura 21 muestra un pago de persona a persona entre una cuenta de tarjeta y una cuenta de no miembro. Este flujo específico incluye: (1) Del teléfono del Ul, un pago de P2P de $5 a un no usuario VI se inicia. (2) Obopay envía la solicitud de P2P a Diamond (quien, a su vez, la envía a ECL y a First Premier) . (3) La cantidad de $5 se cobra de la cuenta de tarjeta de débito del Ul y se abona a la Cuenta de Mete-Saca de Obopay. (4) Una cuota de $0.10 se deduce de la cuenta del Ul y se abona a la cuenta bancaria de Diamond Financial Products en el First Premier Bank. (5) Un registro se ingresa en la tabla de la base de datos de la "INVITACIÓN" del Ul . Aquí es en donde el registro de la viral se almacena; la transacción puede invertirse hasta que el destinatario viral se inscribe para una cuenta de Obopay. La Figura 22 muestra un pago de persona a persona entre una cuenta con tarjeta y una cuenta sin tarjeta. Un usuario "sin tarjeta" es un usuario de Obopay que no ha recibido o activado aún su tarjeta de débito. En otra modalidad de la invención no se requiere la tarjeta de débito. En una modalidad específica, existe un estado entre el encargo de la tarjeta y la activación, donde el usuario aún puede enviar y recibir dinero. Este flujo específico incluye: (1) Desde el teléfono, el Ul inicia una transacción de P2P de $5 para un usuario 01 "sin tarjeta". (2) La cantidad de $5.00 se transfiere de la cuenta de tarjeta de débito del Ul a la Cuenta Bancaria de Mete-Saca de Obopay en First Premier. (3) Una cuota de $0.10 se transfiere (por Diamond) a una cuenta bancaria de Diamond Financial Products en el First Premier Bank. (4) Obopay registra el aumento de $5 en el saldo del 01 en el libro de contabilidad general de Obopay. La Figura 23 muestra un pago de persona a persona de sin tarjeta a sin tarjeta. Este flujo específico incluye: (1) Desde el teléfono, el 01 inicia una transacción de P2P de $10 para un usuario 02 "sin tarjeta". (2) Los $10 permanecen en la Cuenta de Mete-Saca de Obopay en First Premier. La cuota de $0.10 también permanece en la Cuenta de Mete-Saca. (3) Obopay registra el aumento en el saldo del 02 y la disminución en el saldo de 01 en el libro de contabilidad general de Obopay. La Figura 24 muestra una carga de tarjeta de crédito. Un flujo especifico incluye: (1) Desde la web, el Ul ingresa el Número de CC para cargar $300 en la Tarjeta de Obopay. (2) Obopay obtiene una autorización por $300 de Pay-By-Touch para la transacción con la tarjeta de crédito. (3) Obopay envía un mensaje a Diamond que inicia una P2P de $300 de la A/C de CC-Master de Obopay a la tarjeta de débito del Ul . Se le otorga un crédito inmediato al usuario con los fondos. (4) PBT establece una transacción de tarjeta de crédito y envía una ACH de $300 a la cuenta de liquidación de Obopay en el Bancorp Bank. (5) Obopay envía un ACH de $300 a la A/C de CC Master de Obopay para reponer los fondos. La Figura 25 muestra un diagrama general del sistema de otra modalidad específica de la invención. Los siguientes flujos 78 a 85 se relacionan con la aplicación del sistema en la figura 77. En esta aplicación del sistema, no se les requerirá a los usuarios que se registren para una cuenta de tarjeta de débito. Estos usuarios se designarán usuarios "sin tarjeta" y poseerán cuentas virtuales. Los fondos se mantendrán en una cuenta bancaria (para el beneficio de los usuarios de Obopay) . La Figura 26 muestra un pago de persona a persona entre una cuenta sin tarjeta y una cuenta sin tarjeta. Un flujo específico incluye: (1) Del teléfono del 01, un pago de P2P de $5 al 02 se inicia. (2) Debido a que tanto el 01 como el 02 son usuarios existentes, sus fondos se guardan en la Cuenta Común en el Bancorp Bank. Los $5 permanecen en la misma cuenta, menos una cuota de $0.10. (3) El Libro de Contabilidad General de Obopay refleja el cambio en el saldo. La cantidad de $5 se cobra de la cuenta de 01 y $5 se abonan a la cuenta de 02. (4) La cuota de $0.10 se transfiere de la cuenta común de cliente a la cuenta de capital circulante. La Figura 27 muestra un pago de persona a persona entre una cuenta sin tarjeta y una cuenta con tarjeta. Un flujo específico incluye: (1) Del teléfono del 01, un pago de P2P de $5 al U6 se inicia. (2) Se cobran $5.10 de la cuenta del usuario 01. Este cambio se refleja en el Libro de Contabilidad General de Obopay. (3) Obopay (a través de la comunicación con Diamond) inicia un P2P, transfiriendo $5 de la cuenta de Mete-Saca de First Premier a la tarjeta de débito de U6. (4) En un proceso por lotes nocturno, se transfieren $5.10 (existe una cuota de 10 centavos para el envío de dinero) de la Cuenta Común de Obopay a la Cuenta de Capital Circulante de Obopay en Bancorp. La Figura 28 muestra un pago de persona a persona entre una transacción viral con un no miembro. Un pago "viral" es uno en el que un miembro de Obopay, con tarjeta o sin tarjeta, envía un pago a un número telefónico de usuarios que no son de Obopay. Un flujo específico incluye: (1) Del teléfono del 01, un pago de P2P de $5 al VI se inicia. (2) El Libro de Contabilidad General de Obopay refleja el cambio en el saldo de 01. Se cobran $5.10 de la cuenta 01. (3) Los $5.10 permanecen en la Cuenta Común de Cliente. La cuota se transfiere después. (4) La transacción viral se registra en la tabla de "INVITACIÓN" de 01 en la base de datos de Obopay. Si el pago viral vence, los fondos se regresarán a 01. (5) La cuota de $0.10 se transfiere de la cuenta común de cliente a la cuenta de capital circulante. Esto puede realizarse en un proceso por lotes nocturno. La Figura 29 muestra una financiación de incentivos. La financiación de incentivos ocurre cuando a los nuevos usuarios de Obopay se les otorga un bono por inscripción de $5 o cualquier otra cantidad. Cuando el usuario se registra, estos $5 se reflejarán en el saldo. Asimismo, cualquier fondo enviado en forma viral al usuario se transferirá a su cuenta. Un pago viral pendiente ocurre cuando a un usuario que no es de Obopay se le envían en forma viral fondos que se mantienen en la Cuenta Común de Cliente. El pago se rastrea en la "Tabla de Invitación" de los remitentes, una sección de su propio perfil de datos. Los pagos virales sólo están "pendientes" , denotando que el remitente puede cancelar el pago. Un flujo específico incluye: (1) El VI (destinatario de fondos virales, no usuario) se registra en Obopay en Obopay.com. (2) Se crea una cuenta en la base de datos de Obopay. (3) El saldo de los usuarios en el GL de Obopay refleja ahora un bono de $5 y un pago viral de $10. (4) Los fondos enviados en forma viral a VI ($10 enviados al usuario antes del registro) permanecen en la Cuenta Común de Cliente. (5) El perfil de la base de datos para el remitente original de fondos virales se actualiza a "RFPAID" (remisión pagada) . (6) En un proceso por lotes nocturno, se transfieren $5 de la cuenta de c/c de Obopay a la Cuenta Común de Cliente . La Figura 30 muestra una carga de tarjeta de crédito. La carga de la tarjeta de crédito es el proceso de cargas de fondos en una cuenta de Obopay a través de una tarjeta de crédito. La cuenta de capital circulante de Obopay es una cuenta bancaria en Bancorp Bank (o cualquier otro socio bancario) . Esta cuenta contiene capital circulante de Obopay y se provee de fondos con el capital circulante de Obopay. Esta cuenta también se utiliza como cuenta de liquidación para NYCE, PBT y otras. Un flujo específico incluye: (1) El usuario 01 de Obopay acude a Obopay.com e inicia una carga de $300 de su tarjeta Visa a su cuenta en Obopay. (2) Obopay, mediante el uso de Pay-By-Touch como procesador, obtiene una autorización por $301.50 (incluyendo una cuota aproximada) para la transacción de tarjeta de crédito. (3) La cantidad de $300 se abona a la cuenta de 01 en el GL de Obopay. (4) Obopay transfiere $300 de la Cuenta de Capital Circulante a la Cuenta Común de Cliente. Esto puede ocurrir en un proceso por lotes nocturno. (5) Pay-By-Touch establece la transacción y después inicia un ACH de $301.50 a la Cuenta de Liquidación de Obopay en el Bancorp Bank. Esto puede ocurrir en un proceso por lotes al día siguiente. La Figura 31 muestra una carga de ACH. Un flujo específico incluye: (1) Desde el sitio web de Obopay, un usuario 01 sin tarjeta inicia una transacción de ACH de $100 a la cuenta de Obopay desde su DDA. (2) Obopay inicia un cargo de ACH contra la DDA de los usuarios. (3) Los fondos se transfieren de la DDA de los usuarios a la Cuenta de Capital Circulante de Obopay. (4) La cuenta de los Usuarios se abona con $100 en el GL de Obopay. (5) Obopay transfiere $100 de la Cuenta de Capital Circulante de Obopay a la Cuenta Común de Cliente. Esto puede realizarse en una operación de proceso por lotes nocturno. La Figura 32 muestra una descarga de ACH. Un flujo específico incluye: (1) Desde el sitio web de Obopay, un usuario 01 sin tarjeta inicia una transacción de ACH de $100 a su DDA. (2) El "saldo disponible" del usuario 01 se reduce en $100 en el Libro de Contabilidad General de Obopay. (3) A través de Pay-by-Touch, se transfiere un crédito de ACH en la DDA de 01. (4) El ACH se transfiere y los $100 se retiran de la cuenta de Capital Circulante de Obopay. (5) El "saldo actual" de los usuarios se reduce en $100 para corresponder con el saldo disponible. (6) Los $100 se transfieren de la Cuenta Común de Cliente de Obopay a la Cuenta de Capital Circulante de Obopay. La Figura 33 muestra una carga de ATM. La carga puede ser a través de cualquier institución de ATM tal como NYCE, PLUS, STAR y otras. En una modalidad específica, la carga de ATM es una carga de NYCE. Un flujo específico incluye: (1) Desde el sitio web de Obopay, un usuario 01 sin tarjeta inicia una Carga de NYCE de $100 desde su DDA. .(Existe una cuota de $0.99 para la carga de dinero) . (2) Obopay envía y recibe una Autorización por $100.99 de NYCE. (3) La cuenta de 01 en el GL de Obopay se abona con $100. (4) En un proceso por lotes nocturno, se transfieren $100 de la cuenta de capital circulante de Obopay a la Cuenta Común de Cliente. (5) NYCE transfiere un crédito de ACH de $100.99 a la Cuenta de Capital Circulante de Obopay. Los sistemas de pago actuales (es decir, tarjetas de crédito y de débito) tienen costos tanto para los consumidores como para los comercios. Se les puede cobrar a los consumidores cuotas anuales por suscripción. A los comercios se les cobra demasiado con cuotas por intercambio. Lo que se necesita es un sistema de pago disponible para los consumidores y comercios que no tenga cuotas por inscripción, ninguna cuota por suscripción y ninguna cuota por transacción, ya sea para el consumidor o para el comercio. Sin embargo, al mismo tiempo, el "procesador" que ejecuta un sistema debe compensarse en consecuencia. Esquema de Pago de Bucle Cerrado En una modalidad, la invención proporciona un método para operar la infraestructura de transferencia de pagos como un sistema de pago de bucle cerrado. Un sistema de transacciones financieras de bucle cerrado facilita los pagos sin los cargos de pago sustanciales asociados con los sistemas financieros de bucle cerrado y que tenga un alto nivel de seguridad para el titular, el comercio y otros implicados en las transacciones financieras. Un sistema de pago de bucle cerrado ocurre en el caso en el que los componentes del procese de transferencia de valor tiene lugar bajo el control de la entidad que es propietaria del sistema de pago. Debido a que el titular controla el sistema, la fijación de precios subyacente también se encuentra bajo el control del propietario. En cambio, el dinero en efectivo y los cheques son sistemas de pago abiertos en los que cada participante establece su precio por manejar su pieza de la transacción sin un pago a un operador de red. La Figura 35 muestra el flujo de transacción en un sistema de pago de bucle cerrado. En especial, cuando se realiza un pago de un dispositivo 3501 móvil a otro dispositivo 3502 móvil, la solicitud para la transferencia se pasa al servidor 3503 de pagos. La solicitud se indica mediante la flecha 3504 de referencia. El servidor 3503 accede al libro mayor T para el titular de una cuenta asociado con el dispositivo 3501 móvil (como se indica mediante la flecha 3505 de referencia) y transfiere la cantidad especificada a un libro mayor T de beneficiario (como se indica mediante la flecha 3507 de referencia) si se cumplen ciertas normas de velocidad como se indica en 3506. Una vez que se han transferido los fondos al beneficiario, como se indica mediante 3508, el servidor 3503 envía un mensaje de notificación al beneficiario como se indica en 3509. Finalmente, el titular de una cuenta de pagador recibe un mensaje de confirmación del servidor 3503 de que la transacción se ha completado. De preferencia, una sola entidad es propietaria de todo el sistema de bucle cerrado. El sistema se llena o carga por titulares de una cuenta que comercian dólares para un saldo de cuenta mantenido en el servidor de pagos (véase figura 3) . Existen varias ventajas para un sistema de pago de bucle cerrado. La ventaja principal es que el propietario del sistema puede controlar la fijación de precios tanto para el remitente como para el receptor y existe una oportunidad de ganancias de ganancias de interés en los fondos cargados en el sistema. El propietario del sistema de pago puede ganar intereses en todos los fondos en el sistema hasta que éstos se conviertan o descarguen nuevamente en dólares . A medida que se agregan más funciones, el sistema de bucle cerrado se vuelve más rentable debido a un aumento en las cuotas y en los saldos. Las propuestas de valor para el titular de una cuenta participante incluyen: (1) Protección - el dinero del titular de una cuenta se encuentra guardado en forma segura en el dispositivo móvil en lugar de tener que llevar consigo dinero en efectivo en un bolsillo o bolso; (2) Seguridad - verificación oportuna para ver cuánto dinero se encuentra disponible en la cuenta; (3) Información - fácil de obtener información de saldo y de actividad de la cuenta; (4) Conveniente - el titular de una cuenta puede transferir el dinero en segundos en todo el mundo o a través de un sitio. Las propuestas de valor para los comercios incluyen: (1) Protección - nada de dinero en efectivo; (2) Menos costos por manejo - sin recibos de dinero en efectivo de cuentas, sin recibos de depósito, sin cintas para sumadoras ; (3) Menos costos por transacción - cuotas más bajas que las tarjetas de crédito; y (4) fondos garantizados - sin cheques devueltos. Los socios del comercio tienen una oportunidad única para ganar ingresos pare el manejo de transacciones llevadas a cabo para depositar fondos en una cuenta de débito prepagada o para proporcionar dinero en efectivo al titular de una cuenta. Los comercios pueden ganar comisiones cuando los fondos se agregan a una cuenta. El sistema de pago de bucle cerrado independiente de la presente invención está diseñado para integrarse con una cuenta bancaria para acompañante. Esta cuenta puede ser una cuenta preexistente o, para usuarios sin una cuenta en banco, las cuentas pueden crearse o mantenerse en una cuenta común con el banco corresponsal. El sistema de bucle cerrado mantiene una base de datos del perfil de usuario que incluye el nombre del titular de una cuenta y datos demográficos, información utilizada para asegurar el riesgo para cada titular de una cuenta específico e información de cuenta bancaria asociada para cuentas que se utilizarán para cargar o descargar fondos de la cuenta. La base de datos del perfil de usuario también requiere un sitio web orientado al servicio al cliente y orientado al consumidor para la recopilación de datos de inscripción cuando se abran las cuentas . El servidor de pagos mantiene un registro de cuentas T para cada titular de una cuenta. Esta cuenta es un libro mayor que mantiene el rastreo de las transacciones y saldos de cada titular de una cuenta. Junto con la base de datos de la cuenta T, el servidor de pagos proporciona datos de saldo e historial a través del dispositivo móvil, así como un sitio web orientado al servicio al cliente y consumidor. Para obtener dinero dentro y fuera del sistema de pago de bucle cerrado, la presente invención proporciona tres tipos de funciones para diferentes titulares de una cuenta. Algunos titulares de una cuenta ya tendrán una cuenta bancaria con un banco que no sea un socio. El sistema permite que los titulares transfieran los fondos a y desde esta cuenta bancaria a través del sistema de ACH o a través de una integración directa con la DDA del titular de una cuenta o a través de una integración a través de la red de ATM. Debido al riesgo implicado, el usuario se someterá a controles de riesgo que pueden incluir la disponibilidad diferida de fondos transferidos (por ejemplo, una transferencia de su cuenta bancaria en lunes puede no utilizarse hasta el jueves) . Este tiempo de atraso puede reducirse con aseguramiento adicional (ejecutar reportes de crédito u obtener declaraciones financieras) . Una reducción en el tiempo de atraso también puede ocurrir debido a que el usuario tiene un buen historial crediticio con una empresa aseguradora asociada o pagos de garantía con una tarjeta de crédito que se tiene en reserva. En general, este procedimiento no es una primera opción debido al riesgo implicado a menos que exista una empresa aseguradora implicada que puede enviar algunos datos de aseguramiento y suficientes clientes para justificar el aseguramiento adicional . En el caso en el que el titular de una cuenta inscrito como resultado de una relación con un socio bancario, una conexión en tiempo real con el sistema de Cuenta Corriente (cuenta bancaria de cheques) permite que el titular de una cuenta obtenga saldos y realice transacciones a su cuenta en tiempo real. En otros casos, el titular de una cuenta mantiene una cuenta con un banco (por ejemplo, Bancorp Bank o First Premier Bank) que opera el banco, pero sitios web, cheques y declaraciones del cliente implicarán la creación de una marca de afinidad. Este procedimiento permitirá proporcionar la creación de una marca de afinidad con una cuenta bancaria de acompañante (la cuenta será gratis para el usuario) en un ambiente estrechamente integrado.
La presente invención se refiere a un servicio de transacción financiera de bucle cerrado que tiene cuotas bajas o ninguna cuota de transacción y seguridad mejorada. Una modalidad de la presente invención abarca un método para la transferencia fácil y rápida de pagos entre cualquier colega o entre un consumidor y un comercio. Una aplicación del método incluye un dispositivo móvil, telefonía celular (teléfono celular) o dispositivo similar como el mecanismo para acceder a una cuenta tal como una cuenta de débito preconsolidada y autorizar la transferencia de fondos de esa cuenta a otra parte. Modalidades adicionales de la presente invención abarcan una diversidad de socios que incluyen operadores de teléfonos móviles, comercios de marca nacional y proveedores de servicios financieros junto con una plataforma de pagos que proporciona una forma fácil y rápida de que las personas realicen pagos mediante el uso de sus dispositivos celulares u otro dispositivo de comunicación. Con referencia ahora a la figura 36, la cual muestra un sistema de transacción financiera de bucle cerrado de acuerdo con una modalidad de la presente invención. En este sistema de transacción, los consumidores y comercios, un grupo de dos o más consumidores o un grupo de dos o más comercios pueden completar fácilmente transacciones financieras en forma rápida y segura con un costo bajo o ningún costo por transacción.
El sistema de transacción financiera de bucle cerrado utiliza una cuenta de débito preconsolidada y por esta razón puede comprender una terminal 3612 de punto de venta (POS) en la que las tarjetas 3606 de débito tradicionales pueden utilizarse como en el sistema de la técnica anterior - al deslizar la tarjeta en el lector 3613 magnético asociado con la terminal 3612 de POS. La tarjeta 3606 proporciona una segunda vista en las cuentas del titular de una cuenta. En algunas modalidades, la terminal 3612 de POS además incluye una antena y circuitería 3614 de campo cercano (NF) . La antena y circuitería 3614 de NF detectan dispositivos pasivos tales como un teléfono celular activado por NF, un teléfono celular activado por Bluetooth u otro dispositivo de transmisión de corto alcance, tal como de RFID o de códigos de barras, asociados con el teléfono 3618 celular. De este modo, cuando el teléfono 3618 celular se encuentra cerca de la terminal de POS, la información de cuenta es automáticamente para la terminal de POS . En aún otras modalidades, la terminal 3612 de POS incluye una conexión de teléfono celular que establece una conexión con el procesador 3630 de transacciones, el cual también es referido de diferentes modos como servidor de pago ó servidor, con el inicio de una transacción. Se entenderá que el procesador 3630 de transacciones incluye una o más torres de servidores o centros de datos capaces de manejar grandes volúmenes de transacciones simultáneas. Como se entiende bien en la técnica, tales torres de servidores típicamente se encuentran distribuidos en forma geográfica y enlazados con la tecnología adecuada para mantener una vista exacta del estado en tiempo real de todas las cuentas . La terminal de POS transfiere la cantidad de la transacción directamente de la terminal de POS al servidor de pagos para su autorización mediante una conexión 3615 de teléfono celular. El servidor 3630 de pagos llama al teléfono 3619 celular del titular de una cuenta para confirmar los detalles de la transacción. Alguien con experiencia en la técnica apreciará que la terminal de POS puede incluir sólo uno o dos del lector 3613 magnético, la antena y circuito 3614 de NF y teléfono 3615 celular. También se apreciara que la terminal 3612 de POS usualmente está asociada con un comercio. Una ventaja considerable de una modalidad de la presente invención es que tanto el teléfono 3618 ó 3619 celular como la tarjeta 3606 comparten un PIN común. De este modo, no se molesta al titular de una cuenta al tener que recordar múltiples PIN. Además de las transacciones de consumidor a comercio, la presente invención es lo suficiente flexible para incorporar verdaderas capacidades de transacción financiera de persona a persona. Los dispositivos 3620 de persona a persona comprenden, cada uno, un teléfono celular que está asociado a una cuenta y al titular de una cuenta. Cuando uno de los colegas 3620 desea iniciar una solicitud de transacción, tal como enviar un pago a otro colega, la solicitud, autorización y confirmación de la transacción se envían, todas, entre el servidor 3630 de pago y los colegas 3620 a través de una red pública. De manera favorable, puesto que se utilizan una o más redes públicas, no existe ninguna cuota de intercambio, por lo que el costo para los participantes puede ser gratis o demasiado barato para comprender un porcentaje mínimo de las transacciones generales llevadas a cabo en el sistema, especialmente en comparación con la cuota típica por intercambio. Como se observa en lo anterior, las solicitudes de transacción se enrutan a un servidor 3630 de pagos a través de una red pública. En una modalidad, la red 3625 pública es la Internet. En otra modalidad, la red 3625 pública es la red telefónica celular. En aún otra modalidad, la red 3625 pública es una red de radio y, en aún otra modalidad, es la red telefónica conmutada pública o PSTN. La red 3625 pública transfiere las solicitudes de transacción del titular de una cuenta al servidor 3630 de pagos. En una aplicación, la conexión a través de la red 3625 pública es un enlace seguro que se basa en participantes autenticados y una codificación. De este modo, para conexiones a través de la Internet, el protocolo de conexión puede ser HTTPS y el enlace puede ser una red privada virtual o VPN. El servidor 3630 de pagos también se conecta a cuentas 3635 de depósito enlazadas, ya sea a través de la red 3625 pública (no ilustrada) o a través de una red financiera o bancaria de ACH de propiedad exclusiva . La Figura 37 es un diagrama de bloques de un sistema financiero de bucle cerrado de acuerdo con una modalidad de la invención. En particular, la simplicidad de la presente invención permite la capacidad de ser general y de proporcionar un gran valor a los titulares de una cuenta y a los comercios. Como se discute en lo anterior, la presente invención proporciona un servicio de transacción financiera, electrónico y económico para transacciones de consumidor a comercio y de persona a persona. Esta flexibilidad se proporciona, en parte, al interconectar el teléfono 3702 celular de un consumidor a una terminal 3612 de POS. En una modalidad, el consumidor puede ingresar su número telefónico en un teclado asociado con la terminal de POS y cuando el total de la transacción se encuentra disponible, el comercio puede enviar una SOLICITUD DE PAGO al teléfono 3702 celular por medio de una conexión 3706 a Internet y servidor 3704 de pagos. El servidor 3704 de pagos puede llamar al teléfono 3702 celular y solicitar al consumidor que autorice la transferencia de fondos. El consumidor puede entonces ingresar su PIN u otra identificación biométrica y confirmar la cantidad para autorizar el pago. El servidor 3704 de pagos puede transferir los fondos de la cuenta de débito preconsolidada del consumidor (más cualquier cuota de transacción) a la cuenta de los comercios (menos cualquier cuota de transacción) . En modalidades alternas, el teléfono 3702 celular incluye un circuito de comunicación de campo cercano (NFC) , circuito de Bluetooth o circuito de RFID (no mostrados) que permite que la terminal 3712 de POS busque y recupere información de cuenta, tal como el número telefónico del teléfono celular. En esta modalidad, el comercio puede detectar en forma automática la información de cuenta y enviar la solicitud al servidor 3704 de pagos. El servidor 3704 de pagos puede llamar nuevamente al teléfono 3702 celular para solicitar el PIN u otra identificación biométrica y autorización de pago. Las transacciones de persona a persona evita a la terminal de POS el proceso con cada colega 3707 y 3708 que hace contacto con el servidor 3704 de pagos directamente para concluir la transacción financiera. La Figura 38 es un diagrama de bloques de la aplicación de cliente móvil (MCA) de acuerdo con una modalidad de la invención. La MCA reside en el teléfono 3802 celular y comprende las API 3802 y 3803 de interfaz de usuario y una API 3805 de Pagos. La API 3802 proporciona al usuario imágenes en pantalla que guían al titular de una cuenta a través de diversas transacciones financieras tales como identificar a la otra parte, la cantidad de la transacción, si existe alguna, y el tipo de transacciones que se encuentran disponibles. La API 3803 proporciona a los proveedores del servicio u otros socios de valor agregado (tal como servicios de contabilidad o gestión de registros) con un mecanismo para acceder a la API 3805 de pagos para adquirir información para proporcionar los servicios de valor agregado. La API 3805 de pagos proporciona, en una modalidad, la lógica para aplicar la presente invención y para interconectarse con la capa 3810 de comunicación del teléfono celular . Un método para operar una infraestructura de transferencia de pagos, de acuerdo con una modalidad de la presente invención, es un sistema de pago de bucle cerrado. Un sistema de pago de bucle cerrado ocurre en el caso en el que todos los componentes del proceso de transferencia de valor tienen lugar bajo el control de la entidad que es propietaria del sistema de pago. Debido a que el titular controla el sistema, la fijación de precios subyacente también se encuentra bajo el control del propietario. La Figura 39 muestra el flujo de transacción en el sistema de pago de bucle cerrado que se muestra en la figura 36. Específicamente, para una transacción de persona a persona, cuando un pago se realiza desde un dispositivo 3901 móvil a otro dispositivo 3901 móvil, la solicitud para la transferencia se canaliza al servidor 3903 de pagos. La solicitud se indica mediante la flecha 3904 de referencia. El servidor 3903 accede al libro mayor T del titular de una cuenta relacionado con el dispositivo 3901 móvil (como se indica en la flecha 3905 de referencia) y transfiere la cantidad especificada a un libro mayor T del beneficiario (como se indica en la flecha 3907 de referencia) si es que se cumplen ciertas reglas de velocidad como se indica en 3906. Una vez transferidos los fondos al beneficiario, como se indica en 3908, el servidor 3903 envía un mensaje de notificación al beneficiario como se indica en 3909. Finalmente, el titular de una cuenta del pagador recibe un mensaje de confirmación del servidor 3903 de que se completó la transacción. En una modalidad, el sistema de bucle cerrado completo es propiedad de una sola entidad. Los titulares de las cuentas preparan o cargan el sistema y negocian con dólares el saldo de la cuenta mantenido en el servidor de pago (véase figura 36) . Existen varias ventajas para un sistema de pago de bucle cerrado. La principal ventaja es que el propietario del sistema puede controlar los precios tanto del emisor como del receptor y existe una oportunidad de ganancias de interés sobre los fondos cargados al sistema. El propietario del sistema de pago puede ganar intereses en todos los fondos en el sistema hasta que se convierten o se vuelven a cargar en dólares. Mientras más funciones se agreguen, el sistema de bucle cerrado se vuelve más productivo debido a un incremento en las cuotas y en los saldos . Las propuestas de valor para el titular de una cuenta participante incluyen: (1) Seguridad — el dinero del titular de una cuenta está bloqueado en forma segura en un dispositivo móvil en lugar de portar efectivo en los bolsillos o un bolso; (2) Seguridad — verificación oportuna para ver la cantidad de dinero disponible en la cuenta; (3) Información — fácil de obtener movimientos de la cuenta y estados de cuenta; (4) Conveniente — el titular de una cuenta puede mover el dinero en segundos en todo el mundo o a través de un sitio . Las propuestas de valor para los comercios incluyen: (1) Seguridad— sin manejo de efectivo; (2) Manejo menos costoso — sin cobros por caja, sin comprobantes de depósito, sin cinta de sumadora; (3) Menos costos de transacción — cuotas menores que las tarjetas de crédito y (4) Fondos garantizados — sin cheques rechazados. Los socios comerciales tienen una sola oportunidad para obtener ingresos por concepto del manejo de transacciones dirigidas a los fondos depositados en una cuenta de débito prepagada o para proveer de efectivo a un titular de una cuenta. Los comercios pueden ganar comisiones cuando los fondos se agregan a una cuenta a través de su terminal POS. El sistema' de pago de bucle cerrado independiente de la presente invención está diseñado para integrarse con una cuenta bancaria para acompañante . Esta cuenta puede ser una cuenta preexistente o para los usuarios que no tienen una cuenta bancaria existente, un banco corresponsal puede crear una cuenta . El sistema de bucle cerrado mantiene la base de datos del perfil del usuario que incluye el nombre del titular de una cuenta y los datos demogáficos, información utilizada para asegurar el riesgo para cada titular de una cuenta específica e información de la cuenta bancaria enlazada para las cuentas que se utilizarán para cargar o descargar fondos desde una cuenta de débito prepagada. La base de datos del perfil del usuario también requiere de un sitio Web de servicio orientado al cliente y al consumidor para la recopilación de datos de inscripción cuando se abran las cuentas. El sistema de bucle cerrado presente se interconecta favorablemente con el sistema de intercambio de tarjetas de crédito para acceder a las líneas de crédito disponibles de una cuenta de tarjeta de crédito. El servidor de pago mantiene un registro de la cuenta "T" para cada titular de una cuenta. Esta cuenta es un libro mayor que da seguimiento de cada saldo y transacción del titular de una cuenta. El servidor de pago, junto con la base de datos de la cuenta T, proporcionan datos de saldos e historial mediante el dispositivo móvil al igual que el sitio Web de servicio orientado al cliente y al consumidor. La base de datos de la cuenta T es un registro en tiempo real que registra las transacciones a medida que se presentan. Esto significa que existe una transacción, el emisor de los fondos puede observar que el saldo en sus cuentas se reduce de inmediato mientras que el receptor puede observar el aumento inmediato en el saldo de su cuenta. No existe una ACH o retraso relacionado con la transferencia al mover fondos entre cuentas . Para poder obtener dinero dentro y fuera del sistema de pagos de bucle cerrado, la presente invención proporciona tres tipos de funciones para titulares de una cuenta diferentes. Probablemente algunos titulares de una cuenta ya tengan una cuenta bancaria con un banco que no es socio. El sistema permite que los titulares de una cuenta muevan fondos para y desde esta cuenta bancaria a través del sistema de una ACH. Debido al riesgo que esto involucra, el usuario estará sujeto a controles de riesgo que pueden incluir disponibilidad diferida de fondos transferidos (por ejemplo, una transferencia desde su cuenta bancaria en día lunes puede no estar lista sino hasta el jueves) . Este periodo de aplazamiento puede ser menor con un aseguramiento adicional (informes de crédito corriente o bien estados de cuenta) . La reducción en el periodo de aplazamiento puede suceder si el usuario tiene un historial crediticio bueno con una aseguradora asociada o pagos garantizados con una tarjeta de crédito que esté en reserva. En general, no se pretende que este acercamiento sea la primera elección debido al riesgo involucrado en la transferencia de fondos fuera del sistema de transacción financiera de bucle cerrado a menos que haya un portador involucrado que pueda proporcionar datos de un aseguramiento y que los clientes respalden ese aseguramiento adicional . Donde el titular de una cuenta se inscribió debido a la relación con un banco corresponsal, una conexión en tiempo real con el sistema de Contabilidad de Depósitos en Cuenta Corriente (ahorros en cuenta corriente u otra cuenta como cuenta de mercado monetario) permite que el titular de una cuenta obtenga saldos y transacciones posteriores de su cuenta en tiempo real.
En otros casos, el titular de una cuenta mantiene una cuenta con Bancorp Bank, o una institución financiera similar, que opera el banco y todos los sitios Web, cheques y estados de cuenta del cliente, traerá una afinidad de marca. Este enfoque le permite a la afinidad de marca una cuenta bancaria para acompañante (la cuenta será libre para el usuario) en un entorno ampliamente integrado. La Figura 40 muestra una estructura de cuotas ejemplar para el sistema financiero de bucle cerrado de acuerdo con una modalidad de la invención. Se deberá comprender que la estructura de cuotas puede variar y que la ilustración presenta una típica estructura para generar ingresos de operación. Debido a la naturaleza ubicua de la presente invención, las cuotas de transacción pueden ser muy bajas o libres de cuota. De esta forma, como se indica en 4001, para transacciones bajo cierta cantidad de dólares, se descarta la cuota de transacción. Para ilustrar, considere una transacción financiera de $1 transferido en forma de persona a persona. No habría cuota de transacción. Mientras que la cantidad de dólares donde una cuota de transacción puede cargarse se puede establecer de forma arbitraria, por lo regular la cantidad en dólares será una cantidad menor que $25. Los titulares de la cuenta tendrán derecho a un número ilimitado de tales transacciones de forma mensual. Para cuotas de transacción que sobrepasen el máximo seleccionado, el envío del titular de una cuenta (iniciando una transacción de pago) podría incurrir en ciertas cuotas como se indica en 4002. Para ilustrarlo, en cantidades de transacciones que yacen entre $50 y $100, el titular de una cuenta podría incurrir en una cuota de transacción de $1.00, a manera de ejemplo. Para cantidades que sobrepasen la cantidad seleccionada (tales como las que sobrepasan $100) se cargará o negociará una cuota mayor. Estas cuotas son considerablemente menores que la cuota por transacción cargada por la entidad emisora de la tarjeta de crédito. En una modalidad alternativa, la cuota de transacción puede ser una cantidad nominal, tales como centavos, $0.05 ó $0.10, que se carga al emisor. Para transacciones que involucren comercios, el comercio puede ofrecer de forma opcional pagar la cuota de transacción, que de otra forma, se cargaría al consumidor como se indica en 4003. Además, al comercio se le cobra una cuota adicional por recibir fondos. Nuevamente, la cantidad real de la cuota de transacción del comercio puede variar pero en una modalidad es el 1 por cierto nominal de la cantidad de la transacción. Un cargo de servicio nominal mensual se agrega, en una modalidad, a los recibos del usuario de teléfono celular a través del proveedor de servicios móviles como se indica en 4004. El proveedor de servicios móviles y el propietario del sistema de transacción financiera de bucle cerrado de la presente invención comparten el cargo de servicio mensual en una base proporcional . Un sistema de pago respaldado por el miembro se le proporciona a los consumidores y comercios sin cargos de registro, cargos de suscripción o cargos de transacción ya sea a los consumidores o a los comercios. En una aplicación específica, el sistema de pago del miembro es un sistema de pago móvil donde los consumidores pueden llevar a cabo las transacciones a través de un dispositivo móvil como teléfono móvil, teléfono inteligente, asistente digital personal o un dispositivo de mano inalámbrico portátil similar. Los comercios realizarán una contribución reembolsable en una sola exhibición. Estas contribuciones se almacenan en una cuenta fiduciaria común mediante el sistema y los dividendos o intereses flotantes en estas contribuciones que fundarán el sistema . En una aplicación específica, el sistema de pago soportado por miembro (MSPS) proporciona un sistema de pago completamente libre para los consumidores y comercios que utilicen los siguientes principios: 1. Sin cargos de registro para consumidores o comercios 2. Sin cargos de suscripción para consumidores o comercios 3. Sin cuotas de transacción para consumidores o comercios 4. Se requiere una contribución del comercio reembolsable en una sola exhibición. 5. La contribución del comercio en una sola exhibición se une a una cuenta fiduciaria del MSPS 6. La cuenta fiduciaria del MSPS genera dividendos flotantes que proporcionan la compensación para el sistema y la compañía de procesamiento del MSPS . 7. Los consumidores y comercios pueden cargar o descargar desde una cuenta de explotación común del MSPS (separada de la cuenta fiduciaria) . 8. Los fondos disponibles del consumidor están prepagados y disponibles dentro de la cuenta de explotación común del MSPS. 9. El sistema MSPS administra la cuenta "T" (por ejemplo, saldo, débito, crédito) para las cuentas del consumidor y del comercio. En una modalidad, la invención es un método que incluye: recibir una pluralidad de contribuciones de comercios para fundar un sistema de pago de miembro; colocar las contribuciones de comercios en una cuenta fiduciaria común, donde los comercios no recibirán interés en sus contribuciones; permitir una pluralidad de consumidores para convertirse en usuarios registrados del pago móvil sin cargos; permitir que los usuarios registrados carguen o descarguen fondos en una cuenta de explotación del sistema de pago de miembro sin cargos y permitir que los comercios carguen o descarguen fondos de la cuenta de explotación del sistema de pago de miembro sin cargos, donde el interés de la cuenta fiduciaria común fundará el sistema de pago de miembro . La Figura 41 muestra una operación confiable de carga en una aplicación del sistema de pago soportado por miembro de la invención. La Figura 42 muestra un registro del consumidor en el sistema de pago soportado por miembro. La Figura 43 muestra operaciones de carga y de descarga en el sistema de pago soportado por miembro. La Figura 44 muestra una transacción de compra en el sistema de pago soportado por miembro. En una aplicación, la contribución del comercio puede ser un pago en plazos sobre un periodo. Dependiendo de la cantidad de la contribución, el comercio tendrá mayor acceso o privilegios en el sistema. Por ejemplo, puede haber niveles de contribuciones establecidos que correspondan a un número de transacciones a las que un comercio tiene derecho sin cargos adicionales. También, el comercio puede realizar una contribución posterior para incrementar los privilegios del comercio.
En una aplicación, el sistema de pago de miembro permite que un usuario registrado solicite el pago del dinero a otro usuario registrado a través de un teléfono móvil. El sistema de pago de miembro permite que un usuario registrado solicite el pago del dinero a un comercio a través de un teléfono móvil. El sistema de pago de miembro puede administrar los registros de transacciones de los usuarios registrados. El sistema de pago de miembro administra los registros de transacciones de los comercios. El sistema de pago de miembro puede administrar los registros de transacciones de los usuarios registrados y de los comercios. Esto reducirá los costos de los comercios dado que no necesitan administrar sus propios registros de transacciones. La contribución es reembolsable , de manera que el comercio pueda decidir posteriormente no participar. Por ejemplo, cuando un comercio solicita un reembolso de la contribución del comercio al sistema de pago de miembro, los usuarios registrados ya no tienen permitido transferir dinero a otro comercio. Por lo general, al comercio no se le cobra la cuota de transacción recurrente por ser un participante del sistema de pago de miembro. El sistema está financiado por la flotación en la fiduciaria común que contiene las contribuciones del comercio.
Los usuarios registrados pueden cargar o descargar los fondos a través de por lo menos una Cámara de Compensación Automatizada (ACH) o cuenta de depósito directo (DDA) . En aplicaciones posteriores del sistema, los usuarios registrados y los comercios pueden estar provistos de diferentes formas para cargar y descargar fondos. Por ejemplo, un usuario registrado puede elegir tener el cheque de pago del usuario o una parte del cheque de pago directamente depositado en el sistema. En una aplicación, el método incluye: permitir que un usuario registrado autorice pagarle a un comercio a través del sistema de pago de miembro utilizando un esquema de autorización de dos factores. Estos dos factores de autorización pueden incluir (1) lo que tiene la persona (por ejemplo, teléfono, tarjeta) y (2) lo que la persona sabe (por ejemplo, PIN, nombre de soltera de la madre, pregunta secreta) . Por ejemplo, el sistema permite que un usuario registrado autorice pagarle a un comercio a través del sistema de pago de miembro mediante el uso de un teléfono móvil del usuario registrado y que el usuario ingrese correctamente el número de identificación personal o PIN. Opcionalmente , cada usuario registrado también puede tener una tarjeta de débito. Por ejemplo, con la tarjeta de débito, los usuarios pueden realizar cargos sin la necesidad de un teléfono móvil.
Cuentas Comunes Virtuales Con respecto a la figura 45, en una aplicación específica de la invención, para evitar el acumulamiento de libros mayores para cada banco, el sistema móvil guardará un libro mayor para la cuenta común virtual para cada país. Esto reduce los costos operacionales y de liquidación del sistema. Dado que el dinero se guardará en la cuenta común virtual, el propietario de la cuenta común virtual (por ejemplo, el operador del servicio del sistema de pago móvil) recibirá la flotación o interés con respecto a este dinero. El receptor de la flotación en la cuenta común virtual puede distribuir algunas cantidades a los bancos corresponsales (que ya no reciban la flotación en sus libros mayores) . Un método de distribución de los fondos de flotación se determina de la siguiente manera: (1) Las cuentas adquiridas por el banco corresponsal se reconocerán como provenientes de ese banco. Por ejemplo, si el banco Ci comercializa el sistema de pago móvil y contrata al cliente A, entonces el cliente A estará marcado de por vida como "Contratado por Ci . " Para cada registro del usuario (mencionado en otra parte de esta aplicación) , puede haber un campo que indique de qué fuente se contrató a ese usuario en particular. Algunos ejemplos de posibles fuentes incluyen directamente el servicio de pago móvil, banco corresponsal, institución financiera corresponsal y proveedor de telefonía celular corresponsal. Al final de cada día el servicio del sistema de pago móvil calculará la cantidad de fondos guardada en las cuentas del servicio del sistema de pago móvil marcadas como contratadas por cada banco corresponsal. Digamos que esta cantidad calculada será X-Ci, X-BA, X-ING, donde Ci, BA, y ING son ejemplos de instituciones financieras o bancos. Por ejemplo, en la figura 45, el miembro 6504044762 fue contratado por el primer banco Ci mientras que el miembro 4154443214 fue contratado por el tercer banco BA. En este ejemplo, los miembros están identificados mediante el número telefónico. Ejemplos de números telefónicos para los Estados Unidos incluyen 4158675309 ó 2128675309. En una aplicación de la invención, el formato del número telefónico puede ingresarse sin el código de área, por ejemplo 7762323 ó 5550123. Por ejemplo, puede ser la situación en que el receptor esté en la misma área que el emisor. El sistema completaría los dígitos del código de área de forma automática. Como ya se estableció en alguna parte de esta aplicación, los miembros pueden identificarse por otros tipos de identificadores , tales como nombre de usuario de mensajería instantánea, dirección de correo electrónico, número de seguro social, número de licencia de conductor, número de cuenta entre otros . (2) Llamemos al remanente Y. Esta es la cantidad de fondos calculada por guardar en el servicio del sistema de pago móvil que no se ha marcado como contratada. Estas son cuentas contratadas a través del servicio directo del sistema de pago móvil o bancos no corresponsales. En la figura 45, esto se representa mediante el número telefónico 6508622730 que está indicado como contratado por el segundo banco del SPS (proveedor del servicio del sistema de pago móvil) . (3) Probablemente, cada día a una hora designada, el servicio del sistema de pago móvil calculará los fondos adecuados por guardar en un banco corresponsal. Por ejemplo, puede ser de acuerdo con la siguiente fórmula: Banco corresponsal X más un porcentaje de Y. El porcentaje se negociará al momento en que se establezca la asociación del banco y dependerá del nivel del gasto de mercadeo. Por ejemplo, para Ci, el servicio del sistema de pago móvil puede poner un 10 por ciento de Y en la cuenta del servicio del sistema de pago móvil para Ci . El porcentaje puede ser cualquier porcentaje tal como 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 u otros. El porcentaje puede ser un número entero o un número fraccionario que incluye 1.1, 1.2, 1.3, 1.5, menor que 1 , menor que 2 , menor que 3 , menor que 6 y otros . Este método está diseñado para evitar el costo de mantener varios libros mayores y la liquidación neta. También le proporciona al banco corresponsal más de su participación equitativa de los fondos del servicio del sistema de pago móvil . Una cuenta común virtual se utiliza en la operación de un sistema que cuenta con varios socios financieros. En una aplicación específica, el sistema es un sistema bancario móvil. En lugar de guardar libros mayores separados para cada institución financiera, el sistema guardará una cuenta común virtual general. Esto reducirá los costos operacionales y de liquidación del sistema. El propietario de la cuenta común virtual recibirá la flotación sobre la cuenta común virtual y esta flotación se distribuirá a los diversos socios financieros de acuerdo con una fórmula. En - una modalidad, la invención es un método que incluye: el manejo de transacciones financieras de un grupo de usuarios de un sistema, donde las transacciones financieras pueden especificarse a través de teléfonos móviles y los subgrupos de los usuarios están asociados con una institución bancaria; el procesamiento de transacciones financieras relacionadas con una primer institución bancaria, donde los usuarios en un primer subgrupo están asociados con la primer institución bancaria; el procesamiento de transacciones financieras asociadas con una segunda institución bancaria, donde los usuarios en un segundo subgrupo están asociados con la segunda institución bancaria; el procesamiento de transacciones financieras asociadas con la tercer institución bancaria, donde los usuarios en un tercer subgrupo están asociados con la tercera institución bancaria; el mantenimiento de una cuenta común virtual que incluye los fondos para los usuarios del primer, segundo y tercer subgrupo asociados con la primer, segunda y tercer institución bancaria; y la distribución de un primer dividendo a la primer institución bancaria con base en la flotación para los fondos en la cuenta común virtual para los usuarios del primer subgrupo más un porcentaje de flotación sobre los fondos en la cuenta común virtual para los usuarios del tercer subgrupo. En una aplicación, el método incluye la distribución de un segundo dividendo a la segunda institución bancaria con base en la flotación para fondos en la cuenta común virtual para los usuarios del segundo subgrupo más un porcentaje de flotación sobre los fondos en la cuenta común virtual para los usuarios del tercer subgrupo. En una aplicación, el método incluye recibir una indicación de un primer usuario en el primer subgrupo para transferir dinero a un segundo usuario en el segundo subgrupo, donde el dinero no se transfiere fuera de la cuenta común virtual. La indicación puede ser enviada de forma inalámbrica desde un teléfono móvil vía mensajería del SMS. La indicación puede enviarse de forma inalámbrica desde un teléfono móvil utilizando una aplicación que se ejecute en el teléfono móvil.
La tercer institución bancaria puede ser un socio directo del sistema. En una aplicación, el método incluye a cada usuario asociado con sólo una de la primera, segunda o tercera instituciones financieras. En una aplicación, el método incluye la administración de un sistema de registros para la cuenta común virtual, donde el sistema de registros incluye registros de transacciones para los usuarios en el primer, segundo y tercer subgrupo. En una modalidad, la invención es un método que incluye: el manejo de transacciones financieras de un grupo de usuarios de un sistema, donde las transacciones financieras pueden especificarse a través de teléfonos móviles y los subgrupos de los usuarios están asociados con una institución bancaria; el procesamiento de transacciones financieras relacionadas con una primera institución bancaria, donde los usuarios en un primer subgrupo están asociados con la primera institución bancaria; el procesamiento de transacciones financieras relacionadas con una segunda institución bancaria, donde los usuarios en un segundo subgrupo están asociados con la segunda institución bancaria; el procesamiento de transacciones financieras de usuarios en un tercer subgrupo asociados con el sistema y no con la primer y segunda institución bancaria; el mantenimiento de una cuenta común virtual que incluye los fondos para los usuarios del primer, segundo y tercer subgrupo asociados con la primer, segunda y tercer institución bancaria y el sistema; y la distribución de un primer dividendo a la primer institución bancaria con base en la flotación para los fondos en la cuenta común virtual para los usuarios del primer subgrupo más un porcentaje de flotación sobre los fondos en la cuenta común virtual para los usuarios del tercer subgrupo. En una aplicación, el método incluye la distribución de un segundo dividendo a la segunda institución bancaria con base en la flotación para fondos en la cuenta común virtual para los usuarios del segundo subgrupo más un porcentaje de flotación sobre los fondos en la cuenta común virtual para los usuarios del tercer subgrupo. En una aplicación, el método incluye recibir una indicación de un primer usuario en el primer subgrupo para transferir dinero a un segundo usuario en el segundo subgrupo, donde el dinero no se transfiere fuera de la cuenta común virtual. La indicación puede ser enviada de forma inalámbrica desde un teléfono móvil vía mensajería del SMS. La indicación puede enviarse de forma inalámbrica desde un teléfono móvil utilizando una aplicación que se ejecute en el teléfono móvil. La indicación puede enviarse a través del navegador de Internet . En una aplicación, cada usuario está asociado con sólo una de la primera institución, segunda institución o con el sistema. En una aplicación, el método incluye recibir una indicación de un primer usuario en el primer subgrupo para transferir dinero a un segundo usuario en el tercer subgrupo, donde el dinero no se transfiere fuera de la cuenta común virtual. En una aplicación, el método incluye la administración de un sistema de registros para la cuenta común virtual, donde el sistema de registros incluye registros de transacciones para los usuarios en el primer, segundo y tercer subgrupos . La Figura 46 muestra un método para la compra rápida de acuerdo con una modalidad de la presente invención. En una modalidad, los carteles, anuncios de periódicos, o comerciales de televisión incluyen un mecanismo para permitir que un comprador adquiera detalles específicos sobre un producto mostrado en el teléfono celular. Este mecanismo puede incluir códigos de barra impresos o un número telefónico para marcar y solicitar información. En otra modalidad, se utiliza una comunicación de campo cercano para iniciar la conexión entre el comprador y un comercio remoto como se indica en 4601. Iniciar la conexión activa de la MCA de manera que si el comprador decide realizar una compra, la MCA estará al pendiente y se establecerá la conexión como se indica en 4602. Al seleccionar la opción Solicitud de Compra, como se indica en 4603, el comprador puede concluir una transacción de compra con el servidor de pago que controla los detalles tales como dirección de "envío para" y transferencia de fondo. El producto ordenado se entregará en un corto periodo que puede variar desde unos cuantos minutos hasta un par de días, como se indica en 4604. En otra modalidad, el titular de una cuenta tiene la opción de seleccionar una "entrega a la ubicación geográfica actual" en lugar de la dirección del recibo del titular de una cuenta. Esta característica es de una particular conveniencia cuando el titular de una cuenta viaja y desea ordenar del menú en servicio a la habitación pero no desea hablar con nadie. En este caso, el menú incluiría un dispositivo de comunicación de campo cercano de manera que el titular de una cuenta sólo necesitaría seleccionar la Solicitud de Compra y los alimentos se entregarían en la habitación donde se ubique el titular de una cuenta. La Figura 47 muestra aún otra característica de compra rápida de acuerdo con una modalidad de la presente invención. En esta modalidad, un titular de una cuenta espera un pago recurrente periódicamente por concepto de un producto o servicio. Para ilustrarlo, considere al típico trabajador que todas las mañanas se detiene a comprar el periódico antes de subir al tren rumbo a la ciudad. Con la modalidad ilustrada en la figura 47, el titular de una cuenta puede determinar una cuenta preautorizada para tales pagos recurrentes como se indica en 4701. La cuenta preautorizada podría incluir el tipo de producto o servicio que desee obtener, como se indica en 4702, al igual que la cantidad de compra máxima disponible por preautorizar, como se indica en 4703. De esta manera, cuando el trabajador recoge el periódico, una antena de campo cercano detecta la información de la cuenta en el teléfono y envía la cantidad de la transacción al servidor de pago que enviará una confirmación al comercio sin tener que esperar a que el consumidor verifique y autorice específicamente la transacción financiera como se indica en 4704. Esta característica también es un método importante para acelerar el proceso de compra al momento de las transacciones financieras relevantes, tales como cuando un trabajador desea pagar un boleto del metro con su teléfono móvil a medida que se dirige hacia los torniquetes. La cantidad preautorizada puede deducirse en tiempo real o procesarse como una transacción financiera en lote, por ejemplo, cada hora. Para reducir el tiempo del proceso de verificación, el comercio puede recibir por adelantado la notificación de la preautorización. Una vez recibida la preautorización, el número de teléfono se podrá colocar en una "lista verde" que indica que el comercio puede aceptar el pago sin verificación del servidor de pago. La lista verde se almacena en las terminales POS o bien está disponible para las terminales POS desde un servidor local en lugar del servidor de transacción. Si una cuenta preautorizada está vacía y si el titular de una cuenta no la recargó oportunamente, el número telefónico se colocará en la "lista roja" y se prohibirá el uso futuro del servicio. El comercio también podrá almacenar localmente la lista roja en POS o almacenarla en un servidor local acoplado con el equipo POS. Si un número telefónico está en la lista roja, el comercio puede aceptar una forma alternativa de pago. Alternativamente, el servidor puede negar el servicio y enviar un mensaje con la sugerencia de que el titular de una cuenta aproveche esa oportunidad de recargar la cuenta del titular de una cuenta. El comercio puede aceptar el pago de recarga y cobrar la cuota insentiva para recibir los fondos para recarga la cuenta del titular de una cuenta. Para acelerar las compras preautorizadas , en una modalidad, el teléfono celular incluye un código de barras externamente visible que puede escanearse en POS para iniciar y concluir una transacción. Alternativamente, el código de barras podrá mostrarse en la pantalla del teléfono celular y escanearse en el POS. Debido a que la rapidez y la conveniencia son importantes para muchas de las compras diarias, el código de barras, junto con la lista verde oculta localmente, permite que los comercios acepten la compra "al instante" y posteriormente envíen la transacción en un modo de lote en los intervalos seleccionados. Una ventaja para el titular de una cuenta es que si pierde el teléfono móvil, la preautorización puede suspenderse rápidamente ya sea accediendo a la página Web para actualizar el perfil del usuario o llamando a atención al cliente. Si un teléfono móvil se reporta como extraviado, las listas verde y roja nuevas se distribuirán de inmediato a los comercios afectados, limitando así las pérdidas potenciales para el titular de una cuenta y el comercio. Comparado con las pérdidas de un boleto para transporte prepagado mensual perdido — en caso de pérdida, el valor total del boleto también se pierde y la persona que lo encuentra obtiene los beneficios. De esta forma, las lista verde y roja son una herramienta efectiva para evitar fraudes ya sea por robo o pérdida del teléfono con respecto a cuentas preautorizadas . Dado que cada teléfono celular en uso hoy en día no es una aplicación equipada, el servidor de pago adapta el nivel de servicio disponible para cada titular de una cuenta. Un método para comunicar mensajes entre dispositivos de teléfonos celulares es transmitir y recibir mediante el Servicio de Mensajería Corta, que comúnmente se conoce como un "mensaje de texto del SMS" o simplemente SMS, ya que la mayoría de los dispositivos móviles respaldan el servicio SMS. El SMS es un mecanismo para enviar mensajes cortos sobre redes móviles. Es una forma de almacenar y reenviar para transmitir mensajes para y desde teléfonos móviles. El mensaje (sólo texto) desde el teléfono móvil que envía se almacena en un servidor asociado con el sistema de transporte SMS que posteriormente lo reenvía al teléfono móvil destino minutos más tarde. Esto significa que si el destinatario no está disponible, el mensaje se almacena y se envía posteriormente. Dado que SMS utilizó el canal de señalización a diferencia de los canales dedicados, estos mensajes pueden enviarse o recibirse simultáneamente con el servicio de voz por toda la red móvil. Con las redes móviles basadas en las tres tecnologías celulares, con GSM, CDMA, y TDMA que respaldan SMS, SMS es hoy en día un servicio de datos móvil ampliamente disponible. Con SMS, un distribuidor del SMS enruta los mensajes entre el servidor de pago y el titular de una cuenta en tiempo real y los fondos estarán disponibles de inmediato para que el destinatario pueda utilizarlos. Si la transacción financiera incluye otra parte, el servidor también utilizará el SMS para comunicar con otras partes en tiempo real utilizando nuevamente el distribuidor del SMS. El SMS es particularmente un mecanismo importante cuando un titular sin cuenta es el destinatario de una transferencia de pago de un titular de una cuenta. Un problema para el titular sin cuenta es la falta de la MCA insertada en el teléfono de manera que SMS es un mecanismo para comunicar con titulares sin cuenta. La MCA administra e inserta un número de transacción que incluye claves idempotencia que hacen que el número de transacción sea único para los servicios de datos del SMS, HTTP, y mensajes de protocolo HTTPS pero no existe número de transacción al utilizar el SMS de forma manual. Un sistema de transacción financiera móvil con SMS evita los gastos y problemas asociados con tener un chip especial (por ejemplo, un dispositivo de circuito integrado) agregado sólo para respaldar y permitir la funcionalidad financiera de un dispositivo. Agregar componentes adicionales a un teléfono celular u otro dispositivo móvil incrementa los costos de fabricación y respaldo en el campo. Los costos se incrementan aún más si el uso del chip requiere cuotas de autorización u otro tipo de cuotas de propiedad. Además, agregar un chip al teléfono celular incrementa el consumo de energía y degrada la vida de la batería — ambos casos tienen consecuencias negativas para los dispositivos móviles tales como teléfonos celulares. Aunque la mensajería de textos del SMS funciona bien con la mayoría de los tipos de dispositivos celulares y algunos otros tipos de dispositivos de comunicación móvil, tales como asistentes digitales portátiles o PDAs, el SMS expone contraseñas descodificadas o números de identificación personales (PINs) , así como información de saldo o detalles acerca de la transacción más reciente. Puesto que cualquiera en posesión del teléfono puede leer el archivo de mensajes del SMS y saber de inmediato cómo acceder a la cuenta de otro, en la presente invención. Por consiguiente, en una modalidad, la presente invención permite el inicio de la transacción financiera por medio del mensaje de texto del SMS con una parte de la transacción concluida sobre un canal de voz . La Figura 48 es una ilustración del nivel del sistema de una transacción financiera realizada a través de por lo menos un mecanismo de mensajería del SMS de acuerdo con una modalidad de la presente invención. Este método de transacción se utiliza donde ni siquiera el teléfono celular se habilita mediante Internet. Además, tampoco el teléfono celular, es la falta de MCA insertada de manera que se espera que la mensajería del SMS maneje la transacción. Un experto en la técnica apreciará que si uno de los teléfonos estuviera habilitado a través de Internet y tuviera instalada la MCA, entonces su lado de la transacción se presentaría sobre µ? enlace HTTPS y la comunicación con el otro teléfono sería por medio de la mensajería del SMS. Se debe comprender que HTTPS se refiere a Protocolo de Transferencia de Hipertexto sobre el Nivel de Seguridad de la Conexión, o HTTP sobre SSL y que el enlace es un enlace de Internet. Sería idóneo que posteriormente la conexión de Internet proporcionara una interfaz de usuario más rica, es más seguro y más fácil de iniciar y concluir una transacción financiera. Cuando HTTPS no está disponible, la MCA puede adaptar la transacción para utilizar el protocolo HTTP, un mecanismo de transporte menos seguro. En este caso, la cuenta puede invocar la codificación de software antes de insertar la información de transacción antes de enviarla al servidor. Si una conexión de Internet no está disponible, el uso del mensaje SMS (o Servicio de Mensaje Corto) se utiliza en una modalidad. En una modalidad, la aplicación de cliente móvil utiliza la función de servicios de datos para enviar mensajes del SMS binarios. En otra modalidad donde la aplicación de cliente móvil no está disponible, los mensajes del SMS de texto simple se utilizan para conducir transacciones financieras con arreglos especiales tomados para proteger la integridad del PIN. Se apreciaría posteriormente que la falta de aplicación de cliente móvil limite las capacidades de la interfaz del usuario de manera que el usuario pueda derivar la satisfacción limitada de la presente invención, sin embargo, gozaría de todas las características y beneficios del presente sistema de transacción financiera. Con la presente invención, la aplicación del cliente móvil selecciona el modo de transmisión de la transacción financiera al servidor 4804 (también conocido como procesador de transacción) . Por ejemplo, si está disponible una conexión de Internet, la transacción se condice utilizando un enlace HTTPS, que es un protocolo de la Web que codifica y descodifica las solicitudes de la página del usuario al igual que las páginas devueltas por el servidor 4804. Para utilizar Internet, el titular de una cuenta ingresa solamente a los detalles de la transacción de la página Web y selecciona "enviar" para iniciar la transacción. Si otra parte involucrada y esa parte tienen un dispositivo habilitado por la Web, los detalles de la transacción se proporcionarán en la página Web. En esta modalidad, el servidor 4804 funciona como un servidor de Web. Por lo regular, no todos los titulares de una cuenta tienen un teléfono celular o dispositivo habilitado por Internet. Por lo tanto, la presente invención proporciona otros métodos para llevar a cabo transacciones financieras desde el teléfono celular. Tales métodos incluyen el uso de servicios de datos del SMS, el texto simple del SMS (ambos pueden utilizar un canal de voz para transmitir el PIN) o sólo el canal de voz. Para un teléfono celular con capacidad del SMS, el titular de una cuenta transmite un mensaje SMS sobre el puerto 4802 de enlace del SMS al servidor 4804 para iniciar una transacción desde su teléfono celular 4806 como se indica en la flecha 4810 de flujo. El puerto 4802 de enlace transmite el mensaje SMS al servidor 4804 como se indica en la flecha 4811 de flujo. Una vez recibido el mensaje SMS, el servidor 4804 toma la acción especificada solicitada en el mensaje y envía un mensaje SMS de contestación al puerto 4802 de enlace como se indica en la flecha 4812 de flujo. El puerto 4802 de enlace transmite el mensaje SMS de contestación al teléfono 4806 celular como se indica en la flecha 4813 de flujo. Esta secuencia de eventos puede proceder para varias iteraciones hasta completar una transacción financiera. Los mensajes del SMS pueden transmitirse entre teléfonos y puertos 4802 de enlace mediante cualquier red de conmutación de circuitos o conmutación de paquetes. En algunas modalidades, se establece un canal de comunicación de voz como se indica en los canales 4815 y 4835 de voz. Cuando un mensaje inicial SMS se recibe desde un teléfono 4806, el servidor 4804 puede abrir el canal 4815 de voz al marcar el número telefónico asociado con la cuenta. Un ejemplo donde el canal 4815 de voz se utiliza para obtener un PIN (recibido como DTMF o bien información de voz) para completar el proceso de verificación y autenticar al usuario como el titular de una cuenta en respuesta a un mensaje SMS. DTMF se refiere a la multifrecuencia de tono dual, la señal que recibe una compañía telefónica cuando se presionan las teclas del teléfono. El mensaje inicial del SMS inicia con una palabra clave que proporciona el tipo de transacción solicitada - PAGAR, SOLICITAR PAGO, SALDO, TRANSFERIR o AYUDA. En los casos en los que el mensaje del SMS contiene la palabra clave que indica el deseo de transferir fondos del titular de una cuenta a otra cuenta, la palabra clave puede ser pagar o bien solicitar pago. Después de la palabra clave, se ingresa la cantidad con o sin un punto decimal. Después de la cantidad, se ingresa el número telefónico objetivo (o código corto, dirección de correo electrónico u otra información de identificación) . Esta información puede obtenerse automáticamente del directorio telefónico o del dispositivo móvil. Después del número telefónico, el titular de una cuenta puede ingresar un mensaje en un campo de mensaje para mostrarlo a la otra parte. En algunos casos, este mensaje puede ser un mensaje nulo. En algunas modalidades, el titular de una cuenta también puede ingresar un mensaje complementario con el objetivo de guardar los registros. Un código especial en el campo del mensaje delinea el mensaje complementario para indicar que el texto seguido del código especial es privado y no se reenviará. Ejemplos de códigos especiales representativos pueden ser */*/ o /-/ u otros códigos únicos definidos por el usuario. Una vez que el mensaje del SMS se envía al servidor, el titular de una cuenta ingresa el PIN y lo envía a través de una conexión de canal de voz al servidor para verificar el mensaje del SMS. El PIN se ingresa a través del teclado y puede ser cualquier código alfanumérico . Entonces el PIN se envía al servidor de pago como un mensaje DTMF codificado . En el servidor, el servidor recibe el mensaje del SMS a través de la trayectoria de comunicación del mensaje de texto del SMS y el PIN a través del canal de voz. El titular de una cuenta puede realizar la llamada al servidor o el servidor de pagos puede iniciarla como una característica de "llamada de respuesta" en respuesta a la recepción del mensaje del SMS. Sería deseable mandar el PIN como un mensaje codificado de DTMF para mantener la seguridad; sin embargo, en otras modalidades el titular de una cuenta puede pronunciar el PIN y ser convertido mediante un módulo de software de reconocimiento de voz interactivo que opera en el servidor de pagos o en otro servidor (no mostrado) dedicado al manejo de llamadas de voz. Para ilustrarlo, considere el proceso que ocurre cuando el titular de una cuenta que utiliza el teléfono celular 4506 solicita un saldo de la cuenta mediante un mensaje del SMS dirigido al servidor 4504. El usuario da formato al mensaje del SMS para incluir el tipo de transacción financiera solicitado, es decir, SALDO (una forma corta aceptable de la solicitud puede ser SAL o simplemente S) , y el número telefónico asociado con su cuenta, por ejemplo, 4088675309 (es decir, número telefónico de Jenny) .
De forma alterna, el número de cuenta puede determinarse utilizando el ID de llamadas. Cuando el servidor 4804 recibe el mensaje del SMS, el servidor verifica de inicio el número de secuencia o transacción (véase figuras 54, 55 y 56) . Si el número de secuencia es correcto, el servidor 4804 marcará el número telefónico asociado con la cuenta y le pedirá al usuario que ingrese el PIN. En otras modalidades, el PIN se incluye en el mensaje del SMS original de manera que no hay necesidad de llamar al titular de una cuenta para verificarlo. Si el teléfono 4806 celular está bien configurado con una aplicación de cliente móvil, es posible codificar la contraseña antes de incluirla en el mensaje del SMS. La aplicación del cliente móvil utilizará los servicios de datos. El inconveniente de utilizar el mensaje del SMS para transmitir el PIN es que ese número secreto estará visible para todos los que tengan acceso al teléfono, lo que puede ocasionar el uso no autorizado de un titular sin una cuenta. Si el PIN es correcto, el servidor 4804 controlará la transacción solicitada. El usuario puede seleccionar recibir la información solicitada a través de una respuesta de voz sobre un canal 4815 de voz o regresar un mensaje del SMS en cuyo caso el servidor envía un mensaje con la cantidad del saldo al puerto 4802 de enlace que lo reenviará al teléfono 4806 celular.
En otras transacciones financieras, existen dos teléfonos 4806 y 4808 celulares involucrados. Estos tipos de transacciones financieras tienen por lo regular fondos de transferencia del titular de una cuenta para un destinatario que pueda ser un titular de una cuenta asociada con el teléfono 4808 celular. En otras transacciones, el destinatario es un titular sin cuenta. Al igual que con la solicitud SAL, una solicitud para PAGAR el usuario del teléfono 4808 celular se inicia a través de un mensaje del SMS dirigido al servidor 4804. Se da formato al mensaje del SMS para incluir el tipo de transacción financiera solicitada, es decir, PAGAR y el número telefónico del destinatario (por ejemplo, 2127875466) , y el número telefónico asociado con su cuenta, es decir, nuevamente por ejemplo, 4088675309. Si el teléfono del titular de una cuenta soporta la aplicación del cliente móvil, entonces todos los mensajes del SMS intercambiados entre el teléfono 4806 celular y el servidor 4804 pueden codificarse para obtener mayor seguridad. Cuando el servidor 4804 recibe el mensaje del SMS, verifica de inicio el número de secuencia o transacción (si está disponible) y procede sólo si el número de secuencia es correcto o si está indicado como no disponible en el registro de la cuenta guardado en el servidor. Entonces el servidor 4804 recibe y determina si el PIN es correcto. Si el número de secuencia y el PIN son correctos, el servidor 4804 maneja la transacción solicitada al cobrar a la cuenta asociada con el titular de una cuenta (véase figura 43) y enviar un mensaje de confirmación SMS al titular de una cuenta sobre el puerto 4802 de enlace. Si el destinatario 4808 es un titular de una cuenta, el servidor 4802 también enviará un mensaje de confirmación que confirme la recepción de los fondos. Si el teléfono celular es un PDA móvil u otro dispositivo habilitado por IP, entonces HTTPS enviará el mensaje y podría estar codificado para garantizar mayor seguridad. La codificación puede ser a través de cualquier método conocido. Si el destinatario 4808 es un titular de una cuenta con la aplicación del cliente móvil instalada, entonces la aplicación del cliente móvil podría codificar sus mensajes antes de enviarlos al servidor 4804 y recibir mensajes codificados del servidor 4804. Si el destinatario 4808 es un titular de una cuenta pero el teléfono celular no soporta la descarga y ejecución de la aplicación del cliente móvil en el teléfono celular, entonces los mensajes del servidor 4804 estarán en texto simple. El inconveniente de utilizar el mensaje del SMS de texto simple para transmitir el PIN es que ese número secreto estará visible para todos los que posteriormente tengan acceso al teléfono. Esto podría resultar en el uso no autorizado de un titular sin cuenta a menos que el titular de una cuenta se tome el tiempo para eliminar los mensajes del SMS de la bandeja de su teléfono celular. Si el destinatario 4808 no es un titular de una cuenta, entonces los mensajes del SMS también serán mensajes con texto sencillo. Aunque la mensajería de textos del SMS funciona bien con teléfonos celulares y otros tipos de dispositivos de comunicación móvil, tales como asistentes digitales portátiles o PDAs, el SMS expone contraseñas descodificadas o números de identificación personales (PINs) , así como información de saldo o detalles confidenciales acerca de la transacción más reciente. Dado que cualquiera en posesión del teléfono puede leer el historial de mensajes del SMS y saber de inmediato cómo acceder a la cuenta de otro y a la información confidencial de otros, lo mejor es evitar el uso de mensajes del SMS públicos para transmitir el PIN. De esta forma, para el dispositivo móvil emitido por un proveedor de servicios asociados, es deseable que los dispositivos móviles incluyan la aplicación del cliente móvil como un módulo de software preexistente. Como alternativa, es preferible que la aplicación del cliente móvil se descargue desde el proveedor de servicio a los teléfonos celulares que originalmente no estaban equipados con la aplicación del cliente móvil. La aplicación del cliente móvil permite mejoras significativas para el uso del sistema de transacciones financieras. La aplicación de cliente móvil se selecciona, ya sea directamente por el titular de una cuenta o en respuesta a la activación de la característica de mensajería de textos del SMS en el dispositivo móvil. La siguiente es una descripción detallada que ilustra el uso de la mensajería de textos del SMS para permitir a los titulares de una cuenta el acceso al servidor de pagos desde cualquier teléfono móvil apto del SMS u otro dispositivo activado por el SMS en una modalidad donde esté disponible la aplicación del cliente móvil. En operación, el titular de una cuenta envía un mensaje de texto al servidor 4804 mediante el uso de la capacidad de mensajes de texto existente en su teléfono. La funcionalidad incluye Pagar, Solicitar Pago, Saldo, Historial y Ayuda solicitada al utilizar cualquiera de estas características como una palabra clave. El titular de una cuenta ingresa la palabra clave junto con información adicional en el cuerpo del mensaje de texto para construir un comando que posteriormente se envía al servidor. El acceso al servidor puede ser por medio de un número telefónico gratuito, un código corto o una dirección de correo electrónico, de los cuales todos identifican el servidor para el puerto de enlace del SMS. Un ejemplo de un código corto es 62729, el cual se utiliza como el número telefónico objetivo para sus comandos de mensaje de texto para el servidor de pagos. Un ejemplo de una dirección de correo electrónico es sms@obopay.com, la cual es el correo electrónico objetivo para los comandos de mensaje de texto del SMS enviados al servidor . Para enviar un pago a otra persona o a un comercio que utiliza el método del SMS, el titular de una cuenta puede ingresar la cadena de comandos que se muestra en la tabla C. Tabla C Cada elemento debe tener un espacio entre el mismo y el elemento anterior. En una aplicación, la palabra clave no distingue mayúsculas de minúsculas. El número móvil debe incluir un código de área más un número móvil sin espacios presentes en el número móvil. El titular de una cuenta puede ingresar o no un 1 inicial en el número telefónico. No se requiere que se ingrese un símbolo de dólar con la cantidad, pero se permite. El usuario puede incluir de forma opcional un mensaje con su pago. La MCA codifica el mensaje y envía un mensaje del SMS de servicios de datos en código binario en lugar de texto simple. En un ejemplo alternativo, el PIN se envía en un segundo mensaje por medio de una llamada de voz. Para enviar un pago a otra persona o a un comercio que utiliza la combinación del método de canal de voz más el SMS, el titular de una cuenta puede ingresar la cadena de comandos que muestra en tabla D. Tabla D Una vez recibido el mensaje del SMS, el servidor 4804 llama al teléfono celular asociado con el mensaje del SMS para establecer un canal de voz para adquirir el PIN. El PIN se envía al servidor 4104 a través del canal de comunicación de voz 4815, es decir, la red celular. En modalidades alternativas, el PIN se envía a través de la Internet o POTS . Cuando se realiza una solicitud de pago a un titular de una cuenta mediante el uso ya sea del método del SMS o de la combinación del SMS más el método de voz, estos pueden aceptar o rechazar la solicitud mediante el uso del sistema de mensajería de texto del SMS manual. Del lado del servidor, uno o más centros de datos pueden tener sistemas para procesar las transacciones financieras. Cada uno de los centros de datos puede contener una combinación de tecnología de PBX/ACD/VRU para permitir el procesamiento de múltiples llamadas simultáneas. La tecnología de VRU puede utilizarse para proporcionar soporte de DTMF entrante y saliente programable . La VRU puede conectarse a un sistema J2EE empresarial que representa la lógica de negocio y sistema de registro existentes para las transacciones financieras. Por lo tanto, el sistema J2EE puede integrarse con bancos existentes para el establecimiento de las transacciones. La aplicación del cliente móvil determina favorablemente un método mejor o preferido para enviar el PIN tal como la aplicación SMS (servicios de datos) donde el mensaje del SMS está codificado y convertido a binario (por ejemplo, el mensaje no se transmite en texto simple) o por canal de voz mediante el uso de DTMF para mantener la seguridad. En otras modalidades, el titular de una cuenta puede pronunciar el PIN y ser convertido mediante un módulo de software de reconocimiento de voz que opera en el servidor u otro servidor (no mostrado) dedicado al manejo de llamadas de voz . En una modalidad alterna, el PIN se codifica mediante la aplicación del cliente móvil y se incluye en el mensaje del SMS posterior que se envía al servidor 4804. El servidor 4804 se correlaciona con los mensajes al coincidir el número telefónico y la hora de envío de cada mensaje. Si el PIN se envió en un mensaje que estaba distante en tiempo en comparación con el mensaje del SMS, la transacción puede rechazarse. Si sólo se recibe uno de los dos mensajes, la transacción puede rechazarse. Sin embargo, si se reciben oportunamente tanto el mensaje del SMS con los detalles de la transacción financiera (mínimo de en un teclado) como el código de PIN y se verifican, entonces procede la transacción financiera . En una modalidad alternativa, cuando se encuentra disponible un canal de voz, la aplicación de cliente móvil puede invocar un módulo para codificar el PIN en un formato DTMF. La MCA envía entonces el DTMF al servidor de pagos a lo largo de una conexión del canal de voz establecida mediante la aplicación de cliente móvil. El módulo puede ser una API de Java que genera los tonos adecuados con base en la entrada del teclado. DTMF se refiere a la multifrecuencia de tono dual, la señal que recibe una compañía telefónica cuando se presionan las teclas del teléfono. En aún otra modalidad alternativa, la aplicación de cliente móvil permite que una interfaz de usuario (UI) en la pantalla de visualización del dispositivo móvil guíe al titular de una cuenta para concluir la transacción financiera. En esta modalidad, el titular de una cuenta es guiado a través del proceso de construcción del mensaje de texto del SMS mediante la introducción automática de la palabra clave, cantidad, número telefónico objetivo, contraseña y mensajes, si existe alguno. En aún otra modalidad alternativa, el mensaje del SMS puede incluir la palabra clave, la cantidad, el número telefónico objetivo y la contraseña. Un inconveniente de esta aplicación es que la contraseña puede estar visible para cualquiera que controle el dispositivo móvil. Sin embargo, la presente invención soluciona este problema al enviar un mensaje al titular de una cuenta para que elimine el mensaje enviado de la carpeta de registros del SMS en el teléfono del titular de una cuenta. Estos mensajes también sugieren que el titular de una cuenta desactive los mensajes del SMS salientes y mensaje de conexión al llevar a cabo las transacciones financieras mediante el uso de la característica del SMS en un futuro. En vez de utilizar un mensaje del SMS con texto simple, la presente invención también contempla una modalidad mediante el uso de una API de JAVA descargada al teléfono celular para llevar a acabo las transacciones financieras. Las APIs de JAVA generan pantallas de interfaz del usuario para guiar al usuario en la preparación de la solicitud de transacción. El formato del mensaje es similar al ilustrado en la tabla C o la tabla D. Una vez que el titular de una cuenta completa la solicitud de transacción, el usuario selecciona la opción ENVIAR presentada en la interfaz del usuario. Las APIs de JAVA inician una llamada de voz mediante el uso de la conexión del teléfono celular para acceder un módulo de respuesta de voz interactiva (IVR) o interfaz DTMF en el servidor 4804. Cuando la interfaz DTMF contesta la llamada, las APIs de JAVA transmiten la solicitud de transacción mediante los tonos DTMF. Las APIs de JAVA también pueden utilizar un formato de codificación de manera que para que los tonos DTMF no se descifren con facilidad deberán registrarse subrepticiamente. Cuando la IVR proporciona una respuesta a la solicitud de transacción, la respuesta también se encripta y luego se codifica mediante el uso de DTMF y transmitida a través del canal de voz de regreso a la parte adecuada. Debido al aumento de los aspectos de seguridad de las APIs de JAVA, esta modalidad se compara con el envío de un SMS con texto simple. Por lo tanto, la comunicación puede ser por medio de un canal de voz y tonos DTMF. Esto proporciona un canal de comunicaciones posterior (además del SMS, servicios de datos o aplicación SMS, HTTP y HTTPS) para realizar transacciones. Tener varios canales de comunicación proporciona mayor conflabilidad en el sistema ya que cualquier canal puede utilizarse cuando otros canales no estén disponibles. La Figura 49 muestra un método para asegurar las transacciones financieras basadas en SMS de acuerdo con una modalidad de la presente invención. Más específicamente, para dispositivos móviles como teléfonos celulares con tecnología GSM, instalar un MSA en el teléfono involucra la inserción física de una pequeña tarjeta de circuitos, conocida como generador de número de codificación y transacción o simplemente generador, 4902 para interceptar el tráfico de mensajes del SMS. El generador 4902 comprende un circuito eléctrico insertado en el teléfono conectado electrónicamente a la tarjeta 4903 del SIM. En una modalidad, el generador 4902 es una manga insertada alrededor de la tarjeta 4903 del SIM. En otro caso, el generador 4902 es un espaciador interpuesto entre el módulo 4904 de transmisión del teléfono celular y la tarjeta 4903 del SIM. La tarjeta 4903 del SIM es la tarjeta del Módulo de Identificación del Suscriptor, que es una tarjeta electrónica insertada en el teléfono celular u otro dispositivo móvil que tienen como base GSM, GPRS, o 3G e identifica al suscriptor en la red. Aunque las tarjetas del SIM se utilizan principalmente en los sistemas GSM, los módulos compatibles también se utilizan para los teléfonos UMTS UEs (USIM) e IDEN. La tarjeta 4903 del SIM contiene el número de identificación personal del suscriptor, la información tal como el número telefónico del usuario, el directorio telefónico, mensajes del SMS al igual que otra información relacionada con el suscriptor. El generador 4902 intercepta los mensajes del SMS entrantes en busca de mensajes del servidor 1004 (véase la Figura 48) . Cuando el generador 4902 detecta un mensaje del SMS enviado por el servidor 4804, funciona en la forma de la aplicación del cliente móvil al descodificar el mensaje de servicio de datos del SMS y muestra al titular de una cuenta el mensaje en texto simple. El generador 4902 también intercepta los mensajes del SMS salientes dirigidos al servidor 4804. Nuevamente, el generador 4903 funciona para proporcionar los servicios de la aplicación del cliente móvil al agregar un número de transacción para cada transacción y codifica el mensaje del SMS. Debido a que el generador 4902 contiene un módulo de software incrustado, éste puede enviar el mensaje del SMS como un mensaje del SMS de servicio de datos en lugar de texto simple. Se tiene como objetivo vender el generador 4902 o bien proveerlo como un componente separado no permitiendo que los teléfonos celulares equipados con MCA tomen ventaja de tener la aplicación del cliente móvil en el teléfono celular. En otras modalidades, la tarjeta 4903 del SIM incluye el generador 4902 como un circuito incluido y el proveedor del servicio del teléfono celular se lo proporciona al usuario. La Figura 50 muestra el uso de un servidor de adición del SMS seguro de acuerdo con una modalidad de la presente invención donde el generador 4902 también redirige los mensajes del SMS salientes a un servidor 5011 de adición del SMS seguro en lugar del servidor del SMS estándar del proveedor. Enviar mensajes del SMS que contienen información de transacciones financieras al servidor de adición del SMS seguro reduce la oportunidad del robo de datos, reduce la incidencia de mensajes retrasados o perdidos debido a la sobrecarga en el servidor 5010 del SMS y sobre todo mejora el control sobre el sistema de entrega de mensajes. Con referencia ahora a la figura 51 que muestra un proceso de registro para un nuevo titular de una cuenta de acuerdo con una modalidad de la presente invención. Cuando el destinatario de los fondos todavía no es un titular de una cuenta, una modalidad de la presente invención activa una forma viral de la adquisición del cliente nuevo donde los titulares de una cuenta existente llevan a los titulares de una cuenta nueva con sólo enviar los fondos a los destinatarios sin cuenta. El destinatario sin cuenta recibe un mensaje del SMS que establece que hay fondos disponibles y lo invita a registrar el acceso a los fondos como se indica en 5101. Se proporciona una dirección de página Web. El registro puede realizarse en cualquier banco corresponsal o en línea en la página Web con acceso a Internet como se indica en 5102. El proceso de registro permite que el destinatario abra una cuenta de débito (con el uso de los fondos transferidos) previamente financiada. Este proceso es similar a abrir cualquier otra cuenta bancaria con excepción de que no hay un saldo mínimo en la cuenta así que incluso las personas que no califican para una cuenta de cheques o de ahorros en el banco pueden participar. Una vez registrado, el nuevo titular de una cuenta tendrá una cuenta restringidá "sin tarjeta" como se indica en 5103. En esta etapa (fase I), el nuevo titular de una cuenta tiene la posibilidad de ver los fondos en su cuenta de débito prepagada en tiempo real. Sin embargo, debido ' a regulaciones bancarias, el acceso a los fondos de la cuenta del nuevo titular de una cuenta se restringe y queda pendiente hasta la terminación de un informe de la OFAC como se indica en 5104. "OFAC" se refiere a la Oficina de Control de Activos Extranjeros del Departamento de Tesorería de Estados Unidos que administra y hace cumplir las sanciones comerciales y económicas con base en la política internacional y objetivos de seguridad nacional de Estados Unidos contra países extranjeros objetivo, terroristas, traficantes de drogas internacionales buscados y aquellos involucrados en actividades relacionadas con la proliferación no aprobada de armas de destrucción masiva. Revisar que un titular de una cuenta no esté en las listas de sospechosos es un paso esencial en el programa de conformidad de la OFAC. Si el titular de una cuenta está resaltado como una coincidencia con la lista de la OFAC, se iniciará una investigación para determinar, si de hecho, es una coincidencia real. Hasta entonces, no se liberan los fondos. Los paquetes de software disponibles comercialmente están disponibles para la verificación de conformidad. La verificación de conformidad también puede identificar registros duplicados de clientes, establecer enlaces entre las personas y las corporaciones para consolidación domiciliaria tradicional y no tradicional, crear una clave "Domicilio" multifuncional para dar seguimiento a los cambios con el tiempo y establecer el procesamiento basado en las reglas para resolver duplicados y crear enlaces a domicilios. Una vez que se completó la conformidad de la OFAC (un proceso que por lo regular lleva alrededor de 24 horas) y sin enlaces contrarios identificados, el titular de una cuenta se convierte en una cuenta "sin tarjeta", lo que significa que la institución financiera puede abrir una cuenta de tarjeta de débito previamente financiada y ordenar el envío de la tarjeta de plástico de débito al nuevo titular de una cuenta como se indica en 5105. Sin embargo, en esta etapa (fase II) , el nuevo titular de una cuenta sin tarjeta sólo tendrá disponibilidad limitada de los fondos. Por ejemplo, el nuevo titular de una cuenta puede transferir los fondos a otras personas con el uso del sistema de transacción financiera de la presente invención pero debido a las restricciones adicionales gubernamentales, los fondos no podrán retirarse o transferirse a un comercio. En una etapa final del procesamiento de un sistema de la invención, una cuenta de posesión común mantiene los fondos transferidos si el destinatario no es aún un titular de una cuenta. Una entrada del libro mayor identifica (véase la figura 39) los fondos atribuidos a cada número telefónico. El destinatario puede transferir estos fondos a otras cuentas si es que están registrados en una cuenta. Debido a que no se puede obligar a las personas a registrarse en una cuenta, es posible que el destinatario rechace productivamente los fondos o simplemente no responda. En tales casos, los fondos se devuelven al titular de una cuenta que inició la transacción después que expiró la ventana de transacción (la ventana de transacción puede ser de determinada duración, por ejemplo, 30 días o 60 días) o de inmediato con base en un rechazo preventivo. El servidor de la transacción puede enviar mensajes recordatorios periódicos tanto al emisor de los fondos como al destinatario. En otros casos, el emisor de los fondos puede detener el pago si el destinatario no se ha registrado para tener acceso a los fondos. Esta característica es importante donde las partes acuerdan cancelar la transferencia electrónica y concluyen la transacción de otra manera, por ejemplo, con efectivo. Si los fondos para todos titulares de una cuenta se mantienen en la cuenta común, entonces cuando una cuenta nueva empieza a "funcionar" el nuevo titular de una cuenta tendrá acceso completo e inmediato a los fondos. Si los fondos se mantienen en cuentas separadas para cada titular de una cuenta, entonces los fondos se transfieren de la cuenta de posesión a la cuenta del titular de una cuenta cuando la cuenta empieza a funcionar. Puede haber algunos retrasos para que los fondos aparezcan en la cuenta individual. Una vez que se abre la cuenta y concluyeron las verificaciones de conformidad, la institución financiera solicitará el envío de la tarjeta de plástico de débito a la dirección del registro para el nuevo titular de una cuenta. Cuando la tarjeta llega, el titular de una cuenta llama a un número gratuito para confirmar la recepción. La llamada telefónica de confirmación también indica que la dirección del titular de una cuenta también es correcta. Durante esta llamada, el titular de una cuenta también seleccionará su PIN. El PIN está enlazado a la tarjeta y al número telefónico del teléfono móvil del titular de una cuenta. Además, el número de cuenta en la tarjeta de plástico de débito y el teléfono están bloqueados. La tarjeta puede utilizarse para retirar efectivo de la cuenta o depositar efectivo en la cuenta con el uso de un cajero automático bancario. También puede utilizarse en cualquier comercio donde el dispositivo POS acepte tarjetas de crédito o bancarias . En esta etapa (fase III), la cuenta del titular de una cuenta está totalmente activada para su uso. Con referencia ahora a la Figura 52 donde se ilustra un sistema 5200 de detección de fraude estratificado como parte del procesador 3630 de transacción. El primer nivel del sistema 5200 estratificado incluye un motor basado en normativas y componentes 5201 seleccionados por el usuario. El segundo nivel del sistema 5202 estratificado incluye componentes de propiedad que no son accesibles o visibles para los titulares de una cuenta. Los componentes seleccionado por el usuario incluyen, por ejemplo, la capacidad del titular de una cuenta de personalizar la seguridad de su propia cuenta. Los titulares de una cuenta pueden enlazar varios números de teléfonos celulares para miembros de la familia que estén autorizados a acceder a la cuenta prepagada. Para cada número telefónico designado, el titular de una cuenta puede especificar los límites máximos de gastos diario, semanales o mensuales. El titular de una cuenta puede excluir ciertos comercios, números de cuenta o números telefónicos al crear una "lista negra" personal para las partes excluidas designadas . Una aplicación específica de la lista negra permite que el titular de una cuenta designe exclusiones de carácter general tales como bloquear transferencia de fondos a cualquier teléfono que tenga un código de área en particular o a cualquier número "900" o número internacional. El titular de una cuenta puede crear una lista negra personal por separado para un usuario autorizado. Esta característica es particularmente útil para controlar el gasto inadecuado de teléfonos celulares equipados para niños. Cualquier número de números de cuentas puede incluirse en la lista negra. Por el contrario, el titular de una cuenta también puede especificar ciertos comercios o números telefónicos que puedan incluirse en una transacción financiera que involucre a uno de los usuarios autorizados. El resto de los comercios y números telefónicos pueden considerarse de forma opcional colocarse en la lista negra. Nuevamente, esta característica es particularmente útil para controlar el gasto de los niños al permitir compras para transporte, alimentos, y artículos escolares pero no para revistas u otras novedades. Además, para especificar la lista negra y la lista blanca personal, el titular de una cuenta también puede preautorizar las compras en cada comercio que aparezca en la lista blanca mientras que establece un límite por transacción en los otros números de la lista blanca. El titular de una cuenta puede personalizar el mecanismo de detección de fraudes basado en reglas que también se aplica en el primer nivel. El titular de una cuenta también puede especificar la cantidad máxima para cada transacción y el número de transacciones que pueden procesarse en el teléfono celular en un periodo seleccionado. El titular de una cuenta también puede especificar la cantidad máxima de fondos que se depositarán y retendrán en la cuenta de débito prepagada. El procesador 3630 de transacción lleva los fondos excedentes a otra cuenta designada, como la cuenta de ahorros personal, diariamente . El segundo nivel del sistema 5202 estratificado incluye componentes de propiedad que no son accesibles o visibles para los titulares de una cuenta. Por ejemplo, el segundo nivel 5202 incluye un límite de gasto máximo basado en los promedios del historial, verificación geográfica, el número histórico de las transacciones diarias. Otros mecanismos de control (velocidad) de frecuencia de transacción y detección de fraudes basados en reglas también se aplican aquí. Un motor (no mostrado) de reglas de riesgo y fraude controla los riesgos al aplicar límites de gasto y determinar la aceptabilidad de las transacciones solicitadas desde una perspectiva de riesgo. Tales sistemas de detección de fraudes son conocidos y por lo general se utilizan para monitorear fraudes cuando se utilizan tarjetas de crédito. La información recopilada para cada transacción financiera puede extraerse para su uso mediante aplicaciones de valor agregado del consumidor y del comercio, mediante aplicaciones de monitoreo de negocios, mediante aplicaciones de operaciones del sistema y también aplicaciones de monitoreo de seguridad.
Con referencia ahora a la Figura 53, que muestra una modalidad de la cuenta común para reducir la ACH y los cargos de intercambio de la tarjeta de crédito. En vez de mantener una cuenta de débito prepagada por separado para cada titular de una cuenta, la presente modalidad utiliza una cuenta 5300 de débito prepagada común. Cuando las transacciones se presentan entre titulares de una cuenta como se indica en 5301, el dinero se retendrá en la cuenta 5300 común pero se moverá desde la cuenta del titular de una cuenta a la otra cuenta del titular de una cuenta. La transferencia es inmediata y no incurre en alguna cuota de transacción para el operador del sistema. Por esta razón, al titular de una cuenta se le puede cobrar poco o nada por concepto de cuota de transacción. En ocasiones, los titulares de una cuenta pueden agregar fondos a la cuenta común como se indica en 5302. Tales fondos pueden depositarse en un comercio corresponsal que haya aceptado fondos de los titulares de una cuenta y que posteriormente se depositan en la cuenta común. Por otro lado, el titular de una cuenta puede utilizar la tarjeta de plástico de débito en el cajero automático o bien depositar efectivo o cheques, en Internet al realizar una transferencia de cuenta por teléfono o automáticamente como se especifica en la página del perfil del usuario asociada con cada cuenta. En otras ocasiones, los titulares de una cuenta pueden transferir fondos fuera de la cuenta común como se indica en 5303. El nuevo titular de una cuenta puede retirar tales fondos cuando no deseen retener un saldo en su cuenta de débito prepagada. En esta modalidad, el operador del sistema es un agregador de cuenta y convierte el sistema de registros desde el punto de vista de riesgo y control de riesgo. El operador del sistema también es responsable de la realización de la verificación de conformidad de la OFAC. El operador del sistema puede ser un banco, una institución financiera o puede subcontratar la administración de la cuenta común a otro banco. En otra modalidad, la comunicación de campo cercano se utiliza para comunicarse entre dispositivos móviles para concluir transacciones financieras mediante el uso de la infraestructura de la presente invención. En aún otra modalidad, la comunicación de campo cercano se utiliza para comunicarse desde un dispositivo móvil a una terminal POS para concluir las transacciones financieras. Seguridad y Prevención de Fraudes La seguridad y la prevención de fraudes son aspectos importantes para la industria de los pagos y representan una fuente continua de problemas. La infraestructura de transferencia de pagos móviles y el método de operación, de acuerdo con la presente invención, son herramientas efectivas para controlar estos problemas. Específicamente, el uso del dispositivo móvil para llevar a cabo transacciones financieras permite una transacción en tiempo real que utilice fondos disponibles garantizados. La parte receptora puede verificar la validez de la entidad que posee los fondos y verificar que la cuenta tenga saldo suficiente para concluir la transacción. Afortunadamente, la información de la cuenta (número de tarjeta de crédito, número de tarjeta de débito u otra cuenta en la institución financiera) no es necesaria para concluir la transacción. En el lado del envío de la transacción, la parte emisora utiliza un código de PIN para identificar a la persona con el teléfono. Esta autenticación proporciona un alto nivel de seguridad ya que el servidor de pagos puede identificar el dispositivo móvil mediante el uso del identificador de llamadas y la persona mediante el uso del dispositivo móvil se identifica a través de un PIN. Favorablemente, se transfirió de forma segura pero no se almacenó en el dispositivo móvil de forma visible. Además, la transacción puede identificarse mediante un número de secuencia único que se determina a través de la aplicación del cliente móvil y se envía como parte de la cadena de comandos al servidor de pagos. En el servidor de pagos, se mantiene el historial de los números de secuencia utilizados, de manera que las transacciones con números de secuencia previamente utilizados no se procesarán. Después de cada transacción y antes de la siguiente transacción, el dispositivo móvil actualiza el número de secuencia con un nuevo número de secuencia. Pór ejemplo, la nueva secuencia puede ser el número de secuencia anterior incrementada a 1. En una aplicación alternativa, los números de secuencia pueden ser cualquier número, que incluye un número aleatorio. Además, un algoritmo puede utilizarse para crear una secuencia predciable de números. Esta secuencia de números puede generarse mediante el uso de un valor germinal creado desde una función unilateral sobre la información como el número telefónico, hora del día u otro. Al momento de la inicialización, al servidor de pagos se le proporciona el número de secuencia inicial y conoce el algoritmo y lo ve, de manera que pueda predecir cuál número de secuencia es el que sigue. Si el número de secuencia no es correcto, entonces el servidor rechazará la transacción. Esto puede evitar ataques de intercepción. El número de secuencia ayuda a evitar fraudes y también evita el duplicado de transacciones financieras, que puede darse debido al protocolo de comunicaciones donde se envía la información de transacción varias veces. Esto es similar a la situación donde una máquina de fax trata de enviar nuevamente un fax en el caso de no recibir el reconocimiento adecuado.
Si se utilizan mensajes del SMS para completar una transacción, el PIN de autorización es preferentemente un código verbal pronunciado en el dispositivo móvil y transmitido al servidor de pagos para su autenticación mediante el uso del software de reconocimiento de voz. Las transacciones de comercios están estructuradas preferentemente para utilizar una autorización activa donde el teléfono del titular de una cuenta suena con un mensaje para aprobar la cantidad en dólares transferida. Las tarjetas de crédito y cheques no pueden funcionar con este nivel de interacción . Además, la seguridad se proporciona a través del uso del código del PIN para activar la aplicación del cliente móvil. En esta modalidad, el código del PIN se presenta en una primera instancia para abrir la aplicación del cliente móvil e iniciar su operación. El mismo código del PIN o, preferentemente, un código de PIN separado se utiliza para una autorización de transacción a través de la red. Este proceso de código del PIN dual no está disponible en tarjetas de crédito, cheques o incluso tarjetas inteligentes. Cuando se detecta un fraude, el dispositivo móvil puede deshabilitarse y evitar el uso de la red para acceder a la cuenta. En general los dispositivos móviles tienen diversos atributos clave que facilitan las futuras medidas de protección de seguridad. La mayoría, si no es que todos estos atributos no existen en las tarjetas. Específicamente, los dispositivos móviles incluyen una fuente de poder independiente para poner en funcionamiento los dispositivos físicos tales como chips con propósitos especiales y un caso seguro o revestimiento que puede alojar dispositivos como chips inteligentes. Los dispositivos móviles permiten la comunicación de voz y datos a través de la red celular o a través de Internet de manera que la verificación de voz y el PIN puedan utilizarse en conjunto o separados para identificar a un titular de una cuenta. Las transacciones pueden iniciarse y verificarse mediante el uso de la tecnología de reconocimiento de voz y los datos ingresados mediante el teclado. En otras modalidades, la comunicación visual se proporciona a través del uso de una cámara. Otro nivel de seguridad se proporciona por el uso de la tecnología de ubicación como un sistema de posicionamiento global o GPS puede determinar la ubicación física del dispositivo. De esta forma, si el titular de una cuenta utiliza el servicio de pago en una ubicación atípica (como cuando está de vacaciones) , el usuario de la cuenta puede autenticarse al solicitarle que reingrese el PIN. Otra ventaja de la tecnología de ubicación es que los servicios realizados disponibles para el titular de una cuenta pueden ajustarse según el lugar en que estén ubicados. Por ejemplo, los descuentos o promociones especiales pueden enviarse junto con la confirmación para una transacción cuando la ubicación del titular de una cuenta coincida con la del comercio. En otras modalidades, si el titular de una cuenta se encuentra en el área de un comercio que ofrece un descuento especial, se envía un mensaje promocional al titular de una cuenta si se autoriza en su perfil mantenido por el servidor de pago. La Figura 54 muestra un mecanismo y método para evitar fraudes y múltiples duplicados de solicitudes de transacción de acuerdo con una modalidad de la presente invención. El mecanismo de prevención de fraudes incluye el almacenamiento de un número de secuencia en un registro de cada teléfono celular y en el servidor de pagos. Por lo regular, como se indica en 5401, el número de secuencia se inicia cuando se activa el pago del servicio de pagos del teléfono celular. Al mismo tiempo, el mismo número de secuencia se inicia en el servidor de pagos y se almacena en una base de datos junto con otra información del titular de una cuenta. Una vez recibida la solicitud de transacción, como se indica en 5402, el servidor de pago recibe un número de secuencia desde el teléfono celular y lo compara con el número de secuencia en el servidor de pagos . Si los números de secuencia coinciden, como se indica en 5403, entonces el servidor de pagos autoriza que continúe la transacción. Entonces los números de secuencia tanto en el teléfono celular como en el servidor de pagos se actualizan a un número de secuencia nuevo. Este mecanismo de seguridad se utiliza para evitar ataques de intercepción o teléfonos clonados. Entonces al usuario se le pide que ingrese el PIN como se indica en 5405. Al acoplar el uso del número de secuencia con el PIN o el número del teléfono celular, habrá un bloqueo de seguridad de tres niveles que autentique el PIN del usuario, el número telefónico (detectado por el ID de llamadas y enlazado a una cuenta especifica) y el número de secuencia para validar la transacción (evita que un intruso intente capturar una transacción y entonces reenvíe las solicitudes duplicadas para una transacción) . El número de secuencia también se utiliza para diferenciar intentos múltiples del sistema del SMS de entregar un mensaje de transacción desde transacciones múltiples válidas. Si los números de secuencia no coinciden, el servidor de pagos rechaza la solicitud de transacción, como se indica en 5406, y se activan las medidas de prevención de fraudes, como se indica en 5407. Para ejemplificarlo, cuando los números de secuencia no coinciden, la cuenta podría congelarse hasta que el representante de atención al cliente determine la causa de los números de secuencia que no coinciden. Esto puede requerir de una llamada telefónica al titular de una cuenta para verificar si aún tiene el teléfono y si autorizó el intento de transacción.
La Figura 55 muestra otra modalidad del mecanismo y el método para evitar fraudes y múltiples duplicados de solicitudes de transacción de acuerdo con una modalidad de la presente invención. En 5510 un usuario (por ejemplo el titular de una cuenta) inicia una transacción financiera en un dispositivo de telefonía móvil (por ejemplo, un teléfono móvil) . En 5511, el usuario transmite un PIN al momento de iniciar la transacción (Opción A) . Por otro lado, como se indica en 5512, el usuario no transmite un PIN al momento de iniciar la transacción (Opción B) . En 5513, el servidor de pagos recibe la solicitud desde el dispositivo móvil para iniciar la transacción financiera. El servidor verifica el número del identificador de llamadas (ID de llamadas) transmitido por el dispositivo móvil para ver si el dispositivo móvil es un usuario autorizado del sistema en 5514. Si el ID de llamadas no está activado en el teléfono, deshabilite la transacción como se indica en 5915. Se mostrará un mensaje de error para indicar que deshabilitó la transacción debido a que el ID de llamadas no está activado. El usuario puede volver a intentar la solicitud después de activar el ID de llamadas. Si selecciona la opción B, entonces el servidor deberá enviar una solicitud al dispositivo móvil donde se solicitará que el usuario ingrese el PIN, como se indica en 5516. Este PIN puede transmitirse mediante el teclado numérico del dispositivo móvil o mediante la voz (por ejemplo, a una unidad de respuesta de voz interactiva (IVR) del servidor) . Una vez validado el ID de Llamadas, el servidor verificará el PIN transmitido desde el dispositivo móvil contra el PIN grabado en el sistema para verificar que el PIN coincida con el número telefónico esperado como se indica en 5517. Si y sólo si el PIN coincide, el servidor permitirá que proceda la transacción. Si el PIN no coincide, entonces se deshabilitará la transacción, como se indica en 5518. Entonces el servidor recibe un número de transacción (también conocido como un número de secuencia) para la transacción financiera desde el dispositivo móvil. El número de transacción puede enviarse al momento de iniciar la transacción o después como parte de la transferencia de información entre el dispositivo móvil y el servidor. El número de transacción incluye claves idempotencia que hacen que el número sea único. El servidor también verifica el número de la presenta transacción del dispositivo móvil contra una lista de números de transacción previamente utilizados como se indica en 5519. Esta lista se almacena en una base de datos asociada con el servidor. Si el presente número de secuencia coincide con cualquier número de secuencia previamente utilizado, entonces no se autenticará al usuario y se deshabilitará la transacción, como se indica en 5520. Este paso de verificación es útil para evitar que múltiples copias de un mensaje se manejen como un mensaje nuevo e independiente. También evita ataques de intrusos cuando un intruso intente interceptar un mensaje y trate de reenviar una transacción anterior. En algunas modalidades, el servidor también verifica el número de transacción cuando se recibe del dispositivo móvil contra el número de transacción esperado almacenado en el servidor como se indica en 5521. Si los números de secuencia no coinciden, entonces no se autenticará al usuario y se deshabilitará la transacción como se indica en 5520. Si el número de secuencia del teléfono coincide con el número de secuencia almacenado en el servidor o no es un número previamente utilizado, entonces sí se autenticará al usuario y se permitirá continuar con la transacción financiera. En algunas modalidades, el servidor sólo realiza la verificación del número de transacción como se indica en 5519. En otras modalidades, el servidor sólo realiza la verificación del número de transacción como se indica en 5521. En otras modalidades, el servidor sólo realiza la verificación del número de transacción como se indica en 5519 y en 5521. Mientras que el servidor determine que el número de secuencia del teléfono no se ha utilizado antes o es el número de secuencia esperado, o ambos, entonces se permitirá la transacción. El número de secuencia también puede utilizarse como un identificador de transacción única. El paso 5521 se conecta al paso 5622 mediante un enlace 5607. El servidor también almacena el número de secuencia anterior almacenado o bien indicado en el servidor como un número de secuencia que ya se utilizó, como se indica en 5622. Estos números de secuencia utilizados previamente pueden almacenarse en una base de datos en el servidor. Si el servidor mantiene un número de secuencia esperado, el número de secuencia en el teléfono y el servidor se incrementa en preparación para la siguiente transacción como se indica en 5623. Entonces el servidor procede con la terminación de la transacción financiera, como se indica en 5624. Una técnica de autenticación de tres factores autentica con base en los siguientes factores: (1) Verificar el ID de llamadas (2) Verificar el PIN o número de identificación personal (3) Verificar el número de transacción El método de validación anterior presenta algunos pasos de autenticación en un orden específico. Una aplicación de la invención realiza los pasos en el orden proporcionado. Sin embargo, en otras aplicaciones de la invención, puede haber otros pasos incluidos u otros omitidos, o bien el orden de los pasos puede ser diferente al orden de arriba. Por ejemplo, el ID de llamadas, el PIN y la transacción pueden ordenarse de forma independiente. Por lo tanto, en una modalidad, se puede verificar el PIN antes que el ID de llamadas. En otra modalidad, se puede verificar el número de transacción antes que el PIN. Además, algunos de los pasos anteriores pueden realizarse al mismo tiempo en diferentes procesadores o núcleos de procesadores en una aplicación de procesamiento paralelo. En una aplicación, un sistema de la invención puede omitir una o más técnicas de autenticación listadas arriba. Por ejemplo, puede ser que el ID de llamadas no se autentique, de manera que se utilice un método de autenticación de dos factores. Un modelo tradicional para la autenticación de dos factores se basa en (1) lo que se tiene y (2) lo que se sabe. Un primer factor es algo que el usuario tiene, por ejemplo un teléfono móvil, un asistente digital personal, un teléfono inteligente o una tarjeta de plástico. Un segundo factor es algo que el usuario conoce, por ejemplo, un número de identificación personal (PIN), nombre de soltera de la madre, dirección, número de seguro social, número de licencia de conductor o el número telefónico del hogar. Ya sea que se utilice la autenticación de dos factores o la de tres factores, dependerá del canal de comunicación utilizado por el dispositivo móvil y el servidor. Por ejemplo, cuando se utilizan los SMS o servicios de datos del SMS, el ID de llamadas está disponible y entonces se utiliza la autenticación de tres factores. Sin embargo, cuando se utiliza HTTP o HTTPS, por lo regular el ID de llamadas no está disponible y entonces no se utiliza la autenticación de tres factores. Puede haber factores adicionales utilizados para autenticar un titular de una cuenta o usuario, de manera que la técnica puede tener más de tres factores. Además, los componentes del software del lado del servidor y del lado del cliente pueden manejar el tercer factor de autenticación. Flujo de Autenticación Ejemplar de Tres Factores (1) Inicia una transacción financiera en un dispositivo de telefonía móvil (por ejemplo, teléfono móvil) (2a) (Opción A) Transmite un PIN al mismo tiempo que se realiza el paso 1. (2b) (Opción B) No transmite un PIN al mismo tiempo que se realiza el paso 1. (3) En un servidor, recibe la solicitud desde el dispositivo móvil para iniciar la transacción financiera. (4) En el servidor, verifique la identificación de llamadas (ID de llamadas) transmitida por el dispositivo móvil para ver si el dispositivo móvil es un usuario autorizado del sistema. Si el ID de llamadas no está activado en el teléfono, deshabilite la transacción. Se mostrará un mensaje de error que indica que se deshabilitó la transacción porque el ID de llamadas no estaba activado. El usuario puede volver a intentar la solicitud después de activar el ID de llamadas . (5) Si elige la opción A, una vez validado el ID de llamadas, continúe con el paso 6. Si elige la opción B, una vez validado el ID de llamadas, el servidor enviará una solicitud al dispositivo móvil para que el usuario ingrese un PIN. Este PIN puede transmitirse mediante el teclado numérico del dispositivo móvil o mediante la voz (por ejemplo, a una unidad de respuesta de voz interactiva (IVR) del servidor) . (6) Si se validó el ID de llamadas, entonces verifique el PIN transmitido desde el dispositivo móvil contra el PIN registrado en el sistema. Si el PIN coincide, vaya al paso 7. 7) Recibir un número de transacción o número de secuencia para la transacción financiera del dispositivo móvil. Este número de transacción puede enviarse al momento en que se presenta la etapa 1, o puede enviarse posteriormente en la transferencia de información entre el dispositivo móvil y el servidor. Proceda a 8a (opción C) u 8b (opción D) siguiente. (8a) (Opción C) Comprobar el número de secuencia a partir del dispositivo móvil con un número de secuencia almacenado en el servidor. Si los números de secuencia no concuerdan, el usuario no es autenticado y la transacción no será permitida. (8b) (Opción D) Comprobar el número de secuencia presente a partir del dispositivo móvil con una lista o base de datos del número de secuencia previo ya utilizado el cual se almacena en el servidor. Si el número de secuencia presente concuerda cualquiera de los números de secuencia previamente utilizados, el usuario no es autenticado y la transacción no será permitida. (9) Si el número de secuencia del teléfono concuerda con el número de secuencia almacenado en el servidor (para la Opción C) o es un número previamente no utilizado (para la Opción D) , el usuario es autenticado y la transacción financiera se dejará proceder. Para la opción D, en otras palabras, siempre que el servidor determina que el número de secuencia del teléfono no se ha utilizado antes, la transacción será permitida. (10a) Si elige la opción C, se incrementan el número de secuencia en el teléfono y servidor en preparación para la siguiente transacción. (10b) Si elige la opción D, se incrementa el número de secuencia en el teléfono al siguiente número de secuencia. El número de secuencia previo se almacena o de otra forma se indica en el servidor como un número de secuencia que se ha utilizado. Estos números de secuencia previamente utilizados, pueden almacenarse en una base de datos en el servidor. Varias aplicaciones de Transacción o Autenticación de Números de Secuencia. (1) Con el inicio del servicio, utilizar un valor de número de transacción inicial almacenado en el dispositivo móvil y el servidor. El número de transacción inicial puede ser (la) o (Ib) . (la) El número de transacción inicial puede ser un número entero, tal como 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, u otros números . (Ib) El número de transacción inicial puede ser un número aleatorio, tal como el generado por un generador de números pseudoaleatorios y un valor germinal dado. Este valor germinal puede ser un código hash basado en una propiedad o característica del dispositivo. Por ejemplo, el valor germinal puede basarse en el número telefónico, el número de serie del dispositivo, la propiedad o valor almacenado en un circuito integrado del dispositivo, o el valor del reloj de tiempo real . (2) Cuando el usuario utiliza una aplicación donde la autenticación del número de transacción se utiliza, el valor de número de transacción será cambiado del valor de número de transacción inicial o previo al siguiente en secuencia. La secuencia puede ser cualquiera en serie, matemática, pseudoaleatoria u otra. La secuencia puede ser finita, infinita o serie repetitiva. Si es una serie repetitiva, el número de los números de transacción en la serie antes de que se repita puede basarse en un número de bits binarios utilizados para representar el número de transacción. (2a) Por ejemplo, la secuencia puede ser aritmética o geométrica. Para un ejemplo de una serie aritmética, un número de transacción puede ser incrementado por 1 o cualquier otro valor (o disminuido por 1 o cualquier otro valor) para obtener el siguiente número de transacción en secuencia. Si el número de transacción se representa utilizando ocho bits binarios, la secuencia se repetirá cada 256 números. Si el número de transacción se representa utilizando dieciséis bits binarios, la secuencia se repetirá cada 65536 números. Por lo tanto, entre más números de bits se utilicen mayor será la secuencia. (2b) La secuencia puede ser generada en forma pseudoaleatoria por un generador de números pseudoaleatorios . La secuencia de números pseudoaleatorios se basará en el valor germinal de inicio. El número pseudoaleatorio puede representarse utilizando un número de punto flotante. El número de punto flotante puede almacenarse utilizando una representación binaria de punto flotante. (3) Después de cada transacción, el dispositivo móvil y el servidor (donde el número de transacción del dispositivo móvil será autenticado nuevamente) ambos generan el siguiente número de transacción en secuencia de acuerdo con el mismo algoritmo. Si el dispositivo móvil utiliza una serie aritmética, el servidor utilizará una serie aritmética. Si el dispositivo móvil utiliza una serie de número pseudoaleatorio, el servidor utilizará una serie de número pseudoaleatorio . El mismo valor germinal utilizado por el dispositivo móvil se utilizará por el servidor. Dependiendo de la aplicación particular, este valor germinal puede transmitirse desde el dispositivo hasta el servidor, o viceversa, o determinarse en forma independiente. (4) El dispositivo móvil y el servidor almacenarán cada uno números de transacción respectivos. El número de transacción en el dispositivo móvil puede referirse como un número de transacción de dispositivo móvil. El número de transacción en el servidor puede referirse como el número de transacción del servidor. (5) Cuando se presenta una transacción, el servidor comparará en su número de transacción almacenado con el almacenado en el dispositivo móvil. Si los números de transacción concuerdan, se presenta una autenticación y la transacción se dejará proceder. De otra forma, la transacción no será permitida. (6) Después de que se permita una transacción, los números de transacción serán adelantados al siguiente en secuencia en el dispositivo móvil y el servidor. Estas técnicas pueden utilizar un número de transacción para autenticar al dispositivo móvil ayudan a evitar fraude, transacciones duplicadas, y otras circunstancias indeseables. Existen muchas variaciones de las aplicaciones específicas de la autenticación del número de transacción, y cualquiera de estas variaciones pueden utilizarse, y en cualquier combinación con los procedimientos antes descritos. Por ejemplo, en lugar de comprobar si un número de transacción de un dispositivo móvil concuerda con un número correspondiente en el servidor, la técnica de autenticación puede comprobar si el número de transacción (a) no concuerda con un número correspondiente en el servidor o (b) no concuerda con un número previamente utilizado en el servidor (como se describe previamente en esta aplicación) . La Figura 57 muestra un ejemplo de la autenticación del número de secuencia. Existe un dispositivo de cómputo del consumidor (por ejemplo, dispositivo de telefonía, teléfono inteligente, o computadora portátil) , y una aplicación empresarial . En el dispositivo de cómputo del consumidor se encuentra un componente de software de cliente de autenticación de número de secuencia (SNA) . La aplicación empresarial incluye un componente de software de servidor de autenticación de número de secuencia. Estos componentes manejan 'la autenticación cuando el dispositivo del consumidor envía una transacción al servidor. Esta autenticación puede ser el tercer factor en un procedimiento de autenticación de tres factores. En una aplicación particular, el componente de autenticación de número de secuencia de cliente está al tanto de un contador codificado que inicia en un valor no nulo aleatorio el cual se establece durante la instalación del lado de cliente. Con cada transacción, el componente de SNA de cliente incrementa el valor del contador de cliente por un valor no nulo aleatorio. El componente de autenticación de número de secuencia del servidor está al tanto de los valores de contador "último recibido" para clientes basados en el identificador de cliente. Si el valor de contador de cliente entrante es mayor que el último valor recibido, entonces se acepta la transacción. El valor de contador se almacena y la transacción se pone en práctica. De otra forma, si el valor de contador no es mayor que el último valor recibido, la transacción es inválida y la cuenta puede suspenderse.. Esta aplicación sólo es una de muchas variaciones posibles que existen de autenticación de número de secuencia. La Figura 58 muestra otro ejemplo de la autenticación de número de secuencia. En esta técnica especifica, dependiendo del cliente del cual se está originando la transacción, un tipo diferente del número de secuencia se utiliza y se envía al servidor de servicio de pago móvil. Por ejemplo, un cliente solvente o un cliente insolvente puede utilizarse. Ejemplos de un cliente solvente incluyen una aplicación o programa que se ejecuta en un teléfono móvil, teléfono inteligente, computadora portátil, u otro dispositivo electrónico. La aplicación o parte de una aplicación puede escribirse en un lenguaje de programación tal como J2ME ; BREW o . ET CF. La aplicación puede ser una aplicación específica para pagos móviles. Un ejemplo de tal programa y pantalla de usuario anexos, se describe en cualquier lugar en esta solicitud. O la funcionalidad puede ser parte de otro programa, tal como un programa de mensajería instantánea, programa de chat de Internet en tiempo real, programa de transferencia de archivos, programa de reproducción de música, programa reproductor de video, programa de participación de archivos, programa de interfaz de servicio de pago de recibos, o programa de división de recibos. Por ejemplo, cuando utiliza un programa de mensajería instantánea (por ejemplo, AOL Instant Messenger (AIM) , ICQ, Yahhoo! Messenger, Microsoft Windows Live Messenger, Google Talk o Skype) , existirá una opción para enviar a otro usuario un pago. La opción de enviar un pago puede ser accesible utilizando un clic derecho de un ratón o a través de un menú de despliegue o de cascada. El receptor puede ser identificado a través del nombre- de usuario, nombre del miembro, número de teléfono, número de miembro, número de cuenta, u otro identificador . El pago será procesado a través del servidor de servicio de pago móvil. Ejemplos de un cliente insolvente incluyen una aplicación de explorador Web, o teléfono u otro dispositivo con mensajes de texto del SMS, teléfono u otro dispositivo con un explorador de WAP, o programa de emulación de terminal . En una aplicación especifica de la invención cuando se utiliza un cliente solvente, un número de secuencia almacenado será almacenado persistentemente en un contador en el cliente solvente. Este número de secuencia almacenado puede permitir que cualquier secuencia arbitraria tal como un número entero secuencial o contador binario (por ejemplo, 1, 2, 3, 4, etc.), una secuencia aleatoria basada en un valor o secuencia germinal de inicio conocido, de acuerdo con una ecuación, fórmula o regla. El número de secuencia almacenado puede almacenarse por ejemplo, en una memoria flash, memoria eléctricamente borrable (??2) , memoria no volátil, memoria con batería, disco duro, u otra memoria. Con cada transacción, una clave de idempotencia (llamada número de secuencia en otras aplicaciones de la invención) se envía al sistema de pago móvil. Para un cliente solvente, la clave incluirá una combinación de ID de miembro y el número de secuencia almacenado. Este número de secuencia almacenado puede ser el siguiente número de secuencia almacenado no utilizado. Cuando el sistema de pago móvil recibe la clave de idempotencia del cliente solvente, la transacción se almacena en una tabla de transacciones junto con esta clave de idempotencia. En la tabla de transacciones, cada clave de idempotencia se espera que será única. De este modo, si el sistema de pago móvil recibe otra transacción con una clave de idempotencia previamente recibida, la transacción puede dejarse a un lado puesto que probablemente es una transacción duplicada o un problema de seguridad. En una aplicación especifica, la cuenta del usuario puede etiquetarse con una violación de seguridad potencial para que se investigue a la persona. Si un usuario tiene un número de tales violaciones o un número de tales violaciones durante un período particular de tiempo, entonces la cuenta puede suspenderse automáticamente para investigación pendiente. En una aplicación específica de la invención, cuando se utiliza un cliente insolvente, la clave de idempotencia incluirá la ID del miembro, la ID de objetivo, la cantidad de transacción, y el tiempo (o marca de tiempo) . El sistema de pago móvil recibirá esta clave de idempotencia y manejará similarmente la situación cuando reciba una clave de idempotencia de cliente solvente. Por lo tanto, un sistema de pago móvil de la invención puede funcionar con diferentes tipos de clientes y cada tipo de cliente puede enviar diferentes tipos de claves de idempotencia o números de secuencia. Esta modalidad tiene dos diferentes tipos de claves de idempotencia, pero en otras modalidades, puede existir cualquier número de tipos de claves de idempotencia o número de secuencia. Por ejemplo, pueden existir tres, cuatro, cinco, seis, siete, ocho o más tipos de claves. Se utiliza una técnica para asegurar la autenticidad de una fuente de transmisión inalámbrica la cual está solicitando que se realice una transacción por un sistema. La transacción puede ser una transferencia de dinero de persona a persona u otra transacción de intercambio de valores. Esta fuente de transmisión inalámbrica puede ser un teléfono móvil u otro dispositivo similar. La fuente de transmisión inalámbrica transmite una clave con la solicitud de transacción. El sistema determinará la autenticidad de la transmisión basándose en la clave transmitida. Si la transmisión se determina que es auténtica, la transacción será puesta en practica. Varios procedimientos para determinar autenticidad se discuten. La técnica también puede utilizarse para evitar proceder sobre transmisiones duplicadas . En una modalidad, la invención es un método que incluye recibir una solicitud electrónica de una transacción de intercambio de valores, transmitida inalámbricamente desde un dispositivo de usuario; recibir con la solicitud electrónica una clave transmitida asociada con la solicitud electrónica; y determinar si la clave transmitida existe en una tabla de transacciones. Si la clave transmitida no está en la tabla de transacciones, la transmisión se considerará autentica. Por lo tanto, la clave transmitida y la transacción de intercambio de valores se ingresan en la tabla de transacciones, y la transacción de intercambio de valores se procesa por el sistema. Si la clave transmitida está en la tabla de transacciones, la transmisión no se considera auténtica (o puede ser una transmisión duplicada) . Por lo tanto, la transacción de intercambio de valores no se procede por el sistema. El dispositivo de usuario puede ser un teléfono móvil. En una aplicación, la clave transmitida incluye un identificador electrónico que identifica a un usuario que solicitó la transacción de intercambio de valores y número de secuencia. El número de secuencia se almacena en el dispositivo de usuario y se adelanta un siguiente número en secuencia antes de que se transmita una siguiente transacción de intercambio de valores por el dispositivo de usuario.
Entonces cada transmisión válida debe tener un número de secuencia diferente o único. El número de secuencia puede almacenarse en una memoria no volátil o de otra forma persistente en el dispositivo de usuario, tal como flash, memoria eléctricamente borrable (EA2) , almacén magnético, o memoria con batería. Esto asegurará que cada transmisión tendrá un valor único. La clave transmitida puede incluir un número pseudoaleatorio, tal como el generado utilizando un generador de números pseudoaleatorios utilizando un valor germinal particular. El valor germinal cambiará cada vez que se genere un nuevo número pseudoaleatorio, de modo que una secuencia de números pseudoaleatorios se generará. En una aplicación, la clave transmitida incluye un primer identificador electrónico que identifica un usuario que solicitó la transacción de intercambio de valores, un segundo identificador electrónico que identifica un usuario que es el objetivo de la transacción de intercambio de valores, una cantidad de valor de la transacción de intercambio de valores, y un tiempo asociado con la transacción de intercambio de valores. En una aplicación, la transacción de intercambio de valores puede ser enviar dinero desde un primer usuario asociado con el dispositivo de usuario hasta un segundo usuario asociado con otro dispositivo de usuario. Por ejemplo, el primer usuario puede Solicitar el Pago de una cierta cantidad de dinero de la cuenta del primer usuario al segundo usuario . La clave transmitida no se despliega en el dispositivo de usuario, de modo que no se sabrá por el usuario. Esto puede ser útil para evitar que personas que tratan de "clonar" la cuenta de otro usuario y utilizar dinero en la cuenta de otro usuario. Si la clave de transmisión se despliega, otro usuario puede ser capaz de determinar más fácilmente el siguiente número en la secuencia, la función o ecuación que se utiliza para generar las claves, u otra información que pueda ayudar a invertir el diseño de la clave. En una aplicación adicional, la clave transmitida se codifica para volverla difícil de interceptar en la transmisión inalámbrica de la clave. La solicitud electrónica puede realizarse mediante el servicio de mensaje de texto del SMS del dispositivo de usuario. La clave también puede transmitirse utilizando el servicio de mensajes de texto del SMS. Cuando se utilizan diferentes tipos de clientes o programas, la clave transmitida puede generarse u obtenerse en forma diferente, tal como por diferentes funciones. Por ejemplo, la clave puede incluir diferente información. La clave puede incluir primera información cuando el dispositivo de usuario envía la solicitud electrónica utilizando un primer cliente de aplicación y la clave transmitida comprende la primera información cuando el dispositivo de usuario envía la solicitud electrónica utilizando un primer cliente de aplicación, el cual es diferente del primer cliente de aplicación. Ejemplos de la primera información pueden ser una clave que incluye un número de secuencia que se almacena en forma persistente. Ejemplos de la segunda información pueden ser una clave que incluye un tiempo o marca de tiempo. Un primer cliente de aplicación puede ser un cliente solvente, tal como una aplicación de servicio de transacción de intercambio de valores dedicada que se ejecuta en el dispositivo de usuario (por ejemplo, escrita en J2ME, BREW, o . ET CF) o aplicación de mensajes instantáneos. Un segundo cliente de aplicación puede ser el cliente insolvente tal como una aplicación de mensajes del SMS en el dispositivo de usuario. El explorador WAP en el dispositivo de usuario, o explorador Web en el otro dispositivo. Cuando se envía la solicitud del cliente solvente, puede existir un valor almacenado persistente (tal como un contador almacenado) y este se utiliza en la clave. Sin embargo, cuando se envía la solicitud de un cliente insolvente, puede no existir un valor almacenado persistente y un tiempo o marca de tiempo puede utilizarse en la clave de hecho. El sistema será capaz de manejar la recepción de diferentes claves o diferentes tipos de claves . Si la clave transmitida está en la tabla de transacciones, esto quiere decir que la transmisión se envío posiblemente en forma previa o alguien está tratando de entrar en el sistema. La cuenta de usuario puede suspenderse y el asunto investigarse adicionalmente . Esto evitará transacciones ilegales adicionales en la cuenta del usuario. Además, procesar la transacción de intercambio de valores puede incluir generar un número de identificadores de transacción para la transacción de intercambio de valores. Este número de identificador de transacción se generará por el sistema que procesa la solicitud. Un mensaje electrónico puede enviarse al dispositivo de usuario que incluye el número de identificador de transacción. El número de identificador de transacción puede ser visible en el dispositivo de usuario. Eso permite al usuario tener un número de referencia para la transacción, de modo que el usuario puede discutir o indagar sobre la transacción directamente con una representación de servicio al cliente. Este identificador de transacción puede no estar relacionado completamente con la clave de autenticación (la cual se genera en el dispositivo de usuario) . El identificador de transacción puede generarse por un asociado bancario que maneja la transacción. En una aplicación alterativa, la clave puede utilizarse para generar o crear el identificador de transacción . En una modalidad, la invención es un método que incluye recibir una solicitud electrónica de una transacción de intercambio de valores, transmitida inalámbricamente desde el dispositivo de usuario; recibir una clave transmitida asociada con la solicitud electrónica; generar una clave esperada; comparar la clave transmitida con la clave esperada; y si la clave transmitida concuerda con la clave esperada, procesar la transacción de intercambio de valores. La transacción de intercambio de valores puede ser enviar dinero desde un primer usuario asociado con el dispositivo de usuario hasta un segundo usuario asociado con otro dispositivo de usuario, en donde los dispositivos de usuario son teléfonos móviles. Generar la clave esperada puede incluir evaluar una función o ecuación utilizando un valor germinal almacenado para una cuenta de usuario asociada con la transacción de intercambio de valores. Además, la cuenta de usuario también puede almacenar información sobre la función o ecuación particular que utiliza para generar la clave esperada. Por ejemplo, algunos usuarios pueden utilizar una función particular para generar una clave mientras otros usuarios utilizan otras funciones. Diferentes valores germinales de inicio se utilizan para diferentes usuarios, y después de cada uso, un nuevo valor germinal se creará para generar la siguiente clave. En otras palabras, el método además incluye después de evaluar la función, determinar un siguiente valor germinal en secuencia y reemplazar el valor germinal almacenado para la cuenta de usuario con el siguiente valor germinal en secuencia. Por ejemplo, el dispositivo de usuario tiene un contador que cuenta una secuencia particular y genera claves en esta secuencia utilizando una función particular (por ejemplo, generador de número pseudoaleatorios) . En el servidor o lado del sistema, el servidor conocerá la clave esperada debido a que se almacena en el perfil de usuario y también sabrá la función que utiliza para generar la clave. Si la clave esperada concuerda con la clave transmitida, entonces la solicitud de usuario se autentica. Como se establece en lo anterior, la función o ecuación utilizada puede variar o cambiar por usuario o dispositivo, o incluso por uso. La identificación de la cual, la función o ecuación utiliza para generar la clave esperada almacenará alguien en el sistema tal como el perfil de un usuario. En particular, la invención puede incluir: recuperar de un perfil de usuario asociado con la transacción de intercambio de valores un valor germinal ; recuperar de la información de perfil de usuario en una función de acuerdo con la cual se generó la clave transmitida; y evaluar la función utilizando el valor germinal. Como se discute en lo anterior, un método de la invención puede o no incluir una función diferente. En tal caso, la información de función puede no necesitar almacenarse en el perfil. Si la clave transmitida no concuerda con la clave esperada, la transacción de intercambio de valores no se procederá. Una cuenta de usuario asociada con la transacción de intercambio de valores puede suspenderse para evitar transferencias adicionales de dinero puesto que se ha presentado una violación de seguridad. La cuenta puede etiquetarse (por ejemplo, despliegue en una pantalla, enviando un correo electrónico, enviando un mensaje instantáneo) a un administrador de sistema, quien puede investigar adicionalmente . O un correo electrónico automatizado puede enviarse al usuario para contactar el servicio del consumidor debido a que se ha presentado una violación de seguridad para la cuenta del usuario. Procesar la transacción de intercambio de valores puede incluir: generar un número de identificador de transacción, diferente de la clave esperada, para la transacción de intercambio de valores y enviar un mensaje electrónico al dispositivo de usuario que incluye un número del identificador de transacción, en donde el número de identificador de transacción se despliega en el dispositivo de usuario. Infraestructura del Sistema de Pago - Aplicación de Cliente Móvil (MCA) En una modalidad, la MCA se basa en la Plataforma Java 2, Enterprise Edition (J2EE) , y ostenta una interfaz intuitiva simple. Como resultado, los titulares de una cuenta ingresan sus datos de solicitud, tal como una cantidad, número telefónico, u otra información de identidad de cuenta tal como una dirección de correo electrónico o ID de mensajería instantánea de la cuenta de recepción, y el PIN. Diseñada para ser flexible y fácil de configurar, la MCA tiene diferentes versiones para diferentes idiomas y se diseña para ejecutar bajo Java 2 Mobile Edition (J2ME) , dot Net ( . ET) así como WAP, BREW, Symbian, y SIM Toolkit u otros protocolos móviles y pueden transferirse a plataformas tales como dispositivos celulares, PDA u otros dispositivos electrónicos móviles. Java, .Net, Brew, Symbian y Sim Toolkit son marcas comerciales de sus propietarios respectivos. MCA también está disponible para el sistema de operación telefónica, que incluyen Nokia, Motorola, Samsung, Sanyo y otras marcas comunes. Ventajosamente, ningún dispositivo semiconductor o "chip" especial en el dispositivo móvil se requiere para realizar transacciones financieras seguras, económicas y móviles. Para iniciar operación, los titulares de una cuenta se instalan (o han instalado) la MCA en su teléfono móvil. Proporcionar la aplicación puede llevarse a cabo de las siguientes formas: (1) Provisión al Aire utilizando una inserción WAP, el servidor de pago envía un mensaje al titular de una cuenta para comenzar la descarga de la aplicación. Alternativamente, el titular de una cuenta puede utilizar una extracción WAP para enviar un mensaje al servidor de pago para iniciar el proceso ; (2) Provisión de Proximidad en centros de servicio del consumidor, ubicaciones de comercio asociado, o proveedores de servicio móvil, pueden instalar la MCA mediante Bluetooth, infrarrojo u otra conexión inalámbrica de campo cercano; (3) Descarga de Internet donde los titulares de una cuenta pueden descargar el programa en la Internet e instalado a través de un puerto USB - o incluso descargar el programa desde un teléfono a otro; o (4) En una tarjeta SIM donde los titulares de una cuenta pueden comprar dispositivos con la MCA ya instalada en la tarjeta SIM. En un escenario ejemplar, un usuario tiene un dispositivo móvil equipado con capacidad de comunicación de campo cercano. El usuario puede ver un producto o elemento que desea comprar. El usuario pone el dispositivo móvil del usuario en proximidad con un dispositivo de comunicación de campo cercano asociado con el producto o artículo. Entonces la pantalla del dispositivo móvil pregunta si el usuario aprobará una transacción para comprar el producto o artículo. Si el usuario aprueba, la transacción se procesa. El usuario recibirá el artículo, tal como al recogerlo de un punto de distribución, o el artículo puede distribuirse a la dirección de correo del usuario. Se le puede pedir al usuario un PIN o pregunta de recusación para verificar que a aprobado la transacción . Un aspecto de la invención es un sistema o servicio de pago móvil. Esta aplicación discute muchas modalidades especificas y aplicaciones de componentes y elementos individuales, variaciones' y modificaciones de éstas, y combinaciones de éstas. Un sistema de la invención puede incluir cualquiera de las variaciones o aplicaciones especificas discutidas, e individualmente o en combinación. En esta aplicación, un ejemplo de una aplicación especifica de un sistema de pago móvil se proporciona, y esta aplicación especifica es el sistema Obopay. El sistema Obopay solamente es una aplicación de un sistema de pago móvil y se discute para describir varios aspectos más fácilmente de la invención. La invención abarca muchas aplicaciones del sistema de pago móvil y no se limita a las aplicaciones especificas descritas. Procesos de Aplicación Móvil de Aplicación de Cliente Móvil (MCA) La aplicación de cliente móvil permite a personas pagar a amigos, tiendas y transferir fondos por su dispositivo móvil. Un titular de una cuenta puede acceder a la aplicación de cliente móvil para enviar dinero o solicitar dinero de cualquiera por un dispositivo móvil que soporte mensaje de texto o capacidades de Internet móvil. También pueden ver el saldo e historial de su cuenta en tiempo real. La aplicación de cliente móvil soporta las siguientes características: Pago, Saldo, Historial, Solicitud de Pago, Referencia o Invitación, Agregar Dinero (es decir, Cargar), Ajustes, Ayuda. La MCA puede utilizarse para enviar dinero desde la cuenta de un titular de una cuenta a cualquier suscriptor móvil cuyo dispositivo soporte mensaje de texto. El titular de una cuenta que envía el dinero necesita ser un titular de una cuenta; sin embargo, la persona o comercio a quien está enviando el dinero no. La transacción financiera puede iniciarse por ya sea el pagador o el beneficiario. Si el pagador inicia la transacción, la MCA se utiliza para iniciar la transacción. Para utilizar la MCA para enviar dinero desde una cuenta de débito prepagada, el titular de una cuenta pasará a través de una secuencia de etapas: (1) Abrir la MCA en el dispositivo móvil de titular de una cuenta. Esto llevará al titular de una cuenta a una pantalla instantánea que despliega un logotipo y línea de retención. El titular de una cuenta entonces presiona "enter" para continuar. Esto pondrá al titular de una cuenta en la pantalla de menú principal que despliega un menú de las características de la MCA que incluyen Pago, Saldo, Historial, Solicitud de Pago, Referencia o Invitación, Agregar Dinero (es decir, Cargar) , Ajustes, y Ayuda. (2) El titular de una cuenta entonces selecciona la opción pago para enviar un pago. Esto llevará al titular de una cuenta a la pantalla de Pago donde el titular de una cuenta ingresará el número telefónico al cual desea enviar su pago . (3) Para seleccionar un número telefónico en la agenda telefónica del titular de una cuenta, el titular de una cuenta seleccionará las opciones (de la tecla inferior izquierda en el dispositivo móvil), y después buscara (del menú de opciones) cuál llevará al titular de una cuenta a la agenda telefónica existente y le permitirá seleccionar un nombre en la misma. Opcionalmente, el titular de una cuenta puede ingresar el número telefónico directamente del teclado. En otra modalidad, el titular de una cuenta ingresa un código corto para identificar un comercio beneficiario deseado. Una vez que el titular de una cuenta ha ingresado el número móvil, seleccionará OK. (4) Esto lo pondrá en la pantalla de cantidad donde el titular de una cuenta ingresará la cantidad que desea pagar. Dependiendo del perfil del beneficiario, en la pantalla de gratificación puede aparecer que ofrece al titular de una cuenta la posibilidad de agregar un extra a la cantidad que desea pagar. (5) Cuando el titular de una cuenta selecciona OK, será llevado a la pantalla de mensaje donde puede agregar un mensaje en su transacción. Este mensaje puede ser un anexo de texto, audio, o de video. Si el titular de una cuenta no desea agregar un mensaje, simplemente puede hacer clic en OK antes de escribir un mensaje y no se agregará un mensaje a su transacción. Si la red de transmisión que tiene ancho de banda limitado, el titular de una cuenta puede estar restringido en el tipo y duración del mensaje. Si la parte que recibe en la transacción no tiene un dispositivo móvil capaz de manejar mensajes de video o audio, el mensaje se almacenará en el servidor durante un período corto para permitir la recuperación subsiguiente mediante la Internet. (6) Una vez que el titular de una cuenta selecciona OK, será puesto en la pantalla de PIN donde ingresará su PIN y seleccionará OK. Cuando ingresa el PIN, los caracteres alfanuméricos no aparecen en la pantalla sino más bien se despliega de hecho un pseudocaracter . También, el PIN no puede encontrarse en un registro de mensajes u otros registros en el dispositivo móvil. Si otra persona tuviera acceso al dispositivo móvil, no sería capaz de determinar el PIN. Esto llevará al titular de una cuenta a la pantalla de confirmación que le mostrará la siguiente información; Pagar A: (Número Telefónico Objetivo) Cantidad : Cualesquier Cuotas por Transacción relevantes: Mensaje (si ha dejado uno) Una vez que el titular de una cuenta selecciona OK será puesto en una pantalla con la siguiente información: Pagador Si el beneficiario objetivo tiene un titular de una cuenta existente Mensaje Pagar A: (Número telefónico objetivo) Cantidad Fecha: mm/dd/aaaa hh:mm Trans : xxxx Si el beneficiario objetivo no tiene una cuenta existente, entonces su mensaje tal como: Nota: El receptor al que pago no es un titular de una cuenta registrado. Al receptor se le ha enviado un mensaje con instrucciones sobre cómo recibir el pago. Mensaje Pagar a: (Número telefónico objetivo) Cantidad Fecha: mm/dd/aaaa hh:mm Trans : xxxx Beneficiario : Si el beneficiario objetivo es un titular de una cuenta existente, el beneficiario recibirá un mensaje de que tiene un nuevo elemento agregado a su cuenta. Cuando abra el elemento, observará un recibo de transacción con la siguiente información: Fecha: mm/dd/aaaa hh:mm Cuenta: De: (número telefónico del pagador) Si el beneficiario objetivo aún no tiene una cuenta existente, el beneficiario recibirá un mensaje de texto que dice "tiene efectivo", y que le indica a ir a un sitio web, tal como www.obopay.com para convertirse en titular de una cuenta y recibir su efectivo. El proceso para un nuevo registro de titular de una cuenta se detalla posteriormente en este documento. Si la transacción financiera se inicia por el beneficiario, la MCA se utiliza para iniciar la transacción al Solicitud de Pago del pagador. Un ejemplo de una transacción iniciada por el beneficiario es donde un servicio de entrega de pizzas marca al número de la persona quien ordenó la pizza justo antes de cuando se entregue la pizza. Cuando el dispositivo móvil es contestado, al titular de una cuenta se le da la posibilidad de hacer el pago mediante la infraestructura de pago móvil de la presente invención. Para utilizar la MCA para solicitar dinero de una cuenta, el titular de una cuenta pasa a través de una secuencia similar de etapas: (1) Abrir la MCA en el dispositivo móvil del titular de una cuenta. Esto llevará al titular de una cuenta una pantalla instantánea que despliega un logotipo y la línea de retención. El titular de una cuenta entonces presiona "enter" para continuar. Esto pondrá al titular de una cuenta en la pantalla de menú principal que despliega un menú de las características de la MCA que incluyen Pagar, Saldo, Historial, Solicitud de Pago, Referencia o Invitación, Agregar Dinero, Ajustes y Ayuda. (2) El titular de una cuenta entonces selecciona la opción Solicitar para solicitar un pago e ingresará el número telefónico al cual desea enviar su solicitud. (3) Para seleccionar un número telefónico en la agenda telefónica del titular de una cuenta, el titular de una cuenta seleccionará opciones (de la tecla inferior izquierda en el dispositivo móvil) , y después buscará (del menú de opciones) cual lo llevará a la agenda telefónica existente del titular de una cuenta, y le permitirá seleccionar un nombre en la misma. Esta agenda telefónica puede corresponder, por medio de ilustración, a una lista de números telefónicos para titulares de una cuenta que han solicitado una entrega de pizza. Como parte de la solicitud, la persona de distribución puede anexar una pantalla de gratificación que ofrece al titular de una cuenta la posibilidad de agregar un extra a la cuenta que desea pagar. (4) Cuando el beneficiario selecciona OK, será llevado a la pantalla de mensajes donde puede agregar un mensaje a su transacción. En una modalidad, este mensaje puede ser un anexo de texto, audio o video. Si el beneficiario no desea agregar un mensaje, simplemente puede hacer clic en OK antes de escribir un mensaje y el mensaje no será agregado a su transacción. (5) Una vez que el titular de una cuenta selecciona OK será puesto en la pantalla de PIN donde ingresará su PIN, opcionalmente ingresando una gratificación y seleccionando OK. La solicitud será enviada al pagador quien tiene la posibilidad de aprobar la transacción al ingresar su PIN y presionando OK. Como se observa en lo anterior, el PIN se mantiene en un estado confidencial y seguro de modo que personas no autorizadas no pueden determinar el PIN solamente al tener acceso no autorizado al dispositivo móvil. El pago será procesado inicialmente y el beneficiario recibirá la notificación del pago. Si no existen problemas con la transacción, el titular de una cuenta no recibirá ninguna notificación adicional. Si algún problema surge con el pago (es decir, fondos insuficientes) tanto el titular de una cuenta como el beneficiario objetivo serán notificados. La notificación con respecto a algún problema con el pago será indicada después de que el pago se envíe de modo que las partes puedan confirmar la transacción. La MCA también puede utilizarse por un Titular de una cuenta para comprobar el saldo actual de su cuenta de débito prepagada de su dispositivo móvil. Para utilizar la MCA para comprobar su saldo, el titular de una cuenta pasará a través de las siguientes etapas: (1) Abrir la MCA en el teléfono del titular de una cuenta; (2) Esto llevará al titular de una cuenta a la pantalla instantánea que despliega el logotipo y la línea de retención. El titular de una cuenta presionará enter para continuar . Esto pondrá al titular de una cuenta en la pantalla de menú principal que despliega un menú de las características de la MCA que incluyen Pago, Saldo, Historial, Solicitud de Pago, Ajustes, y Ayuda. El titular de una cuenta seleccionará el saldo para comprobar su saldo. Esto pondrá al titular de una cuenta en la pantalla de PIN donde ingresará su PIN y seleccionará OK. Esto pondrá al titular de una cuenta en la pantalla de saldo que le proporcionará con la siguiente información: Fecha: MM/DD/AAAA HH:MM Saldo : Cuando el titular de una cuenta selecciona OK, será puesto nuevamente en la pantalla de menú principal. La MCA puede utilizarse por un titular de una cuenta para observar el historial de su última n, en donde n es un número entero (tal como 3 ó 5 por medio del ejemplo) , transacciones y el saldo actual de su cuenta de débito prepagada de su dispositivo móvil. Para utilizar la MCA para comprobar su historial, el titular de una cuenta pasará a través de las siguientes etapas: (1) Abrir la MCA en el dispositivo móvil del titular de una cuenta. Esto llevará al titular de una cuenta una pantalla instantánea que despliega un logotipo y la linea de retención. El titular de una cuenta entonces presiona enter para continuar. (2) Esto pondrá al titular de una cuenta en la pantalla de menú principal la cual despliega un menú de las características de la MCA que incluyen Pago, Saldo, Historial, Solicitud de Pago, Ajustes y Ayuda. El titular de una cuenta seleccionará el historial para observar su historial . (3) Esto pondrá al titular de una cuenta en la pantalla de PIN donde ingresará su PIN y seleccionará OK. (4) Esto pondrá al titular de una cuenta en la pantalla de historial que le proporcionará con la siguiente información : Datos de la transacción y cantidad de la transacción: MM/DD (+/-)$.$$ El titular de una cuenta será capaz de seleccionar una de las transacciones listadas para obtener más información sobre esa transacción especifica. Para hacer esto, desplegará la transacción especifica que desea observar y la seleccionará. Esto lo pondrá en una pantalla con la siguiente información: Fecha: M/DD/AAAA HH:MM:SS Cantidad: (+/-)$.$$ Para: (Número Telefónico del beneficiario o pagador) Mensaje: (si está disponible) El titular de una cuenta entonces selecciona OK para regresar a la pantalla de historial. Desde aquí, puede observar otra transacción o regresar a la pantalla de menú principal . Además, el titular de una cuenta puede enlazar su cuenta con el software de aplicación de contabilidad de modo que cada transacción se registra en una base de datos para su utilización en presupuesto, planeación, mantenimiento de registros o para propósitos de tributación. En esta modalidad, el titular de una cuenta puede agregar un segundo mensaje que designa el pago, si se envía o se recibe, de acuerdo con la naturaleza de la transacción financiera. Por ejemplo, cuando el titular de una cuenta paga una comida mientras se encuentra en viaje de negocios, el segundo mensaje puede indicar que la transacción es un gasto reembolsable deducible de impuestos. El cargo se registra por el software de aplicación de cuentas. El software de aplicación de cuentas puede proporcionarse por la plataforma del servidor (Véase Figura 3) o por un socio del proveedor de software. El software de aplicación de cuentas puede ser una opción de valor agregado donde el titular de una cuenta puede pagar un cargo mensual para acceder. Cuando el titular de una cuenta selecciona la tecla posterior será puesto en la pantalla de menú principal. Como se observa en lo anterior, la MCA puede utilizarse para solicitar dinero por un titular de una cuenta de cualquier otra cuenta de titular de una cuenta. Tanto el titular de una cuenta que solicita el dinero como el titular de una cuenta que está solicitando el dinero deben ser titulares de una cuenta. En otra aplicación de la invención, el servicio permite solicitar transacción de pago a miembros sin servicio (es decir, pago de solicitud viral) . Para utilizar la MCA para solicitar un pago de un titular de una cuenta, el titular de una cuenta que solicita pasará a través de las siguientes etapas. Abrir la MCA en el dispositivo móvil de titular de una cuenta solicitante. Esto llevará al titular de una cuenta a la pantalla instantánea que despliega el logotipo y la linea de retención. El titular de una cuenta presiona enter para continuar. Esto pondrá al titular de una cuenta en la pantalla de menú principal que despliega un menú de las características de la MCA que incluyen Pago, Saldo, Historial, Solicitud de Pago, Referencia o Invitación, Ajustes y Ayuda. El titular de una cuenta seleccionará Solicitud de Pago para solicitar un pago. Esto llevará al titular de una cuenta a la pantalla de Enviar donde titular de una cuenta ingresará el número de teléfono móvil de donde desea enviar su solicitud de pago. Para seleccionar un número telefónico en la agenda telefónica del titular de una cuenta, el titular de una cuenta seleccionará opciones (de la tecla inferior izquierda en el dispositivo móvil) , y después buscará (del menú de opciones) cuál lo pondrá en la agenda telefónica existente del titular de una cuenta y le permitirá seleccionar un nombre en la misma. Una vez que el titular de una cuenta ingresa el número móvil seleccionará OK. Esto lo pondrá en la pantalla de cantidad donde el titular de una cuenta ingresará la cantidad que desea pagar. El titular de una cuenta solicitante selecciona si desea o no solicitar GRATIFICACIÓN (es decir, la capacidad del solicitante para agregar una cantidad además de la cantidad que está solicitando) . Cuando el titular de una cuenta selecciona OK se pondrá en la pantalla de mensaje donde puede agregar un texto o audio o mensaje de video a su transacción. Si el titular de una cuenta no desea agregar un mensaje, puede hacer clic en OK antes de escribir un mensaje y ningún mensaje se agregará a su transacción. Una vez que el titular de una cuenta selecciona OK, se pondrá en la pantalla de PIN donde ingresará su PIN y seleccionará OK. Esto pondrá al titular de una cuenta en la pantalla de confirmación que le mostrará la siguiente información : Enviar A: (Número Telefónico Objetivo) Cantidad: Solicitud de Gratificación (Activada/Desactivada) Cualesquier Cuotas por Transacción relevantes: Mensaje (si tiene uno) Una vez que el titular de una cuenta selecciona OK será llevado a una pantalla con la siguiente información: Solicitante Mensaje Enviar a: (Número telefónico objetivo) Cantidad Fecha : mm/dd/aaaa hh : mm Trans : xxxx Solicitante: El solicitante recibirá un mensaje de que tiene un nuevo elemento del servidor de pago. Cuando el titular de una cuenta abre el elemento abrirá la MCA y llevará al titular de una cuenta a la pantalla instantánea que despliega el logotipo y las líneas de retención. El titular de una cuenta presiona enter para continuar. Entonces, el titular de una cuenta será llevado a la solicitud de pago donde observará la siguiente información: Mensaje (si es aplicable) Pagar a: (número telefónico del solicitante) Cantidad Fecha: mm/dd/aaaa hh:mm ID de Transacción El beneficiario será capaz de aceptar o rechazar la solicitud de pago. Si el beneficiario acepta la solicitud, seleccionará la tecla 'aceptar' . Si el beneficiario acepta la solicitud y una solicitud de GRATIFICACIÓN se ha establecido por el titular de una cuenta solicitante que acepta la solicitud llevará al beneficiario a una pantalla de cantidad de GRATIFICACIÓN donde puede agregar una GRATIFICACIÓN. Una vez que se ha hecho el ingreso de la GRATIFICACIÓN y se selecciona OK, el titular de una cuenta será llevado a la pantalla de PIN. Una vez que el beneficiario ingrese su PIN y selecciona OK, será puesto en la pantalla de confirmación. La pantalla de confirmación incluye la siguiente información: Pagar A: (número telefónico del peticionario de pago) Cantidad : GRATIFICACIÓN (si es aplicable) Una vez que el beneficiario selecciona OK, la transacción será procesada y el beneficiario será llevado a una pantalla con la siguiente información: Enviar a: (número telefónico de peticionario de pago) Cantidad Saldo : Fecha: MM/DD/AAAA HH:MM Trans : (ID de transacción) Una vez que el beneficiario selecciona OK, será llevado al Menú Principal. Si el beneficiario declina la solicitud, seleccionará la tecla rechazar. El peticionario de pago recibirá una notificación con respecto a sí su solicitud de pago fue aceptada o rechazada. La notificación incluirá la siguiente información: Mensaje: (si es aplicable) De: (número telefónico de beneficiario) Cantidad : Fecha: MM/DD/AAAA HH:MM:SS Trans : El titular de una cuenta puede cambiar los ajustes por defecto que se pueden configurar por el titular de una cuenta. Actualmente, esto incluye cambiar el protocolo (es decir, SMS o HTTP) que utiliza para enviar y recibir la información de pago entre el dispositivo móvil y el servidor. Esto también puede incluir otra información configurable por el titular de una cuenta en versiones futuras de la aplicación. Para cambiar el ajuste en su MCA, el titular de una cuenta puede pasar a través de las siguientes etapas: Abrir la MCA en el dispositivo móvil del titular de una cuenta . Esto llevará al titular de una cuenta a la pantalla instantánea que despliega el logotipo y las lineas de retención. El titular de una cuenta presiona enter para continuar. Esto pondrá al titular de una cuenta en la pantalla de menú principal que despliega un menú de las características de la MCA que incluyen Pago, Saldo, Historial, Solicitud de Pago, Referencia o Invitación, Ajustes y Ayuda. El titular de una cuenta establecerá los Ajustes para cambiar sus ajustes. Esto lo pondrá en la pantalla de ajustes donde puede seleccionar el ajuste que desea modificar. Actualmente, la única opción es el protocolo. Cuando el titular de una cuenta selecciona el protocolo, será puesto en la pantalla de protocolo. El titular de una cuenta será capaz de seleccionar su HTTP o SMS en la pantalla de protocolo. Mediante la aplicación por defecto se establece HTTP. Para regresar a la pantalla de protocolo, el titular de una cuenta necesitará seleccionar la tecla regresar. Para regresar al menú principal, el titular de una cuenta necesitará seleccionar la tecla regresar. El titular de una cuenta será capaz de observar una pantalla de Ayuda de la MCA. Esto incluirá una breve descripción de la aplicación en instrucciones sobre el titular de una cuenta que puede ir para obtener más ayuda. Para observar la sección de Ayuda de la MCA, el titular de una cuenta puede pasar a través de las siguientes etapas. Abrir la MCA en el dispositivo móvil de titular de una cuenta. Esto pondrá al titular de una cuenta en la pantalla instantánea que despliega el logotipo y la línea de retención. El titular de una cuenta necesitará presionar enter para continuar. Esto pondrá al titular de una cuenta en la pantalla de menú principal que despliega un menú de las características de la MCA que incluyen Pago, Saldo, Historial, Solicitud de Pago, Ajustes y Ayuda. El titular de una cuenta seleccionará Ayuda para observar la Ayuda. Esto lo pondrá en la pantalla principal de Ayuda que le proporcionará con los enlaces a lo siguiente: Una breve descripción de la MCA, tal como: Obopay le permite enviar dinero, hacer compras y solicitar pagos utilizando su teléfono. También utilice su tarjeta de débito para realizar compras y retirar efectivo. Más : Enlace a la página de Características que despliega, por ejemplo: Se le pedirá ingresar un número telefónico del titular de una cuenta, una cantidad, y su PIN cuando haga lo siguiente. Más: Pagar aquello que despliega, por ejemplo: Utilice la característica de pago de Obopay para enviar dinero a cualquiera con un teléfono móvil o VOIP. Si aun no tiene una cuenta de débito prepagada, se le dirigirá a un sitio web para crear una. Para cancelar un pago vaya a obopay.com para información. El saldo que despliega por ejemplo: Utilice saldo para obtener cantidad disponible en su cuenta. Historial que despliega por ejemplo: Utilice historial para obtener transacción recientes y saldo disponible. Seleccione uno para obtener detalles . Solicitud de Pago que despliega por ejemplo: Utilice solicitud de pago para solicitar dinero del titular de una cuenta de un teléfono móvil. Es opcional agregar mensaje y solicitar una gratificación. Enlazarse a la página ayuda o Ingrese Información que despliega por ejemplo: Números Telefónicos -cuando selecciona Pago o Solicitud de Pago, ingrese el número telefónico con el código de área, sin guiones o espacios. Cantidades que despliega por ejemplo: Entre $0.01-$9999.99. No necesita agregar puntos decimales-agregue ceros para cantidades en dólares. Su PIN que despliega por ejemplo: Su PIN se proporcionó cuando se activo su cuenta. Si lo ha olvidado, llame al 888-80BOPAY Enlace a la página de ayuda en Atajos Regresar: regresar a la pantalla previa. Borrar: borra el último carácter tecleado. Contactos: accesa a su agenda de direcciones. Salir: cierra la aplicación. Enlace a la página de ayuda en FAQ . Seguridad. Obopay proporciona transacciones seguras a través de transacción de codificación en el nivel de red, el nivel de la aplicación y el nivel de transacción. Para más información visite www.obopay.com Plan de datos (Internet) Usted no necesita un plan de datos para utilizar Obopay. Sin embargo, necesitará un plan de datos para descargar Obopay a su nuevo teléfono. También, un plan de datos puede optimizar el rendimiento del servicio Obopay. ¿Costo? ¿Retirar dinero? Utilice su tarjeta de débito en cualquier ATM que acepte una tarjeta de crédito 0 solicite un cheque de Obopay en www . obopay . com Cancelar transacción Para cancelar una transacción para uno que no es titular de una cuenta vaya a www.obopay.com/help y seleccione cancelar pago. Los pagos a titulares de una cuenta solamente pueden cancelarse si la transacción no fue autorizada (fraude) . Para cancelar una transacción no autorizada llame al 888-80BOPAY ¿Agregar dinero? Vaya a www.obopay.com y seleccione el botón de cargar cuenta Olvido el PIN. Si lo ha olvidado, llame al 888-80BOPAY Enlace a la página de ayuda en Soporte Para más información, vaya a obopay.com o llame al 888-80BOPAY Enlace a la página help en Sobre versión del software Tamaño de archivo : Ventajosamente, la MCA le permite a los titulares de una cuenta crear un perfil fuera de línea que puede configurarse para responder automáticamente cuando su dispositivo móvil está apagado o está fuera de alcance. Por ejemplo, el titular de una cuenta podría configurar su cuenta para aceptar automáticamente depósitos de dinero o aceptar automáticamente retiros de titulares de una cuenta específicos. Si el dispositivo móvil de titular de una cuenta está encendido, cualesquier transacciones fuera de línea podrían recuperarse al llamar al servidor de pago para una consulta de saldo o una solicitud de historial. En otras alternativas, el titular de una cuenta podría especificar qué información de cuentas se distribuye por el SMS o correo de voz . Protocolo Alámbrico MCA y protocolo alámbrico de Plataforma Revisión general La MCA y el protocolo alámbrico de Plataforma se utiliza junto con el codee de la MCAP para serializar/deserializar datos para comunicación entre varios dispositivos que ejecutan la MCA y el centro de datos que aloja los servicios basados en J2EE. La MCA y el protocolo alámbrico de Plataforma especifica el formato de los datos serializados pasados entre dispositivos y el centro de datos.
El codee de la MCAP es el componente en dispositivos móviles y el centro de datos maneja la serialización y desearialización de acuerdo con la MCA y las especificaciones del protocolo alámbrico de Plataforma. La Figura 59 muestra una ilustración directa de los conceptos básicos. Lo siguiente muestra las solicitudes de servicio del dispositivo móvil y las representaciones alámbricas de muestras . Una solicitud de servicio se inicia por el dispositivo móvil en la llamada PaymentService . payP2P . Esta función realiza el pago de titular de una cuenta a titular de una cuenta, la asignatura del método java es: Public PaymentSummary payP2P( String srcDevKey, String srcPin, String tgtDevKey, String transactionAmount , String paymentMemo) throws Exception; Todo aquello diferente a un valor de retorno se explica en el diagrama. Con la respuesta, el valor de retorno se incluye además de la sobrecarga, la cadena de valor de retorno comienza con un código tipo objeto (9 en este caso, se traduce en CommonPaymentSummary) , atributos no nulos del valor de retorno sigue, por ejemplo, atributo #1 paymentAmount - tiene un valor de $1.27, etc.
Con referencia ahora a la Figura 60 la cual es un ejemplo que muestra una invocación exitosa de la llamada de servicio al invocar la llamada PaymentService . retrieveBalance . Esta llamada recupera el saldo de cuenta para una cuenta. public BalanceSummary retrieveBalance ( String devKey, String pin) throws Exception; La parte de solicitud no es diferente del ejemplo previo, pero la respuesta ahora representa una excepción que se extrae como resultado de la llamada de servicio. El tipo de objeto 6 representa un valor de retorno de tipo EWPBusinessException, sus atributos se explican en la figura 61. Otra solicitud de servicio del dispositivo móvil y las representaciones alámbricas de muestra es la llamada de PaymentService . retrieveHistory. Como lo indica el nombre, esta función recupera el historial de transacción de una cuenta . public TransactionSummary [] retrieveHistory ( String devKey, String pin) throws Exception; La Figura 62 demuestra una invocación exitosa, lo único notable aquí es que el "tipo de objeto" (10) del valor de retorno ahora es seguido por un indicador de disposición "<", esto quiere decir que el valor de retorno es una disposición de objetos de tipo 10, lo cual quiere decir CommonTransactionSum ary. Otra solicitud de servicio iniciada por el dispositivo es la función reguestPay que se utiliza para solicitar un pago de otro miembro. public PayRequestSummary requestPay( String srcDevKey, String srcPin, String tgtDevKey, String transactinAmount , Boolean tipRequest, String memoText) throws Exception; La función payRequestPay se utiliza en respuesta a la llamada requestPay, esta llamada aprueba el pago solicitado . public PayRequestSummary payRequestPay ( String payerDevKey, String payerPin, String tgtDevKey, String paymentAmount , String tipAmount, Boolean acceptRequest , String transactionRef , String memoText) throws Exception; Otra función es la función f2egistratior2Service.whoA.TiJ que establece el servicio con el centro de datos y se le llama cuando se invoca la aplicación por primera vez . public String whoAmi (String deviceNumber) throws exception; Otra categoría de solicitudes son aquellas enviadas por el servidor, las características de estas solicitudes son que (1) actualmente sólo se envía por el SMS; (2) normalmente son notificaciones de eventos del servidor a los dispositivos; (3) no existe ninguna respuesta sincrónica para tales solicitudes. Para tener consistencia con la MCA y la arquitectura de plataforma que maneja las llamadas iniciadas por el dispositivo, la presente invención ha implementado el administrador de tales notificaciones en el dispositivo como "servicios de dispositivo" con la misma signatura ServiceProxy cuando los métodos en estos "servicios de dispositivos" son invocados del lado del servidor. El codee y el protocolo alámbrico son exactamente los mismos que aquellas solicitudes iniciadas por el dispositivo. Aquí una lista de los "servicios de dispositivo" actualmente disponibles y sus métodos: Servicio de Pago J2ME P2pNotify-notifica el objetivo del p2p del pago requestPay-notifica el miembro de una solicitud requestPay . notifyi?eguestPayi?eceived-notifica el objetivo de la operación de solicitud de pago de la recepción del pago de la solicitud de pago. cancelViralNotify-notifica el objetivo viral de cancelación del pago viral Revisión General Técnica de la MCAP Otros servicios de dispositivo que pueden definirse fácilmente y agregarse a la MCA y se estima se basan en las consideraciones de diseño de una modalidad particular. El diseño de alto nivel de los tableros de la MCA & Plataforma (MCAP) , asi como la interfaz de usuario (UI) , ahora se discute y presenta un conjunto completo de características móviles que se esperan y se requieren por la MCAP. La MCAP básicamente es una aplicación de cliente/comercio móvil de "cartera móvil" o "pago por teléfono" . La interfaz de usuario de la MCAP es simple ya que sólo requiere ingreso paso por paso de datos de solicitud (tal como cantidad, PIN, etc.) y después el despliegue de los datos de respuesta. Por medio de ilustración y comparación, la interfaz de usuario de la MCAP no requiere las complejidades gráficas de una aplicación de juego móvil. De preferencia, la MCAP se escribe en un lenguaje que fácilmente se transfiere para ejecutarse en tantos dispositivos móviles como sea posible. Sin embargo, la infraestructura de la MCAP espera que cierta funcionalidad esté presente del dispositivo móvil. Por ejemplo, se requiere la capacidad de desplegar campos de entrada y capturar entradas del titular de una cuenta. La capacidad de utilizar los servicios de datos del dispositivo móvil mediante invocaciones de programas HTTPS API también se requiere si la capacidad de utilizar los servicios de texto del SMS del dispositivo móvil mediante las invocaciones de programa SMS API no está disponible. La capacidad de utilizar los servicios de datos persistentes del dispositivo móvil mediante invocaciones de programas API. Por ejemplo, la capacidad de almacenar datos en forma persistente en la tarjeta SIM u otra memoria no transitoria es una funcionalidad opcional. Similarmente , la capacidad de interceptar mensajes de entrada en el dispositivo móvil y "despertar" la MCAP para procesar también es opcional. Esta funcionalidad proporciona, por ejemplo, la capacidad de interceptar un mensaje de entrada del SMS (en un puerto especifico) y manejarlo por la MCAP. La capacidad de integrarse. en forma de programa con la "agenda de direcciones" del dispositivo móvil de modo que un campo de entrada especifico pueda "enlazarse" a la agenda de direcciones también es opcional. La capacidad de notificar con programas al titular de una cuenta de dispositivo móvil de eventos notables mediante sonido, vibración o luz es opcional . De preferencia, la MCAP se coloca en módulos de modo que se implemente fácilmente en J2ME y se consolida en . NET así como J2ME , BREW, Symbian, y . NET CF (Previamente Windows móvil) La Figura 63 muestra las Capas de Diseño o OMAP de Alto Nivel para un dispositivo móvil. La Figura 64 es un diagrama de flujo que muestra el Diseño de Comunicación de OMAP y el esquema de codificación de Solicitud/Respuesta que utiliza una sola cadena de texto con pares de parámetros/valores delimitados. La Figura 65 muestra el Diseño de Persistencia de OMAP que utiliza el mecanismo de memoria persistente del dispositivo móvil y un diagrama de estados que muestra el Diseño de Notificación de Usuario de OMAP. La Figura 66 muestra la Paleta de Pantalla de OMAP para una modalidad. La Figura 67 es un diagrama de estado que muestra las Transiciones de Pantalla de OMAP. La Figura 68 muestra un esquema para el menú principal de OMAP. La Figura 69 muestra el Flujo de Pantalla de Pago de OMAP a partir de la perspectiva de fuente. En otras modalidades de la invención, la característica "pagar dinero" puede llamarse de hecho "enviar dinero" . La Figura 70 muestra el Flujo de Pantalla de Pago de OMAP a partir de la perspectiva objetivo. La Figura 71 muestra el Flujo de Pantalla de Solicitud de Pago de OMAP a partir de la perspectiva de Fuente-Solicitud. En otras modalidades de la invención, la característica "solicitar pago" puede llamarse de hecho "obtener dinero" . La Figura 72 muestra el Flujo de Pantalla de Solicitud de Pago de OMAP a partir de la perspectiva de "objetivo-aceptar" . La Figura 73 muestra el Flujo de Pantalla de Solicitud de Pago de OMAP donde el objetivo rechaza una solicitud . La Figura 74 muestra el Flujo de Pantalla de Solicitud de Pago de OMAP donde la Fuente y Objetivo aceptan una solicitud. La Figura 75 muestra el Flujo de Pantalla de Solicitud de Pago de OMAP donde la Fuente y el Objetivo rechazan una solicitud. La Figura 76 muestra el Flujo de Pantalla de Saldo de OMAP. La Figura 77 muestra el Flujo de Pantalla del Historial de OMAP. La Figura 78 muestra el Flujo de Pantalla de Ajustes de OMAP a la fuente. Las Figuras 79 y 80 muestran los Flujos de Pantalla del Sistema de OMAP. Específicamente, la Figura 79 muestra el flujo de pantalla para el OMAP para una ID Móvil Desconocida. La Figura 80 muestra el Flujo de Pantalla de Excepción de Sistema de OMAP donde falla una solicitud. Las Figuras 81 a 86 muestran pantallas y flujos de usuario para una aplicación de teléfono móvil para realizar pagos de persona a persona. En una aplicación, esta aplicación es una aplicación autónoma que se ejecuta en un teléfono móvil que permite a usuarios enviar pagos a otros usuarios, solicitar pago de otros usuarios, revisar información de saldos, revisar historial de transacción, y realizar otras funciones. El usuario puede cambiar los ajustes tales como el tamaño de fuente (por ejemplo, pequeño, medio o grande) . Un protocolo para comunicarse con el sistema puede seleccionarse, tal como HTTPS, HTTP, o SMS. El usuario puede solicitar que exista una notificación de sonido o luz, o ambas cuando reciba un pago. Existe una palanca de gratificación de modo que el usuario pueda tener una demostración de pantalla de gratificación o ninguna demostración en el objetivo (o teléfono del receptor) para una solicitud de pago. Después, el receptor puede enviar más dinero que el usuario solicitó en la solicitud de pago.
Existe un menú de contactos donde un usuario puede guardar y elegir contactos para pagar o solicitar pago de. Existe un campo de mensajes o memoria donde un usuario puede ingresar un mensaje junto con la solicitud de enviar pago o solicitud de pago. Por ejemplo, el usuario puede llamar al objetivo "money 4 lunch". Existe una pantalla donde el usuario puede ingresar el pin del usuario. El pin no se desplegará, pero en su lugar se desplegaran asteriscos, espacios en blanco, u otro carácter de hecho. Puede existir una pantalla para clasificar toda la transacción y dar al usuario la posibilidad de confirmar la transacción antes de enviarla. Si existe un error, lo confiable puede seleccionarse para editar la transacción antes de enviarla. La aplicación además puede incluir una guía de ayuda o de instrucciones de usuario para ayudar al usuario y responder a la pregunta del usuario con respecto al uso del sistema . Servicios Financieros API La interfaz entre dispositivos móviles y el Servidor de Servicio de Plataforma de Cartera Electrónica (EWP) incluye componentes de servicio tales como el Servicio de Pago y el Servio de Registro y su jerarquía de alto nivel de objetos de Excepción. También se describen clases de transporte de datos comerciales que se regresan de las llamadas de servicio.
Servicio de Pago Este servicio comercial se define e implementa de acuerdo con una definición de infraestructura de servicios de aplicación para la E P. Servicio de Pago comprende llamadas de método de paso directo a un sistema de banco corresponsal. El banco corresponsal maneja el sistema oficial de registros, el procesamiento de pagos, y la información de cuentas y miembros . Los datos administrados dentro de la EWP están más allá de lo que es necesario para integrarse con el banco corresponsal es para uso interno solamente. Paquete : com . ewp . services Clase : interfaz pública PaymentServicelnterface aplicaciones de la clase pública PaymentServícelmplementation PaymentServicelnterface Las interfaces de programación de aplicación (API) definidas para este servicio son: payP2P-ej ecuta una transacción de titular de una cuenta a titular de una cuenta (p2p) entre dos miembros consumidores retrieveSalance-recupera el saldo disponible por la cantidad especifica retrieveHistory-recupera los últimos cinco registros de transacción para la cantidad especifica, que incluyen una sexta línea que muestra el saldo disponible reguestPay-primera etapa de una transacción de dos partes donde un miembro solicita pago de otro miembro payRequestPay-segunda etapa de una interacción de dos partes donde el receptor de la solicitud de pago realiza el pago o rechaza hacer el pago Se proporcionan detalles en las siguientes sub-secciones. Nótese que cualesquier valores monetarios regresados se presentarán como un tipo java . lang . String con el siguiente formato <monetary symbolxdollars><cents> . Por ejemplo, veinte dólares y cincuenta y cinco centavos en dólares norteamericanos tiene la representación de Cadena "$20.55" Asignatura del método: payP2P Este método soporta una llamada de un dispositivo móvil para realizar un pago a otro miembro quien tiene una cuenta asociada con un número de dispositivo móvil. El resultado de la transacción se envía al teléfono móvil del miembro que invoco. Además, una notificación de la recepción de dinero se envía al receptor. public PaymentSummary payP2P ( String srcDevKey, String srcPin, String tgtDevKey, String transactionAmount , String paymentMemo) throws Exception Parámetros de Entrada: srcDevKey*String valor que normalmente es el número telefónico de la cuenta que inicia el pago srcPin*String valor que es el PIN para la cuenta que hace la solicitud tgtDevKey»String valor que normalmente es el número telefónico de la cuenta que recibe el pago transactionAmount«String valor que la cantidad que hace la recepción de cuenta. paymentMemo»String que es una breve nota del pagador al receptor de pago. Objeto Tipo Retorno: PaymentSummary»container objeto que incluye el número de cuenta objetivo, cantidad del pago, y datos de saldo disponible. Véase descripción de clase PaymentSummary para más información. Signatura del método: retrieveBalance Este método soporta una llamada de un dispositivo móvil para obtener el saldo de cuenta actual del miembro. Este resultado se envía al teléfono móvil del miembro que invoca . PublicBalanceSummary retrieveBalance ( String devKey, String pin) throws Exception Parámetros de Entrada: devKey»String valor que normalmente es el número telefónico de la cuenta que esta solicitando su saldo pin»String valor que es el PIN para la cuenta que hace la solicitud Objeto de Tipo Retorno: BalanceSummary»container objeto que incluye los datos de saldo disponible. Véase descripción de clase BalanceSummary para más información. Signatura de método: retrieveHistory Este método soporta una llamada de un dispositivo móvil para recuperar las cinco transacciones más recientes del miembro e incluye el saldo de cuenta actual en su despliegue de historial. El resultado se envía al teléfono móvil del miembro que invoca. public TransactionSummary [] retrieveHistory ( String devKey, String pin) throws Exception Parámetros de Entrada: devKey»String valor que normalmente es el número telefónico de la cuenta que está solicitando su historial de transacción pin»String valor que es el PIN para la cuenta que hace la solicitud Objeto del Tipo Retorno: TransactionSummary [] «una disposición de objetos del contenedor que incluye cada uno el valor de cantidad, la clave de débito/crédito/saldo, y la fecha de los datos de transacción. Véase descripción de clase TransactionSummary para más información. Signatura de método: payRequestPay Este método soporta una llamada de un dispositivo móvil para aceptar o rechazar una solicitud de pago. El resultado de transacción se envía al teléfono móvil del miembro que paga. Además, una notificación de la recepción de dinero se envía al receptor. public PayRequestSummary payRequestPayMobile ( String payerDevKey, String payerPin, String tgtDevKey, String paymentAmount , String tipAmount, Boolean acceptRequest , String transactionRef , String requestText, String memoText) throws Exception Parámetros de entrada: payerDevKey«String valor que normalmente es el número telefónico de la cuenta que llena la solicitud de pago (la misma que la fuente para payP2P) payerPin»String valor que es el PIN para la cuenta que llena la solicitud de pago tgtDevKey»String valor que es el número telefónico de la cuenta que recibe el pago o una clave de referencia utilizada para identificar una clave de conexión JNDI en un dispositivo asociado con la cuenta que recibe el pago paymentAmount*String valor que es la cantidad del pago para realizar la cuenta de recepción. tipAmount»String valor que es la cantidad del pago de gratificación para agregar al total de transacción acceptRequest»Boolean valor que indica si la solicitud de pago fue aceptada o no (verdadera = aceptada) transactionRef«String valor que es el miembro de referencia de transacción de la solicitud original de pago requestText«String que es la breve nota del titular de una cuenta que solicita el pago para que el titular de una cuenta haga el pago. memoText«String que es una breve nota del pagador al receptor de pago. Objeto del Tipo Retorno: PayRequestSummary»container objeto que incluye el miembro de referencia de transacción, el número de cuenta del objetivo, la cantidad de pago, y los datos de saldo disponible. Véase descripción de clase PayReguéstSummary para más información. Signatura de método: requestPay Este método invoca un método de servicio de dispositivo para notificar al miembro objetivo sobre una solicitud de pago de otro miembro. public PayRequestSummary requestPay ( String srcDevKey, String srcPin, String tgtDevKey, String transactionAmount , Boolean tipRequest, String requestText, throws Exception Parámetros de entrada: srcDevKey*String valor que es ya sea el número telefónico de la cuenta que inicia la solicitud de pago o una referencia clave utilizada para identificar una clave de conexión JNDI en un dispositivo asociado con la cuenta que hace la solicitud de pago srcPin»String valor que es el PIN para la cuenta que hace la solicitud tgtDevKey»String valor que normalmente es el número telefónico de la cuenta que debe recibir la solicitud de notificación de pago transactionAmount*String valor que es la cantidad del pago solicitado. tipRequest«Boolean que indica si se presenta o no una pantalla de solicitud de gratificación en el receptor de solicitud requestText»String que es la breve nota del solicitante de pago en el titular de una cuenta que hace el pago . Objeto del Tipo Retorno: PayRequestSummary«container objeto que incluye el número de referencia de transacción, el número de cuenta del objetivo, la cantidad de pago, y los datos de saldo disponible. Véase descripción de clase PayRequestSummary para más información. Servicio de Registro Este servicio comercial se define y se implementa de acuerdo con la definición de infraestructura de Servicio de Aplicación para la EWP. El Servicio de Registro proporciona métodos que se utilizan para las llamadas de servicio web del sistema de banco corresponsal nuevamente del sistema de EWP. Mientras el banco corresponsal mantiene la cuenta oficial y la información del miembro, EWP necesita saber el mapeo entre un número de tarjeta de débito del prepago del miembro y el número telefónico móvil del miembro. Esos datos, y potencialmente más, serán persistentes en el sistema de EWP. Paquete: com . ewp . services Clase : public interface RegistrationServicelnterface public class RegistratiónServicelmplemenation implements paymentServicelnterface Las interfaces de programación de aplicación (API) definidas para este servicio son: AddRegistrationlnfo-crea registros de datos que pertenecen a una cuenta Se proporcionan detalles en la siguiente sub-sección . Signatura de método: addRegistrationlnfo Este método persiste el número del dispositivo como un registro de datos de Cuenta. Si más información está disponible, tal como el nombre del miembro, entonces el método también persistirá la información adicional. Referencias entre objetos de datos se harán cuando sea necesario. El método regresa un objeto de contenedor que indica el estado de registro de la cuenta. public ArrayList addRegistrationlnfo ( ArrayList regContainerList , String dsName) throws Throwable Parámetros de entrada: regContainerList · RegistrationContainer objeto contenedor que como mínimo contiene el teléfono asociado con una cuenta. Objeto de devolución: ArrayList de objetos RegistrationContainer» una lista de los objetos contenedores que contienen información que debería haber persistido. Objetos de transferencia Cada uno de los objetos de transferencia descritos en esta sección proporciona obtenedores y modificadores para cada uno de sus atributos de clase y un constructor por defecto. Los objetos en esta sección implementan la interfaz j ava . io . Serializable y una interfaz Transferlnterface, que es un marcador de posición para las necesidades de interfaz comunes potenciales, así como proporcionar un tipo base. BalanceSummary El objeto contenedor devuelto de la API paymentServicelnterface . retrieveBalanceMobile ( ) . Paquete : com . ewp . transferobj ects Clase : clase pública BalanceSummary implementa Transferlnterface , Serializable Atributos : currentBalanceAmount · Valor de cadena que es la cantidad monetaria de fondos actualmente disponibles para su utilización . errorCode · Valor de cadena que indica la naturaleza del error; determinado sólo si status=0 status · Valor de cadena que indica si un error ocurrió o no durante la ejecución del servicio: I=OK, 0=Error requestDate · Valor de cadena que es la marca de tiempo de revisión para la solicitud del saldo PaymentSummary El objeto contenedor devuelto de la API PaymentServicelnterface . payP2PMobile ( ) . Este objeto también pasa en rellamadas automáticas de notificación a la interfaz del dispositivo móvil con valores para visualización . Paquete : com.ewp. transferobjects Clase : clase pública PaymentSummary implementa Transferlnterface , Serializable Atributos : newBalanceAmount · Valor de cadena que es la cantidad monetaria de fondos disponibles actualmente para su utilización . paymentAmount · Valor de cadena que es la cantidad monetaria de fondos pagados sourceDeviceKey · Valor de cadena que es el número telefónico de la cuenta que realizó el pago targetBalanceAmount · Valor de cadena que es la cantidad monetaria de fondos actualmente disponibles para su utilización en la cuenta de destino targetDeviceKey · Valor de cadena que es el número telefónico de la cuenta a la que se realizó el pago errorCode · Valor de cadena que indica la naturaleza del error; determinado sólo si status=0 status · Valor de cadena que indica si un error ocurrió o no durante la ejecución del servicio: 1=0K, 0=Error requestDate · Valor de cadena que es la marca de tiempo de transacción para la solicitud de pago TransactionSummary El objeto contenedor devuelto de la API PaymentServicelnterface . retrieveHistoryMobile ( ) . Paquete : com . ewp . transferobj ects Clase : clase pública TransactionSummary implementa Transferlnterface , Serializable Atributos : transactionDate · Valor de cadena que es un valor de tiempo universal coordinado (UTC) representado en milisegundos a partir de la medianoche del 1 de enero de 1970. La fecha es la de la transacción inicial. settleDate · Valor de cadena que es un valor de tiempo universal coordinado (UTC) representado en milisegundos a partir de la medianoche del 1 de enero de 1970. La fecha es de cuando la transacción se pagó/completó. transactionAmount · Valor de cadena que es la cantidad monetaria de la transacción específica transactionKey · Valor de cadena que indica si la cantidad de la transacción representa un crédito ("+"), débito ("-"), o saldo ("saldo"). transactionType · Valor' de cadena que indica el tipo de transacción: P2P, POS , ATM, LOAD, BAL. locationName · Valor de cadena que identifica dónde ocurrió la transacción, por ejemplo, la ID de una tienda o la ID de un cajero automático. errorCode · Valor de cadena que indica la naturaleza del error; determinado sólo si status=0 status · Valor de cadena que indica si un error ocurrió o no durante la ejecución del servicio: l=OK, 0=Error PayRequestSummary Un objeto contenedor que pasa en rellamadas automáticas de notificación a la interfaz de dispositivo móvil con valores para visualización. Paquete : com. ewp . transíerobjects Clase : clase pública PayRequestSummary implementa Transíerlnterface , Serializable Atributos : acceptRequest · valor booliano que indica si una solicitud de pago se acepta o no. El valor de TRUE significa procesar un pago p2p. paymentAmount · Valor de cadena que es la cantidad monetario de fondos a pagar payerBalanceAmount · Valor de cadena que es la cantidad monetario de fondos actualmente disponibles para su utilización . payerDeviceKey · Valor de cadena que es el número telefónico de la cuenta desde la que se solicita un pago. requesterDeviceKey · Valor de cadena que es el número telefónico de la cuenta que realiza la solicitud de pago y a la que se realizará el pago. targetBalanceAmount · Valor de cadena que es la cantidad monetaria de fondos actualmente disponibles para su utilización en la cuenta de destino. transactionRef · Valor de cadena que es el número de referencia de transferencia generado por el servidor. errorCode · Valor de cadena que indica la naturaleza del error; determinado sólo si status=0 status · Valor de cadena que indica si un error ocurre o no durante la ejecución del servicio: 1=0K, 0=Error requestDate · Valor de cadena que es la marca de tiempo de la transacción para la solicitud de pago tipRequest · Valor booliano que indica si una cantidad de gratificación debería solicitarse o no al beneficiario Clases de excepción EWPServiceException La clase de excepción base definida para el sistema EWP. Todas las excepciones lanzadas de los Servicios heredarán de esta clase base o de una de sus subclases. Paquete : com . ew . core . exceptions Clase: clase pública EWPException extiende Throwable Atributos : errorCode · Valor de cadena que identifica un código de error único en el sistema EWP. Este código se definirá como una constante Java. Éste se utilizará en archivos message . roperty para identificar cadenas de localización . errorText · Valor de cadena del mensaje de error que está registrado en el registro del sistema EWP. InternalException Esta excepción representa todos los errores del sistema y los servicios que ocurren que deberían seguir siendo internos en el sistema EWP. Típicamente, el origen de estos errores no se propaga de nuevo a la aplicación del cliente. Paquete : com . ewp . core . exceptions Clase : la clase pública InternalException extiende EWPException Atributos: Heredados de la clase padre. BusinessException Esta excepción representa errores que pueden presentarse a la aplicación del cliente. El mensaje de error contenido en el objeto de excepción no es el mensaje mostrado al titular de una cuenta. El mensaje de error devuelto a un titular de una cuenta aparece de forma entendible para el titular de una cuenta y localizado. La traducción de errorCode a mensaje de error ocurre en el Puerto de Enlace. Paquete: com . ew . core . exceptions Clase : la clase pública BusinessException extiende EWPException Atributos: Heredados de la clase padre. Códigos de error Códigos de error que en ocasiones aparecen como código de estatus de evento TransactionEvent y código de estatus de evento AuditEvent. Favor de referirse a ErrorCodesAndNotifications.doc para códigos de error y definiciones . Objetos de negocio Esta sección se refiere a los objetos de datos utilizados en una modalidad. Un conjunto de objetos de datos se define en los documentos de diseño EWP_Design_Pilot.doc y EWPDOModel_v2. vsd. Esos objetos representan todo el diseño del sistema EWP más allá de esta modalidad. Los ejemplos de los objetos de negocio para una modalidad se representan en la siguiente tabla. Se observará que los objetos pueden contener sólo un subconjunto de los atributos propuestos en el modelo de diseño EWPDOModel_v2. vsd. La siguiente tabla muestra el nombre de clase de los objetos de negocio, su nombre de tabla de datos correspondiente, los nombres de los atributos, los nombres correspondientes de las columnas de la tabla de datos, y un índice estimado de crecimiento para la tabla de datos.
Obieto de Nombre de Atributos Utilizados Nombre de Columna de Tasa de Negocio la Tabla de la Tabla de Datos Crecimiento Datos Account ACCOU Intcgcr id NUMBER(24) ID 80 solicitudes NT Long crcateTimeStamp NUMBER( 16) de registro Long timeStamp CREATETIMESTAMP inicialmente Srring accountNumber NLTMBER( I ó) 4 solicitudes de Srring acctStatusCode TIMESTAMP registro viral Boolcan acctWhtlistFlag VARCHAR2( 16) por semana BigDc imal ACCOUNTNUMBER 1 por registro availBalancc VARCHAR2(8) BigDccimal balance ACCTSTATUSCODE String cardNumber NUM BER( l ) Srring eurrencyCode ACCTWHTLISTFLAG String" deviccNumber NUMBER( 19,4) Profile profile AVAILBALANCE BigDccimal NUMBER( 19,4) dailyTransTotal BALANCE BigDecimal VARCHAR2( 16) monthTransTotal CARDNUMBER BigDecimal VARCHAR2(3) wcckTransTotal CURRENCYCODE VARCHAR2(20) DEVICENUMBER NUMBER(24) PROFTLEREFID NUMBER(19,4) DAILYTRANSTOTAL NUMBER( 19,4) Obieto de Nombre de Atributos Utilizados Nombre de Columna de Tasa de Negocio la Tabla de la Tabla de Datos Crecimiento Datos MONTHTRANSTOTAL NUMBER( 19,4) WEEKTRANSTOTAL AuditEvc AUDITE Intcgcr id NUMBER(24) ID Todos los nt VENT Long timeStamp NUMBER( 16) eventos de Intcgcr accountld TIMESTAMP transacción String auditNumber NUM BER(24) + solicitudes String auditTypeCode ACCOUNTID de registro String eventStatusCüde VARCHAR2( 16) String infoText AUDITNUMBER Integer memberld VARCHAR2(8) Srring nerworkConnlnfo AUDITTYPECODE Integer transEventld VARCHAR2(8) BigDecimal EVENTSTATUSCODE transFeesAmt VARCHAR2(250) BigDecimal INFOTEXT transGrossAmt NUMBER(24) Srring rraasNumberRef MEMBERID Intcgcr transTgtAcctld VARCHAR2(250) String transTypeCode NETWORKCONNINFO String memo NU BER(24) String message l TRANSEVENTI D NUMBER( 19,4) TRANSFEESAMT NUMBER( 1 ,4) TRANSGROSSAMT VARCHAR2( 16) TRANSNUMBERREF NUMBER(24) TRA STGTACC?D Obieto de Nombre de Atributos Utilizados Nombre de Columna de Tasa de Negocio la Tabla de la Tabla de Datos Crecimiento Datos VARCHAR2(8) TRANSTYPECODE VARCHAR2(32) MEMO VARCHAR2(32) MESSAGE 1 Transa ti TRANSA Integer id NUMBER(24) ID 2 por cuenta onEvent CTIONE Long timeStamp NUMBER( 16) al dfa VENT CurrencyExehange TIMESTAMP currcncyXC NUMBER(24) String currcncyTranRcf CURRENCYXCREFID String currencyCode VARCHAR2(24) String eventStatusCüde CURRENCYTRANREF String extPayConfRef VARCHAR2(3) String cxtPayAcctRcf CURRENCYCODE String extPayTransRef VARCHAR2(8) Float feeRetainRate EVENTSTATUSCODE BigDecimal VARCHAR2(24) grossAmount EXTPAYCONFREF String infoTcxt VARCHAR2(24) String locationRef EXTPAYACCTREF String networkConnlnfu VARCHAR2(24) Intcgcr srcAccountld EXTPAYTRANSREF BigDecimal NUMBER(5,4) srcFeesAmount FEERETAINRATE Integer srcMemberld(*) NUMBER( 19,4) String srcMcmTransRef GROSSAMOUNT Integer tgtAccountld VARCHAR2(250) BigDecimal INFOTEXT tgtFeesAmount VARCHAR2(24) Integer tgtMenibcrld( *) LOCATIONREF Obieto de Nombre de Atributos Utilizados Nombre de Columna de Tasa de Negocio la Tabla de la Tabla de Datos Crecimiento Datos String transNumber VARCHAR2(250) Srring transTypeCode NETWORKCONNINFO String memo UMBER(24) String mcssagc l SRCACCOLTNT1D NUMBER(1 ,4) SRCFEESAMOUNT NUMBER(24) SRCMEMBERID VARCHA.R2(24) SRCMEMTRANSREF NUMBER(24) TGTACCOUNTJD NUMBERÍ 19.4) TGTFEESAMOUNT J BER(24) TGTMEMBERID VARCHAR2( I 6) TRANSNUMBER VARCHAR2( 8) TRANSTYPECODE VARCHAR2(32) MEMO VARCHAR2(32) MESSAGE I Member MEMBE Integer id NUMBER(24) ID R Long creatcTimeStamp UMBER( 16) Long timeStamp CREATET1MESTAMP Boolcan NUMBER( 16) memBlkListFlag TIMESTAMP Srring chalQucsrion NUMBER( I ) Srring chalAnswer MEMBLKLISTFLAG Obieto de Nombre de Atributos Utilizados Nombre de Columna de Tasa de Negocio la Tabla de la Tabla de Datos Crecimiento Datos Integer conta tlnf ld VARCHAR2(32) Intcger fceSrructureld CHALQUESTION ArrayList VARCHAR2(32) rundsAccounts C HALAN SWER Srring language NUMBER(24) Srring memStatusCode CONTACTJNFOID Srring pinAlarmCode n/a Srring pinCode n/a Profile profile VARCHAR2(24) Srring scrccnNamc LANGUAGE VARCHAR2( 8) MEMSTATUSCODE VARCHAR206) PINALARMCODE VARCHAR2( 16) PINCODE NUMBER(24) PROF1LEREFID VARCHAR2( 16) SCREENNAME Consumer CONSU Tntcger id UMBER(24) ID (*) 1 por ember ER Long birthDate NU BER( 16) registro MEMBE String BIRTHDATE R governmentldNum VARCHAR2(24) (+ Long idDocExpDate GOVERNMENTIDNUM MEMBE Srring idDüdssuer NUMBER( 16) R) Srring idDocNum IDDOCEXPDATE String idDocTypcCode VARCHAR2(24) n/a IDDOCJSSUER VARCHAR2(24) Obieto de Nombre de Atributos Utilizados Nombre de Columna de Tasa de Negocio la Tabla de la Tabla de Datos Crecimiento Datos IDDOCNUM VARCHAR2(8) IDDOCTYPECODE NUMBER(24) MEMBERREFID Mcrchant MERCH Intcger id N(JMBER(24) ID (*) 1 P r ember ANT String employerldNum VARCHAR2(24) registro MEMBE n/a EMPLOYERTDNUM R NUMBER(24) (+ MEMBERREFID MEMBE R) Member MEMBE Integer accountld NUMBER(24) (*) 1 por AccountR RACCOU Intcger mcmbcrld ACCOUNT! D registro ole NTROLE String roleTypeCode NUMBER(24) Long timeStamp M EM BER I D VARCHAR2(8) ROLETYPECODE NUMBER( 16) TIMESTAMP Contactln CONTAC Intcger id N UMBER(24) ID (*) 1 por formation TT FOR Long createTimeStamp UMBERf 16) registro MATION Long timeStamp CREATETIMESTAMP String dataStatusCode NUMBER( l ó) String c-mailAddrcss TIMESTAMP String firstName VARCHAR2(8) String middleName DATASTATUSCODE String familyNamc VARCHAR2(32) E- Address homeAddress MA ILADDRESS PhoneNumber VARCHAR2( 16) Obieto de Nombre de Atributos Utilizados Nombre de Columna de Tasa de Negocio la Tabla de la Tabla de Datos Crecimiento Datos NUMBER(24) CONTACTI FREFID NUMBER(24) FUNDSACCTREFID PhoneNu PHONEN lnteger id NUMBER(24) ID (*) 1 Por mbcr UMBER Long timeStamp N UMBER( 16) registro String arcaCode TIMESTAMP String lücalNumber VARCHAR2(8) String extensión AREACODE String phoneTypeCode VARCHAR2( I 2) n/a LOCALNUMBER n/a VARCHAR2(8) EXTENSION VARCHAR2(8) PHONETYPECODE NUMBER(24) CONTACTINFREFID TJMBER(24) FUNDSACCTREFID Prufile PROFILE lnteger id NUMBER(24) ID (*) 1 por Long createTimcStamp NUMBER( 16) registro Long timeStamp CREATET1MESTAMP String dataStatusCode NTJMBER( I ) String dcscription TIMESTAMP VARCHAK2(8) DATASTATUSCODE VARCHAR2(80) DESCR1PT10N NoAccess NOACCE lnteger id NUMBER(24) ID Event SSEVEN Long timestamp NUMBER( 16) Obieto de Nombre de Atributos Utilizados Nombre de Columna de Tasa de Negocio la Tabla de la Tabla de Datos Crecimiento Datos T String idcntityRcf TIMESTAMP String infoText VARCHAR2(24) String networkConnlnfo IDENT1TYREF String rcqucstTypcCodc VARCHAR2(250) INFOTEXT VARCHAR2(250) NETWORKCONNINFO VARCHAR2(8) REQUESTTYPECODE Gate ayE GATEW Integer id NUMBER(24) ID vent AYEVEN Long timestamp NUMBER( 16) T String chanTypeCode TIMESTAMP String ehanOriglnfo VARCHAR2(8) String chanDestlnfo CHANTYPECODE String hostlnfo VARCHAR2(80) String message CHANOR1GINFO VARCHAR2(80) CHANDESTINFO VARCHAR2(250) HOSTINFO VARCHAR2(250) MESSAGE Devicelnf DEVICE1 integer id NUMBER(24) ID Ü NFO String dcviccNumbcr VARCHAR2(20) String deviceKey DEVICENUMBER String connectionKey VARCHAR2( 16) String processorType DEVICEKEY String appliuationType VARCHAR2(250) CONNECTIONKEY VARCHAR2( I 6) (*) Si los datos de miembro se mantienen El texto en cursivas indica campos que no se definirán. El texto en negritas indica campos que se definirán, pero no se utilizarán (valores nulos en los objetos) . PaymentProcessorHelper Esta sección define las API de prueba para simular la existencia del banco corresponsal como el procesador de pago y encargado del sistema de registro.
Paquete : com . ew . integration . interfaces - define los métodos de ayuda. com. ewp . integration. implemenations - para la aplicación de la interfaz que será utilizada por los servicios que ejecutan los métodos de ayuda. com. ewp. integration.paymentProcessor - para los servicios que ejecutan los métodos de ayuda. Clase : clase pública PaymentProcessorHelper Las interfaces de programación de aplicaciones (las API) definidas por el elemento de ayuda son: saldo - maneja la solicitud para devolver el saldo actualmente disponible historia - maneja la solicitud para devolver una lista de los últimos cinco (5) registros de transacción y un saldo actual p2p - maneja la transacción de pago p2p verifyPin -maneja la solicitud para validar un pin contra una cuenta Signatura de método: saldo public BalanceSummary saldo ( x String sourceMobileID , String sourcePIN ) ; Signatura de método: history public TransactionSummary [] history ( String devNumber, String pin) ; Signatura de método: p2p public PaymentSummary p2 ( String srcDevNumber, String srcPin, String tgtDevNumber, String transactionAmount) ; Servicios de valor agregado Muchos pequeños negocios utilizan un servicio de contabilidad comercial para manejar cuentas pendientes y su libro de contabilidad general. La presente invención preferiblemente se une al servicio de contabilidad para proporcionar un servicio de valor agregado que elimina un paso de entrada de datos y mantiene un registro oportuno de todas las transacciones. Cuando una transacción financiera se termina, la plataforma de pago envía el pago automáticamente al sistema de cuentas pendientes. Un mensaje, anotación de voz u otro medio para designar el tipo de transacción financiera también se envía al servicio de contabilidad. Transacciones fuera de línea Las modalidades de las presentes invenciones discutidas se refieren a un sistema en línea en tiempo real donde el saldo del titular de una cuenta se mantiene en el servidor de pago. Sin embargo, hay instancias en las que se desea una opción de pago fuera de línea. Por consiguiente, en una modalidad de la presente invención, el saldo en la cuenta del titular de una cuenta se almacena en un chip adjunto o asociado con el dispositivo móvil. El chip, al que comúnmente se refiere como chip inteligente, se actualiza mientras ocurre la transacción. Un ejemplo de tal chip inteligente es una tarjeta de chip inteligente fabricada por Sony Corporation y conocida como chip FeliCa. Una transmisión por lotes ocurre al final del día entre cada comercio y el proveedor del sistema de pago para llegar a un acuerdo. La opción de pago fuera de línea se ilustra en las Figuras 87 y 88 junto con la arquitectura en línea en tiempo real de una modalidad de la presente invención que se muestran en la Figura 89. Con referencia primero a la Figura 89 la MCA 8901, residente en el dispositivo 8701 móvil, interactúa con un chip (asociado con el dispositivo 8701 móvil) que funciona como el administrador 8702 fuera de línea. La MCA 8901 y el administrador 8902 fuera de línea tienen acceso a memoria 8903 compartida. En una modalidad, el administrador 8902 fuera de línea también tiene una memoria interna donde almacena cada transacción antes de que actualice la memoria 8903 compartida. El administrador 8902 fuera de línea se controla mediante la MCA en términos de establecer un saldo de cuenta inicial disponible para transacciones fuera de línea, así como para depurar transacciones anteriores del administrador 8902 fuera de línea después de que el dispositivo 8901 resincroniza las cuentas. La resincronización se realiza mediante la MCA 8901 utilizando la plataforma 8904 de comunicaciones, ya sea a un tiempo determinado todos los días o cuando una transacción en línea próxima a ocurrir se inicia por el titular de una cuenta . Con referencia ahora a la Figura 87, cuando el administrador fuera de línea se activa y detecta una terminal POS de comercio, puede ocurrir una transacción en modo fuera de línea. En este modo, el administrador 8902 fuera de línea es responsable por interactuar con la terminal 8702 POS para deducir la cantidad de la transacción. Cuando el administrador 8902 detecta una solicitud de pago, envía un mensaje al la MCA para solicitar autorización o, alternativamente, espera la autorización del usuario. Dicha autorización puede ser una clave seleccionada o una combinación de claves que se digitan en respuesta a la solicitud de autorización. Como se indica por la flecha 8703 de referencia, el pago se envía al POS 8702. En respuesta, el POS 8702 acepta el pago y envía un recibo como se indica por la flecha 8704 de referencia. El administrador 8902 mantiene un saldo corriente de la cantidad disponible para compras fuera de línea, como se indica en 8705. Más tarde, el dispositivo 8701 móvil debe resincronizarse con el servidor 8806 de pago, un proceso que se ilustra en la Figura 88. Dado que el administrador fuera de línea mantiene el saldo del titular de una cuenta disponible para compras fuera de línea, envía periódicamente un informe de gastos fuera de línea y el saldo final al servidor 8806 de pago como se indica por la flecha 8807 de referencia. Típicamente, la resincronización ocurre al final o al principio de cada día. Durante la resincronización, el administrador fuera de línea transmite al servidor 8806 el resumen de las transacciones, que incluye la cantidad de la transacción junto con una marca con fecha y el número de identificación del comercio, como se indica por la flecha 8808 de referencia. El servidor 8806 reconoce la transacción y reestablece la cantidad de la transacción fuera de línea disponible para un valor de post sincronización, como se indica por la flecha 8809 de referencia. Debe entenderse que el valor almacenado para su utilización por el administrador fuera de línea puede seleccionarse por el usuario. Así, cada día, semana o mes, el titular de una cuenta puede empezar con una cantidad preseleccionada de fondos disponibles para transacciones fuera de línea. Para confirmar saldos, el servidor 8806 también sincroniza las cuentas con cada comercio 8802, como se indica por la flecha 8810 de referencia . Las ventajas de esta modalidad fuera de línea comparadas con el envío de dinero fuera de línea a través de un teléfono móvil equipado sólo con un chip inteligente incluyen: (1) La pérdida del dispositivo móvil no significa la pérdida del dinero, ya que con la sincronización en línea, las cuentas pueden cerrarse y los saldos pueden transferirse a una nueva cuenta; y (2) las cuentas problemáticas pueden deshabilitarse fácilmente y luego rehabilitarse después de la resolución del problema. La ventaja principal de la transacción fuera de línea es el reducido tiempo de transacción para concluir la transacción. Las transacciones fuera de línea son un beneficio para el titular de una cuenta, donde una transacción con autorización de red puede ser muy lenta. Sin embargo, la combinación del modelo con autorización de red en tiempo real de la presente invención, combinado con capacidades de pago fuera de línea proporciona un sistema versátil, adaptable y útil. Como se describe en lo anterior, la presente invención se relaciona con una plataforma y servicio de pago de telefonía móvil que proporciona un método rápido, seguro y fácil para realizar pagos por individuos utilizando un dispositivo móvil. Se tiene acceso a los fondos desde el dispositivo móvil del titular de una cuenta, que puede ser un teléfono móvil, PDA u otro dispositivo de comunicación orientado de paquete, para realizar y recibir pagos. Las transacciones financieras se conducen de persona a persona (P2P) , donde cada parte se identifica por un indicador único tal como un número telefónico o un código de barras . Una Aplicación de Cliente Móvil (MCA) , residente en el dispositivo móvil, simplifica el acceso y realiza transacciones financiaras en una manera segura y rápida. La Figura 90 muestra la aplicación de la infraestructura J2ME para la MCA de acuerdo con una modalidad de la presente invención. Las secuencias 9000 de pantalla se componen de una serie de una o más instancias de clases de DataScreen como se ilustra en 9001. Una instancia de DataScreen permite al usuario proporcionar información específica de entrada o de lectura. Las especializaciones DataFieldScreen 9002 permiten la entrada de una cantidad en dólares, número telefónico, número de identificación de texto o personal, etc. Las instancias DataFieldScreen son responsables de validar la entrada de datos del usuario. El MenuDataScreen 9003 y el ListDataScreen 9004 proporcionan diversas capacidades de selección de listas y menús . Las variaciones implementan selección única (botón de selección) , multisección (cajas de selección) o interacción con menús. Las instancias ReadOnlyDataScreen 9005 proporcionan salida. Las especializaciones proporcionan un formato apropiado para los datos visualizados. Las variaciones implementan selección única (botones de selección) , multiselección (cajas de selección) o interacción con menús . Las instancias ReadOnlyDataScreen proporcionan salida. Las especializaciones proporcionan un formato apropiado para los datos visualizados . La figura 91 muestra la inicialización de la aplicación (MCA) y diagramas de secuencia de pantalla. La secuencia de inicio de la aplicación que se muestra en la FIGURA 91 muestra cómo la clase base del menú administra la visualización y selección de sus elementos de menú contenidos. Las clases de elementos de menú definen su funcionalidad asociada -por ejemplo, Pago, Saldo, Historia, etc. Típicamente, esto inicia una secuencia de pantalla. La Figura 92 muestra clases de secuencias de pantalla. Las secuencias 9201 de pantalla agrupan una serie de instancias DataScreen y dirigen la secuencia iniciada mediante las acciones del usuario tales como entrada de datos y selección de los botones Aceptar y Regresar. Las instancias de secuencias de pantalla también implementan el comportamiento que inicia por la terminación de la secuencia de pantalla. Típicamente, esto da como resultado la invocación de un método de servicio - esto es, una llamada a un servicio del lado del servidor tal como un pago de persona a persona. Las secuencias iniciadas mediante notificación del servidor se ilustran en 9202. La Figura 93 muestra la invocación del servicio sincrónico EWP J2ME . Las invocaciones de servicio sincrónicos se inician por la acción de un usuario tal como la terminación de una secuencia de pantalla tal como Pago. En este caso, el mismo hilo que inicia la comunicación con el servicio del lado del servidor también procesa el valor de retorno . La Figura 94 muestra la invocación de servicio asincrónico para los datos EWP J2ME . Si, sin embargo, el protocolo es SMS, el servicio se invoca de manera asincrónica y el hilo se completa una vez que el mensaje (SMS) se ha enviado. El valor de retorno del servicio del lado del servidor se maneja en un nuevo hilo generado a partir del hilo del sistema que recibe el mensaje de notificación. En una modalidad, esta invención se relaciona con dispositivos de comunicaciones móviles para consumidores y, más particularmente, con las maneras de incrementar la funcionalidad de los teléfonos móviles y otros dispositivos de comunicaciones para consumidores móviles con módulos removibles de identificación. La mayoría de los dispositivos de comunicaciones para consumidores móviles, por ejemplo, teléfonos móviles, PDAs (Asistentes Digitales Personales) , computadoras portátiles, y similares, contienen una tarjeta de módulo de identificación removible (IM) o chip que identifica únicamente una cuenta específica de consumidor a un portador de red de comunicaciones inalámbrica. La tarjeta/chip de IM almacena datos y proporciona algo de la "inteligencia" que permite que el dispositivo de comunicaciones para consumidores móviles funcione, por ejemplo, para hacer y recibir llamadas de voz, para enviar o recibir mensajes, para ejecutar aplicaciones de computadora y así sucesivamente. Esto permite que el usuario, por ejemplo, cambie fácilmente teléfonos móviles al remover su tarjeta/chip de IM de un teléfono y reinsertar la tarjeta/chip en otro teléfono. La necesidad de activar el segundo teléfono móvil mediante una red de comunicaciones está eliminada. Diferentes tipos de dispositivos de comunicaciones para consumidores móviles utilizan diferentes tipos de tarj etas/chips de IM. Por ejemplo, una tarjeta SIM (Módulo de Identidad del Suscriptor) funciona con dispositivos GSM (Sistema Global para Comunicaciones Móviles) . Otro tipo de tarjeta/chip de IM es un USIM (Módulo de Identidad del Suscriptor Universal) que opera con los dispositivos UMTS (Sistema Universal de Telecomunicaciones Móviles) y aún otros son los dispositivos RUIM (Módulo Desmontable de Identidad del Usuario) para CDMA (Acceso múltiple por división de código) . Para propósitos de la aplicación de esta patente, cualquier tarj eta/chip de IM se califica simplemente como IM o módulo de identificación. Pero sin importar el tipo, los IM y sus dispositivos de comunicaciones móviles centrales son generalmente sistemas "cerrados" , propiedad registrada de portadores de red de comunicaciones inalámbricas (por ejemplo, Cingular, T-Mobile, Verizon, y así sucesivamente) , el fabricante del dispositivo de comunicaciones para consumidores móviles, y los fabricantes de IM (por ejemplo, Gemplus, Oerthur, y así sucesivamente). No obstante, los protocolos de comunicación, y la interfaz entre los dispositivos de comunicaciones huésped IM, por ejemplo, el dispositivo de comunicaciones para consumidores móviles, y los IM se abren por los estándares de ingeniería establecidos por la ISO (Organización Internacional para la Estandarización) . La presente invención saca provecho de estos estándares abiertos para crear funcionalidades adicionales para dispositivos huésped de comunicaciones para consumidores móviles sin interferir con las operaciones del IM. Los dispositivos de comunicaciones para consumidores móviles todavía operan con el IM, pero una funcionalidad adicional se "inserta" en el dispositivo. La presente invención permite que los portadores móviles, fabricantes de auriculares y fabricantes de IM restrinjan ser ignorados, de modo que las aplicaciones de programa móviles puedan ejecutarse en los dispositivos de comunicaciones para consumidores móviles para mejorar la funcionalidad del dispositivo. El CPU PIP tiene un sistema operativo, llamadas de interfaz de eventos, llamadas de procesamiento de envío de tarjeta de IM. La Figura 95 muestra un dispositivo de comunicaciones para consumidores móviles ejemplares, un típico teléfono 9500 celular en este caso, que puede beneficiarse de la presente invención. Dentro del teléfono móvil hay un IM (módulo de identificación) que se ajusta a un enchufe IM. Como se indica en lo anterior, el IM contiene la información de identificación del usuario para el acceso a la red de comunicaciones y con el IM insertado en el enchufe IM, el dispositivo 9500 puede operar en la red de comunicaciones inalámbrica en una manera convencional. La Figura 96 muestra una modalidad de la presente invención. Un IM 9619, ya sea en forma de una tarjeta o chip, está montada en un alojamiento 9617 delgado que también mantiene una unidad 9618 de procesamiento programable. El alojamiento 9617 interconecta el IM 9619 y la unidad 9618 de procesamiento programable, y por medio de un cable 9616 plano, el alojamiento 9617 se conecta a un adaptador 9615 del IM. El adaptador 9615 del IM puede ajustarse al enchufe del IM de los dispositivos 9500 de comunicaciones para consumidores móviles, como se ilustra en la Figura 97. El adaptador 9615 del IM se ajusta al enchufe 9625 del IM del teléfono 9500 celular que tiene su cubierta posterior (no mostrada) desmontada. Como se muestra, el adaptador 9615 del IM se ajusta en el enchufe 9625 del IM y conecta el IM 9619 a lo largo del cable 9616 plano y la unidad 9619 de procesamiento programable. Dado que el cable 9616 es flexible, el alojamiento 9617 puede voltearse en el teléfono 9500 celular, como se muestra en la Figura 98. En la práctica, una batería (no mostrada) para el teléfono 9500 celular puede instalarse sobre el enchufe 9625 del IM y el adaptador 9615 del IM y luego el alojamiento 9617 volteado sobre la batería, antes de que la cubierta pueda reemplazarse, como se muestra en la Figura 95. La Figura 99 muestra la conexión ecléctica entre el adaptador 9615 del IM, el cable 9616 plano, la unidad 9618 de procesamiento programable y el IM 9619. Todo el tráfico electrónico (por ejemplo, comunicaciones de datos) entre el enchufe 9625 del IM en los dispositivos 9500 de comunicaciones para consumidores móviles y el IM 9619 deben pasar a través de la unidad 9618 de procesamiento programable. Como se explica más adelante, la unidad 9618 de procesamiento programable opera como una puerta para permitir que el tráfico electrónico pase libremente para comunicaciones inalámbricas convencionales o nativas en un caso. En otro caso, el tráfico electrónico puede interceptarse y mejorarse mediante aplicaciones de programa ejecutándose en la unidad 9618 de procesamiento programable para proporcionar una funcionalidad mejorada al usuario del dispositivo 9500. La unidad 9618 de procesamiento programable puede implementarse en un microcontrolador, un ASIC (Circuito Integrado para Aplicaciones Específicas) , el llamado SOC (Sistema en un Chip) y otros circuitos integrados. Cada uno de estos tipos de circuitos integrados tiene una o más y unidades y memoria de procesamiento de capacidad variable y ofrece diferentes grados de personalización, capacidad y costos para los requerimientos particulares de las aplicaciones de programas. La memoria de la unidad 9618 de procesamiento programable mantiene las aplicaciones de programa para funcionalidades mejoradas y las unidades de procesamiento ejecutan las aplicaciones de programa. Las aplicaciones de programa se cargan a través de la red de comunicaciones inalámbrica. En cualquier caso, la unidad 9618 de procesamiento programable opera con un sistema 10110 operativo, llamadas de interfaz de eventos 10111, llamadas 10112 de procesamiento de envío de tarjeta del IM, un registro 10113 de aplicación, y un lenguaje y tiempo de ejecución 10114 programáticos, como se ilustra en la Figura 101. El sistema operativo facilita la etapa de las comunicaciones entre los dispositivos 9500 huésped de comunicaciones para consumidores móviles y el IM 9619, como se explica en lo anterior. El sistema operativo también proporciona llamadas programáticas a las aplicaciones de programa que están registradas e instaladas en la unidad 9618 de procesamiento programable. Las llamadas 10111 de interfaz de eventos proporcionan una interfaz de eventos programática que una aplicación de programa implementa para obtener control programático sobre los dispositivos huésped de comunicaciones para consumidores móviles a partir de eventos específicos del dispositivo móvil, por ejemplo, presionar un botón, una señal de llamada, y así sucesivamente. Durante este control, la aplicación de programa tiene la capacidad de agregar funcionalidad y procesamiento al evento. Las llamadas 10112 de procesamiento de envío de tarjeta del IM proporcionan una interfaz de eventos programáticos que una aplicación de programa implementa para obtener control programático sobre los dispositivos huésped de comunicaciones para consumidores móviles a partir de la devolución del procesamiento del IM nativo del evento de dispositivos de comunicaciones para consumidores móviles. El IM siempre se incluye al final de la cadena de procesamiento de un evento. Durante este control, la aplicación de programa tiene la capacidad de agregar funcionalidad y procesamiento de envío del evento antes de que los dispositivos de comunicaciones para consumidores móviles vuelvan a obtener control . El registro 10113 de aplicación proporciona una configuración, de tal modo que aplicaciones de programa pueden registrarse como interesadas en eventos específicos (y, por tanto, llamarse programáticamente cuando esos eventos ocurren) . Diversas aplicaciones de programa pueden registrarse para el mismo evento y se llaman en una cadena. El lenguaje y tiempo de ejecución 10114 programático proporciona un lenguaje y plataformas programáticos con los que las aplicaciones se crean. Diversos lenguajes/tiempos de ejecución apropiados que son estándar incluyen BREW (Ambiente Binario de Desarrollo para Inalámbricos) desarrollado por Qualcomm, Inc., de San Diego, California para proporcionar un conjunto estándar de interfaces de aplicación y programación para que los desarrolladores agreguen fácilmente nuevas características y aplicaciones al hardware inalámbrico basado en Qualcomm, por ejemplo, auriculares equipados con conjuntos de circuitos integrados CDMA; J2ME (Java 2 Edición portátil) , una tecnología basada en Java para sistemas móviles de Sun Microsystems, Inc., de Santa Clara, California; . ET de Microsoft, Inc., de Redmond, Washington para proporcionar una plataforma de desarrollo de software para el sistema operativo Windows y utiliza XML (Lenguaje de Marcas Extensible) ; y Symbian, una plataforma diseñada para dispositivos móviles de una sociedad conjunta de muchas compañías, incluyendo L.M. Ericsson de Estocolmo, Suecia, y Nokia Corp. de Espoo, Finlandia. Desde luego, las plataformas/lenguaje precedentes representan sólo ejemplos y otros lenguajes de ejecución programables pueden utilizarse. Algunos ejemplos de aplicaciones de programa que pueden ejecutarse en la unidad de procesamiento programable se describen en esta aplicación. Por ejemplo, a continuación, la aplicación describe una manera de enviar datos a través del canal de voz, más que por el canal de datos, de la red de comunicaciones inalámbrica de dispositivos de comunicaciones para consumidores móviles. En una aplicación de programa, los dispositivos de comunicaciones para consumidores móviles pueden enviar mensajes de texto a otros dispositivos de comunicaciones para consumidores móviles a través de su canal de voz. En otra aplicación de la patente, los pagos móviles pueden realizarse mediante los dispositivos de comunicaciones para consumidores móviles a través de su canal de voz. Hasta ahora, se ha descrito que los dispositivos de comunicaciones para consumidores móviles, tales como el teléfono 9500 celular de la Figura 95, requieren únicamente un IM que se ajuste al enchufe del IM del dispositivo para captar una red de comunicaciones inalámbrica. Por otro lado, las computadoras portátiles no tienen típicamente un enchufe del IM incorporado. Las computadoras portátiles utilizan un adaptador 10021 USB que acepta el IM del usuario y el adaptador 10021 USB se conecta a un conector 10022 USB que se ajusta en el puerto USB de la computadora portátil. La Figura 100 muestra cómo el adaptador 9615 previamente descrito se ajusta al adaptador 10021 USB para poner al IM 9619 en contacto con la computadora portátil huésped. Con el IM 9619 en contacto con la computadora portátil para captar la red de comunicaciones inalámbrica, la unidad 9618 de procesamiento programable permite funcionalidad adicional a través de las aplicaciones de programa. Los dispositivos de comunicaciones para consumidores móviles, tales como teléfonos móviles, ordinariamente utilizan un canal de voz para transmitir y recibir voces. La presente invención proporciona una manera para que las aplicaciones de programa comuniquen sus datos a través del canal de voz de los dispositivos de comunicaciones para consumidores móviles. La presente invención permite que las aplicaciones que pueden crearse en varias plataformas/tiempos de ejecución de programa para aplicaciones móviles se interconecten mediante el canal de voz de los dispositivos huésped de comunicaciones para consumidores móviles. Ejemplos de plataformas incluyen BREW (Ambiente Binario de Desarrollo para Inalámbricos) desarrollado por Qualcomm, Inc., de San Diego, California para proporcionar un conjunto estándar de interfaces de aplicación y programación para que los desarrolladores agreguen fácilmente nuevas características y aplicaciones al hardware inalámbrico basado en Qualcomm, por ejemplo, auriculares equipados con conjuntos de circuitos integrados CDMA; J2ME (Java 2 Edición portátil) , una tecnología basada en Java para sistemas móviles de Sun Microsystems, Inc., de Santa Clara, California; .NET de Microsoft, Inc., de Redmond, Washington para proporcionar una plataforma de desarrollo de software para el sistema operativo Windows y utiliza XML (Lenguaje de Marcas Extensible) ; Symbian, una plataforma diseñada para dispositivos móviles de una sociedad conjunta de muchas compañías, incluyendo L.M. Ericsson de Estocolmo, Suecia, y Nokia Corp., de Espoo, Finlandia. Desde luego, otras plataformas/tiempos de ejecución programables pueden utilizarse . La Figura 102 muestra un arreglo por medio del cual los datos se transmite a través de un canal de voz de una red de comunicaciones inalámbrica, de acuerdo con una modalidad de la presente invención. Un ejemplo de dispositivo 10210 de comunicaciones para consumidores móviles, por ejemplo, un teléfono móvil, PDA y similares, se comunica a través de un canal 10211 de voz de la red de comunicaciones inalámbrica. Ordinariamente, estas comunicaciones son conversaciones. Una API 10223 (Interfaz de Programa de Aplicación) permite que los datos de una aplicación móvil, por ejemplo, la aplicación 10221 de cliente huésped, implementada en una plataforma/tiempo de ejecución descrito en lo anterior para comunicarse a través del canal 10211 de voz a un sistema 10212 de servidores. La API 10223 codifica los datos en tonos para transmitir a través del canal 10211 de voz. En este ejemplo, el antiguo DTMF (Tono Dual Multi Frecuencia) se utiliza, pero otra codificación adecuada para el canal de voz puede utilizarse. Con el DTMF recibiendo los tonos, el servidor 10212 a través de la red de comunicaciones inalámbrica sujeta la unidad 10226 IVR (Respuesta de Voz Interactiva) para descodificar los tonos. La IVR envía y recibe tonos DTMF (algunas veces llamados "tonos al tacto") y se encuentra en muchos sistemas de contestación telefónica automática actuales. Esto permite que una computadora interactúe automáticamente con un humano utilizando Reconocimiento de Voz, Reproducción de Sonido, Texto a Voz (TTS) y tecnologías DTMF. Un "Enchufe" 10224 IVR es una API adaptada para IVR para poner los datos de forma apropiada para una aplicación 10222 en el servidor 10212. Esto permite que la aplicación 10221 alojada en los dispositivos 10210 de comunicaciones para consumidores móviles se comunique con la aplicación de la empresa 10222 alojada en el servidor 10212 a través del canal 10211 de voz. Las señales de datos viajan en ambas direcciones entre las dos aplicaciones 10221 y 10222. Las comunicaciones que simplemente viajan entre los dispositivos de comunicaciones para consumidores móviles 10210 y el servidor 10212 son ejemplos de comunicaciones cliente/servidor a través del canal de voz. Por otro lado, la operación de la aplicación 10222 del servidor puede ser para simplemente transmitir los datos de los dispositivos 10210 de comunicaciones para consumidores móviles a otros dispositivos de comunicaciones para consumidores móviles. Este es un ejemplo de comunicaciones semejantes a través del canal de voz . La API en una modalidad de la presente invención, por ejemplo, las API 10223 y 10224 de la Figura 102, se basa en un simple modelo "sendRequest ( ) " /processRequest ( ) " con estructuras de datos solicitud/respuesta conocidas por parte del cliente y el servidor. Las API 10223 y 10224 son un conjunto pareado de las API de clientes y servidores que los desarrolladores de aplicaciones de telefonía móvil y servidores de empresas utilizan para construir una aplicación cliente/servidor completa. El software de procesamiento de datos de voz (por ejemplo, componentes de biblioteca) que el cliente (dispositivo de comunicaciones del consumidor móvil) y los lados del servidor implementan algoritmos de procesamiento de datos de voz para la comunicación de datos a través del canal de voz. Estos algoritmos son, desde luego, distintos de las aplicaciones 10221 y 10223 cliente/servidor particulares. Un ejemplo de una API es el siguiente: SendRequest ( ) Función del cliente: Esta es la única interfaz API que una aplicación de cliente móvil utiliza para enviar una solicitud/datos a una aplicación del servidor de una empresa. Entrada: Una estructura de solicitud Salida: Una estructura de respuesta ProcessRequest ( ) Función del servidor: Esta es la única interfaz API que la aplicación del servidor de la empresa implementa para procesar la solicitud de un cliente móvil que llama. La lógica de procesamiento es completamente responsabilidad de la aplicación de la empresa "huésped" y es también responsabilidad de la aplicación de la empresa huésped recopilar los datos de respuesta que será devuelta al cliente móvil que llama. Entrada: Una estructura de solicitud Salida: Una estructura de respuesta Estructura de respuesta: CommandID - Un valor numérico que representa únicamente un comando (y datos de parámetros asociados) que se entiende tanto por el cliente huésped como por las aplicaciones del servidor. ServerAddress - Un valor numérico que representa un "número telefónico" que se utilizará para "marcar" una llamada de voz que llegará al componente de IVR del servidor que hace las veces de procesador frontal del servicio de destino de la empresa. ParameterData - Una formación de ParameterData que se asocia a "esta" solicitud CommandID. Estructura de respuesta: ResponseID - Un valor numérico que únicamente representa una respuesta (y datos de parámetros asociados) que se entiende tanto por el cliente huésped como por las aplicaciones del servidor. ParameterData - Una formación ParameterData que se asocia a "este" resultado ResponseID. Estructura ParameterData: ParameterID - Un valor numérico que únicamente representa un parámetro dentro de un CommandID dado y se entiende tanto por el cliente huésped, como por las aplicaciones del servidor. ParameterType - Un valor numérico con los siguientes parámetros: 1 - numérico 2 - alfa ... otros tipos ParameterValue - El valor real del parámetro Codificación/descodificación Como se mencionó con anterioridad, una API puede utilizar diferentes algoritmos de codificación/descodificación, de acuerdo con la presente invención. El siguiente es un ejemplo para codificar con DTMF. Estas reglas de codificación DTMF están basadas en reglas comúnmente aceptadas para digitar números y letras utilizando el teclado que se encuentra en los teléfonos. Todos los elementos de datos se codifican al final como un número . Cada elemento de datos completo termina con un código "#" . Los elementos de datos numéricos utilizan sus números DTMF asociados . Los elementos de datos numéricos se envían como una secuencia sin interrupciones. Cada secuencia de elementos de datos numéricos completa termina con un código "#" . Los elementos de datos alfa se dividen en elementos de caracteres individuales. Los elementos de caracteres alfa individuales se codifican utilizando el siguiente patrón: "A" = 2 ...y así sucesivamente utilizando reglas de codificación alfa DTMF estándar. Los elementos de caracteres alfa individuales terminan con código "#" . Cada elemento de datos alfa termina con un código "#" . Cada estructura solicitud/respuesta completa termina con un código "#" . El ejemplo de codificación anterior muestra específicamente caracteres numéricos y alfabéticos en mayúsculas . Sin embargo, la codificación de minúsculas y caracteres especiales también puede hacerse. Por lo tanto, los elementos de la API descritos con anterioridad proporcionan un protocolo mediante el cual los datos de las aplicaciones de programa pueden comunicarse a través del canal de voz de los dispositivos de comunicación del consumidor móvil. Ejemplos de aplicaciones de datos del canal de voz Un ejemplo de una aplicación es un mensaje de texto simple a través del canal de voz, más que a través del canal de datos, como se realiza convencionalmente . La aplicación 10221 alojada en los dispositivos 10210 de comunicaciones para consumidores móviles de la Figure 102, por ejemplo, envía señales alfanuméricas con una identificación del destinatario, por ejemplo, un número Telefónico, a través del canal 10211 de voz. La aplicación 10222 de la empresa en el servidor 10212 simplemente transmite las señales alfanuméricas a los destinatarios designados a través de otro canal de voz. Desde luego, se asume que el destinatario también tiene las capacidades descritas de recibir y enviar datos a través de un canal de voz . Un ejemplo más complejo de una aplicación de red que utiliza de manera más completa las características API particulares descritas con anterioridad es una funcionalidad de pago móvil para consumidores móviles. Toda comunicación de datos cliente/servidor requerida se realiza mediante una "llamada telefónica" de canal de voz. En este ejemplo de aplicación, se asume que los consumidores móviles cuentan con dispositivos de comunicación móvil capaces de ejecutar una aplicación de pago móvil y que el plan de servicio móvil del consumidor permite únicamente llamadas de voz. Un consumidor "de origen" quiere enviar dinero desde su cuenta móvil a la cuenta móvil de un amigo (consumidor "de destino") . Tanto el consumidor fuente como el de destino están "inscritos" para recibir el servicio que la aplicación del servidor de la empresa proporciona. La aplicación del servidor de la empresa proporciona un servicio web API que transfiere fondos de una cuenta de origen a una cuenta de destino. Los comandos en este ejemplo son payRequest, representado por CommandID 1, y payResponse, representado como CommandID 2. Las estructuras de datos de parámetros se definen en las dos tablas a continuación: Tabla E: Definición de datos del parámetro payRequest : Nombre del Párametro Descripción del Párametro Tipo de Datos ID del Párametro suurceAccüuntNumbcT Número de cuenta del 1 - numérico l consumidor que envía el dinero SüurcePIN Datos de autentificación 1 - numérico 2 del consumidor que envía el dinero payAmount Cantidad de dinero que el 1 - numérico 3 consumidor de origen desea enviar al consumidor de destino largctAccountNumber Número de cuenta del 1 - numérico 4 consumidor al que se le envía el dinero payMcssage Un mensaje que el 2 - alfa 5 consumidor de origen desea adjuntar a su transacción (por ejemplo, una nota recordatoria) Tabla F: Definición de datos del parámetro payResponse : Ahora, para el consumidor fuente para pagar a un consumidor objetivo, ocurre las siguientes operaciones e interacciones: La aplicación huésped de cliente móvil interactúa con el consumidor fuente y recopila los siguientes datos: sourceAccountNumber - "123456789" sourcePIN - "4321" payAmount - "15" sourceAccountNumber - "987654321" payMessage - "GRACIAS" La aplicación huésped de cliente móvil "conoce" los siguientes datos como resultado de contexto y configuración: commandID - "1" (por ejemplo, payRequest) serverAddress - "8885551212" (por ejemplo, el "número telefónico" del componente de IVR de la aplicación de la empresa) La aplicación huésped móvil reúne las siguientes estructuras de datos: ParameterData [1] ParameterID = 1 ParameterType = 1 ParameterValue = "123456789" ParameterData [2] ParameterID = 2 ParameterType = 1 ParameterValue = "4321" ParameterData [3] ParameterID = 3 ParameterType = 1 ParameterValue = "15" ParameterData [4] ParameterID = 4 ParameterType = 1 ParameterValue = "987654321" ParameterData [5] ParameterID = 5 ParameterType = 2 ParameterValue = "Gracias" Solicitud commandID = 1 serverAddress = "8885551212" ParameterData = 5 element ParameterData formación a partir de lo anterior La aplicación móvil ahora llama al API SendRequest () utilizando los datos de estructura Request mencionada en lo anterior. El control ahora pasa al cliente API. El cliente API ahora realiza el algoritmo de codificación y convierte la estructura Request en la siguiente cadena de texto: 1#1#1#123456789#2#1#4321#3#1#15#4#1#987654321#5#2#8 #44#2#66#55#7777### Al aplicar las reglas anteriores al ejemplo codificado anterior, se aprecia lo siguiente: El primer "1#" significa "CommandID 1" que se sabe es un comando "payRequest" El siguiente "1#" significa "ParameterID 1" que se sabe es un parámetro "sourceAccountNumber" . El siguiente significa "parámetro AMD tipo 1" que se conoce es "numérico." El siguiente "123456789#" significa que el valor sourceAccountNumber es "123456789." ...y asi sucesivamente para los tipos de parámetros numéricos La terminación "8#44#2#66#55#7777##" es la codificación DTMF alfa para la palabra "GRACIAS." El último "#" indica una secuencia de elementos de datos alfa completa.
El "#" final indica el final de los datos de solicitud/respuesta completa. Regresar a las operaciones de la aplicación de ej emplo . La API marca entonces el "número telefónico" del servidor indicado (por ejemplo, "8885551212") e inicia una llamada de voz. El componente IVR de servidor "recoge" y espera los datos de solicitud DTMF codificada. El cliente API entonces transmite toda la solicitud DTMF codificada anterior. Cuando el # final se recibe, el componente de "conexión" IVR del servidor comienza a descodificar los datos de solicitud DTMF codificada. Para hacer esto, la "conexión" IVR utiliza lo contrario de las reglas de codificación presentadas en lo anterior. La "conexión" IVR ahora ha ensamblado un duplicado exacto de la estructura de Solicitud de cliente, solamente ahora en el espacio de memoria del lado del servidor. La "conexión" IVR ahora invoca la aplicación del servidor empresarial mediante la interfaz ProcessRequest ( ) la cual ha xmplementado la aplicación del servidor empresarial. La aplicación del servidor empresarial procesa la solicitud por consiguiente. La aplicación del servidor empresarial entonces ensambla una estructura de Respuesta justo como la aplicación de cliente móvil ensambló la estructura de Solicitud. La aplicación del servidor empresarial regresa la estructura de Respuesta y el control a la conexión IVR. La conexión de IVR entonces codifica la estructura de Respuesta como se describe en lo anterior (es decir, en este caso con el estado y los elementos de datos de transactionNumber) . El IVR trasmite los datos de respuesta DTMF codificada a la aplicación de cliente móvil API. La aplicación de cliente móvil API descodifica los datos de respuestas DTMF codificado en una estructura de Respuesta de lado del cliente utilizando las reglas de descodificación descritas en lo anterior (es decir, en este caso en una estructura de Respuesta) . La API regresa la estructura de Respuesta y el control a la aplicación móvil de cliente del ordenador central . La aplicación móvil de cliente de ordenador central vuelve a obtener el control, tiene acceso a la estructura de Respuesta del servidor y continúa el procesamiento. Por lo tanto, la presente invención proporciona aplicaciones de programas para comunicarse sobre el canal de voz de dispositivos de comunicación de consumidor móvil. Como se menciona previamente, la codificación diferente de la DTMF puede seleccionarse para acelerar la transmisión de datos a través del canal de voz. Tal codificación puede depender de la aplicación particular en el dispositivo de comunicación de consumidor móvil de ordenador central y el servidor empresarial correspondiente. Los dispositivos de comunicación de consumidor móvil podrían adaptarse para comunicar datos de aplicación de programas a través del canal de voz, en lugar del canal de datos de la red de comunicación inalámbrica. Varias modalidades especificas de la invención incluyen: 1. Un sistema de pago individualizado móvil que comprende : un cliente móvil; un servidor para manejar un sistema de pago de bucle cerrado; y un protocolo que permite al cliente móvil funcionar, junto con el servidor como una "cartera móvil" . 2. El sistema de la reivindicación 1, en donde el protocolo además comprende : una UI simplificada que sólo requiere ingreso paso por paso de datos de solicitud y después despliegue de datos de respuesta. 3. El sistema de la reivindicación 1, que además comprende medios para utilizar los servicios de datos del dispositivo móvil mediante invocaciones de programas HTTPS API. 4. El sistema de la reivindicación 3, que además comprende medios de seguridad para invocar las invocaciones programadas HTTPS API . 5. El sistema de la reivindicación 1, que además comprende medios para utilizar los servicios de texto del SMS del dispositivo móvil mediante invocaciones programadas SMS API. 6. Un sistema de pago individualizado móvil que comprende: una aplicación de cliente móvil dedicada para realizar transacciones financieras; y un servidor, adaptado para comunicarse con la aplicación de cliente, para proporcionar un servicio de pago que utiliza llamadas de método de paso directo a un sistema de banco corresponsal . 7. El sistema de la reivindicación 6, que además comprende una cuenta común mantenida por el sistema de banco corresponsal . 8. El sistema de la reivindicación 7, en donde la cuenta común representa una pluralidad de tarjetas de débito prepagadas . 9. El sistema de la reivindicación 8, en donde la tarjeta de débito prepagada se enlaza a una cuenta de cheques en el sistema de banco corresponsal.
. El sistema de la reivindicación 8, en donde cada una de las tarjetas de débito prepagadas pueden recargarse al transferir fondos a o desde una cuenta enlazada en respuesta a una llamada telefónica iniciada por el programa de cliente. 11. El sistema de la reivindicación 6, que además comprende por lo menos una aplicación de cliente móvil adicional donde la combinación de la aplicación de cliente móvil, el servidor y por lo menos una aplicación de cliente móvil adicional comprenden un sistema de pago de bucle cerrado . 12. El sistema de la reivindicación 6, en donde la combinación de aplicación de cliente móvil, el servidor y por lo menos una aplicación de cliente móvil adicional comprende un sistema de transferencia de pago de persona a persona. 13. El sistema de la reivindicación 6, en donde la combinación de ' aplicación de cliente móvil, el servidor y por lo menos una aplicación de cliente móvil adicional comprende un sistema de transferencia de pago de igual a comercio. 14. Un sistema de pago individualizado móvil que comprende : un cliente y un protocolo alámbrico de plataforma se utiliza junto con un codee de la MCAP para serializar/desearilizar datos para comunicación entre una pluralidad de dispositivos móviles y la plataforma, la plataforma comprende un centro de datos que aloja servicios basados en J2EE. 15. El sistema de la reivindicación 14, en donde el codee de la MCAP es un componente en los dispositivos móviles. 16. El sistema de la reivindicación 14, en donde el centro de datos maneja serialización y deserialización de acuerdo con el cliente y las especificaciones de protocolo alámbrico de plataforma. 17. El sistema de la reivindicación 14, en donde cierta funcionalidad está presente en el dispositivo móvil que incluye la capacidad de desplegar campos de entrada y capturar entradas de titular de una cuenta, la capacidad de utilizar los servicios de datos del servicio móvil mediante invocaciones programadas HTTPS API. 18. El sistema de la reivindicación 14, en donde cierta funcionalidad está presente en el dispositivo móvil que incluye la capacidad de desplegar campos de entrada y capturar entradas de titular de una cuenta, la capacidad de utilizar los servicios de datos del dispositivo móvil mediante servicios de texto del SMS del dispositivo móvil mediante invocaciones programadas SMS API. 19. El sistema de la reivindicación 14, en donde los servicios de datos persistentes del dispositivo móvil son mediante invocaciones programadas API.
. El sistema de la reivindicación 14, en donde los dispositivos móviles comprende la capacidad de interceptar mensajes de entrada en el dispositivo móvil y "despertar" la MCAP para procesar donde un mensaje del SMS de entrada se intercepta en un puerto específico y se maneja por el protocolo. 21. El sistema de la reivindicación 14, en donde el dispositivo móvil comprende medios para integrarse con programas con una "agenda de dirección" del dispositivo móvil de modo que un campo de entrada especifico pueda "enlazarse" a la agenda de direcciones y para notificar con programas al titular de una cuenta del dispositivo móvil de eventos notables mediante sonidos, vibración o luz. 22. Un método para operar un sistema de pago de bucle cerrado que comprende: activar una aplicación de cliente en un dispositivo habilitado por IP; establecer un canal de comunicación en un servidor de pago; transmitir una solicitud desde la aplicación de cliente hasta el servidor de pago donde la solicitud incluye una cantidad de pago y un número de identificación para identificar al beneficiario; ajustar saldos de cuentas para reflejar la solicitud; y notificar al beneficiario de la recepción de pago. 23. El método de la reivindicación 22, que además comprende : establecer una cuenta para el beneficiario si el pago se dirige a un número para el cual no existe ninguna cuenta; y un incentivo viral para que un usuario abra una cuenta para recibir los fondos depositados en la cuenta establecida . 24. El método de la reivindicación 22, que además comprende : solicitar del peticionario de pago que agregue una cantidad "gratificación" y el perfil para el beneficiario indica que es apropiada una gratificación; y ajustar los saldos para reflejar el pago adicional de la gratificación. 25. El método de la reivindicación 22, que además comprende : establecer cada transacción en tiempo real al asignar fondos a cuentas respectivas de una cuenta común. 26. El método de la reivindicación 22, que además comprende : establecer las transacciones seleccionadas en un modo fuera de línea. 27. El método de la reivindicación 26, que además comprende iniciar una transacción basándose en un enlace de comunicación de campo cercano. 28. El método de la reivindicación 26, que además comprende iniciar una transacción basándose en un enlace de comunicación establecido por un transpondedor y receptor de identificación por radiofrecuencia (RFID) . 29. El método de la reivindicación 26, que además comprende registrar una descripción de cada transacción en un programa de cuentas juntas con la cantidad de la transacción. 30. El método de la reivindicación 29, en donde el registro comprende enviar una descripción verbal de la transacción en tiempo real a un programa de cuentas . 31. El método de la reivindicación 29, en donde el registro comprende enviar una descripción de texto de la transacción en tiempo real a un programa de cuentas por el SMS . 32. El método de la reivindicación 22, en donde iniciar la aplicación de cliente comprende: ingresar una primera contraseña para identificar al usuario y para activar la operación de la aplicación de cliente ; ingresar una segunda contraseña para establecer un enlace seguro al servidor de pago; y verificar que las contraseñas concuerden con la ID de llamadas esperadas. 33. Un método para llevar a cabo una transacción financiera que comprende: enviar una solicitud de una transacción financiera de un dispositivo móvil a un servidor de pago mediante una primera trayectoria de comunicación; enviar un número de identificación personal (PIN) mediante una segunda trayectoria de comunicación; asociar la solicitud con el PIN en el servidor de pago; y concluir la transacción financiera basándose en la asociación entre la solicitud y el PIN. 34. El método de la reivindicación 33, en donde el envío de la solicitud además comprende: formar un comando; y enviar el comando por Servicios de Mensajes Cortos (SMS) . 35. El método de la reivindicación 34, en donde formar el comando además comprende: solicitar pago. 36. El método de la reivindicación 35, en donde formar el comando además comprende : solicitar el pago a un igual. 37. El método de la reivindicación 35, en donde formar el comando además comprende: solicitar pago de un comercio. 38. El método de la reivindicación 35, en donde formar el comando además comprende: agregar un mensaje al comando. 39. El método de la reivindicación 38, en donde formar el comando además comprende : agregar un registro que mantiene la notación en el comando . 40. El método de la reivindicación 39, en donde enviar el comando además comprende: enviar el comando a una aplicación de cuentas. 41. El método de la reivindicación 39, en donde enviar el comando además comprende: enviar el comando a un proveedor de servicios de valor agregado . 42. El método de la reivindicación 33, en donde formar el comando además comprende: solicitar un saldo de cuenta. 43. El método de la reivindicación 42, que además comprende : recibir un mensaje de saldo de cuenta por el SMS. 44. El método de la reivindicación 33, que además comprende : solicitar un historial de cuentas. 45. El método de la reivindicación 44, que además comprende: recibir un mensaje de historial de cuentas por el SMS . 46. El método de la reivindicación 33, que además comprende : solicitar que una solicitud de pago sea enviada a un igual . 47. El método de la reivindicación 46, que además comprende : enviar una solicitud de mensaje de pago por el SMS al igual. 48. El método de la reivindicación 47, que además comprende : recibir una indicación de que el pago ha sido autorizado o rechazado, la indicación enviada por el SMS. 49. El método de la reivindicación 48, que además comprende : solicitar al igual establecer una cuenta a partir de la cual se haga el pago al peticionario, la solicitud enviada por el SMS . 50. El método de la reivindicación 33, que además comprende : solicitar ayuda. 51. El método de la reivindicación 50, que además comprende : recibir un mensaje de ayuda por el SMS. 52. El método de la reivindicación 33, en donde el dispositivo móvil es un teléfono celular. 53. El método de la reivindicación 33, en donde la primera trayectoria de comunicación es el canal de comunicación de texto del SMS y la segunda trayectoria de comunicación es un canal de comunicación de voz. 54. El método de la reivindicación 53, en donde el PIN se codifica en DTMF. 55. El método de la reivindicación 53, en donde el PIN se articula y después se descodifica por un sistema de reconocimiento de voz interactivo. 56. Un método para llevar a cabo una transacción financiera utilizando el dispositivo móvil que comprende: activar una aplicación de cliente móvil para manejar la solicitud financiera; desplegar una interfaz de usuario para formar un comando ; enviar una solicitud que comprende el comando de una transacción financiera de un dispositivo móvil a un servidor de pago mediante una primera trayectoria de comunicación; enviar un número de identificación personal (PIN) mediante una segunda trayectoria de comunicación; asociar la solicitud con el PIN en el servidor de pago; y concluir la transacción financiera basándose en la asociación entre la solicitud y el PIN. 57. El método de la reivindicación 56, en donde el envío de la solicitud además comprende: enviar el comando por un protocolo de mensaje. 58. El método de la reivindicación 57, en donde formar el comando además comprende: solicitar pago. 59. El método de la reivindicación 56, en donde formar el comando además comprende: solicitar pago a un igual. 60. El método de la reivindicación 59, en donde formar el comando además comprende: solicitar pago a un comercio. 61. El método de la reivindicación 56, en donde formar el comando además comprende: agregar un mensaje al comando. 62. El método de la reivindicación 61, en donde .formar el comando además comprende: agregar un registro que mantiene la notación en el comando . 63. El método de la reivindicación 62, en donde enviar el comando además comprende: enviar el comando a una aplicación de cuentas. 64. El método de la reivindicación 62, en donde enviar el comando además comprende: enviar el comando a un proveedor de servicio de valor agregado. 65. El método de la reivindicación 56, en donde formar el comando además comprende: solicitar un saldo de cuenta. 66. El método de la reivindicación 65, que además comprende : recibir un mensaje de saldo de cuenta por un protocolo seleccionado. 67. El método de la reivindicación 56, que además comprende : solicitar un historial de cuenta. 68. El método de la reivindicación 67, que además comprende: recibir el mensaje de historial de cuenta por un protocolo seleccionado. 69. El método de la reivindicación 56, que además comprende : solicitar que una solicitud de pago sea enviada a un igual . 70. El método de la reivindicación 69, que además comprende : enviar una solicitud de mensaje de pago por un protocolo seleccionado al igual. 71. El método de la reivindicación 70, que además comprende : recibir una indicación de que el pago ha sido autorizado o rechazado, la indicación enviada por el SMS. 72. El método de la reivindicación 71, que además comprende : solicitar al igual que establezca una cuenta a partir de la cual se haga el pago al peticionario, la solicitud enviada por el SMS. 73. El método de la reivindicación 56, que además comprende : solicitar ayuda. 74. El método de la reivindicación 73, que además comprende : recibir un mensaje de ayuda por el SMS. 75. El método de la reivindicación 56, en donde el dispositivo móvil es un teléfono celular. 76. Un sistema de pago individualizado móvil que comprende : una aplicación de cliente móvil dedicada a realizar transacciones financieras; y un servidor, adaptado para comunicarse con la aplicación de cliente, para proporcionar un servicio de pago enlazado al seleccionado de una pluralidad de cuentas. 77. El sistema de la reivindicación 76, que además comprende por lo menos una aplicación de cliente móvil adicional donde la combinación de la aplicación de cliente móvil, el servidor y por lo menos una aplicación de cliente móvil adicional comprende un sistema de pago de bucle cerrado con cuotas de transacción bajas. . 78. El sistema de la reivindicación 76, que además comprende por lo menos una aplicación de cliente móvil adicional donde la combinación de la aplicación de cliente móvil, el servidor y por lo menos una aplicación de cliente móvil adicional comprende un sistema de pago de bucle cerrado sin cuotas de transacción. 79. El sistema de la reivindicación 76, que comprende un sistema de transferencia de pago de persona a persona . 80. El sistema de la reivindicación 79, que comprende una cuota por servicio mensual cargado a cada igual . 81. El sistema de la reivindicación 76, que comprende un sistema de transferencia de pago de consumidor a comercio donde el consumidor es cargado con una cuota de transacción. 82. El sistema de la reivindicación 81, que además comprende seleccionar un plan de pago de comercio que paga el cuota de transacción a nombre del consumidor. 83. Un método para compra rápida que comprende: seleccionar un producto; activar una aplicación de cliente móvil para manejar una transacción financiera; realizar una compra; y recibir automáticamente producto seleccionado en una dirección específica. 84. Un método para compra rápida que comprende: seleccionar un producto; activar una aplicación de cliente móvil para manejar una transacción financiera; realizar una compra; y recibir automáticamente el producto seleccionado en una ubicación geográfica específica. 85. El método de la reivindicación 84, que además comprende activar la transacción con una exploración de código de barras utilizando un código de barras externamente visible asociado con un teléfono celular. 86. El método de la reivindicación 84, que además comprende activar la transacción con un dispositivo de comunicación de campo cercano asociado con un teléfono celular. 87. El método de la reivindicación 84, que además comprende activar la transacción con un dispositivo de RFID asociado con un teléfono celular. 88. Un método para compra rápida que comprende: preautorizar una compra por un producto o servicio seleccionado; realizar una compra con un teléfono celular; y eliminar cualquier acción adicional por el consumidor para utilizar la compra. 89. El método de la reivindicación 88, que además comprende activar la transacción con una exploración de código de barras utilizando un código de barras externamente visible asociado con el teléfono celular. 90. El método de la reivindicación 88, que además comprende activar la transacción un dispositivo de comunicación de campo cercano asociado con un teléfono celular. 91. El método de la reivindicación 88, que además comprende activar la transacción con un dispositivo de RFID asociado con un teléfono celular. 92. Un método para evitar envío fraudulento de transacciones financieras duplicadas ingresadas desde un teléfono celular que comprende: comparar un número de secuencia recibido de un teléfono celular con un número de secuencia esperado antes de autorizar una transacción financiera; y permitir que la transacción proceda si los números de secuencia concuerdan. 93. El método de la reivindicación 92, que además comprende : solicitar un PIN; y comparar un número telefónico adquirido de la ID de llamadas y el PIN con una base de datos para verificar que el uso del teléfono celular sea legitimo, eliminar cualquier función adicional por el consumidor para autorizar la compra. 94. Un método para evitar envío fraudulento de transacciones financieras duplicadas ingresadas desde un teléfono celular que comprende: comparar un número de secuencia recibido de un teléfono celular con una lista de números de secuencia previamente utilizados antes de autorizar una transacción financiera; y permitir que la transacción proceda si el número de secuencia recibido no concuerda con alguno de los números de secuencia previamente utilizados. 95. El método de la reivindicación 94, que además comprende : solicitar un PIN; y comparar un número telefónico adquirido de la ID de llamadas y el PIN con una base de datos para verificar que el uso del teléfono celular sea legitimo, eliminar cualquier acción adicional por el consumidor para autorizar la compra. 96. Un método para evitar envío fraudulento de transacciones financieras duplicadas ingresadas desde un teléfono celular que comprende: comparar un número de secuencia recibido de un teléfono celular con un número de secuencia esperado antes de autorizar una transacción financiera; comparar el número de secuencia recibido de un teléfono celular con un número de secuencia esperado antes de autorizar una transacción financiera; y permitir que la transacción proceda si los números de secuencia concuerdan en la primera etapa de comparación y no concuerdan en la segunda etapa de comparación. 97. El método de la reivindicación 96, que además comprende : solicitar un PIN; y comparar un número telefónico requerido de la ID de llamadas y el PIN con una base de datos para verificar que el uso del teléfono celular sea legitimo. 98. Un método para evitar envío fraudulento de una transacción financiera ingresada desde un teléfono celular que comprende : iniciar la transacción financiera al enviar una solicitud que tiene un primer identificador, la solicitud enviada utilizando un primer canal de comunicación; enviar un PIN utilizando tonos de DTMF sobre un segundo canal de comunicación; concluir la transacción financiera sólo si la solicitud y el PIN concuerdan con una cuenta común. 99. Un método para evitar envío fraudulento de una transacción financiera ingresada desde un teléfono celular que comprende : recibir una solicitud para iniciar la transacción financiera en un primer canal de comunicación, la solicitud tiene un primer identificador de cuenta; recibir un PIN utilizando tonos de DTMF sobre un segundo canal de comunicación; y concluir la transacción financiera sólo si la solicitud y el PIN concuerdan con una cuenta común. 100. El método de la reivindicación 99, que además comprende iniciar una llamada telefónica en un número telefónico indicado por el primer indicador de cuenta. 101. El método de la reivindicación 99, en donde el primer canal de comunicación es el canal de transmisión del SMS . 102. Un método para evitar fraude en una transacción financiera ingresada de un teléfono celular utilizando el SMS que comprende: formar un primer mensaje de texto del SMS simple con instrucciones para una transacción financiera en el teléfono celular; enviar el mensaje del SMS a un procesador de transacción; interceptar el mensaje del SMS; y convertir el mensaje interceptado del SMS en un mensaje de servicios de datos antes de enviar el mensaje del SMS convertido al procesador de transacción. 103. El método de la reivindicación 102, que además comprende : enviar un segundo mensaje de texto simple que contiene una contraseña al procesador de transacción; interceptar el segundo mensaje del SMS; y convertir el segundo mensaje del SMS interceptado en un mensaje de servicios de datos antes de enviar el mensaje convertido del SMS al procesador de transacción. 104. El método de la reivindicación 103, que además comprende almacenar el primer mensaje de texto del SMS simple en una carpeta de transacción en el teléfono celular. 105. El método de la reivindicación 103, que además comprende codificar el primer y segundo mensajes de texto del SMS simples antes de convertirlos en el mensaje de servicios de datos . 106. El método de la reivindicación 103, en donde la etapa de intercepción se realiza por un manguito de circuito, el manguito de circuito incluye una Aplicación de Cliente Móvil (MCA) interpuesta entre el teléfono celular y su tarjeta de SIM. 107. Un dispositivo de teléfono celular que tiene una tarjeta de SIM, el dispositivo además comprende un circuito interpuesto entre la tarjeta de SIM y el teléfono celular y se adapta para interceptar mensajes del SMS enviados a o recibidos desde un procesador de transacción, el circuito comprende elementos lógicos para codificar y convertir los mensajes interceptados en mensajes de servicios de datos antes de que los mensajes interceptados se envíen al procesador de transacción y para descodificar y convertir los mensajes de servicios de datos en mensaje del SMS de texto simple para mensajes recibidos del procesador de transacción. 108. Un dispositivo móvil para llevar a cabo transacciones financieras que comprende: una capa de comunicación; un API de programa; una interfaz de usuario API para interconectarse al API de programa; y una interfaz de usuario API para interconectarse a servicios de valor agregado. 109. El dispositivo de la reivindicación 108, en donde la capacidad de utilizar servicios de datos del SMS del dispositivo móvil mediante servicios de texto del SMS del dispositivo móvil mediante invocaciones programadas del SMS API. 110. El dispositivo de la reivindicación 108, en donde la capacidad de utilizar servicios de datos persistentes del dispositivo móvil es mediante invocaciones programadas API para los servicios de valor agregado. 111. Un sistema financiero de bucle cerrado que comprende : un procesador de transacción adaptado para recibir solicitudes de transacciones financieras de una pluralidad de titulares de una cuenta; una pluralidad de teléfonos celulares cada uno asociado con el correspondiente de los titulares de una cuenta; una red de comunicación para enlazar teléfonos celulares al procesador de transacción. 112. El sistema de la reivindicación 111, que además comprende una cuenta de libro de contabilidad para transferir fondos desde un titular de una cuenta por lo menos a otro titular de una cuenta sin incurrir en cuotas por transacción de tarjeta de crédito o cuotas ACH bancarios. 113. El sistema de la reivindicación 111, que además comprende una cuenta común que comprende todos los fondos mantenidos por los titulares de una cuenta, la cuenta común asociada con la cuenta del libro de contabilidad para manejar transferencias de fondos entre titulares de una cuenta. 114. El sistema de la reivindicación 113, que además comprende medios para inyectar fondos a la cuenta común desde una fuente exterior. 115. El sistema de la reivindicación 114, que además comprende medios para remover fondos de la cuenta común . 116. Un método para operar un sistema financiero de bucle cerrado que comprende: mantener una cuenta común que contiene fondos de todos los titulares de una cuenta; recibir solicitudes de transacción financiera desde por lo menos un titular de una cuenta para transferir fondos; y mantener una cuenta del libro de contabilidad para rastrear fondos en la cuenta común que se pueden atribuir a cada titular de una cuenta. 117. El método de la reivindicación 116, en donde los fondos se transfieren por lo menos a otro titular de una cuenta . 118. El método de la reivindicación 116, en donde los fondos se transfieren a uno que no es titular de una cuenta . 119. El método de la reivindicación 118, que además comprende avisar al que no es titular de una cuenta de la disponibilidad de fondos por medio de un mensaje del SMS. 120. El método de la reivindicación 119, que además comprende abrir una nueva cuenta para el que no es titular de una cuenta haciendo por consiguiente al que no es titular de una cuenta un nuevo titular de una cuenta. 121. El método de la reivindicación 120, en donde el nuevo titular de una cuenta se obtiene sin gastos por publicidad. 122. El método de la reivindicación 120, que además comprende iniciar una comprobación de cumplimiento (OFAC) en el nuevo titular de una cuenta. 123. El método de la reivindicación 122, que además comprende : designar el nuevo titular de una cuenta como un titular de una cuenta "sin tarjeta"; y conceder al titular de una cuenta sin tarjeta capacidad de acceso limitada a los fondos. 124. El método de la reivindicación 123, que además comprende emitir una tarjeta de débito al titular de una cuenta sin tarjeta al enviar la tarjeta de débito a una dirección de registro. 125. El método de la reivindicación 124, que además comprende : recibir una confirmación de la recepción de la tarjeta en la dirección de registro; y designar el titular de una cuenta sin tarjeta como un titular de una cuenta con acceso completo a los fondos mantenidos en la cuenta común. 126. El método de la reivindicación 116, en donde mantener, recibir y mantenerse todos manejado por una sola entidad. 127. El método de la reivindicación 126, en donde la entidad sencilla es el sistema de registro y asume el riesgo de mantener la cuenta común. 128. Un sistema para evitar envío fraudulento de una transacción financiera ingresada desde un teléfono celular que comprende : un primer grupo que puede ser controlado por un titular de una cuenta; y un segundo grupo que puede ser controlado por una entidad de manejo. 129. El sistema de la reivindicación 128, en donde el primer grupo además comprende: medios para designar titulares de una cuenta elegible para recibir dinero de las cuentas controladas por el titular de una cuenta; y medios para designar titulares de una cuenta que no son elegibles para recibir dinero de las cuentas controladas por el titular de una cuenta. 130. El sistema de la reivindicación 128, en donde el primer grupo además comprende medios para especificar límites de gastos para usuarios de las cuentas controladas por el titular de una cuenta. 131. El sistema de la reivindicación 128, en donde el segundo grupo además comprende medios para especificar los límites de velocidad de gastos para usuarios de las cuentas controladas por el titular de una cuenta. 132. El sistema de la reivindicación 128, en donde el segundo grupo además comprende medios para detectar transacciones fraudulentas. 133. Un dispositivo móvil para llevar a cabo transacciones financieras que comprende: una conexión de comunicación de voz; un JAVA API que se ejecuta en el dispositivo móvil para generar una interfaz de usuario API para crear solicitudes de transacción; un JAVA API que se ejecuta en el dispositivo móvil para transmitir la solicitud al procesador de transacción utilizando tonos DTMF. 134. El dispositivo de la reivindicación 133, que además comprende: un JAVA API que se ejecuta en el dispositivo móvil para recibir una respuesta codificada DTMF del procesador de transacción; y un JAVA API que se ejecuta en el dispositivo móvil para convertir la respuesta codificada en una forma que se puede leer por el humano en la interfaz de usuario. 135. El dispositivo de la reivindicación 134, que además comprende medios para codificar la solicitud antes de transmitir y para descodificar la respuesta antes de convertir. 136. Un sistema de transacción financiera que comprende : un primer dispositivo móvil para iniciar una transacción financiera que tiene medios para seleccionar un canal de comunicación para iniciar la transacción financiera; y un procesador de transacción. 137. El sistema de la reivindicación 136, que además comprende medios asociados con el procesador de transacción para determinar un canal de comunicación para anunciar un segundo dispositivo móvil que una transacción financiera se ha presentado donde la transacción financiera incluye por lo menos dos titulares de una cuenta. 138. El sistema de la reivindicación 137, en donde el canal de comunicación seleccionado por el primer dispositivo no es el mismo que el tipo de canal de comunicación seleccionado por el servidor de transacción para contactar al segundo dispositivo móvil. 139. El método de la reivindicación 102, que además comprende: enviar un mensaje del SMS que contiene una contraseña al procesador de transacción por medio de un sumador del SMS seguro. Existen muchos productos actuales, y potencialmente un gran número de nuevos productos, que se beneficiaran de la presente invención. Por ejemplo, cualquier dispositivo telefónico habilitado por Internet, tal como un teléfono de voz sobre IP (VOIP) puede utilizarse para practicar la presente invención incluso puede fijarse en una ubicación especifica y no necesariamente ser móvil. En otras modalidades, direcciones de correo electrónico pueden utilizarse además de o en lugar de números telefónicos para identificar una o más partes en una transacción financiera. Además, la presente invención no se limita a teléfonos celulares, sino más bien incluye cualquier dispositivo móvil, microteléfono, PDA u otro dispositivo de comunicación que tenga la capacidad de conectarse a un canal de comunicación tal como el teléfono, Internet, celular u otra red de comunicación alámbrica o inalámbrica. Además se apreciará que uno o más elementos representados en los dibujos o figuras también pueden implementarse en una forma separada o integrada, incluso removerse o volverse inoperable en ciertos casos, como es útil de acuerdo con una aplicación particular. Aunque la invención se ha descrito con respecto a modalidades especificas de la misma, estas modalidades solamente son ilustrativas, y no son restrictivas de la invención. Por ejemplo, modalidades adicionales pueden incluir varias arquitecturas de visualización, sensores biométricos, sensores de presión, sensores de temperatura, sensores de luminosidad, sensores químicos, rayos X y otros sensores electromagnéticos, amplificadores, disposiciones de puerta, otros circuitos lógicos, impresoras y circuitos de memoria para implementar las diversas modalidades descritas. El teléfono celular puede ser cualquier dispositivo de comunicación . Adicionalmente , cualesquier flechas de señalamiento en los dibujos o figuras deben considerarse sólo como ejemplares y no limitantes, a menos que se observe específicamente lo contrario. Además, el término "o" como se utiliza en esta solicitud generalmente se pretende para significar "y/o" a menos que se indique lo contrario. Combinaciones de componentes o etapas también se considerarán como siendo observadas, donde la terminología no es clara, se prevé como representado la capacidad de separar o combinar. Como se utiliza en la descripción en esta solicitud y a través de las reivindicaciones que siguen, "uno", "una" y "el" incluyen varias referencias a menos que el contexto dicte claramente lo contrario. También, como se utiliza en esta descripción y a través de las reivindicaciones que siguen, el significado de "en" incluye "en" y "sobre" a menos que el contexto dicte claramente lo contrario. Esta descripción de la invención se ha presentado para propósitos de ilustración y descripción. No se pretende ser exhaustiva o limitar la invención a la forma precisa descrita y muchas modificaciones y variaciones son posibles en vista de la enseñanza anterior. Las modalidades se eligieron y describieron para poder explicar mejor los principios de la invención y sus aplicaciones prácticas. Esta descripción permitirá que aquellos con experiencia en la técnica utilicen y practiquen mejor la invención en varias modalidades y con varias modificaciones según sean adecuadas para su uso particular. El alcance de la invención se define por las siguientes reivindicaciones.

Claims (93)

  1. REIVINDICACIONES 1. Un sistema de transacción financiera caracterizado porque comprende: una ínterfaz de consumidor, acoplada a una red, que comprende : una interfaz web para manejar solicitudes de transacción de un cliente de explorador web; un explorador de Internet móvil para manejar solicitudes de transacción desde un explorador de Internet móvil en un cliente de teléfono móvil; una interfaz del SMS para manejar solicitudes de transacción utilizando mensajes de texto del SMS; y una interfaz de aplicación de cliente móvil para manejar solicitudes de una aplicación de cliente móvil que se ejecuta en el cliente de teléfono móvil.
  2. 2. El sistema de conformidad con la reivindicación 1, caracterizado porque la interfaz de cliente además comprende : una interfaz de respuesta de voz interactiva para manejar solicitudes de un canal de voz de teléfono.
  3. 3. El sistema de conformidad con la reivindicación 1, caracterizado porque comprende: una cuenta común para usuarios recién registrados, donde los usuarios recién registrados pueden llevar a cabo transacciones de usuarios registrados inmediatamente después del registro.
  4. 4. El sistema de conformidad con la reivindicación 1, caracterizado porque la interfaz de aplicación de cliente móvil permite una transacción de envío de dinero, una transacción de carga de cuenta, una transacción de descarga de cuenta, y transacción de consulta de saldo.
  5. 5. El sistema de conformidad con la reivindicación 1, caracterizado porque la interfaz de consumidor además comprende : una interfaz de mensajería instantánea para manejar solicitudes de un cliente de mensajería instantánea.
  6. 6. El sistema de conformidad con la reivindicación 1, caracterizado porque comprende: una interfaz de socio financiero; una interfaz de comercio, donde usuarios a través de la interfaz de consumidor pueden acceder a su dinero en un banco acoplado con el sistema a través de la interfaz de socio financiero y transferir dinero a comercios acoplados con la interfaz de comercio.
  7. 7. El sistema de conformidad con la reivindicación 1, caracterizado porque comprende: un sistema de registro manejado por el sistema de transacción financiera, registrar la transacción ejecutada a través de la interfaz de consumidor.
  8. 8. El sistema de conformidad con la reivindicación 1, caracterizado porque comprende: una cuenta común manejada por el sistema de transacción financiera, donde una pluralidad de clientes que acceden al sistema a través de la interfaz de consumidor tienen una cuenta en la cuenta común.
  9. 9. El sistema de conformidad con la reivindicación 8, caracterizado porque una pluralidad de clientes no tiene una cuenta en la cuenta común pero de hecho tienen una cuenta en una institución financiera, la cual tiene acceso al sistema.
  10. 10. Un método caracterizado porque comprende: proporcionar una interfaz de programa de aplicación para llevar a cabo transacciones con un primer socio financiero; proporcionar una interfaz de mensajes del SMS para recibir solicitudes para llevar a cabo transacciones; proporcionar una interfaz de aplicación de cliente móvil para recibir solicitudes para llevar a cabo transacciones, en donde, a través de la interfaz de mensaje del SMS o la interfaz de cliente móvil, un cliente puede solicitar una transferencia de dinero desde una primera cuenta en el primer socio financiero hasta una segunda cuenta en el segundo socio financiero.
  11. 11. El sistema de conformidad con la reivindicación 10, caracterizado porque comprende: proporcionar una interfaz de programa de aplicación para llevar a cabo transacciones con un segundo socio financiero, en donde, a través de la interfaz de mensaje del SMS o la interfaz de cliente móvil, un cliente puede solicitar una transferencia de dinero desde una cuenta en el primer socio financiero hasta una cuenta en el segundo socio financiero .
  12. 12. El método de conformidad con la reivindicación 10, caracterizado porque comprende: proporcionar un sistema de registro para registrar transacciones solicitadas a través de mensajes del SMS y las interfaces de cliente móvil.
  13. 13. Un método caracterizado porque comprende: desplegar una primera pantalla en un visualizador de un teléfono móvil para mostrar una pluralidad de opciones que comprenden una primera opción para pagar dinero a otro y una segunda opción para solicitar información de saldo; cuando un usuario selecciona la primera opción, desplegar una segunda pantalla donde el usuario ingresa un número telefónico objetivo al cual enviar el pago; después de que el usuario ingrese el número de teléfono objetivo, desplegar una tercera pantalla donde el usuario ingresa una cantidad de transacción; después de que el usuario ingrese el número telefónico, desplegar una cuarta pantalla donde el usuario ingresa un código de PIN; y después de que el usuario ingrese el código de PIN, enviar en forma inalámbrica información de transacción que comprende el número telefónico objetivo, la cantidad de transacción y código de PIN a un servidor para su procesamiento .
  14. 14. Un método caracterizado porque comprende: después de que el usuario ingrese el número telefónico objetivo, desplegar una quinta pantalla donde el usuario ingresa un mensaje opcional.
  15. 15. El método de conformidad con la reivindicación 13, caracterizado porque comprende: cuando el usuario selecciona la segunda opción, enviar inalámbricamente una solicitud de información de saldo al servidor; recibir información de saldo desde el servidor; y desplegar la información de saldo en una quinta pantalla .
  16. 16. El método de conformidad con la reivindicación 13, caracterizado porque la primera pantalla además proporciona una tercera opción para solicitar pago de otro.
  17. 17. El método de conformidad con la reivindicación 13, caracterizado porque la segunda pantalla tiene una tercera opción con la cual la selección por el usuario proporciona el acceso de usuario a una agenda de direcciones de la cual el usuario puede seleccionar una entrada para utilizarse como el número telefónico objetivo.
  18. 18. El método de conformidad con la reivindicación 13, caracterizado porque la información de transacción comprende el número de secuencia generado por el teléfono móvil .
  19. 19. El método de conformidad con la reivindicación 13, caracterizado porque los fondos se mantienen en el servidor y no en el teléfono móvil.
  20. 20. El método de conformidad con la reivindicación 13, caracterizado además porque comprende: recibir una solicitud de solicitud de pago en el teléfono móvil, desplegar la quinta pantalla donde el usuario puede ingresar una cantidad de gratificación.
  21. 21. Un método caracterizado porque comprende: recibir una instrucción de pago desde un primer usuario para pagar a un segundo usuario una cantidad de dinero, donde el primer usuario es un usuario registrado y el segundo usuario se identifica por un número telefónico para el segundo usuario; basándose en el número telefónico, determinar que el segundo usuario no es un usuario registrado; enviar un primer mensaje electrónico a un dispositivo asociado con el número telefónico que notifica al segundo usuario del pago pendiente del primer usuario; después de enviar el primer mensaje electrónico, registrar el segundo usuario y presentar el segundo usuario con una primera opción para aceptar el pago pendiente del primer usuario y una segunda opción para rechazar el pago pendiente del primer usuario; cuando el segundo usuario selecciona la primera opción, cargar la cantidad de dinero de una primera cuenta asociada con el primer usuario y acreditar la cantidad de dinero en una segunda cuenta asociada con el segundo usuario; y cuando el segundo usuario selecciona la segunda opción, enviar un segundo mensaje electrónico al primer usuario de que el pago fue rechazado.
  22. 22. El método de conformidad con la reivindicación 21, caracterizado porque la segunda cuenta es una cuenta común y cuando el primer usuario es un usuario registrado sin tarjeta, la primera cuenta está en la cuenta común, y la cuenta de débito y de crédito comprende mantener la cuenta de dinero dentro de la cuenta común.
  23. 23. El método de conformidad con la reivindicación 21, caracterizado porque la segunda cuenta es una cuenta común y cuando el primer usuario es un usuario registrado sin tarjeta, la primera cuenta es la cuenta común, y la cuenta de débito y de crédito no comprende transferir la cuenta del dinero fuera de la cuenta común.
  24. 24. El método de conformidad con la reivindicación 21, caracterizado porque cuando el primer usuario es un usuario registrado sin tarjeta, la primera cuenta es una primera cuenta común y la segunda cuenta es una segunda cuenta común, diferente de la primera cuenta común, y la cuenta de débito y de crédito comprende transferir la cantidad de dinero desde la primera cuenta común hasta la segunda cuenta común.
  25. 25. El método de conformidad con la reivindicación 21, caracterizado porque el primer usuario es un usuario registrado con tarjeta y la segunda cuenta es una cuenta común, y el débito y crédito comprende transferir la cantidad de dinero desde la primera cuenta hacia la segunda cuenta en la cuenta común, por lo que la cuenta común se incrementa por la cantidad de dinero.
  26. 26. El método de conformidad con la reivindicación 21, caracterizado porque comprende: recibir además de la instrucción de pago un número de secuencia generado por un dispositivo que envío la instrucción de pago; después de recibir el número de secuencia, generar un número de transacción para la instrucción de pago.
  27. 27. El método de conformidad con la reivindicación 21, caracterizado porque comprende: procesar la instrucción de pago sólo si el número de secuencia no concuerda con algún número de secuencia previamente recibido almacenado en una base de datos.
  28. 28. El método de conformidad con la reivindicación 27, caracterizado porque la base de datos comprende números de secuencias recibidos durante un período de tiempo de funcionamiento .
  29. 29. El método de conformidad con la reivindicación 21, caracterizado porque comprende: después de recibir el número de secuencia, generar un número de secuencia esperado; y procesar la instrucción de pago sólo si el número de secuencia concuerda con el número de secuencia esperado.
  30. 30. Un método caracterizado porque comprende: recibir una instrucción de pago desde un primer usuario para pagar a un segundo usuario una cantidad de dinero, donde el primer usuario es un usuario registrado y el segundo usuario se identifica por un número telefónico para el segundo usuario; basándose en el número telefónico, determinar que el segundo usuario no es un usuario registrado; enviar un primer mensaje electrónico a un dispositivo asociado con el número telefónico que notifica al segundo usuario del pago pendiente del primer usuario; después de enviar el primer mensaje electrónico, registrar el segundo usuario y presentar el segundo usuario con una primera opción para aceptar el pago pendiente del primer usuario, una segunda opción para rechazar el pago pendiente del primer usuario, y una tercera opción para solicitar un cambio al pago pendiente del primer usuario; donde el segundo usuario selecciona la primera opción, debitando la cantidad de dinero de una primera cuenta asociada con el primer usuario y acreditando la cantidad de dinero en una segunda cuenta asociada con el segundo usuario; y cuando el segundo usuario selecciona la segunda opción, enviar un segundo mensaje electrónico al primer usuario de que el pago fue rechazado.
  31. 31. El método de conformidad con la reivindicación 30, caracterizado porque comprende: cuando el segundo usuario selecciona la tercera opción, envía un tercer mensaje electrónico al primer usuario de que el segundo usuario ha solicitado un cambio en el pago pendiente .
  32. 32. El método de conformidad con la reivindicación 30, caracterizado porque comprende: cuando el segundo usuario selecciona la tercera opción, recibe una solicitud del segundo usuario para cambiar el pago pendiente para tener una cantidad de dinero diferente , enviar un tercer mensaje electrónico al primer usuario notificando al primer usuario del cambio en el pago pendiente , presentar al primer usuario con una cuarta opción para aceptar el cambio en el pago pendiente o una quinta opción para rechazar el cambio en el pago pendiente, y cuando el primer usuario selecciona la cuarta opción, debita la cantidad de dinero diferente de una cuenta del primer usuario y acredita la cantidad de dinero diferente en una cuenta asociada con el segundo usuario.
  33. 33. El método de conformidad con la reivindicación 30, caracterizado porque el dispositivo es por lo menos uno de un teléfono inteligente, dispositivo de telefonía móvil, un dispositivo de correo electrónico portátil, asistente digital personal, o computadora.
  34. 34. El método de conformidad con la reivindicación 30, caracterizado porque comprende: después de determinar que el segundo usuario no es un usuario registrado, poner una retención en la cantidad de dinero en la primera cuenta.
  35. 35. El método de conformidad con la reivindicación 30, caracterizado porque comprende: después de determinar que el segundo usuario no es un usuario registrado, poner una retención en la cantidad de dinero en la primera cuenta; y después de un cierto número de días transcurridos desde el momento en que se recibió la instrucción de pago y el segundo usuario no se ha registrado, retirar la retención en la cantidad de dinero en la primera cuenta.
  36. 36. Un método caracterizado porque comprende: recibir una instrucción de pago de un primer usuario para pagar a un segundo usuario una cantidad de dinero, donde el primer usuario es un usuario registrado y el segundo usuario se identifica por un número telefónico para el segundo usuario; basándose en el número telefónico, determinar que el segundo usuario no es un usuario registrado; enviar un primer mensaje electrónico a un dispositivo asociado con el número telefónico que notifica al segundo usuario de un pago pretendido del primer usuario; después de enviar el primer mensaje electrónico, registrar el segundo usuario, enviar al primer usuario un segundo mensaje electrónico al primer usuario de que el segundo usuario se ha registrado, y presentar al primer usuario con una primera opción para pagar al segundo usuario la cantidad de dinero; y cuando el primer usuario selecciona la primera opción, debitar la cantidad de dinero de una primera cuenta asociada con el primer usuario y acreditar la cantidad de dinero en una segunda cuenta asociada con el segundo usuario.
  37. 37. El método de conformidad con la reivindicación 36, caracterizado porque comprende: después que el segundo usuario se registra, acreditar la primera cuenta con una cantidad de bono de referencia .
  38. 38. El método de conformidad con la reivindicación 36, caracterizado porque comprende: después que el segundo usuario se registra, acreditar la segunda cuenta con una cantidad de bono de referencia .
  39. 39. El método de conformidad con la reivindicación 36, caracterizado porque comprende: enviar un segundo mensaje electrónico al primer usuario de que el segundo usuario no es un usuario registrado .
  40. 40. El método de conformidad con la reivindicación 36, caracterizado porque comprende: recibir además de la instrucción de pago un número de secuencia generado por un dispositivo que envío la instrucción de pago; y después de recibir el número de secuencia, generar un número de transacción para la instrucción de pago.
  41. 41. Un método caracterizado porque comprende: recibir una solicitud electrónica de una transacción de intercambio de valores, transmitida inalámbricamente desde un dispositivo de usuario recibir con la solicitud electrónica una clave transmitida asociada con la solicitud electrónica; determinar si la clave transmitida existe en una tabla de transacción; si la clave transmitida no está en la tabla de transacción, ingresar la clave transmitida y la transacción de intercambio de valores en la tabla de transacciones, y procesar la transacción de intercambio de valores; si la clave transmitida está en la tabla de transacciones, no actuar sobre la transacción de intercambio de valores.
  42. 42. El método de conformidad con la reivindicación 41, caracterizado porque la clave transmitida comprende un identificador electrónico que identifica a un usuario que solicita la transacción de intercambio de valores y un número de secuencia, el número de secuencia se almacena en el dispositivo de usuario y se adelanta a un siguiente número en secuencia antes de que una segunda transacción de intercambio de valores se transmita por el dispositivo de usuario.
  43. 43. El método de conformidad con la reivindicación 42, caracterizado porque el número de secuencia se almacena en una memoria no volátil en el dispositivo de usuario.
  44. 44. El método de conformidad con la reivindicación 41, caracterizado porque la clave transmitida comprende un número pseudoaleatorio .
  45. 45. El método de conformidad con la reivindicación 41, caracterizado porque la clave transmitida comprende un primer identificador electrónico que identifica un usuario que solicito la transacción de intercambio de valores, un segundo identificador electrónico que identifica un usuario que es el objetivo de la transacción de intercambio de valores, una cantidad de valor de la transacción de intercambio de valores, y un tiempo asociado con la transacción de intercambio de valores.
  46. 46. El método de conformidad con la reivindicación 41, caracterizado porque la transacción de intercambio de valores comprende enviar dinero desde un primer usuario asociado con el dispositivo de usuario hasta un segundo usuario asociado con otro dispositivo de usuario.
  47. 47. El método de conformidad con la reivindicación 41, caracterizado porque el dispositivo de usuario es un teléfono móvil.
  48. 48. El método de conformidad con la reivindicación 41, caracterizado porque la clave transmitida no se despliega en el dispositivo de usuario.
  49. 49. El método de conformidad con la reivindicación 41, caracterizado porque la solicitud electrónica es mediante un servicio de mensajes de texto del SMS del dispositivo de usuario .
  50. 50. El método de conformidad con la reivindicación 41, caracterizado porque la clave transmitida comprende primera información cuando el dispositivo de usuario envía la solicitud electrónica utilizando un primer cliente de aplicación y la clave transmitida comprende primera información cuando el dispositivo de usuario envía la solicitud electrónica utilizando un primer cliente de aplicación, la cual es diferente del primer cliente de aplicación .
  51. 51. El método de conformidad con la reivindicación 50, caracterizado porque el primer cliente de aplicación es una aplicación de servicio de transacción de intercambio de valores dedicada que se ejecuta en el dispositivo de usuario, y el segundo cliente de aplicación es una aplicación de mensajes del SMS del dispositivo de usuario.
  52. 52. El método de conformidad con la reivindicación 41, caracterizado porque si la clave transmitida está en la tabla de transacciones, suspender una cuenta de un usuario enviando la solicitud electrónica.
  53. 53. El método de conformidad con la reivindicación 41, caracterizado porque procesar la transacción de intercambio de valores comprende: generar un número de identificador de transacción para la transacción de intercambio de valores; enviar un mensaje electrónico al dispositivo de usuario que incluye el número de identificador de transacción, donde el número de identificador de transacción se puede ver en el dispositivo de usuario.
  54. 54. Un método caracterizado porque comprende: recibir una solicitud electrónica de una transacción de intercambio de valores, transmitida inalámbricamente desde un dispositivo de usuario; recibir una clave transmitida asociada con la solicitud electrónica; generar una clave esperada; comparar la clave transmitida con la clave esperada; y si la clave transmitida concuerda con la clave esperada, procesar la transacción de intercambio de valores.
  55. 55. El método de conformidad con la reivindicación 54, caracterizado porque generar la clave esperada comprende evaluar una función utilizando un valor germinal almacenado para una cuenta de usuario asociada con la transacción de intercambio de valores, y el método además comprende después de evaluar la función, determinar un siguiente valor germinal en secuencia y reemplazar el valor germinal almacenado para la cuenta de usuario con el siguiente valor germinal en secuencia .
  56. 56. El método de conformidad con la reivindicación 54, caracterizado porque comprende: si la clave transmitida no concuerda con la clave esperada, no actúa sobre la transacción de intercambio de valores y suspender una cuenta de usuario asociada con la transacción de intercambio de valores.
  57. 57. El método de conformidad con la reivindicación 54, caracterizado porque procesar la transacción de intercambio de valores comprende : generar un número de identificar la transacción, diferente de la clave esperada, para la transacción de intercambio de valores; enviar un mensaje electrónico al dispositivo de usuario que incluye el número de identificador de transacción, donde el número de identificador de transacción se despliega en el dispositivo de usuario.
  58. 58. El método de conformidad con la reivindicación 54, caracterizado porque la transacción de intercambio de valores comprende enviar dinero desde un primer usuario asociado con el dispositivo de usuario a un segundo usuario asociado con otro dispositivo de usuario.
  59. 59. El método de conformidad con la reivindicación 54, caracterizado porque la clave esperada es un número pseudoaleatorio .
  60. 60. El método de conformidad con la reivindicación 54, caracterizado porque generar la clave esperada comprende: recuperar de un perfil de usuario asociado con la transacción de intercambio de valores un valor germinal; recuperar del perfil de usuario información sobre una función de acuerdo con la cual se generó la clave transmitida; y evaluar la función utilizando el valor germinal.
  61. 61. Un método caracterizado porque comprende: manejar transacciones financieras de un grupo de usuarios de un sistema, donde las transacciones financieras pueden ser especificas a través de teléfonos móviles y subgrupos de usuarios se asocian con una situación bancaria; procesar transacciones financieras asociadas con una primera institución bancaria, donde usuarios en un primer subgrupo se asocian con la primera institución bancaria; procesar transacciones financieras asociadas con una segunda institución bancaria, donde usuarios en un segundo subgrupo se asocian con la segunda institución bancaria; procesar transacciones financieras asociadas con una tercera institución bancaria, donde el usuarios en un tercer subgrupo se asocian con la tercera institución bancaria; mantener una cuenta común virtual que comprende fondos para el primer, segundo y tercer subgrupos de usuarios asociados con la primera, segunda y tercera instituciones bancarias ; y distribuir un primer dividendo a la primera institución bancaria basándose en el flotador en fondos en la cuenta común virtual para el primer subgrupo de usuarios más un porcentaje del flotador en fondos en la cuenta común virtual para el tercer subgrupo de usuarios .
  62. 62. El método de conformidad con la reivindicación 61, caracterizado porque comprende: distribuir un segundo dividendo a la segunda institución bancaria basándose en el flotador en fondos en la cuenta común virtual para el segundo subgrupo de usuarios más un porcentaje del flotador en fondos en la cuenta común virtual para el tercer subgrupo de usuarios.
  63. 63. El método de conformidad con la reivindicación 61, caracterizado porque comprende: recibir una instrucción de un primer usuario en el primer subgrupo para transferir dinero a un segundo usuario del segundo subgrupo, donde el dinero no se transfiere fuera de la cuenta común virtual .
  64. 64. El método de conformidad con la reivindicación 63, caracterizado porque la instrucción se envía inalámbricamente desde un teléfono móvil mediante mensaje del SMS.
  65. 65. El método de conformidad con la reivindicación 63, caracterizado porque la instrucción se envía inalámbricamente desde un teléfono móvil utilizando una aplicación que se ejecuta en el teléfono móvil.
  66. 66. El método de conformidad con la reivindicación 61, caracterizado porque la tercera institución bancaria es un socio directo del sistema.
  67. 67. El método de conformidad con la reivindicación 61, caracterizado porque cada usuario se asocia con sólo una de la primera, segunda o tercera instituciones financieras.
  68. 68. El método de conformidad con la reivindicación 61, caracterizado porque comprende: manejar un sistema de registro para la cuenta común virtual, donde el sistema de registro comprende registros de transacciones para usuarios en el primer, segundo y tercer subgrupos .
  69. 69. Un método caracterizado porque comprende: manejar transacciones financieras de un grupo de usuarios de un sistema, donde las transacciones financieras pueden ser específicas a través de teléfonos móviles y subgrupos de usuarios se asocian con una situación bancaria; procesar transacciones financieras asociadas con una primera institución bancaria, donde usuarios en un primer subgrupo se asocian con la primera institución bancaria; procesar transacciones financieras asociadas con una segunda institución bancaria, donde usuarios en un segundo subgrupo se asocian con la segunda institución bancaria; procesar transacciones financieras de usuarios en un tercer subgrupo que se asocian con el sistema y no con la primera y segunda instituciones bancarias; mantener una cuenta común virtual que comprende fondos para el primero, segundo y tercer subgrupos de usuarios asociados con la primera y segunda instituciones bancarias en el sistema; y distribuir un primer dividendo a la primera institución bancaria basándose en el flotador de los fondos en la cuenta común virtual para el primer subgrupo de usuarios más un porcentaje del flotador en fondos en la cuenta común virtual para el tercer subgrupo de usuarios.
  70. 70. El método de conformidad con la reivindicación 69, caracterizado porque comprende: distribuir un segundo dividendo a la segunda institución bancaria basándose en el flotador de fondos en la cuenta común virtual para el segundo subgrupos de usuarios más un porcentaje de flotador en los fondos en la cuenta común virtual para el tercer subgrupo de usuarios.
  71. 71. El método de conformidad con la reivindicación 69, caracterizado porque comprende: recibir una instrucción del primer usuario en el primer subgrupo para transferir dinero a un segundo usuario en el segundo subgrupo, donde el dinero no se transfiere fuera de la cuenta común virtual .
  72. 72. El método de conformidad con la reivindicación 71, caracterizado porque la instrucción se envía inalámbricamente desde un teléfono móvil mediante mensaje del SMS.
  73. 73. El método de conformidad con la reivindicación 71, caracterizado porque la instrucción se envía inalámbricamente desde un teléfono móvil utilizando una aplicación que se ejecuta en el teléfono móvil.
  74. 74. El método de conformidad con la reivindicación 69, caracterizado porque cada usuario se asocia con sólo una de la primera institución financiera, segunda institución financiera o el sistema.
  75. 75. El método de conformidad con la reivindicación 69, caracterizado porque comprende: recibir una instrucción de un primer usuario en el primer subgrupo para transferir dinero a un segundo usuario en el tercer subgrupo, donde el dinero no se transfiere fuera de la cuenta común virtual .
  76. 76. El método de conformidad con la reivindicación 71, caracterizado porque la instrucción se envía mediante un explorador de Internet.
  77. 77. El método de conformidad con la reivindicación 71, caracterizado porque comprende: manejar un sistema de registro para la cuenta común virtual, donde el sistema de registro comprende registro de transacciones para usuarios en el primero, segundo y tercer subgrupos .
  78. 78. Un método caracterizado porque comprende: recibir una pluralidad de contribuciones de comercios para financiar un sistema de pagos de miembros; colocar las contribuciones del comercio en una cuenta común de fideicomiso, donde los comercios no recibirán interés sobre sus contribuciones; permitir a una pluralidad de consumidores se vuelvan usuarios registrados del pago móvil sin cargo; permitir que usuarios registrados carguen o descarguen fondos en una cuenta de trabajo del sistema de pago de miembro sin cargo; y permitir que comercios carguen o descarguen fondos en la cuenta de trabajo del sistema de pagos de miembros sin cargo, por lo que el interés sobre la cuenta de fideicomiso común financia el sistema de pagos de miembros.
  79. 79. El método de conformidad con la reivindicación 78, caracterizado porque el sistema de pago de miembros permite a un usuario registrado solicitar pago de dinero a otro usuario registrado mediante un teléfono móvil.
  80. 80. El método de conformidad con la reivindicación 78, caracterizado porque el sistema de pago de miembros permite a un usuario registrado solicitar pago de dinero a un comercio mediante un teléfono móvil.
  81. 81. El método de conformidad con la reivindicación 78, caracterizado porque el sistema de pago de miembros maneja registros de transacciones de los usuarios registrados .
  82. 82. El método de conformidad con la reivindicación 78, caracterizado porque el sistema de pago de miembros maneja registros de transacciones de los comercios.
  83. 83. El método de conformidad con la reivindicación 78, caracterizado porque el sistema de pago de miembros maneja registros de transacciones de los usuarios registrados y los comercios.
  84. 84. El método de conformidad con la reivindicación 78, caracterizado porque cuando un comercio solicita un reembolso de la contribución del comercio al sistema de pagos de miembros, los usuarios registrados ya no se les permitirá transferir dinero al comercio.
  85. 85. El método de conformidad con la reivindicación 78, caracterizado porque el comercio no se carga con una transacción recurrente periódica para ser un participante del sistema de pagos de miembros.
  86. 86. El método de conformidad con la reivindicación 78, caracterizado porque los usuarios registrados pueden cargar o descargar fondos por medio de por lo menos una de una Cámara de Compensación Automatizada (ACH) o una cuenta de depósito directo (DDA) .
  87. 87. El método de conformidad con la reivindicación 78, caracterizado porque el sistema de pago de miembros maneja registros de transacciones de los usuarios registrados . 82. El método de conformidad con la reivindicación 78, caracterizado porque el sistema de pago de miembros maneja registros de transacciones de los comercios. 83. El método de conformidad con la reivindicación 78, caracterizado porque el sistema de pago de miembros maneja registros de transacciones de los usuarios registrados y los comercios. 84. El método de conformidad con la reivindicación 78, caracterizado porque cuando un comercio solicita un reembolso de la contribución del comercio al sistema de pagos de miembros, los usuarios registrados ya no se les permitirá transferir dinero al comercio. 85. El método de conformidad con la reivindicación 78, caracterizado porque el comercio no se carga con una transacción recurrente periódica para ser un participante del sistema de pagos de miembros. 86. El método de conformidad con la reivindicación 78, caracterizado porque los usuarios registrados pueden cargar o descargar fondos por medio de por lo menos una de una Cámara de Compensación Automatizada (ACH) o una cuenta de depósito directo (DDA) . 87. El método de conformidad con la reivindicación 78, caracterizado porque comprende: permitir que un usuario registrado autorice el pago a un comercio a través del sistema de pago de miembros al utilizar un esquema de autorización de dos factores.
  88. 88. El método de conformidad con la reivindicación 78, caracterizado porque comprende: permitir a un usuario registrado autorizar pago a un comercio a través del sistema de pago de miembros al utilizar un teléfono móvil del usuario registrado y el usuario ingresa correctamente un número de identificación personal .
  89. 89. El método de conformidad con la reivindicación 78, caracterizado porque cada usuario registrado se proporciona con una tarjeta de débito.
  90. 90. Un sistema sustancialmente caracterizado como se describe .
  91. 91. Un sistema sustancialmente caracterizado como se muestra.
  92. 92. Un método sustancialmente caracterizado como se muestra.
  93. 93. Un método sustancialmente caracterizado como se describe .
MX2008012503A 2006-03-30 2007-03-30 Sistema movil de pago de persona a persona. MX2008012503A (es)

Applications Claiming Priority (4)

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

Publications (1)

Publication Number Publication Date
MX2008012503A true MX2008012503A (es) 2008-12-12

Family

ID=38532095

Family Applications (2)

Application Number Title Priority Date Filing Date
MX2008012504A MX2008012504A (es) 2006-03-30 2007-03-30 Sistema movil de pago de persona a persona.
MX2008012503A MX2008012503A (es) 2006-03-30 2007-03-30 Sistema movil de pago de persona a persona.

Family Applications Before (1)

Application Number Title Priority Date Filing Date
MX2008012504A MX2008012504A (es) 2006-03-30 2007-03-30 Sistema movil de pago de persona a persona.

Country Status (6)

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

Cited By (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10078821B2 (en) 2012-03-07 2018-09-18 Early Warning Services, Llc System and method for securely registering a recipient to a computer-implemented funds transfer payment network
US10318936B2 (en) 2012-03-07 2019-06-11 Early Warning Services, Llc System and method for transferring funds
US10395247B2 (en) 2012-03-07 2019-08-27 Early Warning Services, Llc Systems and methods for facilitating a secure transaction at a non-financial institution system
US10395223B2 (en) 2012-03-07 2019-08-27 Early Warning Services, Llc System and method for transferring funds
US10438175B2 (en) 2015-07-21 2019-10-08 Early Warning Services, Llc Secure real-time payment transactions
US10748127B2 (en) 2015-03-23 2020-08-18 Early Warning Services, Llc Payment real-time funds availability
US10769606B2 (en) 2015-03-23 2020-09-08 Early Warning Services, Llc Payment real-time funds availability
US10832246B2 (en) 2015-03-23 2020-11-10 Early Warning Services, Llc Payment real-time funds availability
US10839359B2 (en) 2015-03-23 2020-11-17 Early Warning Services, Llc Payment real-time funds availability
US10846662B2 (en) 2015-03-23 2020-11-24 Early Warning Services, Llc Real-time determination of funds availability for checks and ACH items
US10956888B2 (en) 2015-07-21 2021-03-23 Early Warning Services, Llc Secure real-time transactions
US10963856B2 (en) 2015-07-21 2021-03-30 Early Warning Services, Llc Secure real-time transactions
US10970695B2 (en) 2015-07-21 2021-04-06 Early Warning Services, Llc Secure real-time transactions
US10970688B2 (en) 2012-03-07 2021-04-06 Early Warning Services, Llc System and method for transferring funds
US11037121B2 (en) 2015-07-21 2021-06-15 Early Warning Services, Llc Secure real-time transactions
US11037122B2 (en) 2015-07-21 2021-06-15 Early Warning Services, Llc Secure real-time transactions
US11062290B2 (en) 2015-07-21 2021-07-13 Early Warning Services, Llc Secure real-time transactions
US11144928B2 (en) 2016-09-19 2021-10-12 Early Warning Services, Llc Authentication and fraud prevention in provisioning a mobile wallet
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

Families Citing this family (861)

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

Family Cites Families (140)

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

Cited By (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
US10970688B2 (en) 2012-03-07 2021-04-06 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
US11373182B2 (en) 2012-03-07 2022-06-28 Early Warning Services, Llc System and method for transferring funds
US11715075B2 (en) 2012-03-07 2023-08-01 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
US11361290B2 (en) 2012-03-07 2022-06-14 Early Warning Services, Llc System and method for securely registering a recipient to a computer-implemented funds transfer payment network
US10395247B2 (en) 2012-03-07 2019-08-27 Early Warning Services, Llc Systems and methods for facilitating a secure transaction at a non-financial institution system
US10395223B2 (en) 2012-03-07 2019-08-27 Early Warning Services, Llc System and method for transferring funds
US11321682B2 (en) 2012-03-07 2022-05-03 Early Warning Services, Llc System and method for transferring funds
US10878387B2 (en) 2015-03-23 2020-12-29 Early Warning Services, Llc Real-time determination of funds availability for checks and ACH items
US10769606B2 (en) 2015-03-23 2020-09-08 Early Warning Services, Llc Payment real-time funds availability
US10748127B2 (en) 2015-03-23 2020-08-18 Early Warning Services, Llc Payment real-time funds availability
US10846662B2 (en) 2015-03-23 2020-11-24 Early Warning Services, Llc Real-time determination of funds availability for checks and ACH items
US10839359B2 (en) 2015-03-23 2020-11-17 Early Warning Services, Llc Payment real-time funds availability
US10832246B2 (en) 2015-03-23 2020-11-10 Early Warning Services, Llc Payment real-time funds availability
US11037121B2 (en) 2015-07-21 2021-06-15 Early Warning Services, Llc Secure real-time transactions
US11062290B2 (en) 2015-07-21 2021-07-13 Early Warning Services, Llc Secure real-time transactions
US10438175B2 (en) 2015-07-21 2019-10-08 Early Warning Services, Llc Secure real-time payment transactions
US11922387B2 (en) 2015-07-21 2024-03-05 Early Warning Services, Llc Secure real-time transactions
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
US10762477B2 (en) 2015-07-21 2020-09-01 Early Warning Services, Llc Secure real-time processing of payment transactions
US11037122B2 (en) 2015-07-21 2021-06-15 Early Warning Services, Llc Secure real-time transactions
US10970695B2 (en) 2015-07-21 2021-04-06 Early Warning Services, Llc Secure real-time transactions
US11386410B2 (en) 2015-07-21 2022-07-12 Early Warning Services, Llc Secure transactions with offline device
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
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
US11151567B2 (en) 2016-09-19 2021-10-19 Early Warning Services, Llc Authentication and fraud prevention in provisioning a mobile wallet

Also Published As

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

Similar Documents

Publication Publication Date Title
US7873573B2 (en) Virtual pooled account for mobile banking
US8249965B2 (en) Member-supported mobile payment system
MX2008012503A (es) Sistema movil de pago de persona a persona.
US20070255662A1 (en) Authenticating Wireless Person-to-Person Money Transfers
US20070244811A1 (en) Mobile Client Application for Mobile Payments
WO2009114876A2 (en) Network-based viral payment system
US10171961B1 (en) Transaction authorization service
CN101454794A (zh) 移动的个人之间支付系统
US20110320347A1 (en) Mobile Networked Payment System
US20130006848A1 (en) Method of virtual transaction using mobile electronic devices or fixed electronic devices or a combination of both, for global commercial or noncommercial purposes
US20090319425A1 (en) Mobile Person-to-Person Payment System
US20150095236A1 (en) Broker-mediated payment systems and methods
US20130085877A1 (en) Intermediary-based transaction system
US20070094113A1 (en) Transactional mobile system
WO2009152184A1 (en) Mobile payment system
US20150100491A1 (en) Broker-mediated payment systems and methods
US11935066B1 (en) Systems and methods for funds transfers via a token management system
CN112204597A (zh) 区块链支付系统
US20230222462A1 (en) Digital engagement platform for payment solutions with cash-enabled multipay
WO2021105753A1 (en) Electronic currency transfer method and system

Legal Events

Date Code Title Description
FA Abandonment or withdrawal