MX2012009205A - Pagos moviles usando servicios de mensajes cortos. - Google Patents

Abstract

Un consumidor envía un solicitud de texto a un proveedor de pago con una cantidad para preaprobación, en donde la solicitud incluye un identificador de consumidor; el proveedor de pago envía un código de compra de regreso al consumidor que el consumidor puede usar para realizar un pago o compra; el beneficiario o comerciante recibe el código del consumidor, tal como en el punto de venta, y transmite el código al proveedor de pago, en donde la transmisión incluye un identificador de beneficiario y una cantidad de compra; el proveedor de pago procesa la transmisión, y si sí es aprobada, procesa el pago e informa al beneficiario y/o al consumidor.

Description

PAGOS MÓVILES USANDO SERVICIO DE MENSAJES CORTOS REFERENCIA CRUZADA CON SOLICITUDES RELACIONADAS Esta solicitud reclama prioridad a la Solicitud de Patente Provisional de E.U.A No. de serie 61/302,868, incorporada para referencia en su totalidad.

CAMPO DE LA INVENCIÓN La presente invención se refiere en general a pagos en persona y en particular, a pagos efectuados usando un dispositivo móvil.

TÉCNICA RELACIONADA En una transacción de compra típica en persona o cara a cara, un comprador proporciona al vendedor un instrumento de financiamiento, el cual cuando es aceptado, el vendedor proporciona los objetos comprados al comprador. Ejemplos de instrumentos de financiamiento incluyen efectivo, crédito, tarjetas de crédito, tarjetas de débito, y cheques. Sin embargo, un comprador no puede preferir portar demasiado efectivo o puede no tener suficiente efectivo disponible para realizar la compra. Con tarjetas de crédito, tarjetas de débito, y cheques, puede haber porciones significativas de la población quienes no tienen tarjetas de crédito o cuentas bancarias, resultando en que el comprador no sea capaz de realizar la compra si suficiente efectivo no está disponible.

Por lo tanto, existe la necesidad de permitir a un comprador realizar una compra en persona sin las desventajas discutidas anteriormente.

BREVE DESCRIPCIÓN DE LA INVENCIÓN De conformidad con una modalidad de la descripción, un usuario con un dispositivo móvil envía una solicitud a un proveedor de pago, con el cual el usuario tiene una cuenta, para preaprobar una cantidad de compra. La solicitud puede ser transmitida por un mensaje de texto o una llamada, en donde la solicitud incluye la cantidad solicitada y un identificador de cuenta/usuario. Este identificador puede ser incluido automáticamente en la solicitud como el número telefónico del dispositivo móvil. El proveedor de pago entonces determina si el identificador coincide con una cuenta de usuario válida y si esa cuenta tiene fondos suficientes para cubrir la cantidad solicitada. Si es así, el proveedor de pago transmite un código al usuario, el cual nuevamente puede ser vía texto u otros medios, tal como regresar una llamada de voz. El código puede expirar después de un período de tiempo, tal como 15 minutos, donde la expiración siempre puede ser la misma o difiere dependiendo de la cantidad solicitada.

Después de recibir el código, el usuario proporciona el código a un vendedor, el cual puede ser una persona o un comerciante, para realizar una compra. El vendedor transmite el código, junto con la cantidad de compra y un identificador de cuenta/vendedor, al proveedor de pago. Como con la solicitud del usuario, la transmisión puede ser realizada usando texto u otros medios, y el identificador del vendedor, tal como el número telefónico del dispositivo del vendedor realizando la transmisión, puede ser transmitido automáticamente con la transmisión. El proveedor de pago entonces determina si el código recibido es válido (por ejemplo, existe y no ha expirado), la cantidad de compra solicitada es menor o igual a la cantidad asociada con el código, y el vendedor tiene una cuenta con el proveedor de pago. Si es así, el proveedor de pago acredita a la cuenta del vendedor la cantidad de compra y deduce esa misma cantidad de la cuenta del usuario o comprador. El proveedor de pago también puede invalidar el código para uso o mantener éste activo durante la cantidad restante de tiempo asignado, pero deduciendo la cantidad de compra de la cantidad previamente aprobada. Después. El proveedor de pago envía al vendedor una confirmación de que la solicitud de compra ha sido aprobada y los fondos transferidos. El usuario también puede recibir un mensaje que los fondos han sido transferidos al vendedor. El vendedor entonces libera los objetos comprados al usuario o comprador.

Un proceso similar también puede ser usado cuando el usuario está regresando un objeto al vendedor inicial En este caso, el usuario presenta el objeto al vendedor, junto con un identificador de usuario, tal como el número telefónico del dispositivo del usuario. El usuario también puede presentar al vendedor un recibo de la compra. El vendedor entonces transmite un mensaje al proveedor de pago, en donde el mensaje incluye una solicitud para un reembolso, el identificador de usuario, la cantidad de reembolso, y el identificador del vendedor. El identificador del vendedor, el cual puede ser el número telefónico del dispositivo del vendedor, puede ser transmitido automáticamente con el mensaje. A partir de la información en el mensaje, el proveedor de pago determina si el vendedor y el usuario tienen una cuente con el proveedor de pago y cualesquier detalles de transacciones anteriores entre el usuario y el vendedor. Si la cuenta existe, y como mínimo, ha habido al menos un transacción anterior para una cantidad al menos esa de solicitud de reembolso, el proveedor de pago procede al reembolso. Esto puede incluir la cuenta del vendedor siendo cargado la cantidad de reembolso, la cuenta del usuario siendo abonada la cantidad de reembolso, y enviando un mensaje al vendedor y/o al usuario del débito y/o crédito. Éstas y otras características y ventajas de la presente invención serán evidentes más fácilmente a partir de la descripción detallada de las modalidades establecidas a continuación tomadas en conjunto con los dibujos anexos.

