ES2396325T3 - Método de aprovisionar una cuenta - Google Patents

Método de aprovisionar una cuenta Download PDF

Info

Publication number
ES2396325T3
ES2396325T3 ES02255734T ES02255734T ES2396325T3 ES 2396325 T3 ES2396325 T3 ES 2396325T3 ES 02255734 T ES02255734 T ES 02255734T ES 02255734 T ES02255734 T ES 02255734T ES 2396325 T3 ES2396325 T3 ES 2396325T3
Authority
ES
Spain
Prior art keywords
host
payment
request
transmission
response
Prior art date
Legal status (The legal status 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 status listed.)
Expired - Lifetime
Application number
ES02255734T
Other languages
English (en)
Inventor
Tony Moore
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
TURRIFF INTERNAT Ltd
TURRIFF INTERNATIONAL Ltd
Original Assignee
TURRIFF INTERNAT Ltd
TURRIFF INTERNATIONAL Ltd
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 TURRIFF INTERNAT Ltd, TURRIFF INTERNATIONAL Ltd filed Critical TURRIFF INTERNAT Ltd
Application granted granted Critical
Publication of ES2396325T3 publication Critical patent/ES2396325T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

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/04—Payment circuits
    • 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/28—Pre-payment schemes, e.g. "pay before"
    • 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/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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M17/00—Prepayment of wireline communication systems, wireless communication systems or telephone systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M17/00—Prepayment of wireline communication systems, wireless communication systems or telephone systems
    • H04M17/10—Account details or usage
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M17/00—Prepayment of wireline communication systems, wireless communication systems or telephone systems
    • H04M17/20—Prepayment of wireline communication systems, wireless communication systems or telephone systems with provision for recharging the prepaid account or card, or for credit establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M17/00—Prepayment of wireline communication systems, wireless communication systems or telephone systems
    • H04M17/20—Prepayment of wireline communication systems, wireless communication systems or telephone systems with provision for recharging the prepaid account or card, or for credit establishment
    • H04M17/204—Prepayment of wireline communication systems, wireless communication systems or telephone systems with provision for recharging the prepaid account or card, or for credit establishment on-line recharging, e.g. cashless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M17/00—Prepayment of wireline communication systems, wireless communication systems or telephone systems
    • H04M2017/24—Prepayment of wireline communication systems, wireless communication systems or telephone systems with on-line recharging of an account or card, e.g. cashless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2215/00—Metering arrangements; Time controlling arrangements; Time indicating arrangements
    • H04M2215/32—Involving wireless systems

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Strategic Management (AREA)
  • Accounting & Taxation (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Meter Arrangements (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Optical Communication System (AREA)

Abstract

Un método de aprovisionar una cuenta, que comprende: en una etapa de petición: transmitir, desde un dispositivo móvil (1a) de comunicaciones a un anfitrión (15), una petición (33) paraaprovisionar una o más cuentas asociadas con uno o más dispositivos móviles (1a, 1b) decomunicaciones, incluyendo dicha petición (33) información relativa a dichos uno o más dispositivosmóviles de comunicaciones; confirmar el anfitrión la existencia de una o más cuentas; dependiendo de dichas una o más cuentas existentes, transmitir una respuesta (40), desde dichoanfitrión (15) a dicho dispositivo móvil (1a) de comunicaciones, que incluye información de validaciónpara validar la petición; almacenar el anfitrión la información de validación; y almacenar el dispositivo móvil (1a) de comunicaciones, la respuesta (40); en la etapa de pago: transmitir, desde dicho dispositivo (1a) móvil de comunicaciones a un dispositivo de pago (13) unprimer mensaje (51) que incluye la información de validación; realizar un pago en el dispositivo de pago (13), en el que el dispositivo de pago recibe el pago enadición a la información de validación; transmitir, desde dicho dispositivo de pago (13) a dicho anfitrión un segundo mensaje (52) que incluyela información de validación y la información relativa al pago; y comparar el anfitrión la información de validación recibida del dispositivo de pago con la información devalidación almacenada por el anfitrión y, dependiendo de la validación de la información de validaciónrecibida del dispositivo de pago con la información de validación almacenada por el anfitrión, realizar elaprovisionamiento de dichas una o más cuentas.

Description

Método de aprovisionar una cuenta.
La presente invención se refiere a un método de aprovisionar una cuenta y se aplica en particular, pero no exclusivamente, a las cuentas de prepago en telefonía móvil.
Un sistema de telecomunicaciones con móviles, conocido también como red de telefonía celular, se puede usar para proporcionar una pluralidad de servicios al abonado que utiliza un terminal telefónico móvil, tales como hacer y recibir llamadas de voz, proporcionar y recuperar correo de voz y enviar y recibir mensajes de texto. Un ejemplo de tal sistema es uno que cumpla las recomendaciones del Sistema Global para Comunicaciones con Móviles (GSM).
El usuario puede pagar estos servicios generalmente de una de dos maneras. Se pueden cargar de acuerdo con el uso y facturar a intervalos regulares por el proveedor del servicio. Alternativamente, el usuario puede pagar previamente por estos servicios depositando fondos en una cuenta asociada con el terminal. De este modo, cuando se usa un servicio, el crédito se deduce de la cuenta. Siempre que haya suficiente crédito en la cuenta, el usuario podrá seguir usando el servicio. No obstante, se crea usualmente un conflicto cuando la cuenta queda agotada, en cuyo caso se necesitan más fondos. El procedimiento de comprar crédito para la cuenta se conoce corrientemente como "comprar tiempo en antena".
El prepago se puede realizar de diversas maneras.
En un método, el usuario compra una "tarjeta cargada" de valor monetario fijo. El usuario aprovisiona entonces una cuenta asociada con su terminal con el valor de la tarjeta, registrando la compra en un proveedor del servicio. Para registrar la compra, el usuario simplemente llama al proveedor del servicio usando el terminal telefónico móvil y teclea un número de identificación que figura en la tarjeta. Alternativamente, el usuario llama al proveedor del servicio desde cualquier teléfono fijo o móvil y notifica al proveedor del servicio el número del terminal telefónico móvil y el número de identificación.
Aunque el uso de las tarjetas de prepago está muy extendido, presenta diversos inconvenientes. Confía en que el usuario pueda comprar una tarjeta del tipo apropiado en un expendedor. Sin embargo, acceder a un expendedor puede estar limitado, particularmente si el usuario está viajando por el extranjero. Además, el uso de las tarjetas de prepago es caro, ya que las tarjetas se usan sólo una vez y posteriormente se desechan. El uso de las tarjetas también requiere un alto nivel de seguridad, ya que son consideradas como dinero efectivo por los elementos criminales.
En otro método, el usuario se provee de una tarjeta magnética que tiene una banda magnética. La banda magnética lleva información relativa al terminal. El usuario visita a un agente representante del proveedor del servicio y entrega la tarjeta magnética al agente junto con el pago. El agente entonces desliza la tarjeta a través de un lector y teclea el valor monetario con el que se va a aprovisionar la cuenta. La tarjeta magnética se le devuelve al usuario una vez completado el proceso. De esta manera, la información correspondiente al terminal y al crédito se puede transferir directamente al proveedor del servicio. De ese modo, no se requiere ninguna acción más por parte del usuario.
En otro método más, que se describe en el documento WO-A-0111857, un usuario puede aprovisionar su cuenta por medio de una máquina de venta de autoservicio. El usuario introduce la información en la máquina de venta, tal como la identidad de su proveedor del servicio, el número de su terminal, la cuantía que se quiere aprovisionar y paga usando efectivo o tarjeta de crédito. Sin embargo, este tipo de máquinas de venta es caro de instalar y están expuestas al vandalismo. También existe el problema de que el efectivo se guarda en la máquina y debe de ser recaudado.
Todos los métodos anteriores permiten el pago usando efectivo, tarjetas de crédito o tarjetas de débito.
El documento WO-A-0111857 también describe un método de aprovisionar una cuenta usando sólo el terminal telefónico móvil. Sin embargo, el terminal necesita modificación. El pago sólo se puede hacer usando tarjetas de crédito y/o débito y se deben enviar los detalles al proveedor del servicio. Por ello, el terminal necesita medios de cifrado para transferir de modo seguro los detalles de las tarjetas de crédito y débito al proveedor del servicio.
El documento WO-A-9847112 describe un método de venta electrónica de valores previamente pagados, tales como tiempo de llamadas de celulares. Un cliente inicia una transacción y solicita un valor de recarga a un dispositivo de la red, que puede ser un quiosco, un ATM, un punto de dispositivo de ventas o un teléfono celular. Al cliente se le solicita que pague la transacción. El proceso de pago puede ser bien en efectivo, en cuyo caso se le requerirá que introduzca el efectivo para el pago en un receptor de billetes en el dispositivo, o bien por medio de una tarjeta bancaria.
La presente invención pretende proporcionar un método mejorado de aprovisionar una cuenta.
De acuerdo con un primer aspecto de la presente invención se proporciona un método de aprovisionar una cuenta como se especifica en la reivindicación 1.
De acuerdo con un segundo aspecto de la presente invención se proporciona un aparato para aprovisionar una cuenta como se especifica en la reivindicación 29.
Características opcionales se especifican en las reivindicaciones dependientes.
Se describirán ahora realizaciones de la presente invención, a modo de ejemplo, con referencia a los dibujos que se acompañan, en los cuales:
La figura 1 es un diagrama esquemático de una red de telecomunicaciones con móviles; La figura 2 es una ilustración esquemática de un terminal telefónico móvil; La figura 3 es un diagrama esquemático de un centro de facturación; La figura 4 es un diagrama esquemático de un punto de dispositivo de interacción; La figura 5 es un diagrama esquemático de un anfitrión seguro; La figura 6 muestra un proceso de solicitar aprovisionamiento de una cuenta; La figura 7 muestra el flujo de información entre un terminal, un anfitrión seguro y un centro de facturación; La figura 8 es un diagrama esquemático de una petición de aprovisionamiento de una cuenta enviada desde un terminal a un anfitrión seguro; La figura 9 es un diagrama esquemático de un mensaje enviado desde un anfitrión seguro a un terminal; La figura 10 (dos hojas) muestra un proceso de validación de la petición de la figura 8; La figura 11 muestra el flujo de información entre un terminal, un punto de dispositivo de interacción, un anfitrión seguro, un centro de facturación y un banco; y La figura 12 es un diagrama esquemático de un mensaje enviado desde un punto de dispositivo de interacción a un anfitrión seguro.
Con referencia a la figura 1, terminales telefónicos móviles primero y segundo 1a, 1b están provistos de servicios de voz y datos a través de una red pública de móviles terrestre (PLMN) 2. La PLMN 2 incluye una pluralidad de estaciones base transceptoras (BTS) 3 para intercambiar señales de radio con los terminales 1a, 1b y una pluralidad de controladores de estación base (BSC) 4 para controlar grupos de una o más BTSs 3. La PLMN 2 incluye también una pluralidad de centros de conmutación de móviles (MSC) 5 para establecer llamadas a y desde un conjunto de BSC 4. Los MSCs 5 están provistos de un registro de situación doméstico (HLR) 6, que es una base de datos para almacenar datos de autenticación del abonado. Cada MSC 5 está también provisto de un registro de situación de visitante (VLR) 7 que es una base de datos para almacenar datos de autenticación de abonado de los terminales 1a, 1b que visitan un área servida por el MSC 5.
Cada MSC 5 está conectado a los otros MSCs 5 por medio de un enlace de red 8. Al menos un MSC 5 está conectado a otras redes, incluyendo una red integrada de datos de servicio (ISDN) 9, una red pública de datos conmutada de paquetes (PSP-DN) 10 y una red telefónica pública conmutada (PSTN) 11.
La PLMN 2 incluye además un centro de facturación 12 para administrar los cargos y la facturación. Cuando un usuario se abona para usar la PLMN 2, a su terminal 1 se le asigna una identidad internacional de abonado de móvil (IMSI) y un número de red digital de estación de móvil de servicios integrados (MSISDN). La IMSI y el MSISDN se almacenan en el HLR 6. El HLR 6 y el centro de facturación 12 determinan si los terminales 1a, 1b están autorizados para usar la PLMN 2.
Más información relativa a GSM se puede encontrar en “The GSM System for Mobile Communications” de Michel Mouly y Marie-Bernadette Pautet, Cell & Sys. (1992).
Los usuarios de los terminales 1a, 1b han elegido prepagar los servicios antes que ser facturados a intervalos regulares. Para ello, a los terminales primero y segundo 1a, 1b se les asignan cuentas de prepago primera y segunda, respectivamente.
Para permitir que los usuarios aprovisionen sus cuentas, se proporcionan una pluralidad dispositivos de puntos de interacción (POIDs) 13. Los POIDs 13 pueden ser fijos o portátiles y se pueden situar dentro o fuera de un área servida por la PLMN 2. Los usuarios acceden a los POIDs 13 para hacer los pagos como parte de un proceso de aprovisionar sus cuentas. Los POIDs 13 y el proceso de aprovisionamiento se describirán con más detalle de aquí en adelante.
Los POIDs 13 están permanente o temporalmente conectados por medio de una primera línea alquilada 14 a un anfitrión seguro 15 para supervisar el aprovisionamiento de las cuentas de prepago. El anfitrión seguro 15 está conectado por medio de una segunda línea alquilada 16 al centro de facturación 12. El anfitrión seguro 15 está también conectado por medio de una tercera línea alquilada 17 a un banco 18 para autorizar los pagos de tarjeta de
crédito y débito.
Con referencia a la figura 2, los terminales telefónicos móviles 1a, 1b incluyen un teclado 19 para introducir la información, tal como números telefónicos, una pantalla de cristal líquido (LCD) 20 para presentar información y un transceptor 21 de comunicaciones inalámbricas para intercambiar la información con otros dispositivos, incluyendo POIDs 13. En este ejemplo, el transceptor 21 comprende un diodo emisor de luz (LED) y un fotodiodo detector para enviar y recibir señales respectivamente usando radiación infrarroja. Cada uno de los terminales 1a, 1b incluye también un procesador (no mostrado) para controlar el teclado 19, el LCD 20 y el transceptor 21, la memoria de acceso aleatorio (no mostrada) para almacenar la información y una tarjeta de módulo de identidad de abonado (SIM) (no mostrada) para almacenar la IMSI y el MSISDN de los terminales 1a, 1b y una agenda de números telefónicos que comprende una lista de MSISDNs. Se apreciará que se pueden usar otros transceptores 21 de comunicaciones inalámbricas tales como un transceptor Bluetooth™. También se apreciará que los terminales 1a, 1b también incluyen circuitos telefónicos.
Con referencia a la figura 3, el centro de facturación 12 incluye una base de datos de abonado 22 que almacena detalles de las cuentas de prepago y un potente ordenador personal 23. El ordenador personal 23 se usa para deducir crédito de la cuenta adecuada siempre que se haga una llamada desde un terminal 1a, 1b y para aprovisionar la cuenta adecuada siempre que tenga lugar un prepago. Hay que apreciar que el centro de facturación 12 puede incluir una estructura o una pluralidad de ordenadores para gestionar las cuentas de prepago.
Con referencia a la figura 4, cada uno de los POIDs 13 comprende un lector de tarjetas 24 para leer la información almacenada en una tarjeta de crédito, tarjeta de débito o tarjeta de monedero electrónico, uno o más transceptores 25 de comunicaciones inalámbricas para intercambiar información con otros dispositivos incluyendo los terminales 1a, 1b, un microprocesador 26 y una pantalla 27. El lector de tarjetas 24 comprende un lector de tarjeta magnética para leer la información almacenada en las bandas magnéticas de que están provistas las tarjetas de crédito y débito. Alternativa o adicionalmente, el lector de tarjetas 24 puede comprender un interfaz de tarjeta inteligente para intercambiar información con un chip insertado dentro de las tarjetas de crédito y de débito. En este ejemplo, el uno
o más transceptores 25 de comunicaciones inalámbricas comprende un transceptor de infrarrojos que consta de un diodo emisor de luz (LED) y un foto diodo detector y un transceptor inalámbrico que consta de un chip transceptor Bluetooth™. Opcionalmente, el POID 13 puede estar provisto de una caja receptora de efectivo 28 para recibir los pagos en efectivo que empleen billetes y/o monedas. El POID 13 puede también incluir una memoria no volátil 29 para almacenar los datos que provengan de transacciones off-line. El POID 13 está provisto de software, firmware o hardware para cifrar los datos para la transmisión al anfitrión seguro.
Los POIDs 13 pueden adoptar muchas formas. Por ejemplo, los POIDs 13 pueden ser de función única, usados solamente con el propósito de aprovisionar cuentas de prepago, por ejemplo quioscos públicos o terminales expendedores. Los POIDs 13 pueden ser de multifunción y pueden estar incorporados en otros dispositivos, tales como teléfonos fijos públicos o privados, cajeros automáticos, cajas registradoras o dispositivos de Punto de Venta (POS). Además, los POIDs 13 pueden ser fijos o portátiles.
Con referencia a la figura 5, el anfitrión seguro 15 incluye una base de datos 30 para almacenar los datos relativos a las peticiones de aprovisionamiento y a las transacciones, un potente ordenador personal 31 y un módulo 32 de seguridad de anfitrión (HSM) para proporcionar medios de seguridad criptográficos para la autenticación de los mensajes y de los certificados de transacción. El HSM 32 puede también ser conocido como un Gestor de Seguridad de Cuentas (SAM). El HSM 32 puede estar basado en la Norma de Cifrado de Datos (DES), Rivest, Shamir y Adleman (RSA) u otros sistemas de cifrado. El anfitrión seguro puede estar localizado en el local de un banco, en un tercer miembro fiable, en el operador de PLMN 2 o en un proveedor del servicio.
Se describirá ahora un proceso por medio del cual se pueden aprovisionar una o más cuentas.
Brevemente, el proceso de aprovisionamiento comprende dos etapas: una etapa de petición y una etapa de pago:
En la etapa de petición, el primer terminal 1a envía una petición al anfitrión seguro 15 para aprovisionar la primera y/o la segunda cuenta. El anfitrión seguro 15 pasa los detalles de la petición al centro de facturación
12. Si el centro de facturación 12 confirma que la cuenta o cada cuenta existe, entonces el anfitrión seguro 15 envía una respuesta al primer terminal 1a que incluye la información necesaria para validar la petición.
En la etapa de pago, el usuario utiliza uno de los POIDs 13 y transfiere la información de validación sobre un enlace inalámbrico. Este puede ser un enlace punto a punto, diferente del enlace inalámbrico usado en telefonía. Al usuario se le apremia entonces para que haga un pago. Cuando el pago se ha recibido, el POID 13 transmite la información de validación, junto con la información relativa al pago, al anfitrión seguro 15. El anfitrión seguro 15 comprueba la información de validación y, si es la adecuada, realiza la autorización de la tarjeta. Si la petición es válida y el pago está autorizado, el anfitrión seguro 15 contacta entonces con el centro de facturación 12 dándole instrucciones para aprovisionar la cuenta.
Así, el anfitrión seguro 15 gestiona la petición y la validación y recibe el pago. El anfitrión seguro 15 se pone de acuerdo con el centro de facturación 12 en una etapa posterior.
Con respecto a las figuras 6, 7 y 8, el primer usuario prepara una petición 33 seleccionando un menú de prepago en la pantalla 20 e introduciendo detalles relativos a la identidad de los terminales cuyas cuentas tienen que ser aprovisionadas y las correspondientes cantidades (etapa 1). El controlador (no mostrado) selecciona automáticamente el MSISDN 34a del primer terminal 1a, en este caso +44 777 11 22 33, y propone al usuario que elija una cantidad de crédito 35a. En este ejemplo, el usuario selecciona "₤20" de un menú. El primer usuario selecciona entonces el MSISDN 34b del segundo terminal 1b de la lista de MSISDNs almacenados en la tarjeta SIM, por ejemplo, +44 777 44 55 66, y teclea "₤10” de crédito 35b. Se apreciará que el usuario no necesita aprovisionar otra cuenta del terminal. Se apreciará también que el primer usuario puede añadir crédito a cuentas adicionales introduciendo más MSISDNs 34 y más valores de crédito 35c. Se apreciará también que el primer usuario no necesita aprovisionar la primera cuenta, es decir, su propia cuenta. El primer usuario puede establecer un indicador 36 que pida que sea enviado un SMS de admisión una vez que se ha completado el proceso de aprovisionamiento. Además, el primer usuario puede fijar un primer período de tiempo 37, por ejemplo de uno o dos días, para completar la etapa de validación. El primer usuario introduce entonces el número de red del anfitrión seguro 15, por ejemplo +44 207 77 88 99, y envía la petición 33 al anfitrión seguro 15 como un mensaje de texto del servicio de mensajes cortos (SMS) (etapa S2). Se apreciará que el operador de PLMN puede proporcionar un número de la red gratuito. Sin embargo, la petición 33 puede ser enviada usando otros recursos, particularmente si el terminal tiene habilitada la modalidad WAP o si es un terminal telefónico de tercera generación.
La petición 33 se transmite a través de la PLMN 2 y de la PSPDN 10 al anfitrión seguro 15, donde se comprueba a qué PLMN pertenece el primero y el segundo terminales 1a, 1b y que se ha elegido un valor razonable de crédito (etapa S3). Si el anfitrión seguro 15 está satisfecho con la petición, dirige un mensaje de aviso 38 al centro de facturación 12 de la PLMN 2, incluyendo datos relativos al primero y segundo MSISDNs y al primer período límite 37, junto con los correspondientes valores de crédito y un número de referencia (etapa S4). Se apreciará que se pueden enviar mensajes separados 38 a diferentes centros de facturación de diferentes redes, si los terminales primero y segundo 1a, 1b tienen diferentes PLMNs domésticas. Si el anfitrión seguro 15 no está satisfecho con la petición 33, entonces envía un mensaje de error (no mostrado) al primer terminal 1a y finaliza el proceso de petición. Si esto sucede, el anfitrión seguro 15 puede impedir que el primer terminal 1a haga más peticiones.
En el centro de facturación 12, el ordenador 23 comprueba si existen los primeros y segundo MSISDNs y si son activos y si el primer periodo de tiempo 37 es aceptable (etapa S5). Si el primero y segundo MSISDNs son válidos, entonces el centro de facturación 12 envía un mensaje de aceptación 39 al anfitrión seguro 15 que incluye un segundo período de tiempo dentro del cual se debe completar la validación (etapa S6). El segundo periodo de tiempo puede ser uno impuesto por el centro de facturación 12 o el primer período de tiempo 37 especificado por el primer usuario. Si, por otra parte, existe un problema bien con los MSISDNs o bien con cualquiera otra información comprendida en el mensaje de aviso 38, el centro de facturación 12 puede enviar un mensaje de rechazo (no mostrado) rechazando toda o parte de la petición 33. Por ejemplo, la petición con respecto al primer terminal 1a puede ser aceptada, mientras que la petición correspondiente al segundo terminal 1b puede ser rechazada. Bajo estas circunstancias, o bien se pueden enviar los mensajes respectivos de aceptación y rechazo o se puede transmitir un mensaje combinado al anfitrión seguro 15.
Con referencia a la figura 9, el anfitrión seguro 15 prepara una respuesta 40 para enviársela al primer terminal 1a (etapa S7). La respuesta 40 comprende un código de respuesta 41 que informa al terminal 1a si la petición fue satisfactoria, un número de referencia 42 que identifica la petición al anfitrión seguro 15, un número de secuencia 43 que identifica la petición al terminal 1a y una fecha límite 44 para completar la etapa de validación que se computa a partir del segundo periodo de tiempo. La respuesta 40 comprende también una cantidad total 45 a pagar, un número 46 para identificar el MSISDN del terminal que está solicitando el prepago, un código de la divisa 47 para indicar la divisa de cualquier transacción de tarjeta de crédito o de débito, un código de país 48 que identifica el origen del MSISDN del primer terminal 1a, un certificado de transacción 49 que permite que la petición sea validada en la etapa de pago y un código 50 de autenticación del mensaje que son datos generados por las rutinas de cifrado para asegurarse de que los datos comprendidos en la respuesta no están corrompidos o saboteados antes de la transmisión a un POID 13. La respuesta 40 se envía al primer terminal 1a (etapa S8), en donde se almacena en la tarjeta SIM (etapa S9).
Si un anfitrión seguro 15 recibe un mensaje de rechazo (no mostrado) del centro de facturación 12, entonces la respuesta 40 puede ser reemplazada con un mensaje de rechazo (no mostrado). El mensaje de rechazo puede indicar la razón de rechazar la petición y, si fuera adecuado, una invitación para reintentarla.
En este punto, la primera y la segunda cuentas de prepago no han sido aprovisionadas. Antes de que esto suceda, la petición debe de ser validada y realizarse un pago. Estas etapas se realizan en una etapa de pago:
Con referencia a las figuras 10 y 11, el primer usuario se desplaza a uno de los POIDs 13 y transmite una copia 51 de la respuesta 40 sobre el enlace inalámbrico seleccionando un menú de pago y presionando una
tecla para efectuar la transmisión de una señal desde el transceptor 21 del terminal a uno de los transceptores 25 del POID (etapa S10).
El POID 13 puede validar los datos recibidos en la copia 51. Si los datos han sido corrompidos o saboteados o están invalidados por alguna otra razón, entonces el POID 13 puede finalizar el proceso. El POID 13 puede entonces transmitir un mensaje al anfitrión seguro 15 notificándole del fallo y presentar también un mensaje que indique al usuario que la transacción ha fallado.
El POID 13, usando la pantalla 27, requiere al primer usuario que pague y le indica la cantidad total, que en este ejemplo es "₤30". El usuario pasa su tarjeta de crédito por el lector 24 (etapa S11). Alternativamente, el usuario puede pagar en efectivo. Si el usuario es itinerante, entonces el POID 13 puede también presentar en pantalla la cantidad total en la moneda local. Así, si el usuario es británico y se encuentra en Francia, entonces el POID 13 presentará "FF 300". Esto permite que el usuario pague en efectivo usando la moneda local.
Con referencia a la figura 12, el POID 13 envía un mensaje 52 al anfitrión seguro 15 (etapa S12). El mensaje 52 comprende un número de referencia 53 que es una copia del número de referencia 42 enviado al terminal 1a, la cantidad total 54, un número 55 para identificar al MSISDN del terminal que está solicitando el prepago, un certificado de la transacción 56 que es una copia del certificado de transacción 49 enviado al terminal 1a, un sello de fechas 57 en la cual se ha hecho el pago, un número de transacción 58 para identificar la transacción en el POID 13, un número de dispositivo 59 para identificar el POID 13, un número comercial 60 para identificar al vendedor, detalles cifrados 61 de la tarjeta de crédito y un código 62 de autenticación del mensaje, para comprobar de nuevo si los datos han sido corrompidos o saboteados. Se apreciará que si el usuario ha pagado en efectivo, entonces no se envían detalles 61 de la tarjeta.
El anfitrión seguro 15 valida entonces los detalles contenidos en el mensaje 52 (etapa S13). Esto incluye comparar el certificado de transacciones 56 con una copia del certificado 49 de transacción computado a partir de los datos contenidos en su base de datos 30 y comprobar que se ha hecho el pago antes de la fecha límite. El anfitrión seguro 15 puede también enviar un mensaje 63 al banco 18 (etapa S14). El mensaje 63 incluye detalles relativos a la tarjeta de crédito para permitir que el banco compruebe la autenticidad de la tarjeta (etapa S15). Si los detalles de la tarjeta son auténticos, entonces el banco 18 devuelve un mensaje de aceptación 64 al anfitrión seguro 15 (etapa S16). Por supuesto, si el usuario ha pagado en efectivo, entonces no son necesarias las etapas S15 y S16.
En este punto, el anfitrión seguro 15 ha validado la petición 33 y ha comprobado la autorización de la tarjeta de crédito.
El anfitrión seguro 15 envía una notificación 65 al centro de facturación 12 indicando las identidades de la primera y de la segunda cuentas de prepago y la cantidad que hay que aprovisionar a las cuentas (etapa S17). El centro de facturación 12 actualiza las primera y la segunda cuentas de prepago (etapa S18) y devuelve un mensaje de reconocimiento 66 (etapa S19).
El anfitrión seguro 15 envía un mensaje de confirmación 67 al POID 13 (etapa S20) que informa al usuario de que el proceso de aprovisionamiento se ha completado (etapa S21). El POID 13 puede imprimir una nota de acuse de recibo (no mostrada) al usuario.
El anfitrión seguro 15 envía un mensaje de confirmación 68 al primer terminal 1a explicando brevemente la transacción (etapa S22). El anfitrión seguro 15 puede también enviar detalles al segundo terminal 1b.
En este punto, la primera y la segunda cuentas han sido aprovisionadas y, si se agotaron antes de que comenzara el proceso de aprovisionamiento, se pueden usar los terminales 1a, 1b.
Si el anfitrión seguro 15 o el banco 18 encuentran que el mensaje 52 ha sido corrompido, saboteado o de algún modo invalidado o que el pago es insuficiente, bloqueado o de algún modo irregular, entonces la transacción finaliza y el anfitrión seguro 15 envía un mensaje de rechazo (no mostrado) al POID 13 y, opcionalmente, otro mensaje de rechazo al terminal 1a. El mensaje de rechazo puede invitar al usuario a reintentarlo, por ejemplo, retransmitiendo la copia 51 y/o usando una tarjeta de crédito diferente. Alternativamente, al usuario se le puede impedir que haga más intentos de validación en el POID 13. El anfitrión seguro 15 puede poner un indicador (no mostrado) que indique que se ha hecho un intento invalidado para validar la petición. De ese modo, puede rechazar posteriores intentos de validación hechos por el terminal 1a, realizados en cualquier POID 13. El anfitrión seguro 15 puede también rechazar nuevas peticiones de aprovisionamiento hechas desde el terminal 1a. El centro de facturación 12 puede también ser informado del intento invalidado para validar la petición. De ese modo, los operadores de PLMN 2 pueden tomar medidas adecuadas, tales como impedir que se hagan llamadas desde el primer terminal 1a.
Aunque la realización descrita anteriormente muestra un terminal de usuario que accede al anfitrión seguro 15 a través de una PLMN a la cual está conectado el centro de facturación, no es éste necesariamente el caso. Por ejemplo, el usuario puede estar en itinerancia de visita en una PLMN (no mostrada). El usuario envía una petición 33
al anfitrión seguro 15 usando el servicio proporcionado por la PLMN visitada (no mostrada). El anfitrión seguro 15 interroga entonces al centro de facturación 12 de la PLMN doméstica, es decir, PLMN 2. La respuesta 40 se devuelve a través de la PLMN visitada. El usuario valida entonces la petición como antes accediendo a uno de los POIDs 13.
Este procedimiento tiene varias ventajas. En primer lugar, el primer usuario puede aprovisionar no sólo la primera cuenta de prepago asociada al primer terminal 1a, sino también la segunda cuenta de prepago asociada al segundo terminal 1b. Esto es conveniente en el caso en el que el primer usuario sea un padre y el segundo usuario sea un hijo o una hija. Además, el usuario puede preparar la petición a su conveniencia. Sin embargo, dado que los detalles relevantes ya han sido introducidos y se transfieren fácilmente sobre el enlace inalámbrico, la validación es rápida y directa. Más aún, el usuario puede prepagar virtualmente en cualquier lugar del mundo. Los POIDs no son específicos de ninguna red. Por ello, el usuario puede enviar una petición cuando esté discurriendo por una red visitada y pagar en cualquier POID. Si la transacción se realiza en el extranjero, entonces el usuario puede pagar en moneda local usando efectivo o en su propia moneda usando una tarjeta de crédito. En adición, esta disposición no requiere ninguna modificación posterior del hardware del terminal, permitiendo por ello que se puedan usar terminales existentes. De manera importante, la disposición es segura y hace más difíciles las transacciones fraudulentas. Se requiere un terminal tanto para hacer la petición como para la validación. Por ello, se hace más difícil realizar una transacción fraudulenta usando el POID solo.
Si el primer usuario está planeando viajar al extranjero, puede realizar la etapa de petición antes de la salida. No hay obligación de completar la transacción realizando la etapa de pago. Por consiguiente, el usuario puede viajar sabiendo que puede aprovisionar su cuenta, si fuese necesario, sin incurrir en cargos caros de llamadas internacionales.
Un proceso por el cual el crédito se deduce de una cuenta, por ejemplo de la primera cuenta, se describirá brevemente.
Con referencia de nuevo una vez más a la figura 1, el usuario inicia una llamada desde el primer terminal 1a. Esto comprende enviar una petición para establecer una llamada que es recibida por uno de los MSCs 5. El terminal 1a es reconocido como un terminal de prepago. Por consiguiente, el MSC 5 notifica al centro de facturación 12. El ordenador 23 obtiene detalles de la primera cuenta de la base de datos 22 y computa el tiempo de llamada disponible que queda en la cuenta. Si la cuenta está agotada, entonces el tiempo de llamada disponible es cero y la llamada finaliza. Sin embargo, si todavía hay crédito disponible, entonces se permite que la llamada prosiga y se pone en marcha un temporizador, que mide el tiempo de llamada transcurrido. Si, durante la llamada, el tiempo de llamada transcurrido excede el tiempo de llamada disponible, entonces la llamada finaliza. Al final de la llamada, se mide el tiempo de llamada y se computa el costo de la misma. El costo se deduce de la primera cuenta.
En el proceso anteriormente descrito, el terminal 1a está situado en un área servida por la PLMN 2. Los expertos en la técnica comprenderán que el proceso se puede modificar para permitir que el usuario haga una llamada usando el primer terminal 1a desde una PLMN visitada (no mostrada).
Se observará que el terminal 1a puede ser un protocolo habilitado de aplicación inalámbrica (WAP) o una herramienta SIM- habilitada para ser usados con una pasarela de Internet inalámbrica (WIG) o con un soporte de servicios generales de radio por paquetes (GPRS). Alternativamente, el terminal 1a puede ser un terminal 3g para su uso en el sistema universal de telecomunicación por móvil (UMTS) o en redes de banda ancha de acceso múltiple por división de código (W-CDMA). Por eso, la petición 33 y la respuesta 40 se pueden enviar por métodos diferentes al servicio de mensajes cortos (SMS).
El POID y el anfitrión seguro pueden estar conectados por varios tipos de enlaces físicos, incluyendo vía satélite, enlace de microondas o fibra óptica a través de una red PSTO o PLMN, tal como una red GSM.
El POID y el anfitrión seguro pueden estar conectados usando otros tipos de redes.
Se observará también que se puede usar como medio de pago, en lugar de una tarjeta de crédito, cualquier tipo de tarjeta de pago, incluyendo tarjetas de débito, tarjetas de monedero electrónico y tarjetas de chip emitidas por instituciones financieras.

Claims (30)

  1. REIVINDICACIONES
    1. Un método de aprovisionar una cuenta, que comprende:
    en una etapa de petición:
    transmitir, desde un dispositivo móvil (1a) de comunicaciones a un anfitrión (15), una petición (33) para aprovisionar una o más cuentas asociadas con uno o más dispositivos móviles (1a, 1b) de comunicaciones, incluyendo dicha petición (33) información relativa a dichos uno o más dispositivos móviles de comunicaciones; confirmar el anfitrión la existencia de una o más cuentas; dependiendo de dichas una o más cuentas existentes, transmitir una respuesta (40), desde dicho anfitrión (15) a dicho dispositivo móvil (1a) de comunicaciones, que incluye información de validación para validar la petición; almacenar el anfitrión la información de validación; y almacenar el dispositivo móvil (1a) de comunicaciones, la respuesta (40);
    en la etapa de pago:
    transmitir, desde dicho dispositivo (1a) móvil de comunicaciones a un dispositivo de pago (13) un primer mensaje (51) que incluye la información de validación; realizar un pago en el dispositivo de pago (13), en el que el dispositivo de pago recibe el pago en adición a la información de validación; transmitir, desde dicho dispositivo de pago (13) a dicho anfitrión un segundo mensaje (52) que incluye la información de validación y la información relativa al pago; y comparar el anfitrión la información de validación recibida del dispositivo de pago con la información de validación almacenada por el anfitrión y, dependiendo de la validación de la información de validación recibida del dispositivo de pago con la información de validación almacenada por el anfitrión, realizar el aprovisionamiento de dichas una o más cuentas.
  2. 2.
    Un método de acuerdo con la reivindicación precedente, en el que dicha transmisión de dicha petición (33) incluye indicar las identidades de dichos uno o más dispositivos móviles (1a, 1b) de comunicaciones.
  3. 3.
    Un método de acuerdo con la reivindicación 2, en el que dicha indicación de dichas identidades de dichos uno o más dispositivos móviles (1a, 1b) de comunicaciones comprende transmitir MSISDNs (34a, 34b, 34c) correspondientes a dichos uno o más dispositivos móviles de comunicaciones.
  4. 4.
    Un método de acuerdo con cualquiera de las reivindicaciones precedentes, en el que dicha transmisión de dicha petición (33) incluye la indicación de una cantidad respectiva (35a, 35b, 35c) para aprovisionar cada una de dichas una o más cuentas.
  5. 5.
    Un método de acuerdo con cualquiera de las reivindicaciones precedentes, en el que dicha transmisión de dicha petición (33) incluye la indicación de un periodo de tiempo (37) para completar un proceso de pago.
  6. 6.
    Un método de acuerdo con cualquiera de las reivindicaciones precedentes, en el que dicha transmisión de dicha petición (33) comprende el envío un mensaje de texto.
  7. 7.
    Un método de acuerdo con cualquiera de las reivindicaciones precedentes, que comprende además enviar, desde dicho anfitrión (15) a un centro de facturación (12) que gestiona alguna o la totalidad de dichas una o más cuentas, algo o la totalidad de dicha información incluida en dicha petición (33) y/o información relativa a alguno o la totalidad de dichos uno o más dispositivos móviles de comunicaciones.
  8. 8.
    Un método de acuerdo con la reivindicación 7, que comprende además, comprobar en dicho centro de facturación (12), dicha información enviada y/o transmitir, desde dicho centro de facturación (12) a dicho anfitrión (15), un mensaje de aceptación (39).
  9. 9.
    Un método de acuerdo con cualquiera de las reivindicaciones precedentes, que comprende además preparar dicha respuesta (40) en dicho anfitrión (15).
  10. 10.
    Un método de acuerdo con cualquiera de las reivindicaciones precedentes, en el que dicha transmisión de dicha respuesta (40) incluye la indicación de un código de respuesta (41) que especifica una petición satisfactoria.
  11. 11.
    Un método de acuerdo con cualquiera de las reivindicaciones precedentes, en el que dicha transmisión de dicha respuesta (40) incluye la indicación de un número de referencia (42) que permite a un centro de facturación
    identificar dicha petición.
  12. 12.
    Un método de acuerdo con cualquiera de las reivindicaciones precedentes, en el que dicha transmisión de dicha respuesta (40) incluye la indicación de un número secuencial (43) que permite a dicho anfitrión identificar dicha petición para aprovisionar dichas cuentas.
  13. 13.
    Un método de acuerdo con cualquiera de las reivindicaciones precedentes, en el que dicha transmisión de dicha respuesta (40) incluye la indicación de una fecha de expiración (44) para completar un proceso de pago.
  14. 14.
    Un método de acuerdo con cualquiera de las reivindicaciones precedentes, en el que dicha transmisión de dicha respuesta (40) incluye la indicación de una cantidad a pagar (45).
  15. 15.
    Un método de acuerdo con cualquiera de las reivindicaciones precedentes, en el que dicha transmisión de dicha respuesta (40) incluye la indicación de un número (46) que identifica dicho dispositivo móvil (1a) de comunicaciones.
  16. 16.
    Un método de acuerdo con cualquiera de las reivindicaciones precedentes, en el que dicha transmisión de dicha respuesta (40) incluye la indicación de un código de divisa (47) para identificar la divisa del pago.
  17. 17.
    Un método de acuerdo con cualquiera de las reivindicaciones precedentes, en el que dicha transmisión de dicha respuesta (40) incluye la indicación de un código de país (48) para identificar un país en el cual el dispositivo móvil de comunicaciones tiene una red doméstica.
  18. 18.
    Un método de acuerdo con cualquiera de las reivindicaciones precedentes, en el que dicha transmisión de dicha respuesta (40) incluye el envío de un certificado de transacción (49) para validar dicha petición en la etapa de pago.
  19. 19.
    Un método de acuerdo con cualquiera de las reivindicaciones precedentes, en el que dicha transmisión de dicha respuesta (40) incluye el envío de un código de autenticación (50) para determinar si dicha respuesta ha sido corrompida o saboteada.
  20. 20.
    Un método de acuerdo con cualquiera de las reivindicaciones precedentes, en el que la transmisión de dicho primer mensaje (51) comprende el envío de una copia de dicha respuesta (40)
  21. 21.
    Un método de acuerdo con cualquiera de las reivindicaciones precedentes, en el que dicha transmisión del primer mensaje (51) comprende el envío de señales sobre un enlace inalámbrico (21, 25).
  22. 22.
    Un método de acuerdo con la reivindicación 21, en el que dicho envío de señales sobre dicho enlace inalámbrico (21, 25) comprende la transmisión de dichas señales usando radiación infrarroja.
  23. 23.
    Un método de acuerdo con la reivindicación 21, en el que dicho envío de señales sobre dicho enlace inalámbrico (21, 25) comprende transmitir dichas señales usando transmisión radioeléctrica.
  24. 24.
    Un método de acuerdo con cualquiera de las reivindicaciones precedentes, que comprende además la transmisión de un tercer mensaje (63), desde dicho anfitrión (15) a un banco (18), para pedir la autenticación de los detalles de la tarjeta de pago.
  25. 25.
    Un método de acuerdo con la reivindicación 24, que comprende además el envío de un cuarto mensaje (64), desde dicho banco (18) a dicho anfitrión (15), para indicarle la autenticación de dichos detalles de la tarjeta de pago.
  26. 26.
    Un método de acuerdo con cualquiera de las reivindicaciones precedentes, que comprende además la transmisión de un quinto mensaje (65), desde dicho anfitrión (15) a un centro de facturación (12), para notificar a dicho centro de facturación que la petición ha sido validada y el pago recibido.
  27. 27.
    Un método de acuerdo con la reivindicación 26, que comprende además la transmisión de un sexto mensaje (66), desde dicho centro de facturación (12) ha dicho anfitrión (15), como acuse de recibo de dicha notificación.
  28. 28.
    Un método de acuerdo con cualquiera de las reivindicaciones precedentes, que comprende además la transmisión de un séptimo mensaje (67), desde dicho anfitrión (15) a dicho dispositivo de pago (13), confirmando que la petición ha sido validada y el pago recibido.
  29. 29.
    Un método de acuerdo con cualquiera de las reivindicaciones precedentes, que comprende además, la transmisión de un octavo mensaje (68), desde dicho anfitrión (15) a dicho dispositivo móvil (1a) de comunicaciones, confirmando que la petición ha sido validada y el pago recibido.
  30. 30.
    Aparato para aprovisionar una cuenta, que comprende:
    un dispositivo móvil (1a) de comunicaciones; un anfitrión (15); y 5 un dispositivo de pago (13);
    estando configurado el dispositivo móvil (1a) de comunicaciones:
    para transmitir, a un anfitrión (15), una petición (33) para aprovisionar una o más cuentas asociadas con uno10 o más dispositivos móviles (1a, 1b) de comunicaciones, incluyendo dicha petición (33) información relativa a dichos uno o más dispositivos móviles de comunicaciones;
    estando configurado el anfitrión (15):
    15 para confirmar la existencia de una o más cuentas; para transmitir, dependiendo de una o más cuentas existentes, a dicho dispositivo móvil (1a) de comunicaciones, una respuesta (40) que incluye información de validación para validar la petición; y para almacenar la información de validación;
    20 estando configurado además el dispositivo móvil (1a) de comunicaciones:
    para almacenar la respuesta (40); y para transmitir, al dispositivo de pago (13), un primer mensaje (51) que incluye la información de validación;
    25 estando configurado el dispositivo de pago (13):
    para recibir un pago en adición a la información de validación; y para transmitir a dicho anfitrión, en respuesta al pago que se ha hecho en el dispositivo de pago, un segundo mensaje (52) que incluye la información de validación y la información relativa al pago;
    estando configurado además el anfitrión (15):
    para comparar la información de validación recibida desde el dispositivo de pago con la información de validación almacenada por el anfitrión y
    35 dependiendo de la validación de la información de validación recibida desde el dispositivo de pago con la información de validación almacenada por el anfitrión, efectuar el aprovisionamiento de dichas una o más cuentas.
ES02255734T 2001-08-22 2002-08-16 Método de aprovisionar una cuenta Expired - Lifetime ES2396325T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB0120412A GB2379133B (en) 2001-08-22 2001-08-22 Method of crediting an account
GB0120412 2001-08-22

Publications (1)

Publication Number Publication Date
ES2396325T3 true ES2396325T3 (es) 2013-02-20

Family

ID=9920814

Family Applications (1)

Application Number Title Priority Date Filing Date
ES02255734T Expired - Lifetime ES2396325T3 (es) 2001-08-22 2002-08-16 Método de aprovisionar una cuenta

Country Status (6)

Country Link
EP (2) EP1286317B1 (es)
CY (1) CY1113496T1 (es)
DK (1) DK1286317T3 (es)
ES (1) ES2396325T3 (es)
GB (1) GB2379133B (es)
PT (1) PT1286317E (es)

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7676030B2 (en) 2002-12-10 2010-03-09 Ewi Holdings, Inc. System and method for personal identification number distribution and delivery
US20050229003A1 (en) 2004-04-09 2005-10-13 Miles Paschini System and method for distributing personal identification numbers over a computer network
US10205721B2 (en) 2002-12-10 2019-02-12 Ewi Holdings, Inc. System and method for distributing personal identification numbers over a computer network
KR100559008B1 (ko) * 2003-04-02 2006-03-10 에스케이 텔레콤주식회사 이동통신 단말기의 적외선 통신을 이용한 사용자 인증시스템 및 그 방법
US7131578B2 (en) 2003-05-28 2006-11-07 Ewi Holdings, Inc. System and method for electronic prepaid account replenishment
DE10337081B4 (de) * 2003-08-12 2006-04-27 Deutsche Postbank Ag Gutschrifthandhabungs-Vorrichtung
US11475436B2 (en) 2010-01-08 2022-10-18 Blackhawk Network, Inc. System and method for providing a security code
US11599873B2 (en) 2010-01-08 2023-03-07 Blackhawk Network, Inc. Systems and methods for proxy card and/or wallet redemption card transactions
US7280644B2 (en) 2004-12-07 2007-10-09 Ewi Holdings, Inc. Transaction processing platform for faciliating electronic distribution of plural prepaid services
FR2880449B1 (fr) 2004-12-31 2007-04-20 Charles Tuil Procede de transaction electronique par messagerie mobile
US10296895B2 (en) 2010-01-08 2019-05-21 Blackhawk Network, Inc. System for processing, activating and redeeming value added prepaid cards
WO2007147220A2 (en) * 2007-08-28 2007-12-27 Urbis Telecom Corporation Method and system for processing advances/credits for use by subscribers of communication networks
EP2521999A4 (en) 2010-01-08 2015-01-07 Blackhawk Network Inc SYSTEM FOR PROCESSING, ENABLING AND REIMBURSING PREPAID CARDS WITH ADDED VALUE
US10037526B2 (en) 2010-01-08 2018-07-31 Blackhawk Network, Inc. System for payment via electronic wallet
CA2809822C (en) 2010-08-27 2023-09-12 Blackhawk Network, Inc. Prepaid card with savings feature
US11042870B2 (en) 2012-04-04 2021-06-22 Blackhawk Network, Inc. System and method for using intelligent codes to add a stored-value card to an electronic wallet
CA3171304A1 (en) 2012-11-20 2014-05-30 Blackhawk Network, Inc. Method for using intelligent codes in conjunction with stored-value cards

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0848360A1 (en) * 1996-12-11 1998-06-17 BRITISH TELECOMMUNICATIONS public limited company Electronic funds transfer authentication system
AU7061098A (en) * 1997-04-15 1998-11-11 Non Can Jam Trading (Pty) Limited Method for electronically vending, distributing, and recharging of pre-p aid value, a vending machine and an electronic system for use therein
US6636833B1 (en) * 1998-03-25 2003-10-21 Obis Patents Ltd. Credit card system and method
GB9910418D0 (en) * 1999-05-05 1999-07-07 Landis & Gyr Communications Uk Payment apparatus and method
WO2001011857A1 (en) * 1999-08-05 2001-02-15 On Point Technology Systems, Inc. Pre-paid mobile telephone air-time replenishing system and method
CA2324000A1 (en) * 1999-11-12 2001-05-12 Nortel Networks Corporation Business method implemented on a wireless pre-paid platform of business-to-business transaction processing and billing
NL1013732C2 (nl) * 1999-12-02 2001-06-06 Theodorus Arie Jan Snijder Systeem voor het betalen en verkrijgen van diensten via een communicatienetwerk.
GB0001548D0 (en) * 2000-01-24 2000-03-15 Air Pay Limited A method and device for crediting a creditable machine
IL134354A0 (en) * 2000-02-03 2001-04-30 Ranit T S Technical Services L Electronic transaction system
US8706627B2 (en) * 2000-02-10 2014-04-22 Jon Shore Apparatus, systems and methods for wirelessly transacting financial transfers , electronically recordable authorization transfers, and other information transfers

Also Published As

Publication number Publication date
EP1286317A3 (en) 2003-12-03
EP1286317A2 (en) 2003-02-26
EP1286317B1 (en) 2012-10-03
EP2360650A1 (en) 2011-08-24
DK1286317T3 (da) 2013-01-02
CY1113496T1 (el) 2016-06-22
GB2379133B (en) 2003-10-29
GB2379133A (en) 2003-02-26
PT1286317E (pt) 2013-01-23
GB0120412D0 (en) 2001-10-17

Similar Documents

Publication Publication Date Title
ES2396325T3 (es) Método de aprovisionar una cuenta
ES2224971T3 (es) Sistema de telefonia movil, programa de ordenador, unidad de telefono portatil inalambrico y metodo para activar o mantener activa una unidad de telefono movil.
US6415156B1 (en) Transaction method
US6934529B2 (en) Replenishment of pre-paid wireless telephone accounts using short message service (SMS)
ES2262945T3 (es) Procedimiento y sistema para bloquear y desbloquear una cuenta financiera asociada con una tarjeta sim.
ES2201809T3 (es) Procedimiento y sistema de transaccion de pagos.
ES2904529T3 (es) Método y dispositivo para transferir una cantidad de dinero utilizando un código de imagen bidimensional
ES2201808T3 (es) Procedimiento y sistema de transaccion de pagos.
ES2284667T3 (es) Procedimiento para el pago por medio del telefono movil en cualesquiera puntos de venta o de servicios.
JP4036649B2 (ja) トランザクション方法および販売システム
US7533065B2 (en) Advanced method and arrangement for performing electronic payment transactions
EP1136961B1 (en) System and process for remote payments and transactions in real time by mobile telephone
EP2372628A2 (en) Method, apparatus, and system for enabling purchaser to direct payment approval, settlement, and membership subscription using mobile communication terminal
EP1111561A2 (en) Transaction system and method
WO2005004069A1 (es) Sistema de transacciones y pagos mediante teléfono móvil digital
ES2260025T3 (es) Procedimiento y sistema para transacciones de pagos.
ES2701726T3 (es) Procedimiento y sistema de validación de una transacción, terminal transaccional y programas correspondientes
ES2227260T3 (es) Gestor de recarga en itinerancia.
US8775304B2 (en) Money transfer using cellular networks
US20070011103A1 (en) System and method for identity protected secured purchasing
ES2240494T3 (es) Procedimiento y disposicion para la transferencia de una cantidad electronica de dinero desde una memoria de una cuenta de credito.
WO2012145668A1 (en) Method and system for mobile remittance
ES2422805B1 (es) Procedimiento para el pago por teléfono móvil en comercios
WO2004049270A2 (en) Radio controlled prepayed metering system
ES2295013T3 (es) Procedimiento y sistema para cargar o recargar tarjetas chip insertadas en aparatos de radiotelefonia movil con un importe dinerario.