ES2527884B1 - Método y sistema para habilitar ticketing/pagos móviles sin contacto por medio de una aplicación de teléfono móvil, mejorados - Google Patents

Método y sistema para habilitar ticketing/pagos móviles sin contacto por medio de una aplicación de teléfono móvil, mejorados Download PDF

Info

Publication number
ES2527884B1
ES2527884B1 ES201300717A ES201300717A ES2527884B1 ES 2527884 B1 ES2527884 B1 ES 2527884B1 ES 201300717 A ES201300717 A ES 201300717A ES 201300717 A ES201300717 A ES 201300717A ES 2527884 B1 ES2527884 B1 ES 2527884B1
Authority
ES
Spain
Prior art keywords
ticketing
mobile phone
payment
credentials
user
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.)
Active
Application number
ES201300717A
Other languages
English (en)
Other versions
ES2527884A1 (es
Inventor
Carlos Alberto Pérez Lafuente
Imanol GARCÍA MURGA
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.)
Bankinter SA
Seglan SL
Original Assignee
Bankinter SA
Seglan SL
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 to ES201300717A priority Critical patent/ES2527884B1/es
Application filed by Bankinter SA, Seglan SL filed Critical Bankinter SA
Priority to JP2015527844A priority patent/JP6711623B2/ja
Priority to KR1020157005496A priority patent/KR20150046080A/ko
Priority to CA2882986A priority patent/CA2882986C/en
Priority to PE2015000237A priority patent/PE20150704A1/es
Priority to PCT/EP2013/066540 priority patent/WO2014029620A1/en
Priority to CN201811627095.4A priority patent/CN110110515A/zh
Priority to PE2016000050A priority patent/PE20160442A1/es
Priority to CN201380043046.5A priority patent/CN104871189B/zh
Priority to US14/422,555 priority patent/US20150206129A1/en
Priority to EP13748010.9A priority patent/EP2888703A1/en
Priority to MX2015002243A priority patent/MX366316B/es
Priority to RU2015109902A priority patent/RU2651179C2/ru
Publication of ES2527884A1 publication Critical patent/ES2527884A1/es
Priority to CL2015000413A priority patent/CL2015000413A1/es
Priority to ZA2015/01925A priority patent/ZA201501925B/en
Application granted granted Critical
Publication of ES2527884B1 publication Critical patent/ES2527884B1/es
Priority to US15/783,297 priority patent/US20180053179A1/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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

Abstract

Se describe un método para habilitar ticketing/pagos móviles sin contacto utilizando una aplicación de teléfono móvil, donde cada credencial preparada está unívocamente asociada al teléfono móvil del usuario registrado y a un código de activación, y habilita parcialmente el teléfono móvil para el acceso a ticketing sin contacto o para pagos móviles sin contacto; donde la habilitación del teléfono móvil requiere que el usuario inserte un número de identificación personal en la aplicación de ticketing/pagos; y donde el módulo de servidor de ticketing/pagos envía las credenciales al teléfono móvil después de validar con éxito una Contraseña de un Solo Uso (OTP) recibida desde la aplicación de ticketing/pagos. El usuario paga por determinados productos y/o servicios en uno o varios comercios asociados, y el al menos un comercio transfiere parte de dichos importes al proveedor de servicios de ticketing/pagos para que ofrezca al usuario determinados servicios de ticketing/pagos.

Description