BREVE DESCRIPCIÓN DE LAS FIGURAS La Fig. 1 muestra un proceso donde un usuario obtiene un código de compra de un proveedor de pago de conformidad con una modalidad; La Fig. 2 muestra un proceso donde el usuario usa el código de compra para realizar un pago con un vendedor en persona de conformidad con una modalidad; La Fig. 3 muestra un proceso donde el vendedor solicita un reembolso para un usuario regresando una compra de conformidad con una modalidad; La Fig. 4 es un diagrama de bloques de un sistema en red apropiado para implementar el proceso de las Figs. 1-3 de conformidad con una modalidad; y La Fig. 5 es un diagrama de bloque de un sistema de computadora apropiado para implementar uno o más componentes en la Fig. 4 de conformidad con una modalidad de la descripción presente.

Las modalidades de la presente descripción y sus ventajas se comprenden mejor al referirse a la siguiente descripción detallada. Debe observarse que los números de referencia iguales se utilizan para identificar elementos iguales ilustrados en una o más de las figuras, en donde las proyecciones de la misma son para propósitos de ilustrar las modalidades de la presente descripción y no para propósitos de limitar la misma.

DESCRIPCIÓN DETALLADA DE LA INVENCIÓN La Fig. 1 es un diagrama de flujo 100 mostrando un proceso donde un usuario obtiene un código de compra de un proveedor de pago para realizar un pago de conformidad con una modalidad. En el paso 102, el consumidor envía una solicitud al proveedor de pago, tal como PayPal, Inc. de San José, CA. En una modalidad, el usuario envía vía el dispositivo móvil del usuario, tableta, PC, u otro dispositivo de comunicación/computación. La solicitud puede ser enviada por texto (SMS), correo electrónico, voz, u otro medio apropiado en un punto de venta. Otras ubicaciones también pueden ser apropiadas, tales como cuando el usuario está viajando hacia o cerca del punto de venta, en la casa del usuario, oficina, o virtualmente cualquier ubicación donde el usuario puede comunicarse con el proveedor de pago. Aún si no existe comunicación actual, tal como un área si recepción, la solicitud puede ser almacenada y comunicada cuando el dispositivo del usuario sea capaz de comunicarse.

La comunicación transmite una cantidad solicitada y la información de identidad del consumidor o usuario. Si se usa un dispositivo móvil, el consumidor simplemente puede ingresar un número asociado con el proveedor de pago y un número de la cantidad solicitada, el cual puede estar abajo de la cantidad de dólar exacta u otro intervalo, tal como en incrementos de diez dólares. La información del consumidor, tal como el número telefónico del dispositivo, puede estar contenida en el mensaje transmitido. La información del consumidor también puede tomar otras formas, tales como una dirección de correo electrónico, nombre del usuario, etc., dependiendo, en parte, en cómo la solicitud es transmitida. Información adicional también puede ser solicitada, tal como una clave de acceso, para seguridad adicional. En un ejemplo, el usuario envía un SMS a "729725", el cual corresponde al proveedor de pago, con un texto o mensaje de "50", indicando una solicitud para una aprobación de $50 del proveedor de pago.

Bajo recepción de la solicitud, el proveedor de pago determina, en el paso 104, si el usuario tiene una cuenta con el proveedor de pago. Esto puede incluir determinar si el identificador de usuario corresponde a una cuenta válida con el proveedor de pago. Si no existe cuenta válida, una cantidad puede ser creada en el paso 106. La creación de cuenta puede ser por cualesquier medios apropiados. Por ejemplo, puede ser preguntado al usuario proveer cierta información, tal como una fuente de financiamiento, nombre, dirección, dirección de correo electrónico, clave de acceso/PIN, etc.

También puede preguntarse al usuario firmar por la característica de código de compra y/o condiciones establecidas o restricciones asociadas con la característica de código de compra de la cuenta. Por ejemplo, el usuario puede ser capaz solamente de solicitar una cierta cantidad por día, por semana, por solicitud, por mes, o solamente crear un cierto número de solicitudes o transacciones por período. Un período de expiración también puede ser establecido. Por ejemplo, si el usuario tiene la opción de establecer el período de expiración, un período más largo incrementa las probabilidades de un uso no autorizado de fondos aprobados, mientras que un período más corto incrementa la posibilidad de que los fondos aprobados expirarán antes de que el consumidor pueda realizar la compra. Las condiciones o restricciones pueden ser establecidas solamente por el usuario, solamente por el proveedor de pago, o una combinación de los dos. Si el período es establecido por el proveedor de pago, el proveedor de pago puede desear un período más corto para reducir las probabilidades de fraude. Las condiciones también pueden estar basadas-ubicación. En un ejemplo, solamente solicitudes hechas en California pueden ser aprobadas, o solicitudes hechas fuera de una cierta área ser sometidas a autenticación adicional y/o límites inferiores.

Una vez que la cuenta del usuario ha sido identificada o creada, el proveedor de pago determina, en el paso 108, si la información necesaria está para proceder a la solicitud. En una modalidad, la información mínima es una cantidad solicitada y un identificador del consumidor, el cual puede ser transmitido automáticamente sin entrada del usuario, tal como el número telefónico del dispositivo móvil. Aún si la información mínima es recibida, puede no incluir toda la información necesaria. Por ejemplo, si la cantidad tiene una restricción de que autenticación adicional es requerida si la solicitud es hecha desde una ubicación diferente, puede preguntarse al usuario proveer información adicional, tal como un PIN o clave de acceso. Así, en el paso 1 10, se pregunta al usuario proveer información adicional o información correcta solicitada por el proveedor de pago.

Después, el proveedor de pago determina, en el paso 112, si la cuenta del usuario permite la característica de código de compra. Si no, puede preguntarse al usuario firmar o permitir el uso de la característica en el paso 1 14. Esto puede ser a través de cualesquier medios disponibles, tales como el usuario seleccionado un botón o caja que transmita la aceptación de la característica, incluyendo los términos de uso. También puede preguntarse al usuario establecer las condiciones de la característica, como es discutido anteriormente.

El proveedor de pago entonces determina, en el paso 1 16, la cantidad solicitada por el usuario. Convenciones pueden ser establecidas, por el usuario o proveedor de pago, para maneras aceptables de comunicar la cantidad solicitada. Por ejemplo, la cantidad puede ser indicada por una cantidad de dólar, sin decimales o signos de dólar. La moneda puede ser establecida como un estándar por el usuario o puede ser establecida automáticamente por el proveedor de pago con base en la ubicación del usuario cuando la solicitud es hecha. Nótese que los pasos anteriores pueden ser realizados en diferente orden y necesitan ser secuenciales en el orden descrito.

