ES2218832T3 - Procedimiento de transaccion con un aparato movil. - Google Patents
Procedimiento de transaccion con un aparato movil.Info
- Publication number
- ES2218832T3 ES2218832T3 ES98928045T ES98928045T ES2218832T3 ES 2218832 T3 ES2218832 T3 ES 2218832T3 ES 98928045 T ES98928045 T ES 98928045T ES 98928045 T ES98928045 T ES 98928045T ES 2218832 T3 ES2218832 T3 ES 2218832T3
- Authority
- ES
- Spain
- Prior art keywords
- transaction
- terminal
- procedure according
- customer
- vouchers
- 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
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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/327—Short range or proximity payments by means of M-devices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/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/08—Payment architectures
- G06Q20/20—Point-of-sale [POS] network systems
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Engineering & Computer Science (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Finance (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
La invención se refiere a un procedimiento para llevar a cabo transacciones financieras entre un cliente equipado con un teléfono móvil y un terminal electrónico (2), en donde el teléfono móvil comprende un aparato móvil (1) y un módulo de identificación separable en el cual pueden memorizarse al menos un elemento de identificación de cliente y una suma de dinero electrónico. El procedimiento comprende cada uno de los siguientes pasos: recargar la suma de dinero dada por medio de documentos de recarga seguros enviados a través de la red de teléfono móviles desde un centro de servicio (4), la transmisión del elemento de identificación de cliente al terminal (2) por medio de una interfaz sin contactos entre el módulo de identificación (10) y el terminal (2), la verificación en dicho terminal de que el cliente identificado por medio del mencionado elemento de identificación de cliente que ha sido transmitido está autorización par llevar a cabo una transacción financiera, dicha verificación selleva a cabo con datos de autorización transmitidos al terminal (2) por medio de una red telefónica pública (5) y la transmisión de la cantidad de la transacción de la terminal (2) por medio de una interfaz sin contactos.
Description
Procedimiento de transacción con un aparato
móvil.
La presente invención se refiere a un
procedimiento y un sistema para la transmisión de encargos en una
red de telecomunicaciones. La invención se refiere más
particularmente, pero no exclusivamente, a la transmisión de
encargos en una red de telefonía móvil.
De acuerdo con el estado actual de la técnica,
transacciones entre un cliente (o Client, C) y un terminal
[Point-of-Transaktion (POT)], por
ejemplo un punto de venta
[Point-of-Sale (POS)], se realizan
frecuentemente mediante una tarjeta de pago electrónica. Tarjetas
de débito y crédito se emplean, por ejemplo, en las cajas de
comercios, en estaciones de servicio, etc. La tarjeta comprende
generalmente medios de memoria, por ejemplo una banda magnética y/o
un chip, en el cual está memorizada, entre otras, la identificación
del cliente. Para realizar una transacción con el propietario u
operador de un terminal, por ejemplo para pagar un artículo en un
comercio, el cliente debe introducir su tarjeta en un adecuado
lector de tarjetas en el terminal. El terminal lee entonces la
identificación del cliente en la tarjeta, determina e indica el
importe que deba ser pagado, comprueba eventualmente la solvencia
del cliente y solicita al cliente que confirme la transacción con
una tecla de confirmación en el terminal. Si el cliente es solvente
y ha introducido su confirmación, la identificación del cliente, el
importe que deba ser pagado y eventualmente también una
identificación de terminal son transmitidos a un servidor
financiero, administrado por un instituto financiero, que está
conectado con el terminal a través de una red de telecomunicaciones.
En correspondencia, la cuenta del cliente es inmediata o
posteriormente cargada en dicho instituto financiero.
El inconveniente de este procedimiento consiste
en la necesidad de tener que introducir la tarjeta del cliente en
un aparato ajeno. Normalmente, los clientes no tienen su tarjeta a
mano, sino por ejemplo en el monedero; por consiguiente, no es
posible una muy rápida transacción. A veces tampoco es fácilmente
accesible la abertura para la introducción de la tarjeta en el
aparato lector del terminal; ello es particularmente el caso cuando
el terminal consiste en un expendedor de tickets automático para
aparcamientos o un cajero automático que deba ser utilizado por el
automovilista sin bajarse del coche. Además pueden realizarse en el
terminal manipulaciones fraudulentas o lecturas no autorizadas de
zonas de memoria de la tarjeta.
Incluso aunque hoy día ciertas tarjetas chip
contengan un microprocesador, estas tarjetas de débito y crédito
son esencialmente elementos pasivos, que memorizan datos que son
memorizados y empleados esencialmente por la electrónica del
terminal. El cliente no tiene, por el contrario, normalmente
posibilidad alguna de acceder directamente a los datos sin
dirigirse a una ventanilla o a un cajero automático del respectivo
instituto financiero que emita la tarjeta. Por consiguiente, para el
cliente resulta difícil controlar las transacciones efectuadas con
la tarjeta o contabilizarlas.
Estas tarjetas contienen una identificación de
cliente, que no obstante solamente permite identificar al cliente
en el instituto financiero emisor. Por consiguiente, una tarjeta
puede normalmente emplearse únicamente para una transacción
financiera cuando el cliente y el operador del terminal estén
afiliados al mismo instituto financiero. Sin embargo, el uso de la
tarjeta para otros tipos de transacciones - por ejemplo para
transacciones no financieras, pero para las cuales se requiera la
identificación fiable del cliente/poseedor de la tarjeta - no está
previsto. Para el cliente resulta pues imprescindible poseer un gran
número de tarjetas, para cualquier tipo de transacciones financieras
o no financieras, por ejemplo varias tarjetas de débito o crédito
administradas por distintos institutos financieros o cadenas de
comercios, o tarjetas de abono o tarjetas de acceso para zonas
protegidas. Estas tarjetas están generalmente protegidas por
distintos códigos PIN, que el cliente debe memorizar con gran
esfuerzo.
En caso de un robo o de una acción fraudulenta
con la tarjeta, ésta debe ser bloqueada. Sin embargo, el bloqueo
puede realizarse únicamente cuando la tarjeta es introducida en un
correspondiente aparato. Las tarjetas de crédito convencionales
pueden no obstante continuar siendo utilizadas en aparatos operados
manualmente; un bloqueo seguro de la tarjeta no es pues
posible.
Además de tarjetas de débito y de crédito se
conocen las denominadas tarjetas e-cash (tarjetas
de valor), las cuales permiten memorizar electrónicamente importes
dinerarios, que a continuación son aceptados en diversos terminales
como medio de pago. Para volver a cargar estas tarjetas nuevamente
con importes dinerarios, el cliente debe presentarse en la
ventanilla o en el autómata de un instituto financiero, lo cual
tampoco es siempre posible.
En el documento de Patente WO 97/14124 se
describe un sistema que permite el encargo y pago electrónico de
servicios a través de una red de comunicación, por ejemplo la red
telefónica pública (Public Switched Telephone Network, PSTN) o una
red móvil GSM (Global System for Mobile Communication). En el
sistema según la WO 97/14124 un usuario puede solicitar, por medio
de un aparato terminal de comunicación, por ejemplo un teléfono
convencional o un teléfono móvil, y mediante impulsos de selección
a través de un sistema con guiado de menú verbal, servicios de una
unidad de servicios. Para el pago de estos servicios se emplea una
"Smart Card", la cual es acoplada, a través de un interfase,
con el aparato terminal de comunicación y transmite, a través de una
conexión de dicho aparato terminal de comunicación con una unidad
de transacción, informaciones de pago a dicha unidad de
transacción, reduciéndose un importe prepagado, memorizado en la
tarjeta, el cual puede también ser recargado según la WO 97/14124.
La "Smart Card" puede también solamente comprender una
identificación de usuario, de manera que en consecuencia en caso de
un pago resulte cargada la cuenta del respectivo usuario.
El documento de Patente WO 97/18653 describe un
sistema con terminales móviles, a través de los cuales un usuario
con una "Smart Card", que memorice una identificación de
usuario y un importe dinerario, pueda bajarse informaciones
financieras y realizar transacciones financieras, estando
conectados los terminales móviles, a través de una red de telefonía
móvil, con un instituto financiero.
En la Patente WO 96/13814 se describe un sistema
de pago a tiempo real en el cual clientes de un banco pueden
consultar con sus teléfonos móviles informaciones financieras y
pagar facturas intercambiando informaciones de cuenta y pago por
medio de mensajes SMS o a través de una conexión telefónica con una
estación de facturación de un Banco.
En la Patente WO 96/18981 se describe un
procedimiento en el cual se emplean características biofísicas de
un usuario para la identificación del mismo en la ejecución de
funciones de compensación financiera.
Una finalidad de la presente invención consiste
en proponer un nuevo procedimiento o sistema que permita evitar los
arriba citados problemas.
Una ulterior finalidad de la presente invención
consiste en proponer un procedimiento de transacción que resulte
apropiado tanto para transacciones financieras como también no
financieras, y que sea más sencillo y fiable que los habituales
procedimientos de transacción.
De acuerdo con la presente invención, estas
finalidades se consiguen particularmente mediante los elementos de
la parte característica de las reivindicaciones independientes.
Ulteriores formas de realización ventajosas se desprenden, además,
de las reivindicaciones dependientes y de la descripción.
Particularmente, estas finalidades se consiguen
mediante un procedimiento de transacción entre un cliente y un
terminal conectado con una red de telecomunicaciones (por ejemplo
un Point-of-Sale, POS), que
comprenda las características de las reivindicaciones
independientes.
La presente invención resultará mejor
comprensible con ayuda de la siguiente descripción, dada a título
de ejemplo no limitativo e ilustrada en los dibujos adjuntos, en
los cuales:
La Fig. 1 muestra un esquema de bloques que
ilustra el flujo de información en una primera forma de realización
del sistema de la invención, estando equipado el cliente con un
teléfono móvil, preferentemente un aparato móvil GSM o UMTS, apto
para recibir y enviar especiales mensajes cortos;
la Fig. 2 muestra un esquema de bloques que
ilustra el flujo de información en una segunda forma de realización
del sistema de la invención, estando equipado el cliente con un
teléfono móvil, preferentemente un aparato móvil GSM o UMTS, apto
para recibir y enviar especiales mensajes cortos, y siendo el
terminal un aparato apto para Internet o Intranet;
la Fig. 3 muestra un diagrama de flujo de un
procedimiento de transacción de pago según la invención; y
la Fig. 4 muestra un diagrama de flujo de un
procedimiento de transacción de recarga de una tarjeta SIM, según
la invención.
El procedimiento ilustrado en las Figs. 3 y 4
puede realizarse con cualquier variante del sistema, ilustrado por
ejemplo en las Figs. 1 y 2. La primera y segunda variante requieren
ambas un teléfono móvil con una tarjeta SIM y un interfase
adicional infrarrojo o inductivo, que se describirá más adelante con
mayor detalle.
La Fig. 1 muestra el flujo de información en una
primera forma de realización de la invención. El cliente está
equipado con un teléfono móvil que comprende un aparato móvil, por
ejemplo un aparato móvil GSM o UMTS, 1 y un módulo de
identificación 10, por ejemplo una tarjeta SIM. El número 11
designa una unidad de manejo, por ejemplo un teclado. El cliente es
identificado en la red de telefonía móvil 6 por medio del módulo de
identificación 10. La tarjeta SIM comprende un microcontrolador 100
convencional, el cual está incorporado en el soporte de plástico de
la tarjeta y es responsable de las funcionalidades GSM de la
tarjeta - tal como se describen, por ejemplo, en el artículo "SIM
CARDS" de T. Grigorova e I. Leung, aparecido en
"Telecommunication Journal of Australia", vol. 43, No. 2,
1993, en las páginas 33 a 38 - y de nuevas funcionalidades que sean
cargadas posteriormente en las tarjetas SIM. La tarjeta SIM puede
ser preferentemente una tarjeta apta para JAVA, es decir una
tarjeta con un procesador capaz de ejecutar instrucciones en el
lenguaje de programación JAVA (o en otro lenguaje orientado al
objeto). Tarjetas SIM según el concepto Open-card de
IBM pueden también emplearse. La tarjeta SIM comprende, además,
medios de contacto no ilustrados, a través de los cuales la tarjeta
se comunica con el aparato móvil 1 en la cual esté insertada.
La tarjeta SIM comprende, además, un segundo
procesador 101 (CCI, Contactfree Chipcard Interface), el cual es
responsable de la conexión inalámbrica con el aparato POT 2. El
segundo procesador realiza, entre otras, las funciones TTP (Trusted
Third Party) que se describirán más adelante, para recibir y enviar
mensajes codificados y firmados. Un interfase lógico 102 comunica
los dos procesadores 101 y 102. Opcionalmente, un único procesador
podría sustituir estos dos procesadores 101, 102.
El interfase inalámbrico con el terminal 2 puede
comprender, por ejemplo, al menos una bobina (no ilustrada)
integrada en la tarjeta SIM y conectada con el segundo procesador
101, mediante la cual sean transmitidos inductivamente datos en
ambos sentidos en un tramo de radiofrecuencia. Una bobina inductiva
puede también estar integrada, de acuerdo con una variante, en la
carcasa del aparato móvil. De acuerdo con una ulterior variante, el
interfase inalámbrico comprende un emisor-receptor
infrarrojo en la carcasa del aparato móvil. De acuerdo con una
ulterior variante, el interfase inalámbrico está integrado en un
módulo de ampliación susceptible de ser vinculado con el aparato
móvil de forma extraíble. La comunicación inalámbrica entre ambos
aparatos es preferentemente codificada, por ejemplo con un
algoritmo de seguridad DEA, DES, TDES, RSA o ECC.
La comunicación inalámbrica se basa
preferentemente en un estándar conocido, por ejemplo en el
protocolo IrDA (Infrared Data Association). Para esta comunicación
se emplean preferentemente medios de comprobación de errores y de
corrección de errores. Preferentemente se emplean, además, medios de
identificación de aparato terminal, con el fin de establecer una
comunicación de manera fiable con únicamente un determinado aparato
terminal, caso de que en un recinto estén reunidos varios aparatos
terminales, por ejemplo varios aparatos móviles y/o varios
terminales.
Para una transmisión inductiva de señales desde
el terminal a la tarjeta chip se emplea preferentemente un
procedimiento de modulación de fases, mientras que en el sentido
inverso se modula preferentemente la amplitud de las señales.
La tarjeta SIM contiene preferentemente un campo
especial IDUI (International Debit User Identification), mediante el
cual es identificado el cliente por el operador del terminal y/o
por un instituto financiero. La identificación IDUI es
preferentemente memorizada en una primera zona de memoria segura de
uno de los dos procesadores 101, 102. La IDUI contiene al menos una
identificación del operador de red, un número de usuario, que lo
identifica respecto a otros clientes del mismo operador de red, una
indicación de clase de usuario, que define que servicios puede
utilizar, y opcionalmente además una identificación de país.
Además, la IDUI contiene datos de seguridad, entre otros un
contador de transacciones Tz, una ficha de carga LT_{c}, y un
campo Time-Out TO, que indica el tiempo de
validación. La función de estos diversos datos se describirá más
adelante.
La tarjeta SIM contiene, además, una segunda zona
de memoria segura, en la cual pueden memorizarse unidades dinerarias
electrónicas (importes dinerarios).
El terminal 2, ilustrado simbólicamente, está
también dotado de un emisor-receptor inalámbrico
20, por ejemplo con una bobina inductiva o con un
emisor-receptor infrarrojo. Merced a este interfase
el sistema móvil 1, 10 puede comunicarse de forma inalámbrica con el
aparato 2 en ambos sentidos.
El terminal 2 puede por ejemplo ser un
Point-of-Sale (POS), equipado
especialmente con un interfase de radiofrecuencia 20, en un comercio
y es identificado mediante un campo especial POSID (Point of Sale
Identification). La POSID depende de la aplicación; en el caso de
una caja de un comercio, la misma contiene una identificación del
operador de red, una identificación de área (región parcial en un
país), un número POS, que lo identifica respecto a otros POS del
mismo operador de red, una indicación de clase POS, que define que
servicios puede utilizar u ofertar, la fecha, la hora, la divisa
utilizada (SDR, Euro o Dólares) y opcionalmente además una
identificación de país.
El terminal 2 se dota preferentemente de medios
no ilustrados de entrada de datos, por ejemplo de un teclado, y de
medios no ilustrados de indicación de datos, por ejemplo de una
pantalla.
La identificación IDUI es transmitida al terminal
a través del interfase inalámbrico 10/101, y en el terminal es
entrelazada con la POSID y con el importe de transacción A captado,
de modo que se genera un comprobante de transacción electrónico que
es codificado y firmado mediante un proceso TTP (Trusted Third
Party) o PTP (Point-to-Point).
El comprobante de transacción es entonces
transmitido a través de un módem, no ilustrado, y de la red de
comunicación 5, por ejemplo a través de una red de telefonía
pública, a la unidad de compensación 3, también conectada con la
red 5. Esta recibe los comprobantes electrónicos de diversos
terminales 2, independientemente del país o zona de tráfico, e
independientemente del país o instituto financiero del cliente. En
la unidad de compensación 3 son clasificados estos comprobantes de
transacción según instituto financiero, eventualmente también según
operador, y enviados al centro de servicios 4, 4', 4'' del
correspondiente instituto financiero. Unidades de compensación en sí
son ya conocidas en la tecnología GSM y se emplean, por ejemplo,
para la colección y la redistribución de costos de comunicación. La
unidad de compensación puede por ejemplo contener un banco de datos
que indique con que instituto financiero está afiliado el cliente
previamente identificado con su IDUI.
Los comprobantes de transacción electrónicos,
tratados por la unidad de compensación 3, son retransmitidos al
centro de servicios 4, que dispone preferentemente de un servidor
financiero. En el servidor financiero son primeramente
descodificados los comprobantes de transacción presentados y
almacenados en una memoria intermedia 43. Un módulo de gestión de
compensación 42 abona entonces el importe de transacción firmado por
el cliente a las respectivas cuentas bancarias 420, 420' y/o 420''
del operador del terminal. Estas cuentas pueden ser administradas
por el mismo o por otro instituto financiero. El módulo de gestión
de compensación realiza además contabilizaciones de control
respecto a la cuenta del cliente. En correspondencia es cargada la
cuenta de control 41 del cliente en el instituto financiero, o son
memorizados los datos de transacción para un posterior control. El
servidor financiero contiene, además, un servidor TTP 40, a fin de
codificar y firmar comprobantes y mensajes con el algoritmo TTP
(Trusted Third Party). Además, cada servidor financiero 4 está
conectado con un servidor SIM 70, por ejemplo con un servidor
SICAP. El procedimiento SICAP ha sido descrito, entre otras, en la
Patente EP689368, y permite intercambiar ficheros, programas y
también importes dinerarios entre el servidor SICAP 70 y la tarjeta
SIM 10 en el aparato móvil 1 a través de la red pública GSM 6
(flecha 60). Otros protocolos de transmisión pueden también
emplearse para la transmisión de datos entre el servidor SIM y las
tarjetas SIM. De esta manera puede por ejemplo recargarse dinero en
la tarjeta SIM 10, tal como se describirá más adelante. El servidor
SIM 70 permite, además, la comunicación controlada entre el cliente
y el servidor TTP 40 del instituto financiero.
La Fig. 2 muestra el flujo de información en una
segunda forma de realización de la invención. El cliente está
equipado también en esta variante con un teléfono móvil, por
ejemplo con un teléfono GSM 1 con una tarjeta SIM, preferentemente
con una tarjeta SIM apta para SICAP y/o con una tarjeta apta para
JAVA. También está contenido en el sistema móvil 1 un interfase
inductivo o infrarrojo, mediante el cual puede establecerse una
comunicación inalámbrica con el terminal 2. De esta manera pueden
intercambiarse datos y/o programas en ambos sentidos entre el
terminal 2 y la tarjeta SIM 10 en el sistema móvil.
Sin embargo, el terminal 2' es en este caso un
ordenador, que está preferentemente vinculado con una red, por
ejemplo con Internet o una Intranet. Diversas informaciones u
ofertas, por ejemplo ofertas de producto, pueden por ejemplo
ofertarse con un menú adecuado en la pantalla del ordenador 2. El
cliente puede gobernar este ordenador mediante su aparato móvil.
Así por ejemplo, puede gobernar la posición de un cursor en un menú
de productos ofertados a la venta o informaciones mediante
actuación de las teclas de desplazamiento del cursor en el teclado
11 de su teléfono móvil. Las instrucciones de desplazamiento del
cursor son enviadas a través del interfase inalámbrico 101, 20 al
ordenador 2'. El usuario acciona una tecla de confirmación, por
ejemplo la tecla # en su teclado, para confirmar la opción de menú
seleccionada, por ejemplo para encargar un producto.
La identificación de cliente memorizada en el
aparato móvil 1, 10 es entrelazada con la POSID y con el importe de
transacción correspondiente a la opción de menú seleccionada en un
comprobante de transacción electrónico, codificado mediante TTP o
PTP y firmado. El comprobante de transacción contiene
preferentemente una identificación de cliente IDUI obtenida de la
tarjeta SIM 10, una identificación de proveedor correspondiente a la
opción de menú seleccionada, y una identificación de producto
correspondiente a la opción de menú seleccionada, preferentemente
en formato Flexmart, tal como propuesto en la solicitud de Patente
PCT/CH96/00464. Este comprobante es generado por un módulo Flexmart
21. El módulo Flexmart es preferentemente una aplicación de
software ejecutada por el ordenador 2'.
Análogamente a la primera forma de realización,
es entonces transmitido el comprobante de transacción electrónico
al correspondiente servidor financiero 4, 4' o 4'' por la unidad de
compensación 3, y allí procesado.
A continuación se describirá ahora más
detalladamente, con ayuda de la Fig. 3, un procedimiento de
transacción de pago. Este procedimiento puede aplicarse a
cualquiera de las formas de realización de la invención según las
Figs. 1 y 2. Sin embargo, este desarrollo es válido en general y no
está limitado a procesos GSM o UMTS.
La primera columna en la Fig. 3 muestra las
etapas de proceso que conciernen principalmente al teléfono móvil 1
del cliente; la segunda describe las etapas de proceso que son
realizadas por el terminal 2; la tercera se refiere a las
operaciones del centro de servicios 4, y la cuarta a los efectos
sobre las diversas cuentas en el instituto financiero. Debe no
obstante observarse que numerosas etapas de proceso pueden
realizarse ya sea mediante el teléfono móvil 1, por ejemplo como
proceso dentro de la tarjeta SIM 10, o en el terminal 2. Así por
ejemplo, la entrada de datos puede realizarse ya sea mediante el
terminal o mediante el teléfono móvil 1, si éste contiene un
teclado, tal como por ejemplo un aparato móvil GSM.
Este procedimiento presupone en la etapa 200 que
la tarjeta de identificación 10 del cliente comprenda una zona de
memoria segura, en la cual sean almacenadas unidades dinerarias
electrónicas. Tarjetas de valor son en sí ya conocidas; más adelante
se describirá más detalladamente, con relación a la Fig. 4, como
puede ser recargado el importe dinerario. Además, en la solicitud
de Patente EP96810570.0 se describe un procedimiento para recargar
tarjetas SIM con un importe dinerario.
El sistema móvil 1 ó 10 es conectado, listo para
su funcionamiento, en la etapa 201, por ejemplo conectando el
aparato móvil. Igualmente es activado, en la etapa 202, el terminal
2. El terminal 2 pasa entonces lista, en la etapa 203, mediante un
proceso de radiodifusión, del siguiente cliente indefinido
(búsqueda de tarjetas).
Cuando se ha establecido la comunicación entre el
terminal 2 y el teléfono móvil 1, 10, en la etapa 204 el teléfono
móvil transmite al terminal su identificación IDUI (International
Debit User Identification) y la confirmación de que es solvente. La
IDUI está depositada en una primera zona segura de la tarjeta. El
que la solvencia sea suficiente no puede todavía decidirse en este
instante.
El terminal 2 contiene una lista negra de
clientes que deban ser bloqueados, que es preferentemente
actualizada periódicamente por el servidor financiero 4. La IDUI
transmitida por el cliente es comparada con la lista negra (etapa
205) (datos de permiso). Si la IDUI transmitida por el cliente es
hallada en la lista negra (etapa 206), se coloca en la etapa 207
una bandera de bloqueo. Si no se halla coincidencia alguna, puede
entrarse en el teclado del terminal 2 el importe de transacción A.
De acuerdo con una variante, el importe de transacción A puede
también ser entrado con los medios de entrada 11 del aparato móvil
1. El terminal 2, o de acuerdo con una variante la tarjeta SIM 10,
entrelaza entonces este importe con la identificación del terminal 2
y de la IDUI y envía al cliente este comprobante de cargo.
Preferentemente se incorpora, además, también una divisa de
referencia, tal como por ejemplo SDR, Euro o Dólar.
Como la comunicación es firmada, en la etapa 210
puede comprobarse si el comprobante de cargo se correlaciona con
la IDUI. En caso negativo, el motivo del rechazo es indicado en el
terminal 2 (etapa 223). De lo contrario, es comprobada en la etapa
211 una bandera de bloqueo. Si está colocada (212), se produce una
comprobación con el servidor financiero 4 (etapa 248). Si no está
colocada, se produce una comprobación de zona (etapa 213). Así
pueden bloquearse tarjetas SIM según la zona de utilización. Si la
comprobación de zona es negativa, se realiza una comprobación con
el servidor financiero 4 (etapa 248); de lo contrario se efectúa una
comprobación de Time-Out (etapa 215). Es comprobado
si el tiempo de validación, durante el cual pueden realizarse
transacciones sin comprobación, ya ha vencido. Si el tiempo de
validación ha vencido (216), se efectúa una comprobación con el
servidor financiero (etapa 248); de lo contrario, el cliente es
requerido, en la etapa 217, a entrar manualmente su código de
usuario en el aparato móvil 1. Si el código entrado es correcto
(etapa 218), el importe A es eventualmente convertido (etapa 219) a
la divisa unitaria (por ejemplo SDR). Con ello resulta posible un
empleo internacional del concepto. De lo contrario, en la etapa 223
es indicado en el terminal 2 el rechazo con indicación de
motivo.
El teléfono móvil 1/10 comprueba entonces, en la
etapa 220, si el importe de transacción A que deba ser cargado está
cubierto por el importe dinerario cargado en la segunda zona de
memoria (comprobación de solvencia). Si ello no es el caso, en la
pantalla del terminal se indica este motivo de rechazo (etapa
223).
Cuando han tenido lugar todas estas
comprobaciones, en la etapa 222 es contada la transacción por medio
de un contador de transacciones Tz, que es incrementado. Este
contador corresponde al número de transacciones realizadas con la
tarjeta 10. En la etapa 224 son entonces entrelazados el importe de
transacción A, la identificación de terminal POSID y la
identificación de usuario IDUI en un comprobante de transacción, el
cual es adicionalmente certificado y opcionalmente codificado y
eventualmente además comprimido. El procedimiento ECC (Elliptic
Curve Cryptosystem) puede por ejemplo emplearse para la
certificación. Más adelante se describirá más detalladamente, a
título de ejemplo, un adecuado procedimiento de certificación y
codificación.
El importe de transacción A cargado es entonces
contabilizado, en la etapa 225, en la cuenta de importe dinerario
memorizada, y el comprobante de transacción es archivado, en la
etapa 226, en una pila en el módulo de identificación 10. Esta pila
de la tarjeta del cliente puede ser solicitada por el servidor
financiero 4, a discreción, para un control detallado.
Preferentemente, el propio cliente puede ilustrar en su aparato
móvil 1 los comprobantes de transacción memorizados en la pila.
Después de la etapa 224 es entregado el
comprobante de transacción al terminal 2 para la liquidación, y la
firma del cliente es comprobada por el terminal (etapa 227).
Opcionalmente es impreso para el cliente, en la etapa 228, un
comprobante de papel en el terminal.
En la etapa 229 es entonces entrelazado, en el
terminal 2, el comprobante de cargo con eventuales datos
adicionales, y el comprobante de transacción es firmado
electrónicamente por el terminal 2 y opcionalmente comprimido y
codificado. El comprobante de transacción electrónico así preparado
es entonces opcionalmente archivado, en la etapa 230, en una pila
en el terminal 2. La pila contiene comprobantes de transacción de
distintos clientes. Los comprobantes de transacción son luego
transferidos individualmente o por grupos, durante la etapa 231, a
la unidad de compensación 3. La transferencia puede realizarse
inmediatamente después de la transacción, o bien pueden
transferirse en intervalos de tiempo periódicos (por ejemplo cada
hora o cada día) varios comprobantes de transacción desde la pila.
También puede aplicarse un proceso por paquetes, para transferir
todos los comprobantes de transacción, por ejemplo, durante la
noche.
La unidad de compensación 3 recibe comprobantes
de transacción individuales o agrupados desde varios terminales 2
en la misma zona geográfica (etapa 234). Pueden preverse varias
unidades de compensación geográficamente distribuidas. En la etapa
235 la unidad de compensación 3 atribuye los comprobantes de
transacción recibidos de distintos terminales a los correspondientes
institutos financieros u ofertantes de servicios, y retransmite
correspondientemente dichos comprobantes de transacción.
Cuando los comprobantes de transacción están
codificados, los mismos deben ser primeramente descodificados por la
unidad de compensación, a fin de ser atribuidos a un servidor
financiero 4, 4 ', 4 '', y luego nuevamente codificados por la
unidad de compensación, para retransmitirlos. Sin embargo, de
acuerdo con una variante preferida, los elementos de datos en los
campos IDUI y eventualmente POSID del comprobante de transacción,
que se precisan para la compensación, no son codificados por el
terminal 2. De esta manera puede conseguirse una transmisión
segura, codificada de punta a punta, de los comprobantes de
transacción entre los terminales y los servidores financieros 4,
4', 4''.
El respectivo servidor financiero recibe, en la
etapa 236, los comprobantes de transacción, y el servidor TTP 40
los descomprime y descodifica (en caso necesario), y comprueba la
autenticidad de las firmas del terminal 2 y del módulo de
identificación 10. En la etapa 237 se comprueba si la POSID y/o la
IDUI se hallan en una lista de revocación. Si la prueba es positiva
(238), porque ni la identificación de terminal ni la identificación
de cliente IDUI se hallan en la lista de revocación, en la etapa 239
se realiza una prueba de la ficha de carga LT. La ficha de carga LT
da el número de recargas de la tarjeta 10. Esta ficha de carga es
actualizada en el servidor financiero (LT_{S}) y en el módulo de
identificación 10 (LT_{c}) después de cada proceso de recarga, tal
como se describirá más adelante. Una copia de la ficha de carga
LT_{c} está transferida al campo IDUI en el comprobante de
transacción. La ficha de carga LT_{c}, comunicada por el teléfono
móvil 1, 10, debe ser igual que la ficha de carga LT_{S},
memorizada en el servidor financiero 4. En el caso de que
comprobantes de recarga se hallen todavía en el camino entre el
servidor financiero 4 y el sistema móvil 1, 10, LT_{c} puede ser
temporalmente también menor que LT_{S}. El servidor financiero 4
comprueba pues si LT_{c} \leq LT_{S}.
Si en la etapa 240 no se verifica esta condición,
probablemente se realizó un proceso de recarga no autorizado, y el
procedimiento pasa a la etapa 241. Aquí se diferencia si el
falseamiento ha sido realizado por el terminal o por el cliente. Si
el cliente es responsable, el mismo es registrado, en la etapa 242,
en una lista negra. Preferentemente es generado un comprobante de
bloqueo de cliente y es enviado al teléfono móvil 1, 10 del
cliente, para colocar la bandera de bloqueo y bloquear este
sistema, así como a todos los terminales o al menos a todos los
terminales en una zona geográfica predefinida, a fin de registrar a
este cliente en la lista negra de dicho terminal. Si por el
contrario el problema fue originado por el terminal, éste es
registrado, en la etapa 243, en una lista negra de terminales.
Si en la etapa 240 es pasado el examen de fichas
de carga, en la etapa 244 puede cargarse el importe de transacción
A en el comprobante de transacción a una cuenta de comprobación de
cliente 41 en el instituto financiero. En la etapa 245 es abonado
correspondientemente el importe de transacción A a una cuenta 420,
420' o 420'' del operador del terminal en un instituto financiero.
Tasas de tramitación pueden también cargarse por un instituto
financiero y/o por el operador del terminal o por el operador de la
red a la cuenta 420 y/o a una cuenta de cliente.
En la etapa 246 inscribe entonces el servidor
financiero 4 esta transacción en el contador de transacciones.
Entonces se realiza un proceso en la etapa 247, a fin de actualizar
los valores de la ficha de carga LT_{c} y del contador de
transacción Tz en el teléfono móvil.
Volvamos al proceso en el teléfono móvil 1, 10.
Tal como ya se ha explicado, este sistema llega a la etapa 248
cuando ha sido constatado un problema de seguridad en la etapa 212,
214 ó 216. En este caso se produce una comprobación completa con el
servidor financiero, preferentemente a través de la red de
telefonía móvil 6. La comprobación comprende, por ejemplo, una
prueba y una renovación del certificado de autentificación así como
una comprobación de todos los parámetros ejecutados, por ejemplo de
las fichas de carga LT, de los contadores de transacciones Tz, de la
lista negra, etc. Si el resultado de la comprobación es negativo
(etapa 249), se coloca la bandera de bloqueo, de manera que el
sistema móvil 1, o al menos la respectiva aplicación en la tarjeta
SIM 10, resulta bloqueada (etapa 253). Si por el contrario esta
comprobación demuestra que probablemente no se ha intentado ningún
falseamiento, en la etapa 250 se fija de nuevo el tiempo de
validación. Mediante el tiempo de validación puede por ejemplo ser
bloqueado un módulo de identificación, si no es empleado durante un
tiempo predefinido, por ejemplo un año. Por consiguiente, esta
indicación debe ser ajustada de nuevo después de cada empleo. La
bandera de bloqueo es entonces borrada en la etapa 251 y, en caso
necesario, es fijada una nueva zona en la etapa 252.
Es importante observar que el proceso de cargo
puede realizarse con distintas divisas, por ejemplo sobre la base
de los SDR (Derechos de Sorteo Especiales) habituales en el ámbito
de las telecomunicaciones, o con otra divisa de referencia (por
ejemplo Euro o Dólar). El importe máximo en la tarjeta está
definido según la clase de cliente. Como mínimo es posible un valor
por defecto en SDR. Cada terminal 2 memoriza el valor SDR relevante
para el mismo (por ejemplo referido a cada divisa), que le es
comunicado por el servidor durante el proceso de registro. Según
las oscilaciones de cambio, los terminales son alimentados
automáticamente por el servidor financiero con cursos de cambio
actuales.
Un procedimiento para la recarga del sistema
móvil 1, 10 con un importe dinerario se describirá a continuación
más detalladamente con relación a la Fig. 4. Este procedimiento
puede también aplicarse a cualesquiera formas de realización de la
invención según las Figs. 1 ó 2.
Un proceso de recarga se realiza en este ejemplo
conjuntamente mediante el teléfono móvil 1, 10 del cliente y el
terminal 2. Sin embargo, también sería posible efectuar la recarga
del importe dinerario en el modulo de identificación 10 mediante
una transacción que solamente afecte al teléfono móvil 1, 10 y al
centro de servicios 4. Esta solución tendría la ventaja de que el
cliente no precisa recurrir a un terminal; sin embargo, en este
caso no pueden realizarse ciertas comprobaciones de seguridad. Por
consiguiente, esta variante se emplea únicamente para transferir
pequeños importes dinerarios, o cuando estén previstos mecanismos de
seguridad adicionales. Sin embargo, también podría preverse un
proceso de recarga directo por parte del servidor financiero 4.
Según la clase de cliente, o también a discreción, puede bajarse
por el servidor financiero la pila de comprobantes en la tarjeta del
cliente, para un control detallado. Después del proceso de recarga
puede ser borrada la pila por el servidor financiero.
La primera columna en la Fig. 4 muestra las
etapas de proceso que afectan principalmente al teléfono móvil 1,
10; la segunda describe las etapas de proceso que son realizadas
por el terminal 2; la tercera se refiere a las operaciones del
centro de servicios 4 y la cuarta a los efectos sobre las diversas
cuentas en el instituto financiero. Debe no obstante observarse que
múltiples etapas de proceso pueden ser realizadas ya sea mediante
el teléfono móvil 1, 10, por ejemplo dentro de la tarjeta SIM 10, o
mediante el terminal 2. Así por ejemplo, las etapas de proceso que
se refieren a la entrada de datos pueden ser realizadas ya sea en
el terminal o en el aparato móvil 1, siempre que el aparato móvil
contenga una unidad de manejo. La comunicación entre ambas partes
es preferentemente codificada, por ejemplo mediante un algoritmo de
seguridad DEA, DES, TDES, RSA o ECC.
En la etapa 300 es primeramente conectado el
teléfono móvil 1, 10 y liberado operativamente para el proceso de
recarga; el terminal 2 es a su vez activado también en la etapa 301.
El terminal 2 pasa entonces lista, en la etapa 302, según un
procedimiento de radiodifusión, del siguiente, indefinido sistema
móvil 1, 10 ("llamada de tarjetas").
Cuando se ha establecido la comunicación entre el
terminal 2 y el teléfono móvil 1, 10, en la etapa 303 el cliente
comunica al terminal su identificación IDUI (International Debit
User Identification) y el tipo de proceso que deba iniciarse, en
este caso una recarga.
El terminal 2 contiene una lista negra,
preferentemente actualizada periódicamente por el servidor
financiero 4, de sistemas móviles que deban ser bloqueados (lista
de revocación). La IDUI transmitida por el cliente es comparada con
la lista negra (etapa 304). Si la IDUI comunicada por el cliente se
halla en la lista negra (etapa 305), se coloca una bandera de
bloqueo en la etapa 306. A continuación, o cuando no se ha hallado
coincidencia alguna, es comprobado en la etapa 307 si la solicitud
se correlaciona con la IDUI. En caso negativo, se indica en el
terminal 2 el motivo de rechazo (etapa 315). De lo contrario se
comprueba en la etapa 308 la bandera de bloqueo. Si ésta está
colocada, el teléfono móvil 1, 10, o al menos la correspondiente
aplicación en la tarjeta de identificación 10, es bloqueada (etapa
331). Si no está colocada, el cliente es requerido en la etapa 310 a
introducir manualmente su código de usuario en el aparato móvil 1.
Si el código introducido no es correcto (etapa 311), también es
colocada una bandera de bloqueo y se indica el motivo de rechazo en
el terminal 2 (etapa 315); de lo contrario, el proceso está libre
para la recarga y el cliente es requerido en la etapa 312 a entrar
un importe de recarga A. En la variante ilustrada, el importe de
recarga puede ser entrado en el terminal 2; este importe es
entrelazado en la etapa 313 con la POSID y con la IDUI, firmado y
transmitido a la tarjeta 10. Sin embargo, el importe A podría
también captarse en el aparato móvil 1; en este caso no estaría
implicado ningún terminal y la POSID no se requeriría por
tanto.
En la etapa 314 se comprueba si la IDUI en los
datos recibidos por el terminal 2 coincide con la propia IDUI. En
caso negativo, se indica en el terminal 2 el motivo de rechazo
(etapa 315); de lo contrario, el importe de recarga deseado y
entrado en el terminal es indicado en la pantalla del aparato móvil
1. En la etapa 316 son entonces entrelazados la POSID (opcional), la
IDUI, la cantidad ya mencionada de transacciones de pago Tz, la
cantidad memorizada en la tarjeta de procesos de recarga efectuados
(LTc, ficha de carga cliente) y el importe residual en la tarjeta
DRA (Debit Rest Amount), firmados, codificados y luego opcionalmente
comprimidos. De esta manera se genera un comprobante de recarga.
Opcionalmente puede también transmitirse la pila de comprobantes en
la tarjeta, por ejemplo según clase de cliente, a la salida de la
tarjeta o a discreción durante el empleo en caso de problemas de
solvencia. La POSID es únicamente integrada en el comprobante de
recarga cuando el cliente dispone de un aparato móvil sin adecuados
medios de entrada. El importe de recarga es entonces transmitido al
servidor financiero 4, 4' o 4'' a través de la red 6, donde el
servidor TTP 40 recibe este comprobante en la etapa 317,
eventualmente lo descodifica y descomprime, y comprueba la firma
del cliente y eventualmente del terminal.
En la etapa 319 se realizan con ayuda de la tabla
318, que memoriza la cantidad y fichas respecto a los procesos
entre el cliente y el servidor financiero, las siguientes
comprobaciones:
Comprobación de importes: la suma \SigmaA de
todos los importes cargados en el módulo de identificación 10,
inclusive la suma inicial, debe ser igual o menor que la suma de
todos los cargos de control \SigmaKB y del importe residual DRA
en el módulo de identificación. La suma puede ser menor, porque
los comprobantes que se hallan todavía entre el sistema de
telefonía móvil 1, 10, la unidad de compensación 3 y el servidor
financiero 4, 4', 4'' no pueden todavía captarse en este
momento.
Comprobación de fichas de carga: la cantidad de
transacciones de carga o de recarga es contada en el teléfono móvil,
por ejemplo en la tarjeta SIM, con una ficha LTc, y en el servidor
financiero 4 con otra ficha LTs. Estas dos fichas deben ser
iguales.
Comprobación del contador de transacciones: Para
cada transacción de pago es incrementado el contador de
transacciones Tz en el teléfono móvil 1, 10; en cada comprobante de
recarga es también transferido Tz. El contador de transacciones
T_{ZS} memorizado en el servidor financiero, que es incrementado
por los comprobantes transferidos por el cliente, debe ser igual o
eventualmente menor que el contador de transacciones Tz en el
teléfono móvil 1, 10.
Si una de estas tres condiciones no se cumple
(etapa 320), en la etapa 321 es colocada la bandera de bloqueo y el
proceso de recarga es rechazado en la etapa 325. De lo contrario,
en la etapa 322 es comprobado el estado de cuenta 41 del cliente.
Si no es suficiente para la recarga, en la etapa 325 es también
preparado un rechazo.
Si la cuenta (o el límite de cuenta) del cliente
en el instituto financiero 4 es suficiente para el importe que deba
ser recargado (etapas 322, 323), este importe es cobrado de una
cuenta de cliente del instituto financiero (324), incluyendo
eventuales comisiones. Simultáneamente es contabilizado, en la
cuenta de comprobación 41, el importe de recarga solicitado.
Entonces es generado, en la etapa 326, un comprobante de recarga, a
partir de la POSID, la IDUI, el importe A, la nueva ficha de carga
LTn, y un incremento de Time Out predefinido TOi. Este importe de
recarga es firmado en la etapa 327, opcionalmente codificado y
comprimido, y transferido al sistema móvil 1, 10 del cliente. Este
comprueba, durante la etapa 328, si la firma en el comprobante
procede del servidor financiero, y verifica, durante la etapa 329,
si está colocada la bandera de bloqueo. Caso de que esté colocada
(etapa 330), el teléfono móvil 1, o al menos la correspondiente
aplicación, es bloqueada en la etapa 331. De lo contrario, se
comprueba todavía si el servidor financiero ha requerido un rechazo
(etapa 332), lo cual da lugar a la interrupción del proceso con
indicación del motivo de rechazo (334).
Si todas las pruebas han sido pasadas
exitosamente, en la etapa 335 la cuenta de tarjeta es contabilizada
con el importe de recarga solicitado. La antigua ficha de carga LTc
es entonces sustituida por la nueva ficha de carga LTn transmitida
por el servidor financiero (etapa 336), el contador de transacciones
Tz en la tarjeta es reseteado en la próxima etapa 337, y el Time
Out TOi es ajustado de nuevo en la etapa 338. Si en la etapa 339 se
constata que en el comprobante de recarga está contenida la POSID,
se fija adicionalmente en la etapa 340 una nueva zona.
El importe de recarga es entonces indicado como
confirmación, ya sea en la pantalla del aparato móvil o en el
terminal (etapa 341). Finalmente, también es indicado el estado de
cuenta global en la tarjeta (etapa 342).
En el ejemplo descrito con ayuda de las Figs. 3 y
4 es cargada la cuenta bancaria "real" del cliente en el
instituto financiero ya al recargarse la tarjeta. Otras variantes
de pago, por ejemplo con tarjeta de crédito o mediante
establecimiento de una factura, son naturalmente también posibles
dentro del ámbito de la presente invención. De acuerdo con una
variante, el sistema puede también funcionar como sistema de
crédito: en este caso es cargada la cuenta bancaria del cliente
únicamente cuando el servidor financiero 7 reciba un comprobante de
transacción. El importe dinerario memorizado en la segunda zona de
memoria de la tarjeta sirve en este caso únicamente como límite de
gasto.
El aseguramiento de las transmisiones de datos
mediante criptografía se realiza en dos distintos segmentos de
forma diferente. Entre el cliente y el terminal se asegura la
comunicación a través del interfase aéreo mediante, por ejemplo, un
algoritmo tal como DES, TDES, RSA o ECC. Por el contrario, entre el
cliente y el servidor financiero encuentra aplicación el
procedimiento TTP (Trusted Third Party), u opcionalmente un
procedimiento PTP (Point-to-Point).
Los elementos necesarios están integrados en el elemento de
identificación 10 y en el servidor TTP 40. Preferentemente se
codifican los comprobantes de transacción con un algoritmo
simétrico, utilizando el algoritmo simétrico una llave de sesión
codificada con un algoritmo asimétrico. Preferentemente son además
certificados los comprobantes de transacción transferidos.
Claims (26)
1. Procedimiento de transacción financiera entre
un cliente y un terminal (2), estando dicho cliente equipado con
un teléfono móvil apto para ser empleado en una red de telefonía
móvil (6), comprendiendo dicho teléfono móvil un aparato móvil (1)
y un módulo de identificación extraíble, en el cual pueden
memorizarse al menos una identificación de cliente y un importe
dinerario electrónico, siendo dicho importe monetario susceptible de
ser recargado con ayuda de comprobantes de recarga seguros
procedentes de un centro de servicios (4), cuyos comprobantes de
recarga son transferidos mediante mensajes digitales a través de
dicha red de telefonía móvil (6), caracterizado porque
comprende las siguientes etapas:
- -
- transferencia de dicha identificación de cliente al terminal (2) a través de un interfase inalámbrico entre dicho módulo de identificación (10) y dicho terminal (2),
- -
- comprobación en dicho terminal del permiso del cliente, identificado mediante dicha identificación de cliente transferida, a realizar una transacción financiera, efectuándose dicha comprobación mediante datos de permiso que son transmitidos al terminal (2) a través de una red telefónica pública (5),
- -
- transferencia de un importe de transacción electrónico a través de dicho interfase inalámbrico al terminal (2),
- -
- cargo del importe dinerario memorizado en función del importe de transacción transferido,
- -
- preparación de un comprobante de transacción en el terminal (2), el cual contiene dicha identificación de cliente, una identificación de terminal así como una indicación sobre dicho importe de transacción,
- -
- firma electrónica de dicho comprobante de transacción por el terminal (2),
- -
- transferencia de dicho comprobante de transacción al centro de servicios (4) a través de la citada red telefónica pública (5),
- -
- comprobación de la firma electrónica del terminal (2) en dicho centro de servicios (4),
- -
- si la firma corresponde a un terminal autorizado (2), abono en una cuenta del operador del terminal (2).
2. Procedimiento de transacción según la
reivindicación precedente, caracterizado porque dicho centro
de servicios (4) lleva para cada cliente una cuenta de control (41),
en la cual está memorizado el valor del importe dinerario
memorizado en el módulo de identificación, siendo actualizada dicha
cuenta de control con cada recarga del citado importe dinerario y a
la recepción de comprobantes de transacción.
3. Procedimiento de transacción según la
reivindicación precedente, caracterizado porque dichos
comprobantes de transacción son enviados a dicho centro de
servicios (4) por una unidad de compensación (3).
4. Procedimiento de transacción según una de las
reivindicaciones precedentes, caracterizado porque los datos
que son transferidos por dicho teléfono móvil (1, 10) al terminal
(2) a través de dicho interfase inalámbrico están dotados de una
firma electrónica del módulo de identificación (10).
5. Procedimiento de transacción según la
reivindicación precedente, caracterizado porque dicha firma
electrónica del módulo de identificación (10) es comprobada en el
terminal (2).
6. Procedimiento de transacción según una de las
reivindicaciones 4 ó 5, caracterizado porque dicha firma
electrónica del módulo de identificación (10) es retransmitida al
centro de servicios (4) y es comprobada por éste.
7. Procedimiento de transacción según una de las
reivindicaciones precedentes, caracterizado porque los
comprobantes de transacción son susceptibles de ser transferidos a
dicho centro de servicios (4) a modo de paquetes a través de la
citada red telefónica pública (5).
8. Procedimiento de transacción según una de las
reivindicaciones precedentes, caracterizado porque dichos
terminales contienen una lista negra de clientes, susceptible de
ser actualizada por dicho centro de servicios (4) a través de la
citada red telefónica pública (5), y porque la transacción es
interrumpida si la identificación de cliente recibida está
contenida en dicha lista negra.
9. Procedimiento de transacción según una de las
reivindicaciones precedentes, caracterizado porque dicho
centro de servicios (4) es apto para bloquear dichos módulos de
identificación (10) con ayuda de comprobantes de bloqueo de cliente
transferidos a través de dicha red de telefonía móvil (6).
10. Procedimiento de transacción según una de las
reivindicaciones precedentes, caracterizado porque dicho
centro de servicios (4) es apto para bloquear dichos terminales (2)
con ayuda de comprobantes de bloqueo de terminal transferidos a
través de la citada red telefónica pública (5).
11. Procedimiento de transacción según una de las
reivindicaciones precedentes, caracterizado porque el módulo
de identificación (10) es una tarjeta SIM.
12. Procedimiento de transacción según la
reivindicación 2, caracterizado porque el módulo de
identificación es un transpondedor (10'), y porque el aparato móvil
(24) está contenido en el terminal (2).
13. Procedimiento de transacción según una de las
reivindicaciones precedentes, caracterizado porque el módulo
de identificación (10, 10') se comunica con el terminal (2) a
través de una bobina integrada en el módulo de identificación (10,
10').
14. Procedimiento de transacción según una de las
reivindicaciones precedentes, caracterizado porque el módulo
de identificación (10) se comunica con el terminal (2) con ayuda de
una bobina integrada en el aparato móvil (1).
15. Procedimiento de transacción según una de las
reivindicaciones 1 a 13, caracterizado porque el módulo de
identificación (10) se comunica con el terminal (2) con ayuda de un
emisor/receptor infrarrojo integrado en el aparato móvil (1).
16. Procedimiento de transacción según una de las
reivindicaciones precedentes, caracterizado porque al menos
ciertos datos, que son transferidos a través de dicho interfase
inalámbrico (101-20) entre el terminal (2) y el
módulo de identificación (10, 10'), son codificados y/o
firmados.
17. Procedimiento de transacción según una de las
reivindicaciones precedentes, caracterizado porque los
citados comprobantes de transacción son codificados.
18. Procedimiento de transacción según la
reivindicación precedente, caracterizado porque los citados
comprobantes de transacción no son descodificados durante la
transmisión.
19. Procedimiento de transacción según una de las
reivindicaciones 17 ó 18, caracterizado porque los elementos
de datos (IDUI), que se precisan para la compensación en dicha
unidad de compensación (3), no son codificados, de manera que la
unidad de compensación no precisa descodificar los comprobantes de
transacción.
20. Procedimiento de transacción según una de las
reivindicaciones precedentes, caracterizado porque los
comprobantes de transacción (90) son codificados con un algoritmo
simétrico, utilizando dicho algoritmo simétrico una llave de sesión
codificada mediante un algoritmo asimétrico.
21. Procedimiento de transacción según una de las
reivindicaciones precedentes, caracterizado porque los
comprobantes de transacción transmitidos a través de la citada red
telefónica pública (5) son certificados y/o firmados.
22. Procedimiento de transacción según una de las
reivindicaciones precedentes, caracterizado porque dicho
importe de transacción es susceptible de ser leído o captado en el
terminal (2).
23. Procedimiento de transacción según una de las
reivindicaciones precedentes, caracterizado porque dicho
importe de transacción es susceptible de ser leído o captado en el
aparato móvil (1).
24. Procedimiento de transacción según una de las
reivindicaciones precedentes, caracterizado porque el centro
de servicios (4) memoriza una lista negra de terminales, y porque
el procedimiento es interrumpido cuando la identificación de
terminal (POSID) recibida está contenida en la lista negra de
terminales.
25. Procedimiento de transacción según una de las
reivindicaciones precedentes, caracterizado porque el centro
de servicios (4) memoriza una lista negra de clientes, y porque el
procedimiento es interrumpido cuando la identificación de cliente
(IDUI) recibida está contenida en la lista negra de clientes.
26. Procedimiento de transacción según una de las
reivindicaciones precedentes, caracterizado porque el
elemento de identificación (10) contiene una pila con datos sobre
transacciones ya efectuadas, y porque estos datos son susceptibles
de ser bajados por el centro de servicios (4).
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CH156497 | 1997-06-27 | ||
CH1564/97 | 1997-06-27 | ||
PCT/CH1998/000086 WO1998037524A1 (de) | 1997-06-27 | 1998-03-05 | Transaktionsverfahren mit einem mobilgerät |
WOPCT/CH98/00086 | 1998-03-05 |
Publications (1)
Publication Number | Publication Date |
---|---|
ES2218832T3 true ES2218832T3 (es) | 2004-11-16 |
Family
ID=25688016
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES98928045T Expired - Lifetime ES2218832T3 (es) | 1997-06-27 | 1998-06-29 | Procedimiento de transaccion con un aparato movil. |
Country Status (7)
Country | Link |
---|---|
EP (1) | EP0993664B1 (es) |
JP (1) | JP2002511172A (es) |
AU (1) | AU8007098A (es) |
CA (1) | CA2295043A1 (es) |
DE (1) | DE59811009D1 (es) |
ES (1) | ES2218832T3 (es) |
WO (1) | WO1999000773A1 (es) |
Families Citing this family (35)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE19903822C2 (de) * | 1999-02-02 | 2001-09-20 | Mathias Entenmann | Verfahren zur Durchführung bargeldloser Zahlungen und System zur Durchführung des Verfahrens |
US7729986B1 (en) * | 1999-07-30 | 2010-06-01 | Visa International Service Association | Smart card transactions using wireless telecommunications network |
US7376583B1 (en) | 1999-08-10 | 2008-05-20 | Gofigure, L.L.C. | Device for making a transaction via a communications link |
US7720762B1 (en) | 2002-10-03 | 2010-05-18 | Gofigure Payments, Llc | System and method for electronically processing commercial transactions based upon threshold amount |
WO2001016897A1 (de) * | 1999-08-27 | 2001-03-08 | Siemens Aktiengesellschaft | Telekommunikations-endgerät |
GB2357664B (en) * | 1999-12-22 | 2004-03-10 | Nokia Mobile Phones Ltd | Electronic commerce system |
DE10000948A1 (de) | 2000-01-12 | 2001-08-02 | Siemens Ag | Anordnung zur Bereitstellung und flexiblen Vergebührung einer Ware oder Dienstleistung sowie Ausgabeautomat zum Einsatz in einer solchen und Verfahren zum Betrieb einer solchen |
DE10005487A1 (de) * | 2000-02-08 | 2001-08-09 | Siemens Ag | Verfahren zur Nutzeridentitätskontrolle |
EP1257983A2 (en) * | 2000-02-10 | 2002-11-20 | Jon Shore | Apparatus, systems and methods for wirelessly transacting financial transfers, electronically recordable authorization transfers, and other information transfers |
DE10008280C1 (de) * | 2000-02-23 | 2001-06-13 | Wire Card Ag | Verfahren und System zur automatischen Abwicklung von bargeldlosen Kaufvorgängen |
GB2366436B (en) * | 2000-03-09 | 2002-10-09 | Komos Co Ltd | Control and operation system |
NL1015564C2 (nl) * | 2000-05-30 | 2001-12-03 | Beleggings En Exploitatie Mij | Werkwijze en inrichting voor het uitvoeren van (trans)acties. |
US7529563B1 (en) | 2000-07-10 | 2009-05-05 | Pitroda Satyan G | System for distribution and use of virtual stored value cards |
US7209903B1 (en) | 2000-07-13 | 2007-04-24 | Ctech Global Services Corporation Limited | Method and system for facilitation of wireless e-commerce transactions |
US6877094B1 (en) * | 2000-07-28 | 2005-04-05 | Sun Microsystems, Inc. | Method and apparatus for authentication and payment for devices participating in Jini communities |
US6868267B1 (en) * | 2000-11-17 | 2005-03-15 | Qualcomm Inc. | Apparatus, method, and article of manufacture used to invoice for services consumed in a communications network |
WO2003012717A1 (en) | 2001-07-30 | 2003-02-13 | C-Sam, Inc. | System for distribution and use of virtual stored value cards |
EP1282087A1 (de) | 2001-08-02 | 2003-02-05 | Alcatel | Verfahren zur Durchführung von Transaktionen von elektronischen Geldbeträgen zwischen Teilnehmerendgeräten eines Kommunikationsnetzes, Transaktionsserver und Programmmodul hierfür |
FR2832829B1 (fr) * | 2001-11-28 | 2004-02-27 | Francois Brion | Procede, systeme et dispositif permettant d'authentifier des donnees transmises et/ou recues par un utilisateur |
US6816083B2 (en) * | 2002-02-04 | 2004-11-09 | Nokia Corporation | Electronic device with cover including a radio frequency indentification module |
DE10211674B4 (de) * | 2002-03-15 | 2005-07-07 | T-Mobile Deutschland Gmbh | Verfahren zur Bereitstellung und Abrechnung von WIM-Funktionalitäten bei mobilen Kommunikationsendeinrichtungen |
CN1745557A (zh) * | 2003-01-31 | 2006-03-08 | 雅斯拓股份有限公司 | 智能卡和服务器之间的通信 |
GB0308629D0 (en) * | 2003-04-14 | 2003-05-21 | Tagboard Ltd | Payment apparatus and method |
US7357309B2 (en) * | 2004-01-16 | 2008-04-15 | Telefonaktiebolaget Lm Ericsson (Publ) | EMV transactions in mobile terminals |
WO2005076176A1 (ja) * | 2004-02-04 | 2005-08-18 | Terutada Hoshina | 携帯電話機を利用した商品決済システム |
JP2005276184A (ja) | 2004-03-25 | 2005-10-06 | Internatl Business Mach Corp <Ibm> | 無線サービス購買システム |
EP1580702A1 (en) | 2004-03-25 | 2005-09-28 | IBM Corporation | wireless service purchasing system |
JP2005038446A (ja) * | 2004-09-13 | 2005-02-10 | Sony Corp | Icカード及び電子マネー入金システム |
DE102004061479A1 (de) * | 2004-12-21 | 2006-06-29 | Giesecke & Devrient Gmbh | Verfahren zum Aufbuchen eines Guthabens |
US9235831B2 (en) | 2009-04-22 | 2016-01-12 | Gofigure Payments, Llc | Mobile payment systems and methods |
US9240100B2 (en) | 2010-02-10 | 2016-01-19 | Leap Forward Gaming | Virtual players card |
US8271394B1 (en) * | 2011-10-27 | 2012-09-18 | Bogaard Erik T | Confirming local marketplace transaction consummation for online payment consummation |
US10339525B2 (en) | 2011-10-27 | 2019-07-02 | Boom! Payments, Inc. | Confirming local marketplace transaction consummation for online payment consummation |
JP5846985B2 (ja) * | 2012-03-27 | 2016-01-20 | 株式会社Nttドコモ | 端末不正使用特定システム、端末不正使用特定方法、プログラム |
US10621824B2 (en) | 2016-09-23 | 2020-04-14 | Igt | Gaming system player identification device |
Family Cites Families (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5608778A (en) * | 1994-09-22 | 1997-03-04 | Lucent Technologies Inc. | Cellular telephone as an authenticated transaction controller |
FI100137B (fi) * | 1994-10-28 | 1997-09-30 | Vazvan Simin | Reaaliaikainen langaton telemaksujärjestelmä |
WO1996018981A1 (fr) * | 1994-12-14 | 1996-06-20 | Aktsionernoe Obschestvo Zakrytogo Tipa 'blits-Tsentr' | Procede d'execution d'operation de compensation financiere et systeme associe |
JPH08194763A (ja) * | 1995-01-17 | 1996-07-30 | Akihiko Tsunoda | 無線電話端末による取引バランス決済システム |
JP2959451B2 (ja) * | 1995-09-29 | 1999-10-06 | 日本電気株式会社 | 移動体通信端末を利用した料金徴収方法 |
NL1001387C2 (nl) * | 1995-10-10 | 1997-04-11 | Nederland Ptt | Stelsel voor het elektronisch bestellen en betalen van diensten via een communicatienetwerk. |
JPH09116960A (ja) * | 1995-10-18 | 1997-05-02 | Fujitsu Ltd | キャッシュレスシステム及び該システムで使用する携帯機 |
US5796832A (en) * | 1995-11-13 | 1998-08-18 | Transaction Technology, Inc. | Wireless transaction and information system |
FR2749424B1 (fr) * | 1996-06-04 | 1998-07-10 | Ckd Sa | Terminal de transaction electronique portable, notamment terminal de paiement portable |
EP0960402B1 (en) * | 1996-06-19 | 2007-09-26 | Behruz Vazvan | Real time system and method for remote purchase payment and remote bill payment transactions and transferring of electronic cash and other required data |
-
1998
- 1998-06-29 CA CA002295043A patent/CA2295043A1/en not_active Abandoned
- 1998-06-29 DE DE59811009T patent/DE59811009D1/de not_active Expired - Lifetime
- 1998-06-29 ES ES98928045T patent/ES2218832T3/es not_active Expired - Lifetime
- 1998-06-29 EP EP98928045A patent/EP0993664B1/de not_active Expired - Lifetime
- 1998-06-29 AU AU80070/98A patent/AU8007098A/en not_active Abandoned
- 1998-06-29 JP JP50518599A patent/JP2002511172A/ja active Pending
- 1998-06-29 WO PCT/CH1998/000282 patent/WO1999000773A1/de active IP Right Grant
Also Published As
Publication number | Publication date |
---|---|
DE59811009D1 (de) | 2004-04-22 |
EP0993664A1 (de) | 2000-04-19 |
EP0993664B1 (de) | 2004-03-17 |
WO1999000773A1 (de) | 1999-01-07 |
JP2002511172A (ja) | 2002-04-09 |
CA2295043A1 (en) | 1999-01-07 |
AU8007098A (en) | 1999-01-19 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
ES2218832T3 (es) | Procedimiento de transaccion con un aparato movil. | |
ES2286822T3 (es) | Procedimiento y dispositivos para el uso y la compensacion de medios de pago electronico en un sistema abierto e interoperable para la exaccion automatica de tasas. | |
US8387873B2 (en) | System and method for mass transit merchant payment | |
US8165965B2 (en) | Transaction method with a mobile apparatus | |
US8700513B2 (en) | Authentication of a data card using a transit verification value | |
KR100366060B1 (ko) | 광지불송수신장치 및 이를 이용한 광결제시스템 | |
AU2006268199B2 (en) | Apparatus and method for integrated payment and electronic merchandise transfer | |
US7533065B2 (en) | Advanced method and arrangement for performing electronic payment transactions | |
US20080203170A1 (en) | Fraud prevention for transit fare collection | |
US20060173790A1 (en) | Optical payment transceiver and system using the same | |
CN100492420C (zh) | 光学支付发射机 | |
ES2422805B1 (es) | Procedimiento para el pago por teléfono móvil en comercios | |
EP2725535A1 (en) | System and method for securely store and transfer electronic money | |
JP2009015490A (ja) | Etcカード、非接触カードアクセス機能付きetc車載器及びetcシステム | |
JP2000306032A (ja) | 携帯電話を利用した電子通貨と電子的財布。 | |
JP2003187280A (ja) | 通行料金の前納を可能とした有料道路自動料金収受システム及びその方法 | |
WO2001069863A1 (en) | An electronic mail service system comprising an internet network |