limitado el modo en que proporcionan sus propios servicios a través del teléfono móvil ya que, con esta solución, parte del servicio es proporcionado dentro del dominio del operador de telecomunicaciones.
Por tanto, puede ser interesante para los proveedores de servicios tener acceso a nuevas 5 soluciones seguras que puedan estar plenamente disponibles dentro del dominio de la propia entidad de transporte/pagos, pero que a la vez presenten todos los beneficios que proporciona el ticketing/pagos sin contacto basados en el uso de teléfonos móviles NFC.
Descripción de la invención 10
La solicitud de patente P2012 está pensada dotar a los proveedores de servicios de transporte/pagos de un método seguro que pueda llevarse a cabo completamente dentro de su propio dominio, permitiéndoles así continuar manteniendo un control completo del servicio en cuanto a posicionamiento de marca, negocio y aprovisionamiento para 15 ticketing/pagos móviles NFC, evitando restricciones de terceras partes.
Este objeto se consigue proporcionando un método para habilitar ticketing/pagos móviles sin contacto a través de una aplicación de teléfono móvil, comprendiendo el método los siguientes pasos: 20
(a) Un usuario paga al proveedor de servicios por ciertos servicios de ticketing/pagos.
(b) Asociado al pago y a un correspondiente derecho concedido para utilizar los servicios de ticketing/pagos correspondientes, un módulo servidor de ticketing/pagos 25 prepara credenciales de ticketing/pagos para su uso por el usuario y las envía al teléfono móvil del usuario.
(c) El teléfono móvil del usuario recibe las credenciales y las almacena para su uso en el sistema de ticketing para transporte sin contacto, en caso de credenciales de 30 ticketing, o para su uso en pagos móviles sin contacto, en caso de credenciales de pagos.
Dicho método está caracterizado porque cada credencial está unívocamente asociada al teléfono móvil del usuario registrado y a un código de activación, y habilita parcialmente 35 el teléfono móvil para el acceso a ticketing sin contacto, en caso de credenciales de ticketing, o a pagos móviles sin contacto, en caso de credenciales de pagos; donde la habilitación del teléfono móvil para cada acceso a ticketing sin contacto (o pago móvil sin contacto) también requiere que el usuario inserte un Número de Identificación Personal (PIN, Personal ldentification Number) en la aplicación de ticketing/pagos del teléfono 40 móvil; y donde el módulo servidor de ticketing/pagos envía credenciales al teléfono móvil del usuario registrado después de una validación correcta de una Contraseña de un Solo Uso (OTP, One Time Password) recibida desde la aplicación de ticketing/pagos del teléfono móvil.
45
Además, de acuerdo con la solicitud de patente P201200837, sólo los usuarios registrados pueden obtener credenciales de ticketing/pagos después del pago, y el uso de dichas credenciales está asociado al teléfono móvil seleccionado durante el proceso de registro (y a un código de activación) y a un Número de Identificación Personal elegido por el usuario, de modo que se requiere una autenticación de dos factores. Además, las 50 credenciales sólo se envían a la aplicación del teléfono móvil del usuario registrado
después de verificar una OTP generada por dicha aplicación del teléfono móvil después de la interacción con el usuario, de modo que el proceso de descarga de credenciales está adecuadamente controlado por el usuario y por el proveedor de servicios de transporte/pagos.
5
El módulo servidor de ticketing/pagos de la solicitud P201200837 puede estar incluido al menos parcialmente en los medios de procesamiento de datos del proveedor de servicios. Todo o parte del mismo puede pertenecer o ser operado por un proveedor externo fiable del proveedor de servicios. Como ejemplo, varios proveedores de servicios de transporte pueden compartir un módulo servidor de ticketing común simplemente 10 llegando a un acuerdo entre ellos, evitando así la complejidad de soluciones basadas en tarjeta SIM en términos de acuerdos adicionales con operadores de telecomunicaciones.
En una realización particular de la solicitud P201200837, el módulo servidor de ticketing/pagos divide el derecho concedido de ticketing/pagos en varias particiones y 15 genera una credencial independiente para cada una de dichas particiones.
En una realización particular de la solicitud P201200837, se envía un primer conjunto de credenciales a la aplicación del teléfono móvil, y se envían nuevas credenciales a la aplicación del teléfono móvil a medida que sucesivamente sean solicitadas desde el 20 dispositivo móvil del usuario, hasta llegar al límite del derecho concedido relativo al uso de los servicios de ticketing/pagos. Así, el sistema puede monitorizar y limitar en cualquier momento el número de credenciales disponibles en el teléfono móvil para ticketing/pagos.
25
En una realización particular de la solicitud P201200837, al menos una credencial es deshabilitada en, o eliminada de, la aplicación del teléfono móvil mediante el envío de un mensaje de deshabilitación (o eliminación) desde el módulo servidor de ticketing/pagos a la aplicación del teléfono móvil del usuario.
30
En otra realización particular de la solicitud P201200837, el derecho a utilizar servicios de ticketing/pagos puede ser extendido si el usuario paga por ello, de modo que se pueden generar dinámicamente nuevas particiones de derechos de ticketing/pagos en el módulo de servidor ticketing/pagos.
35
En otra realización particular de la solicitud P201200837, la aplicación del teléfono móvil limita la solicitud de nuevas credenciales basándose en información acerca de las credenciales que ya están almacenadas en el teléfono móvil. De modo que si, por ejemplo, el número de credenciales está por debajo de un umbral, se recuerda al usuario que es necesaria conectividad de datos para tener disponibles nuevas credenciales. 40
En una realización particular de la solicitud P201200837, las credenciales de ticketing/pagos son bloqueadas en la aplicación del teléfono móvil después de la introducción errónea del Número de Identificación Personal un determinado número de veces, y se envía un mensaje de advertencia al módulo servidor de ticketing/pagos. 45
En una realización particular de la solicitud P201200837, el módulo servidor de ticketing/pagos bloquea el derecho de ticketing/pagos concedido después de un determinado número de verificaciones erróneas de una OTP recibida desde la aplicación del teléfono móvil, y se envía un mensaje de bloqueo de credenciales a la aplicación del 50 teléfono móvil.
Así, la entidad de transporte/pagos puede monitorizar inserciones erróneas de PIN que ocurren justo antes de un acceso a servicios de ticketing/intento de pago y aquellas que se producen dentro de un proceso de renovación de credenciales.
En una realización particular de la solicitud P201200837 para transacciones on-line de 5 pagos móviles sin contacto, una segunda parte de la credencial es calculada por la propia aplicación del teléfono móvil utilizando el valor de la transacción y el PIN del usuario como entradas para generar un resultado OTP (que constituye la segunda parte de la credencial). La primera y la segunda parte de la credencial se utilizan para la transacción móvil sin contacto, y es necesaria la verificación de dicha OTP por el módulo servidor de 10 pagos para aceptar o denegar la transacción. De ese modo, al aprovechar la ventaja de que el valor de la transacción es conocido por el banco emisor durante el proceso de la transacción online, el reto para esta OTP puede utilizarlo y todavía ser verificado como parte del proceso de autorización online.
15
Las mejoras en la solicitud de patente P201200837 que se introducen a través del presente certificado de adición se refieren a un método en el que el usuario paga por determinados productos y/o servicios en uno o varios comercios asociados, y el al menos un comercio transfiere parte de dichos importes al proveedor de servicios de ticketing/pagos para que este ofrezca al usuario determinados servicios de 20 ticketing/pagos. En esta realización el al menos un comercio gestiona por tanto el pago de dichos importes en nombre del usuario, en el contexto de un programa de fidelización del/los comercio(s).
Típicamente, los programas de fidelización de los comercios ofrecen al usuario puntos, 25 que se acumulan tras cada compra, y que solo se pueden canjear en un conjunto reducido de comercios asociados. La realización anterior permite al menos un comercio ofrecer a su cliente (como herramienta de fidelización) servicios de ticketing/pagos cuyo ámbito de utilización es mucho mayor que el del referido conjunto reducido de comercios.
30
En una implementación particular el usuario puede utilizar su aplicación de pagos del teléfono móvil para pagar en comercios hasta el importe acumulado por las distintas compras en el al menos un comercio. Notar que dichos pagos podrían ser realizados en multiplicidad de comercios sin necesidad de que hubiera acuerdo ninguno entre el al menos un comercio donde se han realizado las compras originales y los comercios en los 35 que se paga con estos importes acumulados.
En otra implementación particular el importe acumulado se utiliza para conceder al usuario determinados derechos de uso de servicios de ticketing. El usuario podrá por tanto utilizar su aplicación del teléfono móvil para acceder a los servicios de ticketing en 40 multiplicidades de puntos de acceso (por ejemplo en cualquiera de los autobuses de una ciudad).
En otra realización particular uno o varios comercios pagan al proveedor de servicios de ticketing/pagos por ciertos servicios de ticketing/pagos para el usuario, en el contexto de 45 un programa de fidelización del comercio. Asimismo, cuando el usuario paga por determinados productos y/o servicios en el al menos un comercio, el al menos un comercio transfiere parte de dichos importes al proveedor de servicios de ticketing/pagos para que este ofrezca al usuario determinados servicios de ticketing/pagos. Al igual que en el caso anterior, en esta realización el al menos un comercio gestiona por tanto el 50
pago por dichos servicios y de dichos importes en nombre del usuario, en el contexto de un programa de fidelización del/los comercio(s).
En una realización particular hay un número máximo predefinido de la primera parte de un conjunto de credenciales para pagos móviles off-line sin contacto que pueden ser 5 almacenadas en el teléfono móvil en un momento dado y, una vez transcurrido el periodo de vigencia de la primera parte de cada una de dichas credenciales, la aplicación de pagos del teléfono móvil limita los pagos móviles off-line sin contacto utilizando esa primera parte de cada una de dichas credenciales. Por tanto para realizar pagos móviles off-line sin contacto una vez que esa primera parte del conjunto de credenciales para 10 pagos móviles off-line sin contacto han caducado, el usuario debe insertar correctamente el valor del PIN, de tal forma que el módulo servidor de pagos envíe nuevas primeras partes de credenciales vigentes para pagos móviles off-line sin contacto al teléfono móvil registrado del usuario.
15
La solicitud de patente WO 03/038719 describe un método donde una tarjeta financiera virtual de un solo uso es generada offline para su uso para un pago por internet o una transacción sin contacto de tipo EMV-MSD (datos de banda magnética). Sin embargo, dicha solución no se puede utilizar para generar una tarjeta financiera virtual de un solo uso para una transacción sin contacto de tipo EMV chip & PIN debido al hecho de que se 20 debe calcular una clave derivada en el lado del servidor y enviarla a la aplicación del teléfono móvil antes del intento de pago (para evitar almacenar la clave del emisor en el teléfono móvil); así, la generación de una tarjeta financiera virtual de un solo uso para una transacción sin contacto de tipo EMV chip &PIN requiere manejar un proceso on/off line para cada tarjeta generada. La última realización descrita anteriormente cumple con el 25 requisito de la actualización online, pero ventajosamente también asocia una segunda parte de la credencial generada offline en el móvil al valor de la transacción y al PIN del usuario, creando así una solución de pago conveniente y muy robusta.
Por último, la solicitud de patente P201200837 describía además un sistema para 30 habilitar ticketing/pagos móviles sin contacto a través de una aplicación del teléfono móvil, comprendiendo dicho sistema:
- medios de registro para registrar usuarios en servicios de ticketing/pagos,
35
- medios de pago para permitir a un usuario pagar por servicios de ticketing/pagos,
- medios de generación de credenciales preparar en el módulo servidor de ticketing/ pagos, basándose en unos derechos de ticketing/pagos concedidos, unas credenciales de ticketing/pagos para su uso por el usuario registrado; y medios de 40 transmisión para enviarlos al teléfono móvil del usuario registrado; y medios de recepción y almacenamiento para recibir en el teléfono móvil las credenciales y almacenarlas para su uso en un sistema de ticketing para transporte sin contacto o, en caso de credenciales de pago, para su uso en pagos móviles sin contacto.
45
caracterizado porque dicho sistema comprende medios de procesamiento para asociar unívocamente cada credencial, que habilita parcialmente el teléfono móvil para el acceso a ticketing sin contacto o para pagos móviles sin contacto, al teléfono móvil del usuario registrado y a un código de activación; medios de procesamiento y comprobación que permiten habilitar el teléfono móvil para el acceso a ticketing sin contacto o para pagos 50 móviles sin contacto, que está también basada en la inserción por parte del usuario de un
Número de Identificación Personal (PIN) en la aplicación de ticketing/pagos del teléfono móvil; medios de procesamiento y trasmisión en la aplicación de ticketing/pagos del teléfono móvil para calcular una OTP y enviarla al módulo servidor de ticketing/pagos; y medios de procesamiento y verificación en el módulo servidor de ticketing/pagos para validar la OTP recibida. 5
Breve descripción de las figuras
En la siguiente descripción detallada de algunas realizaciones, aparecerán otras características y ventajas, y cada descripción hace referencia a las siguientes figuras: 10
La Figura 1.a es un diagrama esquemático que ilustra generalmente los principales bloques funcionales de la invención descrita en la solicitud P201200837, como una extensión de un sistema de transporte legacy;
15
La Figura 1.b es un diagrama esquemático que ilustra una realización de un sistema de ticketing de acuerdo con la invención descrita en la solicitud P201200837;
La Figura 1.c es un diagrama esquemático que ilustra otra realización de un sistema de ticketing de acuerdo con la invención descrita en la solicitud P201200837; 20
La Figura 2.a es un diagrama esquemático que ilustra en general los principales bloques de la invención descrita en la solicitud P201200837como una extensión de un sistema de pagos legacy;
25
La Figura 2.b es un diagrama esquemático que ilustra una realización de un sistema de pago de acuerdo con la invención descrita en la solicitud P201200837;
La Figura 2.c es un diagrama de flujo que ilustra parcialmente una realización de un método de acuerdo con la invención descrita en la solicitud P201200837; 30
Descripción detallada
La Figura 1.a es un diagrama esquemático que ilustra en general los principales bloques funcionales de la invención descrita en la solicitud P201200837 como una extensión de 35 un sistema legacy de transporte; esta figura muestra un sistema legacy 300a de transporte de un proveedor de servicios que soporta tarjetas inteligentes sin contacto (de modo que un usuario de este sistema puede utilizar una tarjeta inteligente sin contactos para acceder a servicios de transporte a través de dispositivos 400a de control de acceso de ticketing). Utilizando el canal 200a web de distribución, los usuarios pueden contratar 40 al menos un servicio, para obtener al menos un título de transporte (perfil) asociado a dicho al menos un servicio y cargar/recargar el al menos un título de transporte. En este ejemplo general, el canal web de distribución pertenece a un banco asociado y el usuario es también cliente de ese banco, de modo que puede pagar a través de la página web utilizando medios de firma electrónica proporcionados por el banco. 45
Cuando el usuario solicita, a través del canal web de distribución, los servicios móviles de ticketing de la presente invención (y paga por ellos de acuerdo con un método acordado entre, por ejemplo, el banco referido y el proveedor de servicios de ticketing), el sistema legacy de transporte reenvía la solicitud al módulo 500a servidor de ticketing de la 50 invención. Los bloques funcionales principales de este módulo se ilustran en esta figura.
La Figura 1.b muestra más detalles acerca de los bloques funcionales de la figura 1.a, y es un diagrama esquemático que ilustra una realización de un sistema de ticketing de acuerdo con la invención descrita en la solicitud P201200837 para habilitar servicios de ticketing móvil sin contacto a través de una aplicación en el teléfono móvil. La figura 1.b muestra el proceso desde el registro del usuario para servicios de ticketing móvil hasta la 5 provisión de dichos servicios.
En el paso (1), el usuario se descarga la aplicación de ticketing para el teléfono móvil, desde una tienda 700 de aplicaciones a su teléfono móvil dotado de tecnología sin contacto. 10
En el contexto de la invención descrita en la solicitud P201200837, el usuario paga por ciertos servicios de ticketing solicitados al proveedor de servicios. En el paso (2) de esta realización, el usuario solicita servicios de ticketing a través de un canal web de distribución y confirma el pago a través de este medio (por ejemplo, la misma situación 15 que la descrita en la figura 1.a; el canal web de distribución pertenece a un banco asociado). En el paso (3), la solicitud es enviada al sistema legacy de transporte y después reenviada al módulo servidor de ticketing. En esta realización, el módulo de registro del módulo servidor de ticketing recibe en el paso (3) una referencia de cliente y una referencia de derecho de transporte. Asociado al pago y al correspondiente derecho 20 concedido para utilizar ciertos servicios de ticketing, un módulo servidor de ticketing prepara credenciales de ticketing para su uso por el usuario registrado y las envía al teléfono móvil del usuario registrado, como se describe con mayor detalle a continuación.
En el paso (4) el módulo de registro del módulo servidor de ticketing asigna un derecho 25 de transporte al usuario (representado en la fig. 1.b como tarjeta "A" en el módulo servidor), basándose en la referencia de derecho de transporte recibida, y esa información se almacena en la base de datos del módulo servidor de ticketing (referencia de cliente  A). Luego, el módulo de registro solicita al módulo de credenciales de usuarios que genere una única credencial (representada en la fig. 1.b como tarjeta 30 "VMC(A)" en el módulo servidor) y ésta queda vinculada a la referencia de cliente de transporte y al derecho de transporte en la base de datos del módulo servidor de ticketing (referencia de cliente  A  VMC(A)). La credencial generada tiene una fecha de caducidad, de modo que no puede ser utilizada pasada dicha fecha.
35
En el paso (5), el módulo de credenciales de usuarios solicita al módulo de seguridad un código de activación; de modo que el módulo de seguridad genera un código de activación con una fecha de caducidad determinada y éste se almacena en la base de datos del módulo servidor de ticketing (referencia de cliente  A  VMC(A)  CA). Un código de activación no puede utilizarse después de la expiración de su fecha de 40 caducidad. En el paso (6), el código de activación es enviado desde el módulo de registro al sistema legacy de transporte, reenviado al canal web de distribución y mostrado al usuario.
En el paso (7), el usuario inserta el código de activación en la aplicación de ticketing del 45 teléfono móvil, y en el paso (8) el teléfono móvil envía al módulo de seguridad del módulo servidor de ticketing, por ejemplo vía https, el [código de activación y el hash (número de identificación del teléfono móvil & código de activación)].
En el paso (9), el módulo de seguridad comprueba si código de activación es correcto; en 50 caso afirmativo, el módulo de seguridad almacena el valor del hash en la base de datos
del módulo servidor de ticketing, de modo que los vínculos quedan como sigue: referencia de cliente  A  VMC(A)  CA  hash (ID&CA).
En el paso (10), la tarjeta "A" es pre-personalizada en la aplicación del teléfono móvil.
5
La pre-personalización hace referencia al paso anterior a la personalización; y la pre-personalización/personalización de la tarjeta "A" hace referencia a la pre- personalización/personalización de la aplicación de ticketing del teléfono móvil sin contacto de la invención para que funcione en "modo de emulación de tarjeta" para servicios móviles de ticketing sin contacto, de un modo equivalente a una aplicación de 10 ticketing basada en SIM funcionando en "modo de emulación de tarjeta" para servicios móviles de ticketing sin contacto (por ejemplo, emulando la tecnología subyacente de mifare DESFIRE). La personalización completa de la tarjeta "A" en la aplicación de ticketing del teléfono móvil requiere la descarga de credenciales desde el módulo servidor de ticketing a la aplicación de ticketing del teléfono móvil, como se describe con detalle a 15 continuación.
Cuando el paso (10) termina, el usuario ya está registrado en el sistema de la invención, pero aún está pendiente la recepción de credenciales en la aplicación de ticketing del teléfono móvil. En esta etapa, cada credencial está asociada de manera unívoca al 20 teléfono móvil del usuario registrado y a un código de activación, y habilita parcialmente el teléfono móvil para el acceso a ticketing sin contacto.
En el paso (11), se solicita al usuario que seleccione un Número de Identificación Personal (PIN) para los servicios de ticketing móvil sin contacto. El valor del PIN no se 25 almacena en la aplicación de ticketing del teléfono móvil, sino que se envía de manera segura en el paso (12) al módulo de seguridad del módulo servidor de ticketing, junto con una Contraseña de un Solo Uso (OTP) calculada utilizando el valor del PIN (y los valores del Código de Activación y el hash (CA&ID), para ser capaz de asignar en el módulo servidor de ticketing el PIN seleccionado y la OTP resultante a la referencia de cliente 30 correcta).
En el paso (13), el módulo de seguridad almacena el PIN en la base de datos del módulo servidor de ticketing, junto con las claves y parámetros para calcular un resultado OTP basado en el PIN. Todo este almacenamiento se indica en la base de datos de la figura 35 1.b como datos "OTP(PIN)". De modo que los vínculos y almacenamiento en la base de datos son ahora los siguientes: referencia de cliente  A  VMC(A)  CA  hash (ID&CA)  OTP(PIN).
Todavía en el paso (13), el módulo servidor de ticketing calcula un resultado OTP 40 utilizando el PIN del usuario y las claves y parámetros OTP almacenados, y compara el resultado con el recibido en el módulo de seguridad desde la aplicación de ticketing del teléfono móvil. Si la validación tiene éxito, entonces se pueden enviar credenciales de ticketing desde el módulo de credenciales de usuarios a la aplicación de ticketing del teléfono móvil. De ese modo, el módulo servidor de ticketing envía credenciales al 45 teléfono móvil del usuario registrado después de la validación con éxito de una Contraseña de un Solo Uso (OTP) recibida desde la aplicación de ticketing del teléfono móvil.
En el paso (14), las credenciales de ticketing son enviadas a la aplicación de ticketing del 50 teléfono móvil; el teléfono móvil del usuario recibe las credenciales y las almacena para
su uso en el sistema de transporte de ticketing sin contacto (de modo que el proceso de personalización de la tarjeta "A" queda entonces completado). En una realización, las credenciales han sido cifradas en el módulo de seguridad utilizando el PIN, de modo que para que la aplicación de ticketing del teléfono móvil pueda utilizar una credencial recibida y almacenada es necesario que el usuario inserte su código PIN. 5
En el paso (15), el usuario registrado puede utilizar el teléfono móvil para acceder a servicios de transporte. En el paso (15), el usuario debe insertar su código PIN en la aplicación de ticketing del teléfono móvil antes de tratar de acceder al sistema 400 de control de acceso de ticketing; de modo que la habilitación completa del teléfono móvil 10 para cada acceso a ticketing sin contacto también requiere que el usuario inserte un código de identificación personal (PIN) en la aplicación de ticketing del teléfono móvil.
En el paso (16), el módulo de credenciales de usuarios del módulo servidor de ticketing sabe que las credenciales de ticketing han sido recibidas y almacenadas con éxito en la 15 aplicación de ticketing del teléfono móvil (éxito en el paso 14), de modo que se envía la confirmación al distribuidor web, que realiza el cargo final del pago e informa al usuario (por ejemplo, a través de un SMS o una alerta en la página web del distribuidor).
La Figura 1.c es un diagrama esquemático que ilustra otra realización de un sistema de 20 ticketing de acuerdo con la invención descrita en la solicitud P201200837, para habilitar servicios de ticketing móvil sin contactos a través de una aplicación en el teléfono móvil; la figura 1.c muestra el proceso desde el registro del usuario para servicios de ticketing móvil hasta la provisión de dichos servicios.
25
Esta realización toma como referencia la de la figura 1.b con ciertas variaciones que se describen a continuación. Los pasos (1), (2) y (3) son los mismos que los de la figura 1.b.
Asociado al pago y al correspondiente derecho concedido para utilizar ciertos servicios de ticketing, un módulo servidor de ticketing prepara credenciales de ticketing para su uso 30 por el usuario registrado y las envía al teléfono móvil del usuario registrado, como se explica con mayor detalle a continuación. Sin embargo, en esta realización el módulo servidor de ticketing divide el derecho de ticketing concedido en varias particiones y genera una credencial independiente para cada una de dichas particiones.
35
De modo que en el paso (4) el módulo servidor de ticketing asigna un derecho de transporte al usuario (representado en la fig. 1.c como tarjeta "A" en el módulo de servidor), vinculado a un conjunto de credenciales (representadas en la fig. 1.c como tarjetas "VMC(A)1" a "VMC(A)n" en el módulo de servidor) y a una referencia de cliente de transporte, y almacena estos vínculos en la base de datos del módulo servidor de 40 ticketing (referencia de cliente  A  VMC(A)i, i = 1...n).
En el paso (5), se genera un código de activación y se almacena en la base de datos del módulo servidor de ticketing (referencia de cliente  A  VMC(A)i, i = 1...n  CA). En el paso (6), el Código de Activación es enviado al sistema legacy de transporte, reenviado 45 al canal web de distribución y mostrado al usuario.
Los pasos (7), (8) y (9) son los mismos que en la figura 1.b, de modo que los vínculos después del paso (9) son como sigue: referencia del cliente  A  VMC(A)i, i = 1...n  CA  hash(ID&CA). 50
En el paso (10), la tarjeta "A" es pre-personalizada en la aplicación del teléfono móvil.
Al igual que en la realización 1.b, la pre-personalización hace referencia al paso previo a la personalización; y la pre-personalización/personalización de la tarjeta "A" hace referencia a la pre-personalización/personalización de la aplicación de ticketing móvil sin 5 contacto de la invención para que funcione en "modo de emulación de tarjeta" para servicios de ticketing móvil sin contacto, de un modo equivalente a una aplicación de ticketing basada en SIM funcionando en "modo de emulación de tarjeta" para servicios de ticketing móvil sin contacto. La personalización completa de la tarjeta "A" en la aplicación de ticketing del teléfono móvil requiere la descarga de credenciales desde el módulo 10 servidor de ticketing a la aplicación de ticketing del teléfono móvil, como se describe a continuación.
Cuando termina el paso (10), el usuario ya está registrado en el sistema de la invención, pero aún está pendiente la recepción de credenciales en la aplicación de ticketing del 15 teléfono móvil. En esta etapa, cada credencial está unívocamente asociada al teléfono móvil del usuario registrado y a un código de activación, y habilita parcialmente al teléfono móvil para el acceso a servicios de ticketing sin contacto.
En el paso (11), se solicita al usuario que seleccione un Número de Identificación 20 Personal (PIN) para los servicios de ticketing móvil sin contacto. El valor del PIN no se almacena en la aplicación de ticketing del teléfono móvil, sino que se envía de manera segura en el paso (12) al módulo servidor de ticketing junto con una Contraseña de un Solo Uso (OTP) calculada utilizando el valor del PIN (y los valores del Código de Activación y del hash(CA&ID), para ser capaz de asignar en el módulo servidor de 25 ticketing el PIN seleccionado y la OTP resultante a la referencia de cliente correcta).
En el paso (13), el PIN es almacenado en la base de datos del módulo servidor de ticketing, junto con las claves y parámetros para calcular un resultado OTP basado en el PIN. Todo este almacenamiento es indicado en la base de datos de la figura 1.c como 30 datos "OTP(PIN)". De este modo, los vínculos y almacenamiento en la base de datos son ahora los siguientes: referencia de cliente  A  VMC(A)i, i = 1...n  CA  hash(ID&CA)  OTP(PIN).
Todavía en el paso (13), el módulo servidor de ticketing calcula un resultado OTP 35 utilizando el PIN del usuario y las claves y parámetros OTP almacenados, y compara el resultado con el recibido desde la aplicación de ticketing del teléfono móvil. Si la validación tiene éxito, entonces se pueden enviar credenciales de ticketing a la aplicación de ticketing del teléfono móvil. De ese modo, el módulo servidor de ticketing envía credenciales al teléfono móvil del usuario registrado después de haber validado con éxito 40 una Contraseña de un Solo Uso (OTP) recibida desde la aplicación de ticketing del teléfono móvil.
En el paso (14), se envía un primer conjunto de credenciales (por ejemplo, las credenciales desde i = 1 hasta i = j, j < n) a la aplicación de ticketing del teléfono móvil; el 45 teléfono móvil del usuario recibe las credenciales y las almacena para su uso en el sistema de ticketing para transporte sin contacto (de modo que el proceso de personalización de la tarjeta "A" para el uso de las credenciales i = 1 hasta i = j queda entonces completado).
50
El usuario registrado puede, en el paso (15), utilizar el teléfono móvil para acceder a los servicios de transporte. En el paso (15), el usuario inserta su código PIN en la aplicación de ticketing del teléfono móvil antes de tratar de acceder al sistema 400 de control de acceso de ticketing; de modo que la habilitación del teléfono móvil para cada acceso a ticketing sin contacto también requiere que el usuario inserte un código de identificación 5 personal (PIN) en la aplicación de ticketing del teléfono móvil.
En el paso (16), el módulo servidor de ticketing sabe que un primer conjunto de credenciales de ticketing han sido correctamente recibidas y almacenadas en la aplicación de ticketing del teléfono móvil (éxito en el paso 14), de modo que se envía una 10 confirmación al distribuidor web, que realiza el cargo final del pago e informa al usuario (por ejemplo, mediante un SMS o una alerta en la página web del distribuidor).
Se envían nuevas credenciales a la aplicación del teléfono móvil a medida que son sucesivamente solicitadas desde el dispositivo móvil del usuario, hasta el límite del 15 derecho concedido para utilizar los servicios de ticketing sin contacto.
En el paso (17), el módulo de credenciales de la aplicación de ticketing del teléfono móvil detecta que son necesarias nuevas credenciales y envía un mensaje request_credentials al módulo servidor de ticketing. Este mensaje contiene un resultado Contraseña de un 20 Solo Uso (OTP) que se ha calculado utilizando el valor del PIN (y los valores del Código de Activación y del hash(CA&ID), para poder asignar en el módulo servidor de ticketing el resultado OTP a la referencia de cliente correcta). En una realización, la aplicación calcula la OTP aprovechando que el usuario inserta su código PIN cuando trata de acceder al sistema de ticketing para transporte. En otra realización, se solicita al usuario 25 que inserte su código PIN para poder calcular la OTP.
Al igual que en la segunda parte del paso (13), el módulo servidor de ticketing calcula un resultado OTP utilizando el PIN del usuario y las claves y parámetros OTP almacenados, y compara el resultado con el recibido desde la aplicación de ticketing del teléfono móvil. 30 Si la validación tiene éxito, entonces se pueden enviar más credenciales de ticketing a la aplicación de ticketing del teléfono móvil. De ese modo, el módulo servidor de ticketing envía más credenciales al teléfono móvil del usuario registrado después de la validación con éxito de una Contraseña de un Solo Uso (OTP) recibida desde la aplicación de ticketing del teléfono móvil. 35
En el paso (18), se envía un nuevo conjunto de credenciales (por ejemplo, las credenciales desde i = j + 1 hasta i = k, k < n) a la aplicación de ticketing del teléfono móvil; el teléfono móvil del usuario recibe las credenciales y las almacena para su uso en el sistema de ticketing para transporte sin contacto (de modo que el proceso de 40 personalización de la tarjeta "A" para utilizar las credenciales i = j + 1 hasta i = k queda entonces completado).
En esta realización, se repiten los pasos (17), (13) y (18) hasta que las credenciales hasta la credencial i = n se han enviado al teléfono móvil y se han recibido y almacenado 45 en la aplicación de ticketing del teléfono móvil para su uso en el sistema de ticketing para transporte sin contacto.
Todas esas credenciales, hasta la credencial n, pueden ser utilizadas en el paso (15) por el usuario registrado para acceder a los servicios de transporte. En el paso (15), el 50 usuario inserta su código PIN en la aplicación de ticketing del teléfono móvil antes de
intentar acceder al sistema 400 de control de acceso de ticketing; así, la habilitación del teléfono móvil para cada acceso a ticketing sin contacto también requiere que el usuario inserte un código de identificación personal (PIN) en la aplicación de ticketing del teléfono móvil.
5
El derecho para utilizar los servicios de ticketing se puede extender si el usuario paga por ello, de modo que se pueden generar dinámicamente nuevas particiones del derecho de ticketing en el módulo servidor de ticketing. Así, por ejemplo después de una nueva ejecución del proceso de los pasos (2) y (3), se pueden generar las particiones i = n + 1 hasta i = m en una nueva ejecución del proceso del paso (4), y las credenciales desde 10 i = n + 1 hasta i = m pueden ser enviadas sucesivamente al teléfono móvil y recibidas y almacenadas en la aplicación de ticketing del teléfono móvil de acuerdo con los pasos repetidos (17), (13) y (18) para su uso en el sistema de ticketing para transporte sin contacto.
15
En un ejemplo particular, el usuario paga 50 € a través del canal web de distribución y el derecho de transporte concedido le permite acceder a una Zona A de los servicios de ticketing para transporte en autobús durante el mes de Abril (30 días). El módulo servidor de ticketing prepara la credencial 1 para su uso el primer día del mes... y la credencial 30 para su uso el último día del mes. Las primeras cinco credenciales son enviadas a la 20 aplicación del teléfono móvil antes de empezar el mes, después de recibir un valor correcto de la OTP; en caso de que en el teléfono móvil aún haya credenciales disponibles para cuatro días restantes, el mensaje request_credentials se envía para solicitar credenciales para 1 día extra, aprovechando que el usuario inserta el PIN para acceder a los servicios de ticketing móvil; en caso de que haya credenciales disponibles 25 para tres días restantes, la solicitud será para 2 días extra, aprovechando que el usuario inserta el PIN para acceder a los servicios de ticketing móvil; en caso de que haya credenciales disponibles para 2 días o 1 solo día, se solicitará al usuario que inserte su código PIN en la aplicación de ticketing del teléfono móvil para solicitar, recibir y almacenar nuevas credenciales (hasta el limite de credenciales para 5 días, disponibles 30 en el teléfono móvil).
En otro ejemplo particular, el usuario paga 40 € a través del canal web de distribución y el derecho de transporte concedido le permite 40 viajes en autobús dentro de la Zona A. Las primeras cinco credenciales, una por viaje, son enviadas a la aplicación del teléfono 35 móvil después de recibir un valor de la OTP correcto; en caso de que en el teléfono móvil haya todavía credenciales disponibles para cuatro viajes restantes, el mensaje de request_credentials se envía para solicitar credenciales para 1 viaje extra, aprovechando que el usuario inserta el PIN para acceder a los servicios de ticketing móvil; en caso de que haya disponibles credenciales para tres viajes restantes, la solicitud será para 2 40 viajes extra, aprovechando que el usuario inserta el PIN para acceder a los servicios de ticketing móvil; en caso de que haya credenciales disponibles para 2 viajes o sólo 1 viaje, se solicitará al usuario que inserte su código PIN en la aplicación de ticketing del teléfono móvil para solicitar, recibir y almacenar nuevas credenciales (hasta el límite de credenciales para 5 viajes, disponibles en el teléfono móvil). 45
De modo que la aplicación del teléfono móvil limita la solicitud de nuevas credenciales basándose en información acerca de las credenciales que están ya almacenadas en el teléfono móvil. Ventajosamente, esta característica permite al proveedor de servicios de ticketing monitorizar y controlar el número de credenciales disponibles en el teléfono 50
móvil del usuario, manteniendo así parte del derecho concedido en el módulo servidor de ticketing.
El módulo de operaciones (o el de seguridad) en el módulo servidor de ticketing puede solicitar que al menos una credencial sea deshabilitada (o eliminada) de la aplicación del 5 teléfono móvil mediante el envío de un mensaje de deshabilitación (o eliminación) desde el módulo de servidor de ticketing a la aplicación del teléfono móvil del usuario. De ese modo, el proveedor de servicios de ticketing todavía puede gestionar el ciclo de vida de las credenciales cuando ya están disponibles en la aplicación del teléfono móvil.
10
En una realización descrita en la solicitud P201200837, las credenciales de ticketing se bloquean en la aplicación del teléfono móvil después de que se haya producido un número determinado de inserciones erróneas del Número de Identificación Personal, y se envía un mensaje de advertencia al módulo servidor de ticketing. En otra realización, el modulo servidor de ticketing bloquea el derecho de ticketing concedido después de que 15 se produzca un número determinado de verificaciones erróneas de una OTP recibida desde la aplicación del teléfono móvil, y se envía un mensaje de bloqueo de credenciales a la aplicación del teléfono móvil. Así, el proveedor de servicios de ticketing tiene disponibles herramientas de gestión de seguridad y del PIN, tanto en la aplicación como en el lado del módulo servidor de ticketing. 20
El módulo de seguridad comprueba periódicamente la validez de los códigos de activación y las credenciales, de modo que no se pueden utilizar después de la expiración. En un ejemplo, si se utiliza un código de activación o credencial después de su fecha de caducidad, se envía un mensaje al sistema legacy de transporte para 25 informar de este evento.
La Figura 2.a es un diagrama esquemático que ilustra generalmente los principales bloques funcionales de la invención descrita en la solicitud P201200837 como una extensión de un sistema legacy de pagos; esta figura muestra un sistema 3000a legacy 30 de pagos de un de un banco (/entidad de medios de pago) proveedor de servicios, que soporta tarjetas inteligentes de contacto & sin contacto para pagos (de modo que un usuario de este sistema puede tener disponible una tarjeta inteligente financiera de contacto/sin contacto para pagar en establecimientos comerciales equipados con un Terminal 4000a Punto de Venta de contacto/sin contacto). Los usuarios 1000a pueden 35 solicitar, a través de un canal 2000a web de distribución, tarjetas inteligentes financieras para pagos a débito/crédito/prepago. En este ejemplo, el canal web de distribución pertenece al banco que posee el sistema legacy de pagos y el usuario también es cliente de este banco, de modo que puede confirmar el pago de tarjetas financieras solicitadas y más tarde activarlas a través de la página web, utilizando un medio de firma electrónica 40 proporcionado por el banco.
Cuando el usuario solicita, a través del canal web de distribución, los servicios móviles de pago relacionados con la presente invención (es decir, la capacidad para utilizar al menos una tarjeta financiera móvil para pagos móviles sin contacto) y paga por ellos (el usuario 45 paga por la capacidad que solicita) utilizando el medio de firma electrónica del banco, el sistema legacy de pagos reenvía la solicitud al módulo 5000a servidor de pagos de la invención. Los principales bloques funcionales de este módulo se ilustran en esta figura.
La figura 2.b proporciona más detalles acerca de los bloques funcionales de la figura 2.a 50 y es un diagrama esquemático que ilustra una realización de un sistema de pagos de
acuerdo con la invención descrita en la solicitud P201200837, para habilitar pagos móviles sin contacto a través de una aplicación de teléfono móvil; la figura 2b muestra el proceso desde el registro del usuario para los servicios móviles de pago hasta la provisión de dichos servicios.
5
En el paso (1), el usuario descarga en su teléfono móvil dotado de tecnología sin contacto la aplicación de pagos para teléfono móvil, desde una tienda 7000 de aplicaciones.
En el contexto de la invención, el usuario paga por ciertos servicios de pago solicitados al proveedor de servicios. En el paso (2) de esta realización, el usuario solicita servicios de 10 pago (es decir, solicita la capacidad para utilizar al menos una tarjeta financiera móvil para pagos móviles sin contacto) a través de un canal web de distribución y confirma el pago a través de ese medio (el usuario paga por la capacidad solicitada). En esta realización aplica el mismo escenario que el descrito en la figura 2.a: el canal web de distribución pertenece al banco. En el paso (3), la solicitud es enviada al sistema legacy 15 de pagos y luego reenviada al módulo servidor de pagos.
Asociado al pago y al correspondiente derecho concedido para utilizar ciertos servicios de pago, un módulo servidor de pagos prepara credenciales de pago para su uso por el usuario registrado y las envía al teléfono móvil del usuario registrado, como se detalla a 20 continuación. En esta realización, el módulo servidor de pagos divide el derecho de pagos concedido en varias particiones y genera una credencial independiente para cada una de dichas particiones.
En el paso (4), el módulo servidor de pagos asigna un derecho de pagos al usuario 25 (representado en la fig. 2.b como tarjeta "A" en el módulo servidor), vinculado a un conjunto de credenciales (representadas en la fig. 2.b como tarjetas "VMC(A)1" a "VMC(A)n" en el módulo servidor) y a una referencia de cliente de pagos, y almacena estos vínculos en la base de datos del módulo servidor de pagos (referencia de cliente  A  VMC(A)i, i = 1...n). 30
En el paso (5), se genera un código de activación y se almacena en la base de datos del módulo servidor de pagos (referencia de cliente  A  VMC(A)i, i = 1...n  CA). En el paso (6), el Código de Activación es enviado al sistema legacy de pagos, reenviado al canal web de distribución y mostrado al usuario. 35
En el paso (7), el usuario inserta el código de activación en la aplicación de pagos del teléfono móvil, y en el paso (8) el teléfono móvil envía al módulo servidor de pagos, por ejemplo vía https, el [código de activación y el hash(número de identificación del teléfono móvil & código de activación)]. 40
En el paso (9), el valor del hash es almacenado en el módulo servidor de pagos, de modo que los vínculos quedan ahora como sigue: referencia de cliente  A  VMC(A)i, i = 1... n  CA hash(ID&CA).
45
En el paso (10) se pre-personaliza la tarjeta "A" en la aplicación del teléfono móvil.
La pre-personalización hace referencia al paso anterior a la personalización; y la pre-personalización/personalización de la tarjeta "A" hace referencia a la pre- personalización/personalización de la aplicación de pagos móvil sin contacto de la 50 invención para que funcione en "modo de emulación de tarjeta" para servicios de pagos
móviles sin contacto, de un modo equivalente a una aplicación de pagos basada en tarjeta SIM funcionando en "modo de emulación de tarjeta" para servicios de pagos móviles sin contacto (como por ejemplo pagos de tipo EMV chip & PIN). La personalización completa de la tarjeta "A" en la aplicación de pagos del teléfono móvil requiere la descarga de credenciales desde el módulo servidor de pagos a la aplicación 5 de pagos del teléfono móvil, como se describe a continuación.
Cuando termina el paso (10), el usuario ya está registrado en el sistema de la invención, pero aún está pendiente la recepción de credenciales en la aplicación de pagos del teléfono móvil. En esta etapa, cada credencial está asociada unívocamente al teléfono 10 móvil del usuario registrado y a un código de activación, y habilita parcialmente el teléfono móvil para servicios de pago sin contacto en establecimientos comerciales.
En el paso (11), se solicita al usuario que seleccione un Número de Identificación Personal (PIN) para servicios de pago móviles sin contacto. El valor del PIN no es 15 almacenado en la aplicación de pagos del teléfono móvil, sino que es enviado de manera segura en el paso (12) al módulo servidor de pagos, junto con una Contraseña de un Solo Uso (OTP) calculada utilizando el valor el PIN (y los valores del Código de Activación y del hash(CA&ID), para poder asignar en el módulo servidor de pagos el PIN seleccionado y el resultado OTP a la correcta referencia de cliente). 20
En el paso (13) el PIN se almacena en la base de datos del módulo servidor de pagos, junto con las claves y parámetros para calcular una OTP basada en el PIN. Todo este almacenamiento es indicado en la base de datos de la figura 1.c como datos "OTP(PIN)". De modo que los vínculos y almacenamiento en la base de datos son ahora los 25 siguientes: referencia de cliente  A  VMC(A)i, i = 1...n  CA  hash(ID&CA)  OTP(PIN).
Todavía en el paso (13), el módulo servidor de pagos calcula un resultado OTP utilizando el PIN del usuario y las claves y parámetros OTP almacenados, y compara el resultado 30 con el recibido de la aplicación de pagos del teléfono móvil. Si la validación tiene éxito, entonces se pueden enviar credenciales de pago a la aplicación de pagos del teléfono móvil. De modo que el módulo servidor de pagos envía credenciales al teléfono móvil del usuario registrado después de la correcta validación de una Contraseña de un Solo Uso (OTP) recibida desde la aplicación de pagos del teléfono móvil. 35
En el paso (14), un primer conjunto de credenciales (por ejemplo, las credenciales desde i = 1 hasta i = j, j < n) son enviadas a la aplicación de pagos del teléfono móvil; el teléfono móvil del usuario recibe las credenciales y las almacena para su uso en establecimientos comerciales dotados de Terminales Punto de Venta sin contacto (de modo que el proceso 40 de personalización de la tarjeta "A" para el uso de las credenciales i = 1 hasta i = j queda entonces completado).
El usuario registrado puede, en el paso (15), utilizar el teléfono móvil para pagar en comercios dotados de Terminales Punto de Venta sin contacto. En el paso (15), el 45 usuario inserta su código PIN en la aplicación de pagos del teléfono móvil antes de intentar pagar en el Terminal 4000 Punto de Venta sin contacto; de modo que la habilitación completa del teléfono móvil para cada pago móvil sin contacto requiere además que el usuario inserte un código de identificación personal (PIN) en la aplicación de pagos del teléfono móvil. 50
En el paso (16), el módulo servidor de pagos sabe que un primer conjunto de credenciales de pago ha sido correctamente recibido y almacenado en la aplicación de pagos del teléfono móvil (éxito en el paso 14), de modo que se envía una confirmación al distribuidor web, que realiza el cargo final del pago e informa al usuario (por ejemplo, a través de un SMS o una alerta en la página web del distribuidor). 5
Se envían nuevas credenciales a la aplicación del teléfono móvil a medida que son sucesivamente solicitadas desde el dispositivo móvil del usuario, hasta el límite del derecho concedido para el uso de los servicios de pago sin contacto.
10
En el paso (17), la aplicación de pagos del teléfono móvil detecta que son necesarias nuevas credenciales y envía un mensaje de request_credentials al módulo servidor de pagos. Este mensaje contiene un resultado Contraseña de un Solo Uso (OTP), que ha sido calculada utilizando el valor PIN (y los valores del Código de Activación y el hash(CA&ID), para ser capaz de asignar en el módulo servidor de pagos el resultado 15 OTP a la referencia de cliente correcta). En una realización, la aplicación calcula la OTP aprovechando que el usuario inserta su código PIN cuando trata de realizar un pago móvil sin contacto en un establecimiento comercial. En otra realización, se solicita al usuario que inserte su código PIN para poder calcular la OTP.
20
Al igual que en la segunda parte del paso (13), el módulo servidor de pagos calcula un resultado OTP utilizando el PIN del usuario y las claves y parámetros OTP almacenados, y compara el resultado con el recibido desde la aplicación de pagos del teléfono móvil. Si la validación tiene éxito, entonces se pueden enviar más credenciales de pago a la aplicación de pagos del teléfono móvil. De modo que el módulo servidor de pagos envía 25 más credenciales al teléfono móvil del usuario registrado después de la validación con éxito de una Contraseña de un Solo Uso (OTP) recibida desde la aplicación de pagos del teléfono móvil.
En el paso (18), se envía un nuevo conjunto de credenciales (por ejemplo, las 30 credenciales desde i = j + 1 hasta i = k, k < n) a la aplicación de pagos del teléfono móvil; el teléfono móvil del usuario recibe las credenciales y las almacena para su uso en pagos móviles sin contacto (de modo que el proceso de personalización de la tarjeta "A" para el uso de las credenciales i = j + 1 hasta i = k queda entonces completado).
35
En esta realización, los pasos (17), (13) y (18) se repiten hasta que las credenciales hasta la credencial i = n son enviadas al teléfono móvil, y son recibidas y almacenadas en la aplicación de pagos del teléfono móvil para su uso en pagos móviles sin contacto.
Todas estas credenciales, hasta la credencial n, pueden ser utilizadas en el paso (15) por 40 el usuario registrado para pagos móviles sin contacto. En el paso (15), el usuario inserta su código PIN en la aplicación de pagos del teléfono móvil antes de intentar pagar en un Terminal Punto de Venta de un establecimiento comercial; de modo que la habilitación del teléfono móvil para cada pago móvil sin contacto también requiere que el usuario inserte un código de identificación personal (PIN) en la aplicación de pagos del teléfono 45 móvil.
El derecho a utilizar los servicios de pagos puede ser extendido si el usuario paga por ello, de modo que se pueden generar dinámicamente nuevas particiones del derecho de pagos en el módulo servidor de pagos. Por tanto, después de una nueva ejecución de los 50 pasos (2) y (3), se pueden generar particiones desde i = n + 1 hasta i = m en un nuevo
proceso de ejecución del paso (4), y las credenciales desde i = n + 1 hasta i = m pueden ser sucesivamente enviadas al teléfono móvil y recibidas y almacenadas en la aplicación de pagos del teléfono móvil de acuerdo con los pasos repetidos (17), (13) y (18) para su uso en pagos móviles sin contacto.
5
En un ejemplo particular, el usuario paga 20 € a través del canal web de distribución y el derecho de pagos concedido le habilita para llevar a cabo operaciones de pago sin contacto, a través de su aplicación móvil sin contacto, de acuerdo con un esquema tradicional de producto de crédito, en Terminales Punto de Venta de comercios durante un ano. El módulo servidor de pagos prepara credenciales para su uso durante el periodo 10 anual, cada una de las cuales es válida para un único intento de pago. En primer lugar, se envían cinco credenciales a la aplicación del teléfono móvil al comenzar el período, después de recibir un valor OTP correcto; en caso de que en el teléfono móvil haya todavía credenciales disponibles para cuatro operaciones de pago restantes, se envía el mensaje request_credentials para solicitar credenciales para 1 pago extra, aprovechando 15 que el usuario inserta el PIN para un intento de pago móvil sin contacto en un establecimiento comercial; en caso de que haya credenciales disponibles para tres operaciones de pago restantes, se hará una solicitud de 2 pagos extra, aprovechando que el usuario inserta el PIN para un intento de pago móvil sin contacto en un establecimiento comercial; en caso de que haya disponibles credenciales para 2 o sólo 20 para una operación de pago, se solicitará al usuario que inserte su código PIN en la aplicación de pagos del teléfono móvil para solicitar, recibir y almacenar nuevas credenciales (hasta el límite de 5 credenciales de pago, disponibles en el teléfono móvil).
De modo que la aplicación del teléfono móvil limita la solicitud de nuevas credenciales 25 basándose en información acerca de las credenciales que ya están almacenadas en el teléfono móvil. Ventajosamente, esta característica permite al proveedor de servicios de pago monitorizar y controlar el número de credenciales disponibles en el teléfono móvil del usuario, manteniendo así parte del derecho concedido en el módulo servidor de pagos. 30
El módulo de seguridad (o el de operaciones) del módulo servidor de pagos puede solicitar que al menos una credencial sea deshabilitada (o eliminada) de la aplicación del teléfono móvil mediante el envío de un mensaje de deshabilitación (o eliminación) desde el módulo servidor de pagos a la aplicación del teléfono móvil del usuario. De ese modo, 35 el proveedor de servicios de pagos todavía puede gestionar el ciclo de vida de las credenciales cuando ya están disponibles en la aplicación del teléfono móvil.
En una realización descrita en la solicitud P201200837, las credenciales de pago son bloqueadas en la aplicación del teléfono móvil después de un número determinado de 40 intentos erróneos de introducir el Número de Identificación Personal, y se envía un mensaje de advertencia al módulo servidor de pagos. En otra realización, el módulo servidor de pagos bloquea el derecho de pagos concedido después de un número determinado de verificaciones incorrectas de una OTP recibida desde la aplicación del teléfono móvil, y se envía un mensaje de bloqueo de credenciales a la aplicación del 45 teléfono móvil. Por tanto, el proveedor de servicios de pago tiene herramientas de gestión de la seguridad y del PIN disponibles tanto en la aplicación como en el lado del módulo servidor de pagos.
La figura 2.c es un diagrama de flujo que ilustra parcialmente una realización de un 50 método de acuerdo con la invención descrita en la solicitud P201200837.
En esta realización, para transacciones on-line de pagos móviles sin contacto, una segunda parte de la credencial de pago es calculada por la propia aplicación de pagos del teléfono móvil, utilizando el valor de la transacción y el PIN del usuario como entradas para generar un resultado OTP (que constituye la segunda parte de la credencial). La primera y la segunda partes de la credencial se utilizan para la transacción de pago móvil 5 sin contacto y la verificación de dicha OTP por el módulo servidor de pagos es necesaria para aceptar o denegar la transacción.
En un entorno EMV chip & PIN, se asigna un número PAN a una tarjeta EMV proporcionada al usuario (tarjeta (A)). Esta tarjeta incluye otro conjunto de datos que son 10 parte de la propia credencial: fecha de caducidad (FC), CW y clave derivada para el cálculo del criptograma.
En esta realización, la credencial de pagos para la tarjeta VMC(A)¡ es generada primero en el módulo servidor de pagos, de modo que el PAN, FC, CW y la clave derivada son 15 calculados en el lado del servidor y enviados, junto con el BIN, a la aplicación de pagos móvil. En un ejemplo particular, el número PAN es generado utilizando el hash(ID&CA) y la referencia de cliente como datos de entrada.
Durante el proceso de pago online que utiliza esta credencial de pago VMC(A)¡, el PIN es 20 insertado en la aplicación de pagos del teléfono móvil. En esta realización, el valor de la transacción (la cantidad a pagar) también es insertado por el usuario en la aplicación de pagos del teléfono móvil, de modo que tanto el valor de la transacción como el PIN del usuario son entradas que se usan para generar un resultado OTP (que constituye la segunda parte de la credencial). En un ejemplo particular, la OTP es un resultado de 7 25 dígitos, FC' (4 dígitos) y CW' (3 dígitos). La FC' será una fecha de caducidad válida en el sistema de medios de pago.
El intento de transacción de pago sin contacto se lleva a cabo utilizando el BIN/PAN/FC'/CW' y el criptograma como credenciales, de modo que la primera parte de 30 la credencial ha sido calculada en el lado del servidor y la segunda parte en la aplicación de pagos del teléfono móvil, utilizando el PIN y el valor de la transacción como datos de entrada.
El módulo servidor de pagos procesa el PAN recibido y obtiene datos de referencia de 35 cliente & dispositivo, de modo que puede asignar la transacción a una cuenta particular (PIN, claves OTP, etc.). En el contexto de una transacción online, el valor de la transacción es conocido en el lado del servidor y el PIN está almacenado en el módulo servidor de pagos, de modo que la OTP puede ser verificada por el módulo servidor de pagos. Si la verificación de la OTP tiene éxito, se validan las credenciales y se puede 40 autorizar la transacción en el host del banco como si fuese una transacción con tarjeta (A). Los mensajes de respuesta al banco adquiriente, sin embargo, se referirán a una transacción VMC(A)i.
Ventajosamente, calcular parte de la credencial en la aplicación de pagos del teléfono 45 móvil dota al usuario y al sistema de un nivel de seguridad más elevado en el ciclo de vida de las credenciales de pago.
Aunque la invención de la solicitud P201200837 se ha descrito con detalle por motivos de ilustración, se entiende que dichos detalles se muestran únicamente con ese objeto, y 50 que los expertos en la materia podrán realizar variaciones en el mismo sin salirse del
ámbito de la invención. Por tanto, aunque las realizaciones preferidas del método y del sistema móvil se han descrito con referencia al entorno en el que fueron desarrollados, son simplemente ilustrativos de los principios de la invención. Se pueden concebir otras realizaciones y configuraciones sin salirse del ámbito de las reivindicaciones adjuntas.
5
Además, aunque las realizaciones de la invención descritas con referencia a las figuras comprenden aparatos de ordenador (se entiende por "ordenador'' cualquier medio de procesamiento electrónico capaz de ejecutar una secuencia de operaciones codificadas como un programa) y procesos llevados a cabo en aparatos de ordenador, la invención también se extiende a programas de ordenador, en particular programas de ordenador en 10 o sobre una portadora, adaptados para llevar a la práctica la invención. El programa puede estar en la forma de código fuente, código objeto, o un código intermedio entre objeto y fuente, como por ejemplo en forma parcialmente compilada, o en cualquier otra forma adecuada para su uso en la implementación de procesos de acuerdo con la invención. La portadora puede ser una entidad o dispositivo capaz de almacenar el 15 programa. Por ejemplo, la portadora puede comprender un medio de almacenamiento, como un ROM, por ejemplo un CD ROM o un ROM semiconductor, o un medio de almacenamiento magnético, por ejemplo un disco flexible o un disco duro. Además, la portadora puede ser una portadora transmisible, como una señal eléctrica u óptica que pueda transportarse a través de un cable eléctrico u óptico o por radio u otros medios. 20 Cuando el programa está incorporado en una señal que pueda transportarse directamente por cable o por otro dispositivo o medio, la portadora puede estar constituida por dicho cable o dicho otro dispositivo o medio. Alternativamente, la portadora puede ser un circuito integrado en el que está embebido el programa, estando adaptado el circuito para llevar a cabo, o para su uso llevar a cabo, los procesos 25 correspondientes.

Claims (6)

  1. REIVINDICACIONES
    1. Nuevas mejoras introducidas en la solicitud de patente número P201200837 titulada "Método para habilitar ticketing/pagos móviles sin contacto mediante una aplicación de teléfono móvil", comprendiendo el método los siguientes pasos: 5
    (a) un usuario paga a un proveedor de servicios por unos servicios de ticketing/pagos, obteniendo un código de activación;
    (b) asociado al pago y a un correspondiente derecho concedido para utilizar los 10 servicios de ticketing/pagos correspondientes, un módulo servidor de ticketing/pagos prepara credenciales de ticketing/pagos para su uso por el usuario y las envía al teléfono móvil del usuario;
    (c) el teléfono móvil del usuario recibe las credenciales y las almacena para su uso en 15 un sistema de ticketing para transporte sin contacto, en caso de credenciales de ticketing, o para su uso en pagos móviles sin contacto, en el caso de credenciales de pago;
    donde cada credencial preparada está unívocamente asociada al teléfono móvil del 20 usuario registrado y a un código de activación, y habilita parcialmente el teléfono móvil para el acceso a ticketing sin contacto, en caso de credenciales de ticketing, o para pagos móviles sin contacto, en caso de credenciales de pagos; donde la habilitación del teléfono móvil para cada acceso a ticketing sin contacto o pago móvil sin contacto también requiere que el usuario inserte un número de identificación personal en la 25 aplicación de ticketing/pagos del teléfono móvil; y donde el módulo servidor de ticketing/pagos envía credenciales al teléfono móvil del usuario registrado después de la validación con éxito de una Contraseña de un Solo Uso (OTP) recibida desde la aplicación de ticketing/pagos del teléfono móvil,
    30
    caracterizado por que el usuario paga por determinados productos y/o servicios en uno o varios comercios asociados, y el al menos un comercio transfiere parte de dichos importes al proveedor de servicios de ticketing/pagos, que asocia los importes transferidos a las credenciales que habilitan parcialmente el teléfono móvil para acceso a ticketing sin contacto, en caso de credenciales de ticketing, o para pagos móviles sin 35 contacto, en caso de credenciales de pagos.
  2. 2. Nuevas mejoras introducidas en la solicitud de patente número P201200837 titulada "Método para habilitar ticketing/pagos móviles sin contacto mediante una aplicación de teléfono móvil" de acuerdo con la reivindicación 1, donde el uno o varios comercios pagan 40 al proveedor de servicios de ticketing/pagos por ciertos servicios de ticketing/pagos para el usuario.
  3. 3. Nuevas mejoras introducidas en la solicitud de patente número P201200837 titulada "Método para habilitar ticketing/pagos móviles sin contacto mediante una aplicación de 45 teléfono móvil" de acuerdo con cualquiera de las reivindicaciones 1 a 2, donde hay un número máximo predefinido de la primera parte de un conjunto de credenciales para pagos móviles off-line sin contacto que pueden ser almacenadas en el teléfono móvil en un momento dado y, una vez transcurrido el periodo de vigencia de la primera parte de cada una de dichas credenciales, la aplicación de pagos del teléfono móvil limita los 50
    pagos móviles off-line sin contacto utilizando esa primera parte de cada una de dichas credenciales.
  4. 4. Programa de ordenador que comprende instrucciones de programa para provocar que un ordenador lleve a cabo el método de cualquiera de las reivindicaciones 1-3. 5
  5. 5. Programa de ordenador de acuerdo con la reivindicación 4, incorporado en un medio de almacenamiento.
  6. 6. Programa de ordenador de acuerdo con la reivindicación 4, incorporado en una señal 10 portadora.
ES201300717A 2012-08-21 2013-08-01 Método y sistema para habilitar ticketing/pagos móviles sin contacto por medio de una aplicación de teléfono móvil, mejorados Active ES2527884B1 (es)

Priority Applications (16)

Application Number Priority Date Filing Date Title
ES201300717A ES2527884B1 (es) 2013-08-01 2013-08-01 Método y sistema para habilitar ticketing/pagos móviles sin contacto por medio de una aplicación de teléfono móvil, mejorados
EP13748010.9A EP2888703A1 (en) 2012-08-21 2013-08-07 Method and system to enable mobile contactless ticketing/payments via a mobile phone application
CA2882986A CA2882986C (en) 2012-08-21 2013-08-07 Method and system to enable mobile contactless ticketing/payments via a mobile phone application
PE2015000237A PE20150704A1 (es) 2012-08-21 2013-08-07 Metodo y sistema para habilitar ticketing/pagos moviles sin contacto por medio de una aplicacion de telefono movil
PCT/EP2013/066540 WO2014029620A1 (en) 2012-08-21 2013-08-07 Method and system to enable mobile contactless ticketing/payments via a mobile phone application
CN201811627095.4A CN110110515A (zh) 2012-08-21 2013-08-07 通过手机应用实现移动非接触式票务/支付的方法和系统
PE2016000050A PE20160442A1 (es) 2012-08-21 2013-08-07 Metodo y sistema para habilitar ticketing/pagos moviles sin contacto por medio de una aplicacion movil
CN201380043046.5A CN104871189B (zh) 2012-08-21 2013-08-07 通过手机应用实现移动非接触式票务/支付的方法和系统
JP2015527844A JP6711623B2 (ja) 2012-08-21 2013-08-07 移動体電話アプリケーションを介した移動体電話による非接触発券／支払を可能にするための方法及びシステム
KR1020157005496A KR20150046080A (ko) 2012-08-21 2013-08-07 이동전화 애플리케이션을 통해 모바일 비접촉 발권/결제를 가능하게 하는 방법 및 시스템
MX2015002243A MX366316B (es) 2012-08-21 2013-08-07 Metodo y sistema para habilitar ticketing/pagos moviles sin contacto por medio de una aplicacion de telefono movil.
RU2015109902A RU2651179C2 (ru) 2012-08-21 2013-08-07 Способ и система обеспечения мобильной бесконтактной покупки билетов/обработки платежей через приложение мобильного телефона
US14/422,555 US20150206129A1 (en) 2012-08-21 2013-08-07 Method and System to Enable Mobile Contactless Ticketing/Payments Via a Mobile Phone Application
CL2015000413A CL2015000413A1 (es) 2012-08-21 2015-02-20 Método y sistema para habilitar ticketing/pagos móviles sin contacto por medio de una aplicación de teléfono móvil
ZA2015/01925A ZA201501925B (en) 2012-08-21 2015-03-20 Method and system to enable mobile contactless ticketing/payments via a mobile phone application
US15/783,297 US20180053179A1 (en) 2012-08-21 2017-10-13 Method and System to Enable Mobile Contactless Ticketing/Payments Via a Mobile Phone Application

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
ES201300717A ES2527884B1 (es) 2013-08-01 2013-08-01 Método y sistema para habilitar ticketing/pagos móviles sin contacto por medio de una aplicación de teléfono móvil, mejorados

Publications (2)

Publication Number Publication Date
ES2527884A1 ES2527884A1 (es) 2015-02-02
ES2527884B1 true ES2527884B1 (es) 2015-09-29

Family

ID=52395387

Family Applications (1)

Application Number Title Priority Date Filing Date
ES201300717A Active ES2527884B1 (es) 2012-08-21 2013-08-01 Método y sistema para habilitar ticketing/pagos móviles sin contacto por medio de una aplicación de teléfono móvil, mejorados

Country Status (1)

Country Link
ES (1) ES2527884B1 (es)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080208681A1 (en) * 2006-09-28 2008-08-28 Ayman Hammad Payment using a mobile device
US8565723B2 (en) * 2007-10-17 2013-10-22 First Data Corporation Onetime passwords for mobile wallets
US8763097B2 (en) * 2011-03-11 2014-06-24 Piyush Bhatnagar System, design and process for strong authentication using bidirectional OTP and out-of-band multichannel authentication
US8346672B1 (en) * 2012-04-10 2013-01-01 Accells Technologies (2009), Ltd. System and method for secure transaction process via mobile device

Also Published As

Publication number Publication date
ES2527884A1 (es) 2015-02-02

Similar Documents

Publication Publication Date Title
AU2021209143B2 (en) Method and Apparatus for Providing Secure Services Using a Mobile Device
CN107925572B (zh) 软件应用程序到通信装置的安全绑定
CA2882986C (en) Method and system to enable mobile contactless ticketing/payments via a mobile phone application
ES2732564T3 (es) Sistema y procedimientos de aprovisionamiento de datos cifrados de servidor remoto
US10515362B2 (en) Methods and apparatus for card transactions
CN104603809B (zh) 在移动设备上使用虚拟卡促进交易的系统和方法
ES2758658T3 (es) Sistema de pago
EP2526514B1 (en) Method, device and system for securing payment data for transmission over open communication networks
US9218557B2 (en) Portable e-wallet and universal card
US10270587B1 (en) Methods and systems for electronic transactions using multifactor authentication
RU2651245C2 (ru) Защищенный электронный блок для санкционирования транзакции
US20130226812A1 (en) Cloud proxy secured mobile payments
US20160117673A1 (en) System and method for secured transactions using mobile devices
US20150142666A1 (en) Authentication service
GB2518277A (en) Improvements relating to secure payment transactions
US20150142669A1 (en) Virtual payment chipcard service
US20150142667A1 (en) Payment authorization system
CA2943854A1 (en) Remote transaction system, method and point of sale terminal
EP3364352A1 (en) Determining legitimate conditions at a computing device
WO2011110697A1 (es) Procedimiento y sistema para realizar una transacción
ES2527884B1 (es) Método y sistema para habilitar ticketing/pagos móviles sin contacto por medio de una aplicación de teléfono móvil, mejorados
ES2865380T3 (es) Método de realización de una transacción, terminal y programa informático correspondiente
ES2449190A2 (es) Método y sistema para habilitar ticketing/pagos móviles sin contacto por medio de una aplicación de teléfono móvil
WO2015022712A1 (en) Method and computer system for performing electronic transactions by means of a user device provided with a short range wireless communication interface
KR20230130039A (ko) 공개/개인 키 인증을 위한 디바이스들, 시스템들 및방법들

Legal Events

Date Code Title Description
FG2A Definitive protection

Ref document number: 2527884

Country of ref document: ES

Kind code of ref document: B1

Effective date: 20150929