El procesamiento continúa en el paso 118, donde el proveedor de pago determina si aprueba la solicitud del código de compra. Esta determinación puede incluir determinar si el usuario tiene suficientes fondos en la cuenta y si las condiciones, si existen, se han cumplido. Si la cuenta requiere autenticación adicional, puede preguntarse al usuario proveer la información solicitada como parte de la determinación. Nótese que en algunas modalidades, el usuario no tiene fondos suficientes en la cuenta. En ese caso, el proveedor de pago puede jalar la cantidad solicitada de una o más fuentes de financiamiento del usuario y no justo de la cuenta del usuario con el proveedor de pago. Por ejemplo, el proveedor de pago puede deducir la cantidad de una cuenta bancaria del usuario o cuenta de tarjeta de crédito. Si alguna condición no es cumplida, puede solicitarse al usuario re-enviar la información. De otra manera, la solicitud es rechazada.

Si todas las condiciones necesarias son cumplidas, el proveedor de pago aprueba la solicitud y "separa" la cantidad solicitada del resto de la cuenta en el paso 120. La cantidad separada no es usada actualmente, sino simplemente mantenida. Los fondos pueden ser mantenidos un período de tiempo predeterminado, como es establecido por el proveedor de pago o el usuario y puede estar basado en detalles de la solicitud, a menos que los fondos sean usados antes del período de tiempo. Ejemplos de períodos de tiempo incluyen una hora o un día. En una modalidad, si la cantidad solicitada completa no es aprobada, una cantidad menor puede ser aprobada. Así, el proceso de aprobación no es "todo o nada".

En el paso 122, el proveedor de pago genera el código de compra y asocia el código con la cantidad mantenida. En una modalidad, el código de compra es una cadena de números. La longitud puede ser variable o fija. El código también puede incluir letras, caracteres, símbolos, o una combinación con números. Códigos de barras u otros códigos que son legibles también pueden ser apropiados.

Una vez generado, el código de compra es transmitido al usuario en el paso 124. El código puede ser transmitido por cualesquier medios apropiados, incluyendo por SMS, correo electrónico, o voz. La transmisión también puede incluir el valor o cantidad del código (por ejemplo, $50) y cualesquier restricciones en su uso, tal como válido por los próximos diez minutos. El usuario ahora puede usar el código de compra para crear una compra o pago. Nótese que en algunas modalidades, si el usuario no es aprobado para la cantidad completa, el proveedor de pago puede aprobar una porción, tal como cuando el usuario ha excedido una cantidad de dólar, pero podría haber sido aprobado para una cantidad menor. La transmisión del código de compra podría incluir esta cantidad menor.

La Fig. 2 es un diagrama de flujo 200 mostrando un proceso donde el usuario usa el código de compra para realizar un pago con un vendedor en persona de conformidad con una modalidad. En otras modalidades, el pago no necesita ser hecho en persona o en el POS, sino remotamente, tal como a través de una PC u otro dispositivo de computación. En el paso 202, el usuario presenta el código de compra al vendedor o comerciante en el punto de venta. Esto puede ser hecho en cualesquier número de maneras. Por ejemplo, el usuario puede decir el código, escribirlo y mostrarlo al vendedor, o mostrarlo del dispositivo móvil del usuario al vendedor para identificación visual o exploración.

En el paso 204, el vendedor transmite un mensaje al proveedor de pago, donde el mensaje incluye al menos el código de pago e información de identificación del vendedor. El mensaje también puede incluir la cantidad de compra. La transmisión puede incluir automáticamente la información de identificación del vendedor, tal como el número telefónico del dispositivo de transmisión del vendedor. El mensaje pude ser transmitido electrónicamente a través de cualquier medio alámbrico o inalámbrico. En un ejemplo, el vendedor envía "9876 47" a "72975", el cual representa el código de compra y la cantidad de compra a un número de texto del proveedor de pago. En otro ejemplo, el vendedor envía "9876 47 6503340405" a "729725", el cual incluye un número telefónico adicional del vendedor, es descrito, un identificador del vendedor. Otros formatos u órdenes también pueden ser apropiados. La información también puede ser transmitida a través de una llamada de voz, correo electrónico, o cualesquier otros medios apropiados.

Una vez que el mensaje es recibido, el proveedor de pago determina, en el paso 206, si el vendedor o comerciante tiene una cuenta con el proveedor de pago. Por ejemplo, el proveedor de pago puede determinar si una cuenta válida está asociada con la información de identificación del vendedor, como el número telefónico del vendedor. Si no existe cuenta válida, el vendedor puede crear una cuenta en el paso 208. El vendedor puede ser notificado por el proveedor de pago que el vendedor necesitará crear una cuenta antes de que la solicitud de compra pueda ser procesada. La creación de una cuenta puede incluir el vendedor proporcionando la información requerida por el proveedor de pago, tal como dirección de correo electrónico, clave de acceso/PIN, dirección postal, nombre de usuario, información de tarjeta de crédito, información bancaria, etc.

Después de que la cuenta de vendedor ha sido accedida o creada, el proveedor de pago además procesa el mensaje para determinar el código de pago y posiblemente la cantidad de compra en el paso 210. Nótese que si la cantidad de compra no está incluida o requerida en el mensaje, el proveedor de pago puede simplemente procesar la solicitud con base en el código de compra.

Después, el código de compra es procesado en el paso 212. Éste puede incluir determinar si el código es válido, por ejemplo, un código aprobado anteriormente que no ha expirado, cualesquier limitaciones asociadas con el código, y/o la cantidad del código es aprobada. El procesamiento del código también puede incluir análisis adicional para reducir la posibilidad de que el vendedor solicite fraudulentamente una transferencia de dinero. Esto puede incluir observar el número de intentos no exitosos que este vendedor particular ha hecho en comparación con el número total de solicitudes hechas por el vendedor, el número de intentos hechos por el usuario particular, y ubicación geográfica y frecuencia de solicitudes de comerciantes del mismo usuario.

