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
Application number
ES98928045T
Other languages
English (en)
Inventor
Rudolf Ritter
Hanspeter Bouquet
Walter Heutschi
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.)
Swisscom Mobile AG
Original Assignee
Swisscom Mobile AG
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
Priority claimed from PCT/CH1998/000086 external-priority patent/WO1998037524A1/de
Application filed by Swisscom Mobile AG filed Critical Swisscom Mobile AG
Application granted granted Critical
Publication of ES2218832T3 publication Critical patent/ES2218832T3/es
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327Short range or proximity payments by means of M-devices
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/20Point-of-sale [POS] network systems

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Finance (AREA)
  • 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).
ES98928045T 1997-06-27 1998-06-29 Procedimiento de transaccion con un aparato movil. Expired - Lifetime ES2218832T3 (es)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
CH1564/97 1997-06-27
CH156497 1997-06-27
WOPCT/CH98/00086 1998-03-05
PCT/CH1998/000086 WO1998037524A1 (de) 1997-06-27 1998-03-05 Transaktionsverfahren mit einem mobilgerät

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 (34)

* Cited by examiner, † Cited by third party
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
WO2001059732A2 (en) * 2000-02-10 2001-08-16 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
EP1412890A4 (en) * 2001-07-30 2004-11-24 C Sam Inc SYSTEM FOR DISTRIBUTING AND USING 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
US20080010456A1 (en) * 2003-01-31 2008-01-10 Jacques Seif Communication between a smart card and a server
GB0308629D0 (en) * 2003-04-14 2003-05-21 Tagboard Ltd Payment apparatus and method
WO2005076176A1 (ja) * 2004-02-04 2005-08-18 Terutada Hoshina 携帯電話機を利用した商品決済システム
EP1580702A1 (en) 2004-03-25 2005-09-28 IBM Corporation wireless service purchasing system
JP2005276184A (ja) 2004-03-25 2005-10-06 Internatl Business Mach Corp <Ibm> 無線サービス購買システム
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
US10339525B2 (en) 2011-10-27 2019-07-02 Boom! Payments, Inc. Confirming local marketplace transaction consummation for online payment consummation
US8271394B1 (en) 2011-10-27 2012-09-18 Bogaard Erik T 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)

* Cited by examiner, † Cited by third party
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ä
AU1904395A (en) * 1994-12-14 1996-07-03 Aktsionernoe Obschestvo Zakrytogo Tipa "Blits-Tsentr" Method of carrying out financial clearing operations and an associated system
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

Also Published As

Publication number Publication date
DE59811009D1 (de) 2004-04-22
JP2002511172A (ja) 2002-04-09
CA2295043A1 (en) 1999-01-07
AU8007098A (en) 1999-01-19
WO1999000773A1 (de) 1999-01-07
EP0993664B1 (de) 2004-03-17
EP0993664A1 (de) 2000-04-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
US9213977B2 (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
JP2009015490A (ja) Etcカード、非接触カードアクセス機能付きetc車載器及びetcシステム
JP2000306032A (ja) 携帯電話を利用した電子通貨と電子的財布。
JP2003187280A (ja) 通行料金の前納を可能とした有料道路自動料金収受システム及びその方法
WO2001069863A1 (en) An electronic mail service system comprising an internet network