Si el código de compra es válido, el proveedor de pago determina si las condiciones o restricciones, si existen, son cumplidas. Por ejemplo, el proveedor de pago puede determinar si la cantidad aprobada del código de compra es menor o igual que la cantidad de pago solicitada. Otro ejemplo incluye determinar si los detalles de la transacción están dentro de cualesquier restricciones de compra, tal como frecuencia de uso de un código de compra por el usuario, nombre del comerciante o tipo, ubicación del comerciante, etc.

Si la solicitud de compra del vendedor es aprobada, como es determinado en el paso 214, el proveedor de pago procesa la solicitud de compra en el paso 216. El procesamiento puede incluir abonar a la cuenta del vendedor la cantidad apropiada, cargar a la cuenta del usuario la cantidad apropiada, y actualizar el código de compra. La cantidad acreditada y cargada pueden ser diferentes, tal como cuando existen tarifas asociadas con el uso de servicios del proveedor de pago, los cuales pueden ser pagados por el vendedor o el usuario. Las tarifas también pueden ser divididas igualmente o en proporciones diferentes entre el vendedor y el usuario. Actualizar el código de compra puede incluir invalidar el código para uso futuro, tal como cuando el código es un código de uso de una vez, la cantidad preaprobada máxima del código ha sido agotada, u otras limitaciones cumplidas, tal como tiempo máximo que el usuario puede usar el código ha sido alcanzado con este uso. El código también puede ser actualizado y permanecer válido para uso futuro, tal como reduciendo la cantidad preaprobada y/o actualizar el número de transacciones permitidas, asumir que otras condiciones son cumplidas, tales como límite de tiempo aún no expirado y saldo restante suficiente para una solicitud de compra subsiguiente.

Después, el proveedor de pago notifica al usuario y/o al vendedor en el paso 218, informar a éstos del pago. Notificación puede ser hecha por SMS, correo electrónico, llamada de voz o cualesquier otros medios apropiados. La notificación puede incluir un mensaje de que el pago solicitado ha sido aprobado, con la cantidad de crédito al vendedor y/o la cantidad cargada del usuario.

Una vez que el vendedor ha sido notificado del pago, el cual puede ser a través del usuario/comprador en lugar de directamente a través del proveedor de pago, el vendedor puede liberar los productos al usuario en el paso 220. El vendedor también pude proporcionar al usuario con un recibo físico, o el proveedor de pago puede proveer un "recibo" electrónico al usuario y/o al vendedor.

La Fig. 3 es un diagrama de flujo 300 mostrando un proceso donde el vendedor/comerciante solicita un reembolso para un usuario regresando una compra de conformidad con una modalidad. En el paso 302, el usuario presenta el objeto(s) regresado al vendedor o comerciante, junto con un identificador de usuario, tal como un número telefónico, correo electrónico, nombre del usuario, etc. El objeto puede ser un producto físico o un producto digital. En una modalidad, el usuario también presente una indicación de que objeto fue comprado por el comerciante particular, tal como un recibo en papel físico o un recibo electrónico en el dispositivo móvil del usuario.

Después, en el paso 304, el vendedor envía un mensaje al proveedor de pago, donde el mensaje incluye al menos información de identificación del usuario e información de identificación del vendedor. La información del usuario puede ser un número telefónico de un dispositivo de usuario que el vendedor ingresa manualmente o registra en el mensaje. La información de identificación del vendedor, tal como el número telefónico del dispositivo de transmisión del vendedor, puede ser transmitida automáticamente cuando el mensaje es enviado. El mensaje también puede incluir la cantidad de reembolso solicitada y/u otra información acerca de la solicitud de reembolso, tal como un ID de transacción, o una indicación de que la solicitud es para un reembolso. El envío puede ser por SMS, correo electrónico, voz, o cualquier método apropiado.

Una vez que el mensaje es recibido, el proveedor de pago procesa el mensaje en el paso 306. El procesamiento puede incluir determinar si el vendedor tiene una cuenta válida con el proveedor de pago, y si no, el vendedor haber abierto o actualizado una cuenta para continuar con la solicitud de reembolso. El procesamiento también puede incluir observar transacciones anteriores entre el usuario (con base en la identificación del usuario) y el vendedor (con base en la identificación del vendedor). Esto puede indicar si el reembolso solicitado del usuano es actualmente de una compra anterior entre el usuario y el vendedor. El proveedor de pago también puede observar otra información, tal como la información geográfica del vendedor, usuario, y solicitud de reembolso actual, número y cantidad de dólares de solicitud de reembolso hecha por el vendedor particular, y solicitudes de reembolso no exitosas contra exitosas involucrando el usuario particular y vendedor, ambos juntas e individualmente. Si el usuario tiene un recibo actual u otra prueba de compra, este análisis puede no ser necesario. En este caso, el vendedor puede indicar en el mensaje del paso 304 que el vendedor ha confirmado que la solicitud de reembolso es válida.

El proveedor de pago entonces determina, en el paso 308, si aprueba la solicitud de reembolso. Si la solicitud de reembolso no es aprobada, el proveedor de pago puede solicitar al vendedor proveer información adicional o tomar ciertas acciones en el paso 310. Por ejemplo, si la solicitud fue denegada debido a fondos insuficientes en la cuenta del vendedor, el vendedor puede ser preguntado al vendedor depositar más fondos en la cuenta. Si la solicitud fue denegada debido a que la transacción de compra inicial podría no ser verificada, puede preguntarse al vendedor aprobar en extremo del vendedor u obtener información adicional, tal como del usuario, para verificar la transacción original. El proveedor de pago determina nuevamente si aprueba la transacción, en el paso 312, con base en alguna nueva información. El proveedor de pago entonces puede aprobar, rechazar, o solicitar nuevamente información adicional.

Si el proveedor de pago aprueba la solicitud de reembolso, la solicitud de reembolso es procesada en el paso 314. Esto puede incluir cargar una cantidad apropiada de la cuenta del vendedor y abonar una cantidad apropiada a la cuenta del usuario. Las cantidades pueden variar, dependiendo de si las tarifas son impuestas para el servicio, el cual puede incurrido por el vendedor, el usuario, o ambos. El proveedor de pago también puede actualizar la base de datos asociada con el vendedor y usuario para reflejar el reembolso procesado, incluyendo la cantidad, la fecha, la ubicación, etc.

Una vez procesado, el proveedor de pago puede enviar, en el paso 316, tal como SMS, correo electrónico, o voz, al usuario y/o vendedor. El usuario recibe confirmación en el dispositivo de usuario de que la cantidad de reembolso ha sido abonada a la cuenta, y/o el vendedor recibe confirmación de que la cantidad de reembolso ha sido abonada de la cuenta del vendedor.

Bajo confirmación, el usuario libera el objeto(s) regresado al vendedor en el paso 318.

Así, los usuarios pueden conducir transacciones financieras (compras y reembolsos) en persona en puntos físicos de venta sin tener que portar efectivo, cheques, tarjetas de crédito, tarjetas bancarias o crédito abierto o cuentas bancarias. Estos beneficios tanto para comerciantes y consumidores promueven maneras más fáciles de comprar objetos. El vendedor es asegurado de pago a través del proveedor de pago. Así, tanto el vendedor como el usuario/comprador obtienen lo que quieren, mientras con métodos de pago convencionales, la transacción puede no haber ocurrido debido a que el usuario no tiene suficiente efectivo, un cheque o una tarjeta de crédito/débito para usar.

La Fig. 4 es un diagrama de bloque de un sistema en red 400 configurado para manipular una transacción financiera entre un recipiente (por ejemplo, un comerciante o vendedor) y un emisor (por ejemplo, usuario o consumidor), tal como es descrito arriba, de conformidad con una modalidad de la invención. El sistema 400 incluye un dispositivo de usuario 410, un dispositivo de comerciante 462, un servidor de comerciante 440, y un servidor de proveedor de pago 470 en comunicación en una red 460. El servidor de proveedor de pago 470 puede ser mantenido por un proveedor de pago, tal como PayPal, Inc. de San José, CA. Un usuario 405, tal como el emisor o comprador, utiliza el dispositivo de usuario 410 para realizar una transacción de pago con el servidor de comerciante 440 usando el servidor de proveedor de pago 470 y el dispositivo de comerciante 462.

El dispositivo de usuario 410, dispositivo de comerciante 462, servidor de comerciante 440, y servidor de proveedor de pago 470 pueden cada uno incluir uno o más procesadores, memorias, y otros componentes apropiados para ejecutar instrucciones tales como código de programa y/o datos almacenados en uno más medios legibles en computadora para implementar las varias aplicaciones, datos y pasos descritos en la presente. Por ejemplo, tales instrucciones pueden ser almacenadas en uno o más medios legibles en computadora tales como memorias o dispositivos de almacenamiento de datos internos y/o externos a varios componentes del sistema 400, y/o accesibles en la red 460.

La red 460 puede ser implementada como una red única o una combinación de múltiples redes. Por ejemplo, en varias modalidades, la red 460 puede incluir el Internet o una o más intrarredes, redes de línea terrestre, redes inalámbricas, y/u otros tipos de red apropiadas.

El dispositivo de usuario 410 y el dispositivo de comerciante 462 pueden ser implementados usando cualesquier hardware apropiado y software configurado para comunicación alámbrica y/o alámbrica sobre la red 460. Por ejemplo, en una modalidad, los dos dispositivos pueden ser implementados como una computadora personal (PC), un teléfono inteligente, un asistente digital personal (PDA), computadora portátil, y/u otros tipos de dispositivos de computación capaces de transmitir y/o recibir datos, tales como un iPad™ para Apple™.

El dispositivo de usuario 410 puede incluir una o más aplicaciones de buscador 415 las cuales pueden ser usadas, por ejemplo, para proporcionar una interfaz conveniente para permitir al usuario 405 buscar información disponible sobre la red 460. Por ejemplo, en una modalidad, la aplicación de buscador 415 puede ser implementada como un buscador de red configurado para ver información disponible sobre el Internet. El dispositivo de usuario 410 también puede incluir una o más aplicaciones de barra de herramientas 420 las cuales pueden ser usadas, por ejemplo, para proveer procesamiento del lado del cliente para realizar las tareas deseadas en respuesta a operaciones seleccionadas por el usuario 405. En una modalidad, la aplicación de barra de herramientas 420 puede desplegar una ¡nterfaz de usuario en combinación con la aplicación del buscador 415.

El dispositivo de usuario 410 además puede incluir otras aplicaciones 425 como puede ser deseado en modalidades particulares para proveer las características deseadas al dispositivo de usuario 410. Por ejemplo, otras aplicaciones 425 pueden incluir aplicaciones de seguridad para implementar características de seguridad del lado del cliente, aplicaciones de cliente programáticas para interconectarse con las interfases de programación de aplicación apropiadas (APIs) sobre la red 460, u otros tipos de aplicaciones. Las aplicaciones 425 también pueden incluir correo electrónico, texto, voz y aplicaciones IM que permiten que el usuario 405 envía y reciba correos electrónicos, llamadas, y textos a través de la red 460, así como aplicaciones que permiten al usuario hacer pagos a través del proveedor de pago y crear/controlar la característica de código de compra como es discutido anteriormente. El dispositivo de usuario 410 incluye uno o más identificadores 430 los cuales pueden ser implementados, por ejemplo, como entidades de registro del sistema operativo, registros de identificación asociados con la aplicación del buscador 415, identificadores asociados con hardware del dispositivo de usuario 410, u otros identificadores apropiados, tales como usados para autenticación de pago/usuario/dispositivo. En una modalidad, el identificador de usuario 430 puede ser usado por un proveedor de servicio de pago al usuario asociado 405 con una cantidad particular mantenida por el proveedor de pago como es descrito adicionalmente en la presente. Una aplicación de comunicaciones 422, con ¡nterfases asociadas, permite al dispositivo de usuario 410, comunicarse con el dispositivo de comerciante 462 y servidor de proveedor de pago 470, así como otros dispositivos dentro del sistema 400.

El dispositivo de comerciante 462 puede tener aplicaciones similares y módulos como dispositivo de usuario 410, pero puede ser el mismo dispositivo o uno diferente que el dispositivo de usuario 410. Por ejemplo, el dispositivo de usuario puede ser un teléfono inteligente o móvil, y el dispositivo de comerciante puede ser una terminal POS, tableta u otro dispositivo de computación/comunicación. El dispositivo de comerciante 462 también puede incluir una o más aplicaciones de buscador 415 y una o más aplicaciones de la barra de herramientas 420 las cuales pueden ser usadas, por ejemplo, para proporcionar una interfaz conveniente para permitir al usuario 406 buscar información y realizar tareas sobre la red 460. Por ejemplo, en una modalidad, una aplicación de buscador 415 puede ser implementada como un buscador de red configurado para observar información disponible sobre el Internet y comunicarse con el servidor de proveedor de pago 470 para recibir y enviar información acerca del procesamiento de un código de compra o un reembolso.

El dispositivo de comerciante 462 además puede incluir otras aplicaciones 425 tales como aplicaciones de seguridad para implementar las características de seguridad del lado del cliente, aplicaciones de cliente programáticas para interconexión con las interfases de programación de aplicación apropiadas (APIs) sobre la red 460, u otros tipos de aplicaciones. Las aplicaciones 425 también pueden incluir aplicaciones de correo electrónico, texto, IM, y de voz que permitan que un comerciante 406 se comunique a través de red 460 para realizar una compra o reembolso. El dispositivo de comerciante 462 incluye uno o más identificadores de usuario 430 los cuales pueden ser implementados, por ejemplo, como entradas de registro de sistema operativo, registros de verificación asociados con la aplicación del buscador 415, identificadores asociados con hardware del dispositivo de comerciante 462, u otros identificadores apropiados, tales como los usados para autenticación de pago/usuario/dispositivo, por ejemplo, el número telefónico o ID del dispositivo asociado con el dispositivo de comerciante 462. Identificadores pueden ser usados por un proveedor de servicio de pago al comerciante asociado 406 con una cuenta particular mantenida por el proveedor de servicio de pago. Nótese que el dispositivo de comerciante 462 y/o el dispositivo de usuario 410 pueden ser teléfonos más simples (es decir, no teléfonos inteligentes) capaces de solamente comunicación y texto, tal como con el proveedor de pago. Así, teléfonos inteligentes complicados no son requeridos para realizar las transacciones descritas en la presente.

El servidor de comerciante 440 puede ser mantenido, por ejemplo, por un comerciante o vendedor ofreciendo varios productos y/o servicios en intercambio por el pago a ser recibido sobre la red 460. El servidor de comerciante 440 puede estar ubicado con o lejos del dispositivo de comerciante 462. Generalmente, el servidor de comerciante 440 puede ser mantenido por cualquiera o cualquier entrada que reciba dinero, el incluye donaciones así como minoristas. El servidor de comerciante 440 incluye una base de datos 445 identificando los productos disponibles y/o servicios (por ejemplo, referidos colectivamente como objetos) los cuales pueden ser hechos disponibles para observación y compra por el usuario 405. Como corresponde, el servidor de comerciante 440 también incluye una aplicación de centro de compras 450 la cual puede ser configurada para servir información sobre la red 460 al buscador 415 del dispositivo de usuario 410 y dispositivo de comerciante 462. En una modalidad, el usuario 405 pueden interactuar con la aplicación del centro de compras 450 a través de las aplicaciones del buscador sobre la red 460 para observar varios productos o servicios identificados en la base de datos 445. Nótese que el servidor de comerciante 440 puede no ser requerido en sistemas más simples, donde las ventas y las transacciones son realizadas en una ubicación física.

El servidor de comerciante 440 también incluye una aplicación de salida 455 la cual puede ser configurada para facilitar la compra por el usuario 405 de productos o servicios identificados por la aplicación de centro de compras 450. La aplicación de salida 455 puede ser configurada para aceptar información de pago del usuario 405 a través del servidor de proveedor de servicio de pago 470 sobre la red 460. Por ejemplo, la aplicación de salida 455 puede recibir y procesar una confirmación de pago desde el servidor de proveedor de servicio de pago 470, así como transmitir información de transacción al proveedor de pago y recibir información del proveedor de pago (por ejemplo, un ID de transacción) La aplicación de salida 455 también puede ser configurada para aceptar una o más opciones de pago diferentes, incluyendo códigos de compra.

El servidor de proveedor de pago 470 puede ser mantenido, por ejemplo, por un proveedor de servicio de pago en línea el cual puede proporcionar pago entre el usuario 405 y el operador del servidor de comerciante. A este respecto, el servidor de proveedor de pago 470 incluye una o más aplicaciones de pago 475 las cuales pueden ser configuradas para interactuar con el dispositivo de usuario 410, el dispositivo de comerciante 462, y/o el servidor de comerciante 440 sobre la red 460 para facilitar la compra o devolución de productos o servicios por el usuario 405 del dispositivo de usuario 4 0.

El servidor de proveedor de pago 470 también mantiene una pluralidad de cuentas de usuario 480, cada una de las cuales puede incluir información de cuenta 485 asociada con usuarios individuales y comerciantes. Por ejemplo, la información de cuenta 485 puede incluir información financiera y privada de los usuarios de dispositivos tales como números de cuenta, claves de acceso, identificadores de dispositivo, nombres de usuario, números telefónicos, información de tarjeta de crédito, información bancaria, condiciones de código de compra, u otra información financiera la cual puede ser usada para facilitar las transacciones en línea por el usuario 405. Ventajosamente, la aplicación de pago 475 puede ser configurada para interactuar con el servidor de comerciante 440 a cuenta del usuario 405 durante una transacción con aplicación de salida 455 para rastrear y manipular compras hechas por los usuarios.

Una aplicación de procesamiento de transacción 490, la cual puede ser parte de o separada de la aplicación de pago 475, puede ser configurada para recibir información de un dispositivo de usuario, dispositivo de comerciante, y/o servidor de comerciante 440 para procesar y almacenar en una base de datos de pago 495. La aplicación de procesamiento de transacción 490 puede incluir una o más aplicaciones para procesar información del usuario 405 y/o comerciante para procesar un pago o reembolso como es descrito en la presente. La aplicación de pago 475 puede ser configurada adicionalmente para determinar la existencia de y para manejar cuentas para el usuario 405 y/o comerciante 406, así como para crear nuevas cuentas si es necesario, tal como la configuración, administración, y uso de códigos de compra.

Así, el sistema 400 permite al usuario 405 crear una compra o reembolso como es descrito en la presente, tanto electrónicamente como físicamente en persona.

La Fig. 5 es un diagrama de bloque de un sistema de computadora 500 apropiado para implementarse en una o más modalidades de la presente descripción. En varias implementaciones, el dispositivo de usuario puede comprender un dispositivo de computadora personal (por ejemplo, una computadora personal, computadora móvil, teléfono inteligente, PDA, Dispositivo Bluetooth, teclado FOB, credencial, etc.) capaz de comunicarse con la red. El comerciante y/o proveedor de pago puede utilizar un dispositivo de computación en red (por ejemplo, un servidor de red) capaz de comunicarse con la red. Debería ser apreciado que cada uno de los dispositivos utilizados por los usuarios, comerciantes, y proveedores de pago pueden ser implementados como sistema de computadora 500 en una manera como sigue.

El sistema de computadora 500 incluye un bus 502 u otro mecanismo de comunicación para comunicar información. Los componentes incluyen un componente de entrada/salida (l/O) 504 que procesa una acción de usuario, tal como seleccionar teclas de un teclado numérico/teclado, seleccionado uno o más botones o enlaces, etc., y envía una señal correspondiente hacia el bus 502. El componente de E/S 504 también puede incluir un componente de salida, tal como una pantalla 511 y un control de cursor 513 (tal como un teclado, teclado numérico, ratón, etc.). Un componente de entrada/salida de audio opcional 505 también puede ser incluido para permitir al usuario ingresar información convirtiendo señales de audio. El componente de E/S de audio 505 puede permitir al usuario escuchar y transmitir audio. Un transceptor o ¡nterfaz de red 506 transmite y recibe señales entre el sistema de computadora 500 y otros dispositivos, tales como otro dispositivo de usuario, un servidor de comerciante, o un servidor de proveedor de pago vía red 460. En una modalidad, la transmisión es inalámbrica, aunque otros medios de transmisión y métodos también pueden ser apropiados. Un procesador 512, el cual puede ser un microcontrolador, procesador de señal digital (DSP), u otro componente de procesamiento, procesa varias señales, tales como para despliegue en el sistema de computadora 500 o transmisión a otros dispositivos vía un enlace de comunicación 518. El procesador 512 también puede controlar la transmisión de la información, tal como registros de verificación o direcciones IP, a otros dispositivos.

Los componentes del sistema de computadora 500 también incluyen un componente de memoria del sistema 514 (por ejemplo, RAM), un componente de almacenamiento estático 516 (por ejemplo, ROM), y/o una unidad de disco 517. El sistema de computadora 500 realiza operaciones específicas por el procesador 512 y otros componentes ejecutando una o más secuencias de instrucciones contenidas en el componente de memoria del sistema 514. Lógica puede ser codificada en un medio legible por computadora, el cual puede referirse a cualquier medio que participa en proporcionar instrucciones al procesador 512 para ejecución. Dicho medio puede tomar cualesquier formas, incluyendo sin limitación, medios no volátiles, medios volátiles y medios de transmisión. En varias implementaciones, medios no volátiles incluyen discos ópticos o magnéticos, medios volátiles incluyen memoria dinámica, tale como componente de memoria del sistema 514, y medio de transmisión incluye cables coaxiales, alambre de cobre, y fibras ópticas, incluyendo alambres que comprenden el bus 502. En una modalidad, la lógica está codificada en medio legible en computadora no-transitorio. En un ejemplo, el medio de transmisión puede tomar la forma de una onda acústica o luz, tal como esos generados durante onda de radio, óptico y comunicaciones infrarrojas de datos.

Algunas formas comunes de medios legibles por computadora incluyen, por ejemplo, disquete, disco flexible, disco duro, cinta magnética, cualesquier otro medio magnético, CD-ROM, cualesquier otro medio óptico, tarjetas perforadas, cinta de papel, cualesquier otro medio físico con patrones u orificios, RAM, PROM, EPROM, FLASH-EPROM, cualesquier otro chip de memoria o cartucho, o cualesquier otro medio a partir del cual una computadora es adaptada para lectura.

En varias modalidades de la presente descripción, la ejecución de secuencias de instrucciones para practicar la presente descripción puede ser realizada por el sistema de computadora 500. En varias otras modalidades de la presente descripción, una pluralidad de sistemas de computadoras 500 acoplados por el enlace de comunicación 518 a la red (por ejemplo, tal como una LAN, WLAN, PTSN, y/o varias otras redes alámbricas o inalámbricas, incluyendo telecomunicaciones, móviles, y redes de teléfono celular) pueden realizar las secuencias de instrucciones para practicar la presente descripción en coordinación con otra.

En los casos en que es aplicable, las diversas modalidades provistas por la presente descripción pueden ser implementadas utilizando hardware, software o combinaciones de hardware y software. También, en los casos en que es aplicable, los diversos componentes de hardware y/o componentes de software establecidos en la presente descripción pueden ser combinados en componentes compuestos que comprenden software, hardware y/o ambos sin alejarse del alcance de la presente descripción. En los casos en que es aplicable, los diversos componentes de hardware y/o componentes de software establecidos en la presente descripción pueden ser separados en subcomponentes que comprenden software, hardware y/o ambos sin alejarse del alcance de la presente descripción. Además, en los casos en que es aplicable, se contempla que los componentes de software pueden ser implementados como componentes de hardware y viceversa.

El software, de conformidad con la presente descripción, tal como el código de programa y/o datos, puede ser almacenado en uno o más medios legibles por computadora. También se contempla que el software identificado en la presente puede ser implementado utilizando una o más computadoras de propósito general o de propósito especifico y/o sistemas de cómputo, en red y/o de otra forma. En los casos en que es aplicable, el orden de los diversos pasos descritos en la presente descripción pueden cambiarse, combinarse en pasos compuestos, y/o separarse en subpasos para proporcionar las características descritas en la presente.

La descripción anterior no está prevista para limitar la presente descripción a las formas precisas o campos particulares de uso descritos. De tal manera, se contempla que varias modalidades alternativas y/o modificaciones para la presente invención, ya sea descritas en forma explícita o implícita en la presente, son posibles a la luz de la descripción. Con las modalidades de la presente descripción descritas, los expertos en la técnica reconocerán que se pueden hacer cambios en la forma y detalle sin alejarse del alcance de la presente descripción. Por consiguiente, la presente descripción está limitada únicamente por las reivindicaciones.

Claims (24)

NOVEDAD DE LA INVENCIÓN REVINDICACIONES

1.- Un método para realizar una transacción financiera, que comprende: recibir, por un procesador de un proveedor de pago, una solicitud de código de compra procedente de un usuario a través de un dispositivo de usuario, en donde la solicitud de código de compra comprende una cantidad y un primer identificador de usuario; transmitir un código de compra al usuario si la solicitud de autorización es aprobada; recibir una solicitud de compra procedente de un beneficiario a través de un dispositivo de beneficiario, en donde la solicitud de compra comprende el código de compra, un segundo identificador de usuario, y un identificador de beneficiario; y transmitir un mensaje al beneficiario si la solicitud de compra es aprobada .

2.- El método de conformidad con la reivindicación 1 , caracterizado además porque el código de compra expira después de un período de tiempo predeterminado.

3. - El método de conformidad con la reivindicación 1 , caracterizado además porque el código de compra expira después de una cantidad de usos predeterminados.

4. - El método de conformidad con la reivindicación 3, caracterizado además porque la cantidad predeterminada de usos es uno.

5. - El método de conformidad con la reivindicación 1 , caracterizado además porque el código de compra es presentado al beneficiario en persona.

6. - El método de conformidad con la reivindicación 1 , caracterizado además porque el identificador de usuario es transmitido automáticamente con la solicitud del código de compra.

7 - El método de conformidad con la reivindicación 6, caracterizado además porque el primer identificador de usuario comprende un número telefónico del usuario.

8.- El método de conformidad con la reivindicación 1 , caracterizado además porque el identificador del beneficiario es transmitido automáticamente con la solicitud de compra.

9. - El método de conformidad con la reivindicación 8, caracterizado además porque el identificador del beneficiario comprende un número telefónico del beneficiario.

10. - El método de conformidad con la reivindicación 1 , caracterizado además porque el primero y el segundo identificadores de usuario son los mismos.

1 . - El método de conformidad con la reivindicación 1 , caracterizado además porque comprende adicionalmente transmitir un mensaje al usuario si la solicitud de compra es aprobada.

12. - El método de conformidad con la reivindicación 1 , caracterizado además porque la transmisión y la recepción son a través de texto.

13. - El método de conformidad con la reivindicación 1 , caracterizado además porque comprende adicionalmente recibir información del usuario para establecer o modificar el código de compra.

14. - El método de conformidad con la reivindicación 13, caracterizado además porque la información recibida comprende limitaciones y condiciones para uso del código de compra por el usuario.

15.- Un método para realizar una transacción financiera, que comprende: recibir, por un procesador de un proveedor de pago, una solicitud de reembolso de un vendedor, en donde la solicitud de reembolso comprende una cantidad, un identificador de vendedor, y un identificador de consumidor; determinar, por el procesador, si la solicitud de reembolso está asociada con una compra anterior por el consumidor al vendedor; abonar a una cuenta del consumidor y cargar a una cuenta del vendedor con la cantidad si la solicitud de reembolso es aprobada; y transmitir un mensaje al consumidor si la solicitud de reembolso es aprobada.

16 - El método de conformidad con la reivindicación 15, caracterizado además porque los identificadores del vendedor y del consumidor son números telefónicos.

17. - El método de conformidad con la reivindicación 15, caracterizado además porque el identificador del vendedor es transmitido automáticamente con la solicitud de reembolso.

18. - El método de conformidad con la reivindicación 15, caracterizado además porque la recepción y la transmisión son mediante SMS.

19. - Un medio legible en máquina no transitorio comprendiendo una pluralidad de instrucciones legibles en máquina las cuales cuando son ejecutadas por uno o más procesadores de un servidor son adaptadas para causar que el servidor realice un método comprendiendo: recibir una solicitud de código de compra desde un usuario a través de un dispositivo de usuario, en donde la solicitud del código de compra comprende una cantidad y un primer identificador de usuario; transmitir un código de compra hacia el usuario si la solicitud de autorización es aprobada; recibir una solicitud de compra desde un beneficiario a través de un dispositivo de beneficiario, en donde la solicitud de compra comprende el código de compra, un segundo identificador de usuario, y un identificador de beneficiario; y transmitir un mensaje hacia el beneficiario si la solicitud de compra es aprobada.

20. - El medio legible en máquina de conformidad con la reivindicación 19, en donde el primer identificador de usuario es transmitido automáticamente con la solicitud del código de compra.

21 . - El medio legible en máquina de conformidad con la reivindicación 19, caracterizado además porque el identificador de beneficiario es transmitido automáticamente con la solicitud de compra.

22. - El medio legible en máquina de conformidad con la reivindicación 19, caracterizado además porque la transmisión y la recepción son a través de texto.

23. - El medio legible en máquina de conformidad con la reivindicación 19, caracterizado además porque el método adicionalmente comprende recibir información desde el usuario para establecer o modificar el código de compra.

24. - El medio legible en máquina de conformidad con la reivindicación 23, caracterizado además porque la información recibida comprende limitaciones y condiciones para uso del código de compra por el usuario.