ES3033832T3 - Mobile payment roaming - Google Patents

Mobile payment roaming

Info

Publication number
ES3033832T3
ES3033832T3 ES18726162T ES18726162T ES3033832T3 ES 3033832 T3 ES3033832 T3 ES 3033832T3 ES 18726162 T ES18726162 T ES 18726162T ES 18726162 T ES18726162 T ES 18726162T ES 3033832 T3 ES3033832 T3 ES 3033832T3
Authority
ES
Spain
Prior art keywords
server
roaming
pan
payment
token
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
ES18726162T
Other languages
English (en)
Inventor
M Oleg Makhotin
M Mehdi Elhaoussine
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.)
Idemia France SAS
Original Assignee
Idemia France SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Idemia France SAS filed Critical Idemia France SAS
Application granted granted Critical
Publication of ES3033832T3 publication Critical patent/ES3033832T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3672—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes initialising or reloading thereof
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/38—Payment protocols; Details thereof
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3224—Transactions dependent on location of M-devices
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/38—Payment protocols; Details thereof
    • G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G06Q2220/00—Business processing using cryptography

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Finance (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

La invención se refiere a un método implementado por un sistema (SI) que comprende un primer servidor (H-TSP) de un proveedor de servicios de token local y un segundo servidor (R-TSP) de un proveedor de servicios de token de itinerancia, comprendiendo el método: recibir (S86), por parte del segundo servidor, un token de itinerancia (R-PAN) asignado a una tarjeta de pago móvil (CI) para operar en una red de banca en itinerancia (R-NT); obtener (S88), por parte del segundo servidor, basándose en el token de itinerancia (R-PAN), un token local (H-PAN) asignado a la tarjeta de pago móvil para operar en una red de banca en casa (H-NT); recibir (S94), por parte del primer servidor, el token local (H-PAN); y obtener (S96), por parte del primer servidor, basándose en el token local (H-PAN), un número de tarjeta principal (C-PAN) de la tarjeta de pago móvil para operar en la red de banca en casa. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Itinerancia de pagos por móvil
Antecedentes
La presente descripción hace referencia en general al campo de las aplicaciones móviles para llevar a cabo transacciones financieras, tales como transacciones de pago. La descripción hace referencia más particularmente, pero no exclusivamente, a la gestión de una aplicación de monedero digital en un dispositivo móvil para permitir a un usuario llevar a cabo transacciones, tales como transacciones de pago, en una red de pago en particular.
Los pagos de productos y servicios se suelen realizar utilizando tarjetas de crédito, débito o cualquier otro tipo de tarjeta de pago. Los sistemas de pago móviles basados en carteras móviles son cada vez más populares debido a la comodidad de poder realizar un pago o una compra desde el dispositivo móvil o el teléfono inteligente del usuario. Los proveedores de pagos y servicios ofrecen esta funcionalidad a los usuarios, normalmente por medio de una aplicación móvil (o applet) que se ejecuta en un dispositivo móvil. Esta aplicación móvil permite al usuario realizar el pago a través de un emisor de tarjetas de crédito o un banco, o a través de un proveedor de pagos tercero.
Los pagos móviles que utilizan un monedero móvil normalmente implican que un usuario registre los datos de una tarjeta de pago en un dispositivo móvil. El dispositivo móvil almacena un monedero móvil que se puede utilizar para efectuar pagos utilizando la tarjeta de pago. En una transacción de pago con monedero móvil, un consumidor puede presentar su dispositivo móvil, que proporciona detalles de la tarjeta de pago, al terminal lector de un comerciante. El comerciante utiliza a su vez esta información para autorizar la transacción.
En la actualidad, las tarjetas de pago móviles, al igual que las tarjetas de pago reales, se configuran para ser compatibles con redes de pago específicas (o redes bancarias) dentro de las cuales se pueden utilizar para llevar a cabo transacciones financieras. Normalmente, una tarjeta de pago móvil se configura en un monedero digital para operar en una red de pago nacional de acuerdo con las especificaciones del emisor de la tarjeta. Para este fin, la aplicación de monedero digital del usuario recibe los datos de la tarjeta (identificador, claves, parámetros, etc.) compatibles con esta red de pago nacional. En Francia, por ejemplo, la red de pago conocida como "Tarjeta Bancaria" (o CB, por "Cartes Bancaires" en francés) es la red de pago nacional que se utiliza habitualmente para llevar a cabo una transacción de pago utilizando una tarjeta de pago móvil emitida por un banco francés.
Sin embargo, los usuarios itinerantes se pueden encontrar fuera del alcance de la red de pago nacional para la que su tarjeta de pago móvil está configurada para operar. Un usuario puede tener dificultades para llevar a cabo una transacción financiera, como un pago, cuando se encuentra en itinerancia en una región en la que las redes de pago disponibles no aceptan la tarjeta de pago móvil, por ejemplo, cuando se encuentra en itinerancia fuera del área nacional del usuario.
La norma bien establecida para el pago en itinerancia hoy en día es utilizar una red de pago global como las redes de pago VISA™ o MASTERCARD™. Estas redes globales son ventajosas porque cubren amplias áreas geográficas y, por lo tanto, ofrecen una solución de pago en itinerancia fácilmente accesible para los usuarios finales. Sin embargo, las redes de pago actuales también pueden presentar inconvenientes y su uso para pagos en itinerancia no siempre es satisfactorio.
Existe, por tanto, una necesidad en la técnica de una solución de itinerancia de pago eficiente.
Resumen de la invención
Según se ha mencionado anteriormente, un usuario en itinerancia en diferentes áreas (por ejemplo, cambiando de país) puede encontrarse fuera del alcance de una red de pago nacional con la que su tarjeta de pago móvil esté configurada para operar. Al igual que en el caso de las tarjetas de pago reales, un monedero móvil se puede configurar para utilizar una tarjeta bancaria móvil en una red de pago internacional cuando se encuentre en situación de itinerancia.
La norma bien establecida hoy en día para los pagos en itinerancia es que los usuarios utilicen una única red de pago global, como las redes de pago internacionales operadas por VISA™ o MASTERCARD™.
Sin embargo, es posible que un usuario en itinerancia no desee utilizar una red de pago internacional para llevar a cabo una transacción de pago. Además, algunos actores del ámbito de las soluciones de pago móvil tienden a promover el despliegue y el uso de sistemas de pago nacionales en lugar de internacionales.
La presente invención trata de remediar las preocupaciones mencionadas anteriormente y, más en general, permitir el uso de una tarjeta de pago móvil mientras un usuario está en itinerancia. La invención proporciona una solución eficiente de pago móvil en itinerancia.
Para remediar las preocupaciones mencionadas anteriormente, la presente invención se aparta de la práctica actual bien establecida de utilizar un único pago global para llevar a cabo pagos en itinerancia y, en su lugar, proporciona una solución basada en un nuevo enfoque, es decir, hacer compatibles dos redes de patentes distintas (es decir, una red de pago en casa y una red de pago en itinerancia) de modo que puedan cooperar entre sí para permitir la itinerancia de pagos.
En la actualidad, la falta de interoperabilidad entre las redes de pago nacionales se debe a las diferentes especificaciones, a menudo incompatibles, de cada red de pago. Aunque existe un esfuerzo global para implementar un sistema de pago estandarizado a escala mundial, es probable que una solución de este tipo requiera un tiempo y un esfuerzo considerables antes de que surja.
La presente invención proporciona una solución eficiente para el pago en itinerancia estableciendo la interoperabilidad entre múltiples redes de pago, permitiendo de este modo que los pagos en itinerancia se realicen a través de una combinación de dos (o más) redes de pago distintas en lugar de utilizar una única red de pago global como es la práctica bien establecida hoy en día.
La invención proporciona un método de procesamiento según se reivindica en la reivindicación 1.
El método de procesamiento puede comprender además las características descritas en las reivindicaciones 2-5.
En una forma de realización particular de la invención, las diversas etapas del método de procesamiento de acuerdo con la invención se especifican mediante instrucciones de programa informático.
En consecuencia, la invención también proporciona un programa informático en un medio de grabación, estando dispuesto este programa informático para ser implementado por un servidor, y más generalmente por un procesador, comprendiendo este programa informático instrucciones adaptadas para la implementación del método de procesamiento según se ha definido anteriormente.
La invención también proporciona un medio de grabación no transitorio legible por un servidor, o más generalmente por un procesador, comprendiendo este medio de grabación instrucciones de programa informático según se ha mencionado anteriormente grabadas en el mismo.
El medio de grabación mencionado anteriormente puede ser cualquier entidad o dispositivo capaz de almacenar el programa informático. Por ejemplo, el medio de grabación puede comprender un medio de almacenamiento, como una memoria ROM (un CD-ROM o una ROM implementada en un circuito microelectrónico), o un medio de almacenamiento magnético como un disquete o un disco duro, por ejemplo.
El soporte de grabación de la invención puede corresponder a un soporte transmisible, como una señal eléctrica u óptica, que se puede transportar por medio de un cable eléctrico u óptico, o por radio o cualquier otro medio apropiado. El programa informático de acuerdo con la invención puede, en particular, descargarse de Internet o de una red similar.
Como alternativa, el soporte de grabación puede corresponder a un circuito integrado en el que se carga un programa informático, estando adaptado el circuito para ejecutar o ser utilizado en la ejecución de los métodos de la invención.
La invención también hace referencia a un sistema según se reivindica en la reivindicación 8.
El sistema puede comprender además las características descritas en las reivindicaciones 9-11.
Cuando en la presente descripción se hace referencia a módulos funcionales para llevar a cabo diversas etapas de los métodos descritos, se debe entender que estos módulos se pueden implementar en hardware, en software o en una combinación de ambos. Cuando se implementan en hardware, los módulos se pueden implementar como uno o más módulos de hardware, como uno o más circuitos integrados de aplicación específica. Cuando se implementan en software, los módulos se pueden implementar como uno o más programas informáticos que se ejecutan en uno o más procesadores.
Cada etapa, que se puede llevar a cabo por una entidad técnica según se describe en el presente documento, puede corresponder a un módulo funcional específico. Un módulo funcional determinado se puede configurar para llevar a cabo varias etapas.
La presente invención proporciona una solución de pago móvil en itinerancia eficiente. En particular, permite una interoperabilidad eficiente de las tarjetas de pago móviles con múltiples redes de pago a las que un usuario puede acceder utilizando su dispositivo móvil.
Se garantiza la interoperabilidad entre los socios del sistema, al tiempo que se puede mantener un nivel adecuado de seguridad en el proceso de transacción. Al llevar a cabo una doble destokenización durante la transacción, la invención permite que cada sistema de pago utilice sus testigos de manera eficiente.
La invención evita, por ejemplo, la necesidad de una red de pago internacional. Cuando un usuario se encuentra en itinerancia fuera de su red de pago nacional (o regional), una transacción bancaria móvil se puede llevar a cabo ventajosamente en otra red de pago nacional (o regional). La invención puede garantizar una interoperabilidad adecuada entre distintos sistemas de pago con especificaciones diferentes, de tal forma que ya no sea necesario utilizar una red de pago internacional. Los sistemas bancarios nacionales pueden obtener aceptación internacional por medio de acuerdos de itinerancia con otros sistemas bancarios. Se pueden firmar, por ejemplo, contactos bilaterales de coidentificación estándar e integraciones de anfitrión a anfitrión.
Breve descripción de los dibujos
La descripción se entenderá mejor y se ilustrará por medio de los siguientes ejemplos de formas de realización y ejecución, en modo alguno restrictivos, con referencia a las figuras anexas en las que:
- la figura 1 es un diagrama esquemático que representa la estructura de, y las etapas llevadas a cabo por, un entorno que comprende un dispositivo móvil y un servidor de proveedor de servicios de testigo local, de acuerdo con una forma de realización particular de la presente invención;
- la figura 2 es un diagrama esquemático que representa la estructura de, y las etapas llevadas a cabo por, un entorno que comprende un dispositivo móvil de acuerdo con una forma de realización particular de la presente invención;
- la figura 3 es un diagrama esquemático que representa la estructura de, las etapas llevadas a cabo por, un entorno que comprende un dispositivo móvil y un servidor de un operador de servicios de testigos, de acuerdo con una forma de realización particular de la presente invención;
- la figura 4A muestra la estructura de un dispositivo móvil de acuerdo con una forma de realización particular de la presente invención;
- la figura 4B muestra módulos funcionales implementados por el dispositivo móvil de la figura 4A, de acuerdo con una forma de realización particular de la presente invención;
- la figura 5A muestra la estructura de un servidor de un operador de servicios de testigos de acuerdo con una forma de realización particular de la presente invención;
- la figura 5B muestra módulos funcionales implementados por el servidor de la figura 5A, de acuerdo con una forma de realización particular de la presente invención;
- la figura 6 es un diagrama esquemático que representa la estructura de, y las etapas llevadas a cabo por, un entorno que comprende un dispositivo móvil y un servidor de un operador de servicios de testigos, de acuerdo con una forma de realización particular de la presente invención;
- la figura 7 es un diagrama esquemático que representa la estructura de, y las etapas llevadas a cabo por, un entorno que comprende un dispositivo móvil que lleva a cabo una transacción, de acuerdo con una forma de realización particular de la presente invención;
- la figura 8 es un diagrama esquemático que representa una forma de realización alternativa de la figura 7;
- la figura 9A muestra la estructura de un servidor de un proveedor de servicios de testigos en itinerancia de acuerdo con una forma de realización particular de la presente invención;
- la figura 9B muestra módulos funcionales implementados por el servidor de la figura 9A, de acuerdo con una forma de realización particular de la presente invención;
- la figura 10A muestra la estructura de un servidor de un proveedor de servicios de testigo local de acuerdo con una forma de realización particular de la presente invención;
- la figura 10B muestra módulos funcionales implementados por el servidor de la figura 10A, de acuerdo con una forma de realización particular de la presente invención; y
- las figuras 11-15 son diagramas esquemáticos que representan formas de realización particulares de la presente invención.
En las figuras 1-15, algunos bloques representados son entidades puramente funcionales, que no corresponden necesariamente a entidades físicamente independientes. Es decir, se podrían desarrollar en forma de software, hardware, o implementarse en uno o varios circuitos integrados, que comprenden uno o más procesadores.
Para simplificar y aclarar la ilustración, se utilizarán los mismos números de referencia en todas las figuras para referirse a los mismos elementos o a elementos correspondientes, a menos que se indique lo contrario.
Los componentes de las figuras no están necesariamente a escala, sino que se hace hincapié en ilustrar los principios de la invención.
Descripción de determinadas formas de realización de la invención
En el dibujo se muestran y se describirán en detalle en la presente memoria formas de realización específicas, entendiéndose que la presente descripción se debe considerar como una ejemplificación de los principios de la descripción y no pretende limitar la descripción a las formas de realización específicas ilustradas. En su lugar, el alcance de la invención queda definido por las reivindicaciones adjuntas.
Muchos detalles específicos de la invención se exponen en la siguiente descripción y en las figuras 1 -10B.Sin embargo, un experto en la técnica comprenderá que la presente invención se pueda poner en práctica sin algunos de los detalles descritos en la siguiente descripción. En otros casos, no se han descrito en detalle métodos, procedimientos y componentes bien conocidos para evitar oscurecer las formas de realización descritas en los mismos.
La presente invención proporciona un dispositivo móvil, un servidor, un sistema y los métodos correspondientes para permitir que se lleve a cabo una transacción de manera eficiente utilizando una tarjeta de pago móvil. Más concretamente, la invención permite realizar transacciones de pago en itinerancia utilizando un monedero digital provisto de una tarjeta de pago móvil en un dispositivo móvil. La invención tiene por objetivo permitir una interoperabilidad eficiente entre múltiples sistemas de pago, de tal forma que una misma tarjeta de pago móvil se pueda utilizar fácilmente con diferentes redes de pago, como redes de pago nacionales o regionales, por ejemplo.
La figura 1 muestra un entorno, de acuerdo con una forma de realización particular de la invención, que comprende un dispositivo móvil DV, un servidor proveedor de monederos digitales DWP, un servidor H-TSP de un proveedor de servicios de testigo local y un terminal lector T.
El dispositivo móvil DV se puede utilizar por un usuario UR para llevar a cabo transacciones de pago en una red de pago. Para este fin, el dispositivo móvil DV implementa una aplicación de monedero digital (o applet) DWA capaz de utilizar datos de una tarjeta de pago móvil para llevar a cabo pagos móviles. En el estado inicial mostrado en la figura 1, la aplicación de monedero digital DWA se configura con un primer conjunto de datos DT1 asociados a una tarjeta de pago móvil C1. Esta aplicación de monedero digital puede recuperar y utilizar los datos DT1 almacenados en el dispositivo móvil DV para llevar a cabo transacciones en una red de pago local H-NT (o sistema de pago local).
La tarjeta de pago móvil C1 es una tarjeta virtual (o digital) que puede mostrarse en una pantalla del dispositivo móvil DV y que se puede utilizar de forma desmaterializada para completar transacciones financieras, como las transacciones de pago.
En el presente documento, las formas de realización se describen en el contexto de las transacciones de pago, aunque la invención no se limita a ello y se aplica más generalmente a cualquier tipo de transacción bancaria (o financiera) móvil.
El dispositivo móvil DV puede ser un teléfono inteligente, una tableta o cualquier dispositivo de comunicación móvil adecuado equipado con recursos de procesamiento para gestionar la aplicación de monedero digital DWA. En las formas de realización de ejemplo contempladas en el presente documento, el dispositivo móvil es un teléfono inteligente o un aparato equivalente. Este teléfono inteligente se puede comunicar a través de una red celular utilizando datos de autentificación almacenados en una tarjeta SIM o similar.
Según se muestra en lafigura 1, el dispositivo móvil DV también puede implementar una aplicación de pago PA1 que se puede utilizar en cooperación con la aplicación de monedero digital DWA para llevar a cabo operaciones (configuración, transacción de pago...) con respecto a la tarjeta de pago móvil C1.
La figura 1 ilustra, de acuerdo con una forma de realización particular de la invención, cómo se puede configurar inicialmente la aplicación de monedero digital DWA con el conjunto de datos DT1 correspondientes a la tarjeta de pago móvil C1.
En una etapa S2, el dispositivo móvil DV recupera un número de cuenta principal (o número de tarjeta de pago) PAN, designado como C-PAN, asignado a la tarjeta de pago móvil C1 para operar en la red de pago local H-NT. El número de cuenta principal es un identificador bien conocido de una tarjeta de pago, a veces denominado número de tarjeta de pago. Este número identifica al emisor de la tarjeta. Este número de cuenta primario (o identificador) C-PAN se puede almacenar en el dispositivo móvil DV de modo que pueda ser recuperado por la aplicación de monedero digital DWA en la etapa S2.
El dispositivo móvil DV, bajo el control de la aplicación de monedero digital DWA, envía a su vez (S2) el C-PAN al servidor DWP de un proveedor de servicios de monedero digital.
El servidor DWP transmite (S6) el número de cuenta C-PAN de la tarjeta de pago al servidor H-TSP del proveedor de servicios de testigo local. Este servidor H-TSP se encarga de proporcionar a los titulares de tarjetas un testigo digital que se utilizará en sustitución del número PAN. El PAN es un dato sensible y, por consiguiente, su difusión se debe limitar por una cuestión de seguridad.
En respuesta al número de cuenta C-PAN, el servidor H-TSP devuelve (S6) el primer conjunto de datos DT1 que es recibido por el servidor DWP y reenviado (S8) al dispositivo móvil DV. El conjunto de datos DT 1 incluye un testigo local H-PAN asignado a la tarjeta de pago móvil C1 para operar con la red de pago local H-NT. El primer conjunto de datos DT1 puede incluir datos adicionales tales como un identificador H-PANID correspondiente al testigo local H-PAN.
Además, el servidor H-TSP almacena (S5), en una base de datos, por ejemplo, el testigo local H-PAN en asociación con el número de cuenta C-PAN recibido de la aplicación de monedero digital DWA.
El testigo local H-PAN, que puede adoptar cualquier forma digital apropiada (como un código, una secuencia de caracteres, etc.), es un dato menos sensible que el número de cuenta principal C-PAN. La utilización del testigo local H-PAN se puede restringir a un dispositivo concreto y a un entorno de transacción específico (las denominadas restricciones de dominio de transacción). El testigo local H-PAN puede ser utilizado por la aplicación de monedero digital DWA en lugar del número de cuenta C-PAN, permitiendo de este modo un sistema de pago más seguro.
En una etapa S10, el dispositivo móvil DV configura la aplicación de monedero digital DWA con el primer conjunto de datos DT1 recibidos para permitirle llevar a cabo transacciones de pago en la red de pago local H-NT. Como parte de esta configuración, el dispositivo móvil DV puede personalizar el aspecto visual (imagen de la tarjeta, logotipo, colores, etc. ) de la interfaz gráfica de usuario (GUI) de la aplicación de monedero digital DWA con parámetros visuales incluidos en el primer conjunto de datos DT 1 proporcionado por el servidor H-TSP.
Además, el dispositivo móvil DV almacena (S10) el conjunto de datos DT1 para su posterior recuperación por la aplicación de monedero digital DWA.
Una vez completada esta configuración inicial, el usuario UR puede utilizar la aplicación de monedero digital DWA ejecutada en el dispositivo móvil DV para completar una transacción de pago en la red de pago local H-NT. Para este fin, el usuario UR puede presentar el dispositivo móvil DV cerca de un terminal de pago T de un comerciante, tal y como se muestra en la figura 1. El dispositivo móvil DV puede cooperar (S12) con el terminal de pago T de cualquier manera apropiada para llevar a cabo un pago móvil. En particular, el dispositivo móvil DV transmite el primer conjunto de datos DT1, o al menos el testigo local H-PAN, de modo que la transacción pueda ser autenticada por el terminal T. Según se ha mencionado anteriormente, se puede evitar la transmisión del número de cuenta principal sensible C-PAN, ya que en su lugar se utiliza el testigo local H-PAN.
La figura 2 representa, de acuerdo con una forma de realización particular de la invención, cómo el dispositivo móvil DV puede llevar a cabo una transacción de pago utilizando la tarjeta de pago móvil C1 en la red de pago local H-NT.
En una etapa S12, el dispositivo móvil DV envía el testigo local H-PAN al terminal de pago T, según ya se ha descrito anteriormente con respecto a la figura 1. Otra información incluida en el primer conjunto de datos DT, como la fecha de caducidad de la tarjeta de pago C1, se puede transmitir junto con el terminal T.
En un ejemplo particular, el dispositivo móvil DV y el terminal de pago T cooperan (o interactúan) entre sí de acuerdo con el estándar EMV ("Europay, MasterCard y Visa") o patentado que se puede o no obtener a partir del EMV, para llevar a cabo la transacción de pago. Esto se puede hacer mediante una comunicación sin contacto entre el dispositivo móvil DV y el terminal T, utilizando por ejemplo interfaces NFC o similares (Bluetooth...).
Durante esta interacción S12, la aplicación de monedero digital DWA puede interactuar con la aplicación de pago PA1 desplegada por el banco emisor de la tarjeta móvil de pago C1.
El terminal de pago T, situado por ejemplo en un punto de venta de un comerciante, transmite a continuación (S22) los datos de la transacción DR1 al sistema bancario AC de la entidad adquirente (por ejemplo, el banco del comerciante). Los datos de la transacción DR1 contienen cualquier dato (fecha, importe de la transacción...) que caracterice la transacción de pago para permitir su procesamiento posterior, como la autentificación, la validación... En particular, los datos de la transacción DR1 incluyen el testigo local H-PAN proporcionado por la aplicación de monedero digital DWA del dispositivo móvil DV.
En la etapa S24, el sistema bancario AC de la entidad adquirente transmite los datos de la transacción DR1 a un servidor de enrutamiento H-SV de la red de pago local H-NT. Este servidor H-SV reenvía (S26) el testigo local H-PAN al servidor H-TSP del proveedor de servicios de testigo local.
El servidor H-TSP determina (S27) a su vez el número de cuenta primario C-PAN almacenado (ver S5 en la figura 1) en asociación con el testigo local H-PAN recibido en S26, y devuelve (S28) este número de cuenta C-PAN al servidor H-SV.
En la etapa S30, el servidor H-SV reenvía, al sistema bancario IS de un emisor, el número de cuenta principal C-PAN junto con cualquier otra información útil que pueda haberse recibido en los datos de la transacción DR1 (importe, fecha...). El emisor IS, que es, por ejemplo, el banco emisor de la tarjeta de pago móvil C1, puede a su vez procesar la transacción de pago basándose en el número de cuenta primario C-PAN asignado a la tarjeta de pago móvil C1 para operar con la red de pago local H-NT.
Según se ha descrito anteriormente, la red de pago local H-NT, y más concretamente el servidor H-TSP, permite un proceso de destokenización obteniendo de este modo un identificador PAN a partir de un testigo digital.
En el presente ejemplo, el sistema bancario AC del adquirente, los servidores H-SV y H-TSP, y el sistema bancario IS del emisor forman parte de la red de pago local H-NT, según se muestra en la figura 2.
Gracias al primer conjunto de datos DT1 proporcionado a la aplicación de monedero digital DWA, el usuario UR puede por tanto utilizar la tarjeta de pago móvil C1 en el sistema de pago local. El término "local" en este contexto se utiliza simplemente como convención para designar una red o sistema de pago con el que la aplicación de monedero digital DWA es inicialmente compatible para llevar a cabo una transacción de pago utilizando los datos de la tarjeta de pago móvil C1. Normalmente es el emisor de la tarjeta de pago móvil el que define qué sistema o sistemas de pago corresponden al sistema o sistemas de pago local de la tarjeta.
Sin embargo, se debe tener en cuenta que la transacción sólo se puede llevar a cabo entre el dispositivo móvil DV y el terminal de pago T si ambos dispositivos se configuran de manera compatible. En otras palabras, la transacción sólo se puede procesar con éxito si el terminal de pago T también se configura para operar en la red de pago local H-NT. Si el terminal de pago T forma parte de una red de pago diferente, con especificaciones incompatibles con las de la red de pago local, la transacción fallará. Esto puede ocurrir, por ejemplo, cuando se intenta realizar un pago móvil en itinerancia utilizando el dispositivo de pago móvil C1, mientras el dispositivo móvil DV se encuentra en itinerancia fuera de la red de pago local H-NT.
Si, por ejemplo, el dispositivo móvil DV está en itinerancia y la aplicación de monedero digital DWA intenta una transacción con un terminal de pago conectado a una red de pago en itinerancia incompatible con la configuración actual de la aplicación de monedero digital DWA, la transacción fallará.
Un objetivo de la invención es superar estos problemas.
La figura 3 muestra, de acuerdo con una forma de realización particular de la invención, un entorno que comprende el dispositivo móvil DV y el servidor de monedero digital DWP según se ha descrito anteriormente con respecto a las figuras 1 y 2, junto con un servidor TSO de un operador de servicios de testigos que puede acceder a una base de datos DB1.
Una implementación detallada del dispositivo móvil DV, de acuerdo con una forma de realización particular de la presente invención, se describirá más adelante con respecto a las figuras 4A y 4B. Del mismo modo, una implementación detallada del servidor TSO, de acuerdo con una forma de realización particular de la presente invención, se describirá más adelante con respecto a las figuras 5A y 5B.
Como se muestra en la figura 3, se supone que el usuario UR está en itinerancia de tal forma que el dispositivo móvil DV está fuera del alcance de la red de pago local H-NT. La figura 3 representa cómo la aplicación de monedero digital DWA puede detectar una red de pago en itinerancia, distinta de la red de pago local H-NT, a la que se puede acceder para llevar a cabo transacciones de pago.
En una etapa S40, el dispositivo móvil DV envía una solicitud de información que contiene información de localización LOC representativa de la posición actual del dispositivo móvil DV. En el presente ejemplo, el envío S40 de esta solicitud de información es comandado por la aplicación de monedero digital DWA.
En un ejemplo concreto, la aplicación de monedero digital DWA activa el envío de esta solicitud de información al detectar que el dispositivo móvil DV se encuentra en itinerancia fuera (es decir, fuera del alcance) de la red de pago local H-NT. Por ejemplo, el titular de la tarjeta UR se encuentra en itinerancia en un área (o país) de itinerancia, es decir, un área (o país) distinta de un área predefinida en la que se puede acceder a la red de pago local H-NT.
En un ejemplo particular, la aplicación de monedero digital DWA activa el envío (S40) de esta solicitud de información al detectar que el dispositivo móvil DV está en itinerancia en una red celular distinta de una red celular local predefinida. Para este fin, la aplicación de monedero digital DWA puede supervisar la red celular a la que está conectado el dispositivo móvil DV. Por ejemplo, cuando el usuario UR se encuentra en itinerancia en el extranjero, el dispositivo móvil DV se puede conectar a una red móvil en itinerancia distinta de la red móvil local. Basándose en el identificador de esta red móvil en itinerancia, el dispositivo móvil DV (o, más concretamente, la aplicación de monedero digital DWA) puede determinar que ya no se puede acceder a la red de pago local y, por lo tanto, activa el envío (S40) de la solicitud de información.
En un ejemplo particular, la aplicación de monedero digital DWA activa el envío (S40) de la solicitud de información al detectar que el dispositivo móvil DV se encuentra fuera de un área geográfica predefinida, designada como área local. Para este fin, la aplicación de monedero digital DWA puede supervisar la posición geográfica del dispositivo móvil DV, utilizando, por ejemplo, un módulo de localización 14 según se describe más adelante con respecto a lasfiguras 4Ay4B.Por ejemplo, al detectar que el dispositivo móvil DV se encuentra en itinerancia en Alemania, y por tanto fuera de Francia, que está predefinida como área local, la aplicación de monedero digital DWA puede determinar que ya no se puede acceder a la red de pago local y, por tanto, activa el envío (S40) de la solicitud de información.
Según se ha mencionado anteriormente, la solicitud de información comprende información de localización LOC representativa de la posición actual del dispositivo móvil DV. La información de localización puede comprender al menos uno de los siguientes:
- información geográfica (por ejemplo, coordenadas GPS, país, área, ciudad, etc.) representativa de una posición geográfica del dispositivo móvil DV; y
- un identificador de red que indica una red celular, o parte de ella, a la que está conectado el dispositivo móvil DV.
La posición actual representada por la información de localización LOC puede ser una última posición conocida detectada por el dispositivo móvil DV.
La aplicación de monedero digital DWA puede supervisar la posición geográfica o de red del dispositivo móvil DV y compararla con criterios de localización predefinidos. Basándose en el resultado de la comparación, la aplicación de monedero digital DWA determina si la solicitud de información que contiene la información de localización LOC se debe enviar en S40.
En el presente ejemplo, el dispositivo móvil DV envía (S40) la solicitud de información al servidor de monedero digital DWP que a su vez la reenvía (S42) al servidor TSO del operador del servidor de testigos. Como se verá en las formas de realización descritas en las mismas, el servidor TSO se encarga de gestionar los testigos que se proporcionan a la aplicación de monedero digital DWA y que posteriormente se utilizan en las transacciones de pago.
En una etapa S44, el servidor TSO determina, basándose en la información de localización LOC, al menos una red de pago en itinerancia que se puede utilizar o a la que puede acceder el dispositivo móvil DV, y más concretamente la aplicación de monedero digital DWA. En otras palabras, el servidor TSO determina una o más redes de pago en itinerancia que están a disposición del usuario para llevar a cabo transacciones de pago en itinerancia en la posición correspondiente a la información de localización LOC. Para ello, el servidor TSO puede consultar la base de datos DB1, que almacena una lista de al menos una red de pago asociada a una localización o área determinada. Según se ha mencionado anteriormente, la localización del dispositivo móvil se puede definir a nivel de red celular y/o a nivel geográfico. La base de datos DB1 puede almacenar información de red que caracterice al menos una red de pago accesible en un área determinada.
De acuerdo con la presente forma de realización, se pueden realizar acuerdos de itinerancia particulares entre bancos y operadores de esquemas de pago de todo el mundo. Los esquemas locales pueden obtener aceptación internacional por medio de acuerdos de itinerancia con otros esquemas mediante la firma de contactos bilaterales de coidentificación e integraciones de anfitrión a anfitrión, según será más evidente a continuación en la presente memoria.
En el presente ejemplo, se supone que el servidor TSO identifica (S44) tres redes de pago en itinerancia que pueden ser potencialmente utilizadas por la aplicación de monedero digital a efectos de transacciones de pago. En consecuencia, el servidor TSO envía de vuelta (S46) información de itinerancia RI al servidor de monedero digital DWP, identificando esta información de itinerancia RI las varias redes de pago en itinerancia identificadas como disponibles en S44. En el presente caso, la información de itinerancia incluye los identificadores ID1, ID2 e ID3 de las tres respectivas redes de pago en itinerancia identificadas por el servidor TSO.
En una etapa S48, el servidor de monedero digital DWP reenvía la información de itinerancia RI al dispositivo móvil DV.
Basándose en la información de itinerancia RI, la aplicación de monedero digital DWA selecciona (S50) a su vez una red de pago en itinerancia (o sistema de pago en itinerancia), denominada R-NT, entre las tres opciones seleccionables ID1-ID3 identificadas por el servidor TSO. La información de itinerancia RI proporcionada por el servidor TSO puede incluir, además de los identificadores ID1-ID3, cualquier otra información que pueda ayudar a la aplicación de monedero digital DWA en su proceso de selección de una red de pago en itinerancia.
En el presente caso, la red de pago en itinerancia R-NT seleccionada (S50) por la aplicación de monedero digital DWA es diferente de la red de pago local H-NT con la que se configuró inicialmente para operar.
En un ejemplo particular, la información de itinerancia RI incluye diversa información que caracteriza las redes de pago en itinerancia disponibles, como tarifas de intercambio (estructura de tasas), parámetros, etc.
En un ejemplo particular, la información de itinerancia incluye al menos uno de los siguientes:
- parámetros asociados con al menos una red bancaria en itinerancia, definiendo dichos parámetros al menos una de las tarifas de servicio y un área de aceptación; y
- información de prioridad que define un orden de prioridad según el cual cada red de pago en itinerancia debe ser seleccionada por el dispositivo móvil DV.
En el presente ejemplo, la información de itinerancia RI incluye información de prioridad que define la red de pago en itinerancia R-NT como la red a seleccionar con prioridad por la aplicación de monedero digital DWA. La información de prioridad puede definir un orden de prioridad de acuerdo con el que seleccionar entre varias redes de pago en itinerancia R-NT. En la información sobre itinerancia RI, se podrán asignar múltiples valores de prioridad a cada una de las redes de pago en itinerancia disponibles en función de criterios como la fecha, el tipo de transacción que se deba realizar, etc.
En la presente invención, la forma en que la red de pago en itinerancia es seleccionada por la aplicación de monedero digital DWA se puede adaptar dinámicamente con el tiempo en función de diversos factores. En particular, la base de datos DB1 se puede actualizar periódicamente para modificar las redes de pago en itinerancia que se presentan como opciones a una aplicación de monedero digital en una localización determinada. Los criterios sobre los que la aplicación de monedero digital DWA realiza su selección S50 también se pueden adaptar con el tiempo.
La selección S50 puede ser completamente automática o requerir la confirmación del usuario UR.
En un ejemplo particular, la información de itinerancia RI identifica sólo una única red de pago en itinerancia.
Además, el servidor TSO se puede configurar para llevar a cabo una preselección de redes de pago en itinerancia disponibles para el usuario UR entre varias posibles redes de pago en itinerancia. Esta preselección se puede realizar basándose en la identidad del dispositivo móvil DV o del usuario.
En un ejemplo particular, la aplicación de monedero digital DWA ordena al dispositivo móvil DV que envíe en la etapa S40 el testigo local H-PAN junto con la información de localización LOC (figura 3). El testigo local H-PAN y la información de localización LOC son transferidas (S42) por el servidor de monedero digital DWP al servidor TSO. En la etapa S44, el servidor TSO tiene en cuenta la información de localización LOC y el testigo local H-PAN para determinar la al menos una red de pago en itinerancia que puede utilizar o a la que puede acceder el dispositivo móvil DV, y más concretamente la aplicación de monedero digital DWA. El testigo local H-PAN permite al servidor TSO comprobar a qué red de pago en itinerancia está autorizado a acceder y utilizar el usuario UR con su tarjeta de pago móvil C1. En un ejemplo concreto, el servidor TSO puede consultar la base de datos DB1 que indica, para cada red de pago existente en una localización concreta, si el acceso a la misma está autorizado para el usuario UR de la tarjeta de pago móvil C1. El servidor TSO podrá a su vez identificar (S46, figura 3) en la información de itinerancia RI únicamente la red o redes de pago en itinerancia existentes a las que el usuario está autorizado a acceder. En una variante, el dispositivo móvil DV envía (S40) un identificador del dispositivo móvil DV, como por ejemplo un identificador MAC, y lo utiliza (S44) como criterio de selección de la red de pago en itinerancia en lugar del testigo local H-PAN.
Según se ha descrito anteriormente en la presente forma de realización, el dispositivo móvil DV envía (S40) la solicitud de información que contiene la información de localización LOC al servidor de monedero digital DWP, que la reenvía al servidor TSO. Sin embargo, son posibles otras formas de realización.
En una variante, el dispositivo móvil DV envía directamente la solicitud de información al servidor TSO, sin pasar por el servidor de monedero digital DWP. En este caso, la aplicación de monedero digital DWA puede cooperar con la aplicación de pago PA1 dentro del dispositivo móvil DV. El servidor H-TSP puede servir como interfaz de enrutamiento entre el dispositivo móvil DV y el servidor TSO. En otra variante, una aplicación móvil TSO (no mostrada) originada por el operador de servicios de testigos se puede implementar en el dispositivo móvil DV y puede cooperar con la aplicación de monedero digital DWA. En este caso, esta aplicación móvil TSO puede permitir al dispositivo móvil DV interactuar directamente con el servidor TSO para enviar (S40) la solicitud de información y recibir (S48) a cambio la información de itinerancia RI.
La figura 4A muestra, de acuerdo con una forma de realización particular de la invención, la estructura del dispositivo móvil DV ya descrito anteriormente. En este ejemplo, el dispositivo móvil DV presenta la arquitectura de hardware de un teléfono inteligente, o más generalmente de un ordenador. En particular, el dispositivo móvil DV comprende un procesador 2, una memoria no volátil reescribible 4 (por ejemplo, una Flash), una memoria RAM 6, una primera interfaz de comunicación 8, una segunda interfaz de comunicación 10 y una interfaz persona-máquina 12. Algunos elementos normalmente incluidos en un teléfono inteligente se han omitido voluntariamente en la presente forma de realización para mejorar la claridad de la presente descripción.
La memoria no volátil regrabable 4 del dispositivo móvil DV constituye un medio de grabación no transitorio de acuerdo con una forma de realización particular de la invención. Esta memoria incluye un programa informático PG1 de acuerdo con una forma de realización particular de la invención, comprendiendo este programa informático instrucciones para implementar un método de acuerdo con una forma de realización particular de la invención. En el presente ejemplo, el programa informático PG1 corresponde a la aplicación de monedero digital DWA implementada en el dispositivo móvil DV.
La memoria no volátil regrabable 4 también puede almacenar el primer conjunto de datos DT1 proporcionados por el servidor H-TSP del proveedor de servicios de testigo local, según se ha descrito anteriormente con referencia a la figura 1.En el presente ejemplo, los datos DT1 incluyen el testigo local H-PAN y un identificador H-PANID asociado con el testigo local H-PAN.
Además, la memoria 4 puede almacenar un segundo conjunto de datos DT2, según se describirá más adelante.
La memoria 4 también puede almacenar un programa informático para implementar la aplicación de pago PA1.
La primera interfaz 8 es una interfaz de comunicación utilizada por el dispositivo móvil DV para comunicarse a través de una red de telefonía móvil. En el presente caso se puede contemplar cualquier estándar de comunicación móvil adecuado, como 3G, 4G, LTE, etc.
La segunda interfaz 10 es una interfaz sin contacto para llevar a cabo la comunicación sin contacto con terminales de pago, como el terminal T representado en la figura 1. Esta interfaz 10 puede ser una interfaz NFC, una interfaz Bluetooth o similar. El dispositivo móvil 10 puede utilizar esta segunda interfaz 10 para llevar a cabo una transacción de pago con un terminal de pago.
La interfaz hombre-máquina puede incluir cualquier medio apropiado (pantalla, teclado...) que permita al usuario UR comandar e interactuar con el dispositivo móvil DV, y más particularmente con la aplicación de monedero digital DWA.
El procesador 2, pilotado por el programa informático PG1, implementa una serie de módulos funcionales según se representa en la figura 4B, a saber: un módulo de localización MD2, un módulo de recepción MD4, un módulo de selección MD6, un módulo de obtención de datos MD8, un módulo de configuración MD10 y un módulo de ejecución MD12.
El módulo de envío MD2 se configura para enviar una solicitud de información que contiene información de localización LOC representativa de la posición actual de un dispositivo móvil, según ya se ha descrito con respecto a la figura 3.
El módulo receptor MD4 se configura para recibir, en respuesta a la solicitud de información, información de itinerancia RI que identifica al menos una red de pago en itinerancia R-NT (distinta de la red de pago local H-NT) que está disponible en la posición actual del dispositivo móvil DV, según ya se ha descrito con respecto a la figura 3.
El módulo de selección MD6 se configura para seleccionar una red de pago en itinerancia R-NT basándose en la información de itinerancia RI recibida, según ya se ha descrito con respecto a la figura 3.
El módulo de obtención de datos MD8 se configura para obtener un segundo conjunto de datos DT2 asignados a la tarjeta de pago móvil C1 para operar en la red en itinerancia R-NT seleccionada, como se describirá a continuación con respecto a la figura 6.
El módulo de configuración MD10 se configura para configurar la aplicación de monedero digital DWA con el segundo conjunto de datos DT2 de modo que pueda utilizar la tarjeta de pago móvil C1 en la red de pago en itinerancia R-NT seleccionada, según se describirá a continuación con respecto a la figura 6.
El módulo de ejecución MD12 se configura para llevar a cabo una transacción de pago (o cualquier otra transacción bancaria apropiada) utilizando la tarjeta de pago móvil C1 en la red de pago en itinerancia R-NT seleccionada, según se describirá a continuación con respecto a la figura 7-10B.
Estos módulos MD2-MD12 sólo constituyen una forma de realización no restrictiva de la presente invención.
La figura 5A muestra, de acuerdo con una forma de realización particular de la invención, la estructura del servidor TSO ya descrita anteriormente. En este ejemplo, el servidor TSO presenta la arquitectura de hardware de un ordenador. En particular, el servidor TSO comprende un procesador 20, una memoria no volátil reescribible 22 (por ejemplo, una Flash), una memoria RAM 24, una base de datos 26 y una interfaz de comunicaciones 28. Algunos elementos normalmente incluidos en un servidor han sido voluntariamente omitidos en la presente forma de realización para mejorar la claridad de la presente descripción.
La memoria no volátil reescribible 22 del servidor TSO constituye un medio de grabación no transitorio de acuerdo con una forma de realización particular de la invención. Esta memoria incluye un programa informático PG2 de acuerdo con una forma de realización particular de la invención, comprendiendo este programa informático instrucciones para implementar un método de acuerdo con una forma de realización particular de la invención.
La base de datos 26 incluye información de red de pago en itinerancia que define una lista de al menos una red de pago en itinerancia seleccionable en asociación con una posición particular (red celular, posición geográfica...). Según se ha descrito anteriormente con respecto a la figura 3, la base de datos 26 almacena los identificadores ID1, ID2 e ID3 de tres redes de pago en itinerancia respectivas, en asociación con una posición actual del dispositivo móvil DV.
La interfaz 28 es una interfaz de comunicación que es utilizada por el servidor TSO para comunicarse con el servidor de monedero digital DWP o, en una variante, directamente con el dispositivo móvil DV a través de una red celular.
El procesador 20, pilotado por el programa informático PG2, implementa una serie de módulos funcionales según se representa en la figura 5B, es decir: un módulo de localización MD20, un módulo de determinación MD22, un primer módulo de envío MD24, un módulo de procesamiento de solicitudes MD26, un módulo de aprovisionamiento MD28 y un segundo módulo de envío MD30. En un ejemplo particular, el procesador 20 implementa además un módulo de conexión MD32.
El módulo de localización MD20 se configura para recibir, desde el dispositivo móvil DV, una solicitud de información que contiene información de localización LOC representativa de la posición actual del dispositivo móvil DV, según ya se ha descrito con respecto a la figura 3.
El módulo determinante MD22 se configura para determinar, basándose en la información de localización, al menos una red de pago en itinerancia a la que puede acceder el dispositivo móvil DV, según ya se ha descrito con respecto a la figura 3.
El primer módulo de envío MD24 se configura para enviar, al dispositivo móvil DV, información de itinerancia RI que identifica la al menos una red de pago en itinerancia determinada por el módulo de determinación MD22, según ya se ha descrito con respecto a la figura 3.
El módulo de procesamiento de solicitudes MD26 se configura para recibir, desde el dispositivo móvil DV, una solicitud de aprovisionamiento RQ1 para la red de pago en itinerancia R-NT seleccionada por el dispositivo móvil DV entre dicha al menos una red de pago en itinerancia, según se describirá con más detalle a continuación.
El módulo de aprovisionamiento MD28 se configura para obtener un segundo conjunto de datos DT2 asignados a la tarjeta de pago móvil C1 para operar en la red de pago en itinerancia R-NT seleccionada, según se describirá con más detalle a continuación.
El segundo módulo de envío MD30 se configura para enviar el segundo conjunto de datos DT2 al dispositivo móvil DV para configurar la aplicación de monedero digital DWA de modo que pueda utilizar la tarjeta de pago móvil C1 en la red de pago en itinerancia R-NT seleccionada.
El módulo de conexión MD32 se configura para conectar entre sí la red de pago local H-NT y la red de pago en itinerancia R-NT seleccionada mientras se procesa una transacción de pago, según se describe con más detalle en el ejemplo particular de la figura 8.
Estos módulos MD20-MD32 sólo constituyen una forma de realización no restrictiva de la presente invención.
En una forma de realización particular, la invención se puede implementar utilizando componentes de software y/o hardware. En este contexto, el término "módulo" se puede referir en este documento a un componente de software, así como a un componente de hardware o a varios componentes de software y/o hardware.
Una vez completada la etapa de selección S50 representada en la figura 3, la aplicación de monedero digital DWA ha identificado la red de pago en itinerancia R-NT que se va a utilizar en la localización actual del dispositivo móvil DV. La provisión de datos se lleva a cabo a su vez según se representa en la figura 6, de acuerdo con una forma de realización particular de la invención.
Más particularmente, la aplicación de monedero digital DWA ordena al dispositivo móvil DV que envíe (S60) una solicitud de aprovisionamiento RQ1 para la red de pago en itinerancia R-NT que fue previamente seleccionada en S50. En la presente forma de realización, la solicitud de aprovisionamiento RQ1 es enviada por el dispositivo móvil DV al servidor de monedero digital DWP que la reenvía (S62) al servidor TSO del operador de servicio de testigos.
La solicitud de provisión RQ1 transmitida por medio del servidor de monedero digital DWP al servidor TSO incluye el identificador H-PANID que fue previamente almacenado como parte de los datos DT1 por el dispositivo móvil DV en S10 (figura 1). Como ya se ha mencionado, mediante el uso de este identificador H-PANID se puede evitar la difusión del testigo H-PAN (que es un dato sensible).
En el presente ejemplo, la solicitud de provisión RQ1 también incluye el identificador ID1 de la red de pago en itinerancia R-NT seleccionada. Basándose en este identificador ID1, el servidor TSO detecta que se ha seleccionado la red de pago en itinerancia.
En una etapa S64, el servidor TSO determina un segundo conjunto de datos DT2, diferente del primer conjunto de datos DT1, asignado a la tarjeta de pago móvil C1 para operar en la red de pago en itinerancia R-NT seleccionada. A continuación, se describe una forma particular en que el servidor obtiene los datos DT2, aunque son posibles otras formas de realización.
En una etapa S64a, el servidor TSO envía el identificador H-PANID, extraído de la solicitud de provisión RQ1, al servidor H-TSP del proveedor de servicios domésticos. El servidor H-TSP determina (S64b) a su vez el testigo local H-PAN correspondiente al identificador H-PANID. Según ya se ha explicado con respecto a la figura 1 (etapa S5), el servidor H-TSP puede recuperar información que incluya la pareja [H-PAN, H-PANID] para la tarjeta de pago móvil C1.
En una etapa S64c, el servidor H-TSP devuelve el correspondiente testigo local H-PAN al servidor TSO, que a su vez la reenvía (S64d) a un servidor R-TSP de un proveedor de servicios de testigos de itinerancia. En un ejemplo concreto, el servidor TSO determina el servidor R-TSP al que se debe enviar el testigo local H-PAN basándose en la red de pago en itinerancia R-NT seleccionada e identificada como tal en la solicitud de aprovisionamiento RQ1. El servidor TSO puede, por ejemplo, acceder a una lista en donde el servidor R-TSP se define en asociación con el identificador ID1 de la red de pago en itinerancia R-NT.
En una etapa S64e, el servidor R-TSP determina, basándose en el testigo local recibido H-PAN, el segundo conjunto de datos DT2 que se debe suministrar a la aplicación de monedero digital DWA. Además, el servidor almacena (S64e) el testigo local recibido H-PAN en asociación con el segundo conjunto de datos DT2.
El servidor R-TSP devuelve (S64d) el segundo conjunto de datos DT2 al servidor TSO, que a su vez lo reenvía (S62) al servidor de monedero digital DWP. El segundo conjunto de datos DT2 es finalmente transmitido (S68) por el servidor de monedero digital DWP al dispositivo móvil DV.
Este segundo conjunto de datos DT2, diferente del primer conjunto DT1, se asigna a la tarjeta de pago móvil para operar en la red de pago en itinerancia R-NT seleccionada. Para este fin, los datos DT2 incluyen un testigo de itinerancia R-PAN y pueden incluir también un identificador correspondiente R-PANID.
El testigo de itinerancia R-PAN, que puede adoptar cualquier forma digital apropiada (como un código, una secuencia de caracteres, etc.), es un dato menos sensible que el número de cuenta C-PAN de la tarjeta de pago. El testigo de itinerancia R-PAN puede ser utilizado por la aplicación de monedero digital DWA en lugar del número de cuenta C-PAN, permitiendo de este modo un sistema de pago más seguro.
En una etapa S70, el dispositivo móvil DV configura la aplicación de monedero digital DWA con el segundo conjunto de datos DT2 recibidos para permitirle llevar a cabo transacciones de pago en la red de pago en itinerancia R-NT seleccionada. En la etapa S70, el dispositivo móvil DV almacena, por ejemplo, el segundo conjunto de datos DT2 en su memoria 4 (figura 4A).
Como parte de esta configuración S70, el dispositivo móvil DV puede personalizar el aspecto visual de la interfaz gráfica de usuario (GUI) de la aplicación de monedero digital DWA con parámetros visuales R-PRM que también se pueden incluir en el segundo conjunto de datos DT2 proporcionado por el servidor TSO. Como resultado, la configuración visual (por ejemplo, la imagen de la tarjeta, el logotipo y/o los colores) de la GUI de la aplicación de monedero digital DWA se puede adaptar para reflejar el sistema de pago en itinerancia utilizado. El usuario UR podrá a su vez darse cuenta fácilmente de que su aplicación de monedero digital DWA se configura en un modo de funcionamiento en itinerancia. En otras palabras, los parámetros visuales R-PRM permiten configurar el aspecto visual de la aplicación de monedero digital DWA para indicar que la tarjeta de pago móvil C1 se utiliza en el dispositivo bancario en itinerancia seleccionado.
En un ejemplo particular, el segundo conjunto de datos DT2 puede comprender una aplicación de pago en itinerancia (distinta de AP1) a instalar en el dispositivo móvil DV para cooperar (interactuar) con la aplicación de monedero digital DWA cuando la tarjeta de pago móvil C1 se utiliza en la red de pago en itinerancia R-NT. En consecuencia, como parte de la configuración S70, el dispositivo móvil DV puede instalar la aplicación de pago en itinerancia para permitir el procesamiento adecuado de una transacción de pago en itinerancia en la red de pago en itinerancia.
Una vez completada esta configuración S70, el usuario UR puede utilizar la aplicación de monedero digital DWA ejecutada en el dispositivo móvil DV para completar una transacción de pago en la red de pago en itinerancia R-NT. Para este fin, el usuario UR puede presentar el dispositivo móvil DV cerca de un terminal de pago T de un comerciante, tal y como se muestra en la figura 6. El dispositivo móvil DV puede cooperar (S80) con el terminal de pago T de cualquier manera apropiada para llevar a cabo un pago móvil. En particular, el dispositivo móvil DV transmite el segundo conjunto de datos DT2, o al menos el testigo de itinerancia R-PAN, de modo que la transacción pueda ser autenticada por el terminal T. Según se ha mencionado anteriormente, se puede evitar por tanto la transmisión de datos sensibles como el número de cuenta C-PAN.
La figura 11 representa una variante de la forma de realización particular descrita anteriormente con referencia a la figura 6. La variante de la figura 11 difiere de la figura 6 en que, cuando el servidor TSO recibe en S64c el testigo local H-PAN, ya ha adquirido y almacenado el correspondiente segundo conjunto de datos DT2. Un proveedor de servicios de testigos puede, por ejemplo, proporcionar por adelantado al servidor TSO un conjunto de datos que incluya el segundo conjunto de datos (testigo de itinerancia R-PAN...). Este conjunto de datos DT2 se almacena a su vez en una memoria del servidor TSO y es recuperado por el servidor TSO una vez que se recibe el H-PAN (S64c) del servidor H-TSP. En otras palabras, el servidor TSO y el servidor R-TSP forman un mismo servidor (el servidor TSO desempeña el papel de servidor R-TSP). Por lo tanto, no es necesario que el servidor TSO interrogue al servidor remoto R-TSP según se representa en la figura 6 (S64d, S64f).
La figura 7 representa, de acuerdo con una forma de realización particular de la invención, cómo el dispositivo móvil DV puede llevar a cabo una transacción de pago utilizando la tarjeta de pago móvil C1 en la red de pago en itinerancia R-NT, una vez completada la configuración S70 (figura 6) con los datos DT2.
En la etapa S80, según ya se ha descrito con respecto a la figura 6, el dispositivo móvil DV envía el testigo de itinerancia R-PAN al terminal de pago T. Otra información incluida en el segundo conjunto de datos DT2, como la fecha de caducidad de la tarjeta de pago C1, se puede transmitir junto con el terminal T.
La interacción S80 entre el dispositivo móvil DV y el terminal de pago T puede proceder de manera análoga a la interacción S12 descrita con respecto a la figura 1. En un ejemplo particular, el dispositivo móvil DV y el terminal de pago T cooperan entre sí de acuerdo con el estándar EMV para llevar a cabo la transacción de pago. Esto se puede hacer mediante una comunicación sin contacto entre el dispositivo móvil DV y el terminal T, utilizando por ejemplo interfaces NFC o similares (Bluetooth, código QR...).
Durante esta interacción S80, la aplicación de monedero digital DWA puede interactuar con la aplicación de pago PA1 desplegada por el banco emisor de la tarjeta móvil de pago C1 o con otra aplicación de pago (no mostrada), denominada aplicación de pago en itinerancia, implementada en el dispositivo móvil DV y destinada a ser utilizada para transacciones en la red de pago en itinerancia R-NT.
El terminal de pago T, situado por ejemplo en un punto de venta de un comerciante, transmite (S82) a su vez los datos de la transacción DR2 al sistema bancario AC de la entidad adquirente (por ejemplo, el banco del comerciante). Los datos de la transacción DR2 contienen cualquier dato (fecha, importe de la transacción...) que caracterice la transacción de pago para permitir su procesamiento posterior, como la autentificación, la validación... En particular, los datos de la transacción DR2 incluyen el testigo de itinerancia R-PAN proporcionado por la aplicación de monedero digital DWA del dispositivo móvil DV.
En una etapa S84, el sistema bancario AC de la entidad adquirente transmite los datos de la transacción DR2 a un servidor de enrutamiento R-SV de la red de pago en itinerancia R-NT. Este servidor R-SV reenvía (S86) el testigo de itinerancia R-PAN al servidor R-TSP del proveedor de servicios de testigos en itinerancia (según ya se ha mostrado en la figura 6). En este ejemplo, el sistema bancario AC de la entidad adquirente, los servidores R-SV y el servidor R-TSP forman parte de la red de pago en itinerancia R-NT.
En una primera etapa de destokenización S88, el servidor R-TSP obtiene (o determina), basándose en el testigo de itinerancia R-PAN, el testigo local H-PAN asignado a la tarjeta de pago móvil C1 para operar en la red de pago local H-NT (diferente de la red de pago en itinerancia R-NT). Para este fin, el servidor R-TSP puede recuperar el testigo local H-PAN a partir de la información almacenada previamente en asociación con el testigo de itinerancia R-PAN en la etapa S64e (figura 6).
El servidor R-TSP devuelve (S90) el testigo local H-PAN al servidor R-SV que lo reenvía (S92), como parte de una solicitud de transacción, a un servidor H-SV de la red de pago local. En la presente forma de realización, esto es posible porque la red de pago local H-NT y la red de pago en itinerancia R-NT están conectadas por medio de una conexión de anfitrión a anfitrión (o de servidor a servidor). Esta conexión de anfitrión a anfitrión significa que existe una conexión directa entre los dos servidores R-SV y H-SV. Entre los servidores R-SV y H-SV no hay ninguna red intermediaria ni ningún conmutador que garantice la comunicación.
El servidor H-SV reenvía (S94) el testigo de itinerancia H-PAN al servidor H-TSP del proveedor de servicios de testigo local (según ya se ha mostrado en la figura 6).
En una segunda etapa de destokenización S96, el servidor H-TSP obtiene (o determina), basándose en el testigo local H-PAN, el número PAN C-PAN de la tarjeta de pago móvil C1 asignado por el emisor bancario. Para este fin, el servidor H-TSP puede recuperar el número de cuenta principal C-PAN a partir de la información previamente almacenada en asociación con el testigo local H-PAN en la etapa S5 (figura 1).
El servidor H-TSP devuelve (S98) el número de cuenta C-PAN al servidor H-SV, que lo reenvía (S100) al sistema bancario IS del emisor como parte de una solicitud de transacción, junto con cualquier otra información útil que se pueda haber recibido en los datos de la transacción DR2 (importe, fecha...). Según ya se ha mencionado con respecto a la figura 2, el emisor IS puede ser, por ejemplo, el banco emisor de la tarjeta de pago móvil C1.
El emisor IS puede procesar a su vez la transacción de pago basándose en el número de cuenta C-PAN asignado a la tarjeta de pago móvil C1 para operar con la red de pago local H-NT.
En este ejemplo, el sistema bancario IS del emisor, los servidores H-SV y el servidor H-TSP forman parte de la red de pago local R-NT.
Los servidores H-TSP y R-TSP forman juntos un sistema de gestión de testigos S1 que se configura para llevar a cabo una doble destokenización, es decir, la primera destokenización S88 (R-PAN convertido en H-PAN) y la segunda destokenización S96 (H-PAN convertido en C-PAN).
Gracias a este doble proceso de destokenización, se puede lograr la interoperabilidad entre diferentes sistemas de pago, garantizando al mismo tiempo que las transacciones de pago se lleven a cabo de forma segura.
La figura 8 representa, de acuerdo con otra forma de realización de la invención, cómo se puede llevar a cabo una transacción de pago por el dispositivo móvil DV utilizando la tarjeta de pago móvil C1 en la red de pago en itinerancia R-NT, una vez completada la configuración S70 (figura 6) con los datos DT2.
El proceso de transacción se lleva a cabo en esencia según se muestra en la figura 7, salvo que se supone que en este caso no se puede lograr una comunicación de anfitrión a anfitrión entre la red de pago en itinerancia R-NT y la red de pago local H-NT. Esta forma de realización difiere por tanto del ejemplo de la figura 7 en que el servidor TSO ya mencionado anteriormente (figuras 5A y 5B) se utiliza como interfaz de enrutamiento entre la red de pago en itinerancia R-NT y la red de pago local H-NT durante el proceso de transacción.
Según se muestra en la figura 8, una vez que se ha completado la determinación del testigo local S88, el servidor R-TSP envía (S110) e testigo local H-PAN al servidor TSO en una solicitud de transacción. El servidor TSO conduce (S112) la solicitud de transacción incluyendo el testigo local H-PAN desde el servidor R-TSP al servidor H-TSP.
El servidor H-TSP determina el número de cuenta primario C-PAN en la etapa S96 y el procesamiento de la transacción continúa de la misma manera que en la forma de realización de la figura 7.
Los servidores H-TSP, el servidor TSO y el servidor R-TSP forman juntos un sistema de gestión de testigos S2 que se configura para llevar a cabo una doble destokenización, es decir, la primera destokenización S88 (R-PAN convertido en H-PAN) y la segunda destokenización S96 (H-PAN convertido en C-PAN).
Se debe tener en cuenta que el enrutamiento S112 del testigo local H-PAN al servidor H-TSP se puede llevar a cabo por un servidor que no esté encargado de proporcionar la información de itinerancia RI al dispositivo móvil DV (etapas S42-S46, figura 3) o de aprovisionar el conjunto de datos DT2 (etapas S62-S66 figura 6) en primer lugar. En una variante, el enrutamiento S112 mostrado en la figura 8 se lleva a cabo por cualquier servidor apropiado distinto del servidor TSO descrito anteriormente.
La figura 9A muestra, de acuerdo con una forma de realización particular de la invención, la estructura del servidor R-TSP según ya se ha descrito anteriormente. En este ejemplo, el servidor R-TSP presenta la arquitectura de hardware de un ordenador. En particular, el servidor R-TSP comprende un procesador 40, una memoria 42 no volátil reescribible (por ejemplo, una Flash), una memoria RAM 44 y una interfaz de comunicación 46. Algunos elementos normalmente incluidos en un servidor han sido voluntariamente omitidos en la presente forma de realización para mejorar la claridad de la presente descripción.
La memoria no volátil reescribible 42 del servidor R-TSP constituye un medio de grabación no transitorio de acuerdo con una forma de realización particular de la invención. Esta memoria incluye un programa informático PG3 de acuerdo con una forma de realización particular de la invención, comprendiendo este programa informático instrucciones para implementar un método de acuerdo con una forma de realización particular de la invención según ya se ha descrito con referencia a las figuras 7 y 8.
La memoria no volátil regrabable 42 también puede almacenar datos R-DT que comprenden el testigo local H-PAN en asociación con el testigo de itinerancia R-PAN de la tarjeta de pago móvil C1 (según ya se ha descrito con referencia a la figura 6).
La interfaz de comunicación 46 permite al servidor R-TSP comunicarse dentro de la red de pago en itinerancia R-NT y, en el caso particular de la figura 8, con el servidor TSO.
El procesador 40, pilotado por el programa informático PG3, implementa una serie de módulos funcionales según se representa en la figura 9B, es decir: un módulo receptor MD40, un módulo de obtención MD42 y un módulo de envío MD44.
El módulo receptor MD40 se configura para recibir el testigo de itinerancia R-PAN asignado a la tarjeta de pago móvil C1 para operar en la red de pago en itinerancia R-NT, según ya se ha descrito con respecto a las figuras 7 y 8.
El módulo de obtención MD42 se configura para determinar, basándose en el testigo de itinerancia R-PAN, el correspondiente testigo local H-PAN asignado a la tarjeta de pago móvil C1 para operar en la red de pago local H-NT que es diferente de la red de pago en itinerancia R-NT. Para este fin, el módulo de obtención MD42 consulta los datos almacenados R-DT.
El módulo de envío MD44 se configura para enviar el testigo local H-PAN al servidor R-SV (figure 7) o al servidor TSO (figure 8).
La figura 10A muestra, de acuerdo con una forma de realización particular de la invención, la estructura del servidor H-TSP según ya se ha descrito anteriormente con respecto a las figuras 7-8. En este ejemplo, el servidor H-TSP presenta la arquitectura de hardware de un ordenador. En particular, el servidor H-TSP comprende un procesador 50, una memoria no volátil reescribible 52 (por ejemplo, una Flash), una memoria RAM 54 y una interfaz de comunicación 56. Algunos elementos normalmente incluidos en un servidor han sido voluntariamente omitidos en la presente forma de realización para mejorar la claridad de la presente descripción.
La memoria no volátil reescribible 52 del servidor H-TSP constituye un medio de grabación no transitorio de acuerdo con una forma de realización particular de la invención. Esta memoria incluye un programa informático PG4 de acuerdo con una forma de realización particular de la invención, comprendiendo este programa informático instrucciones para implementar un método de acuerdo con una forma de realización particular de la invención según ya se ha descrito con referencia a las figuras 7 y 8.
La memoria no volátil regrabable 52 también puede almacenar datos H-DT que comprenden el número de cuenta C-PAN en asociación con el testigo local H-PAN de la tarjeta de pago móvil C1 (según ya se ha descrito con referencia a la figura 6).
La interfaz de comunicación 56 permite al servidor H-TSP comunicarse dentro de la red de pago local R-NT y, en el caso particular de la figura 8, con el servidor TSO.
El procesador 50, pilotado por el programa informático PG4, implementa una serie de módulos funcionales según se representa en la figura 10B, es decir: un módulo receptor MD50, un módulo de obtención MD52 y un módulo de envío MD54.
El módulo receptor MD50 se configura para recibir el testigo local H-PAN asignado a la tarjeta de pago móvil C1 para operar en la red de pago local H-NT, según ya se ha descrito con respecto a las figuras 7 y 8.
El módulo de obtención MD52 se configura para determinar, basándose en el testigo local H-PAN, el PAN correspondiente, denominado C-PAN, asignado a la tarjeta de pago móvil C1 para operar en la red de pago local H-NT. Para este fin, el módulo de obtención MD52 consulta los datos almacenados H-DT.
El módulo de envío MD54 se configura para enviar el número de cuenta C-PAN al sistema del banco emisor IS.
La presente invención proporciona una solución de pago móvil en itinerancia eficiente. En particular, en lugar de utilizar una única red de pago global, la invención permite una interoperabilidad eficiente de las tarjetas de pago móviles con múltiples redes de pago a las que un usuario puede acceder utilizando su dispositivo móvil.
Según se ha mencionado anteriormente, un usuario que se desplaza en itinerancia por diferentes áreas (por ejemplo, cambiando de país) se puede encontrar fuera del alcance de una red de pago nacional con la que su tarjeta de pago móvil esté configurada para operar. Además, es posible que un usuario no desee o no pueda utilizar una red de pago internacional. La invención permite configurar una aplicación de monedero digital de modo que pueda utilizar una tarjeta de pago móvil mientras se encuentra en situación de itinerancia en una determinada red de pago en itinerancia. Gracias a la invención, es posible adaptar dinámicamente la configuración de una aplicación de monedero digital de modo que se puedan realizar transacciones en un sistema de pago en itinerancia, como una red de pago local o nacional.
La invención evita la necesidad de una red de pago global (internacional). En lugar de utilizar redes de pago globales, cuando un usuario se encuentra en itinerancia fuera de su red de pago nacional (o regional), una transacción bancaria móvil se puede llevar a cabo ventajosamente en otra red de pago nacional (o regional). La invención puede garantizar una interoperabilidad adecuada entre distintos sistemas de pago con especificaciones diferentes, de tal forma que ya no sea necesario utilizar una red de pago internacional. Los sistemas bancarios nacionales pueden obtener aceptación internacional por medio de acuerdos de itinerancia con otros sistemas bancarios. Se pueden firmar, por ejemplo, contactos bilaterales de coidentificación estándar e integraciones de anfitrión a anfitrión.
Gracias a la invención, un dispositivo móvil puede configurar de forma automática una aplicación de monedero digital en función de la posición del dispositivo móvil. Los parámetros y aspectos visuales (logotipo, apariencia...) de la aplicación de monedero digital se pueden adaptar en consecuencia para informar al usuario de la reconfiguración de la itinerancia. En particular, la imagen de la tarjeta, el logotipo y/o los colores se pueden adaptar en función de las necesidades.
Se garantiza la interoperabilidad entre los socios del sistema, al tiempo que se puede mantener un nivel adecuado de seguridad en el proceso de transacción. Al llevar a cabo una doble destokenización durante la transacción, la invención permite que cada sistema de pago utilice sus testigos de manera eficiente.
La invención supera los problemas e inconvenientes mencionados anteriormente y ello sin la carga que supone concebir y desplegar un sistema de pago normalizado a escala mundial.
La aplicación de monedero digital puede contener y gestionar varias tarjetas de pago móviles y permitir que cada una de estas tarjetas se utilice en una red de pago en itinerancia de acuerdo con la presente invención. Se puede implementar una aplicación de pago específica en el dispositivo móvil para cada tarjeta de pago móvil presente en el monedero digital.
Variantes particulares de las formas de realización mostradas en las figuras 7 y 8 se describen ahora con referencia a las figuras 12-15.
Más particularmente, la figura 12 representa una variante que difiere de la forma de realización de la figura 8 en que es el servidor TSO el que lleva a cabo la primera destokenización obteniendo el testigo local H-PAN basado en el testigo de itinerancia. Esto es posible porque el servidor ha almacenado previamente el testigo local H-PAN en asociación con el testigo de itinerancia R-PAN, según se describe por ejemplo en la variante mostrada en la figura 11. En la variante mostrada en la figura 12, el servidor R-TSP no lleva a cabo por tanto la primera etapa de destokenización S88 y transmite en S110 el testigo de itinerancia R-PAN al servidor TSO. Es el servidor TSO el que convierte el testigo de itinerancia R-PAN en el correspondiente testigo local H-PAN y transmite este H-PAN en S112 al servidor H-TSP.
En otra variante, el servidor R-SV transmite el testigo de itinerancia R-PAN en S86 directamente al servidor TSO. En este caso, no hay necesidad de que el servidor R-TSP transmita el testigo de itinerancia R-PAN desde el servidor R-SV al servidor TSO.
Según se puede entender a partir de las formas de realización descritas anteriormente, el proceso de doble destokenización se puede llevar a cabo en varios servidores u otras entidades.
La figura 13 representa una variante que difiere de las formas de realización anteriores de las figuras 8, 9 y 12 en que el terminal de pago T (en un punto de venta, por ejemplo) no tiene la capacidad de comunicarse bilateralmente con el dispositivo de usuario DV. En esta variante, cuando el usuario UR y un comerciante desean iniciar una transacción de pago, el comerciante configura el terminal de pago T de modo que muestre en una pantalla un código gráfico, como un código QR (o código de barras), por ejemplo. El usuario UR coloca su dispositivo móvil DV orientada hacia el terminal de pago y el dispositivo móvil DV adquiere o lee (S150) el código QR utilizando una cámara (no mostrada) del dispositivo móvil DV (proceso de escanear y pagar). El dispositivo móvil DV a su vez determina, basándose en el código QR, el conjunto de datos DT2 según se ha descrito en las formas de realización anteriores, y transmite (S154) este conjunto de datos DT2 a un servidor M-SV del comerciante. El conjunto de datos DT2 comprende el testigo de itinerancia R-PAN e información sobre la transacción (identificador de transacción, importe...). Basándose en el código QR, el dispositivo móvil DV también puede determinar la dirección del servidor M-SV al que se debe transmitir el conjunto de datos DT2.
Paralelamente, el terminal de pago transmite también (S152) datos de la transacción DT3 que comprenden, por ejemplo, el identificador de la transacción y el importe de la transacción. El servidor M-SV del comerciante comprueba a su vez que el conjunto de datos DT2 recibidos del dispositivo móvil DV y los datos de la transacción DT3 recibidos del terminal de pago T coinciden y, si hay coincidencia, el servidor M-SV del comerciante transmite (S156) el conjunto de datos DT2 al sistema bancario AC de la entidad adquirente para su posterior procesamiento, según se describe en las demás formas de realización.
Según se puede entender a partir de la forma de realización de la figura 13, un proceso de escaneo y pago se puede aplicar al concepto de la presente invención que se basa en la doble tokenización y doble destokenización.
La figura 14 representa una variante que difiere de las formas de realización anteriores en que se lleva a cabo un proceso de autentificación 3-D Secure (3DS) para autenticar a un usuario UR que desea llevar a cabo una transacción de pago en línea.
3-D Secure es un conocido protocolo basado en XML diseñado como una capa de seguridad adicional para las transacciones de pago en línea.
En la variante de la figura 14, se supone que el usuario UR lleva su primer dispositivo móvil DV para acceder a su aplicación de monedero digital DWA y desea llevar a cabo una transacción de pago en línea en el sitio web de un comerciante WB. Para este fin, el usuario utiliza un segundo dispositivo DV2 para acceder al sitio web del comerciante WB. El segundo dispositivo DV2 puede ser de cualquier tipo (PC, tableta...) y puede ser el mismo que el primer dispositivo DV1 o diferente del primer dispositivo DV1.
Primero se lleva a cabo una fase de autentificación de acuerdo con el protocolo IDS para autenticar al usuario UR antes de validar la transacción de pago.
En una etapa S170, el usuario UR configura su dispositivo móvil DV de modo que muestre el testigo de itinerancia R-PAN que se asignó previamente al usuario (según se ha descrito anteriormente) para llevar a cabo pagos en itinerancia en la red de pago en itinerancia R-NT. El usuario UR utiliza a su vez su segundo dispositivo DV2 para introducir (S172), en el sitio web del comerciante WB, los datos de tarjeta asignados a la tarjeta de pago móvil C1 para operar en la red de pago en itinerancia R-NT, incluyendo estos datos de tarjeta el testigo de itinerancia R-PAN, la fecha de caducidad y el valor de verificación de tarjeta CVV de la tarjeta móvil C1. En una etapa S174, el segundo dispositivo DV2 transmite los datos de la tarjeta, incluido el testigo de itinerancia R-PAN, a un servidor M-SV del comerciante que gestiona el sitio web WB.
Este servidor M-SV transmite (S176) el testigo de itinerancia R-PAN a un servidor de directorio DS que a su vez lo transmite (S178) a un servidor TSO2 de un proveedor de servicios de testigos. El servidor TSO2 puede ser el mismo que el servidor TSO o uno diferente.
En una etapa S180, el servidor TSO2 transmite el testigo de itinerancia R-PAN al servidor R-TSP que lleva a cabo una primera destokenización para obtener el testigo local H-PAN basado en el R-PAN. El servidor R-TSP transmite (S182) a su vez el testigo local H-PAN resultante de esta primera destokenización de vuelta al servidor TSO2. En la etapa S184, el servidor TSO2 transmite el testigo local H-PAN al servidor H-TSP que lleva a cabo una segunda destokenización para obtener el correspondiente número PAN C-PAN de la tarjeta de pago móvil C1 basándose en el testigo local H-pAn . El servidor H-TSP transmite (S186) a su vez el número PAN C-PAN de vuelta al servidor TSO2. De este modo, los servidores R-TSP y H-TSP llevan a cabo una doble destokenización para obtener el número PAN C-PAN de la tarjeta C1 basándose en el testigo de itinerancia R-PAN.
En una etapa S188, el servidor TSO2 envía el número PAN C-PAN a un servidor de control de accesos IS (ACS), denominado servidor ACS. Basándose en el número PAN C-PAN, el servidor ACS determina la información de contacto asociada con el usuario UR. En este ejemplo, el servidor ACS determina un número de teléfono almacenado en asociación con el C-PAN de la tarjeta de pago móvil C1. En una etapa S190, el servidor ACS transmite un código 3DS CS1 (una secuencia de números, por ejemplo) al usuario UR. En este ejemplo, el UR recibe el código CD1 en su dispositivo móvil DV (por ejemplo, un teléfono inteligente).
El usuario UR puede a su vez introducir (S191) el código 3DS, anotado CD2, en el sitio web WB utilizando su segundo dispositivo DV2. Una vez recibido, el segundo dispositivo DV2 transmite (S192) el código 3DS CD2 al servidor ACS por cualquier medio de comunicación apropiado. Sin embargo, son posibles otras formas de realización para proporcionar al servidor ACS el código 3SD CD2. Según otra forma de realización, en la etapa S190, una aplicación móvil en el dispositivo móvil DV puede recibir una solicitud de autentificación del servidor ACS. El usuario UR puede utilizar esta aplicación móvil para autenticarse en S191 introduciendo el código 3DS recibido en S190. La aplicación móvil en el dispositivo móvil DV puede a su vez reenviar en S192 el código 3DS al servidor ACS para confirmar la autentificación.
El servidor ACS comprueba a su vez si el código 3DS CD2 introducido por el usuario UR en el dispositivo DV2 coincide con el código original CD1 que fue proporcionado previamente por el servidor ACS en la etapa S190. En caso de coincidencia, el servidor ACS transmite (S193) una notificación al servidor TSO2, indicando que la autentificación se ha realizado correctamente. En respuesta a ello, el servidor TSO2 genera un criptograma CRY, denominado criptograma de verificación de autentificación, y lo transmite (S194) al servidor de directorios DS, que lo reenvía (S196) al servidor M-SV. En una etapa S198, el servidor M-SV transmite el criptograma CRY y los datos de la transacción, incluido el testigo de itinerancia R-PAN, al sistema bancario AC de la entidad adquirente para que proceda con la transacción de pago.
Según se ha descrito en las formas de realización anteriores, se vuelve a llevar a cabo una doble destokenización para validar la operación de pago. El sistema bancario IS del emisor autoriza la transacción de pago únicamente si recibe el criptograma CRY que indica que el usuario UR ha sido autenticado.
Según se puede deducir de esta forma de realización, el proceso de autentificación 3DS se puede aplicar al concepto de la presente invención que se basa en la doble tokenización y la doble destokenización.
Normalmente, ni los comerciantes ni los emisores de tarjetas de pago están obligados a soportar 3DS para las transacciones en línea. En caso de que el comerciante y/o el emisor no admitan 3DS, el segundo dispositivo DV2 puede, a su vez, en la etapa S174, transmitir directamente los datos de la transacción, incluido el testigo de itinerancia R-PAN, al sistema bancario AC de la entidad adquirente para proceder con la transacción de pago. Por lo tanto, las etapas S176 a S198 no se llevan a cabo (figura 14).
La figura 15 representa una variante que difiere de las formas de realización anteriores en que la aplicación APP1 de un comerciante está preinstalada en el dispositivo móvil DV del usuario UR. En un caso en el que el usuario UR desea llevar a cabo una transacción de pago en línea en el sitio web de un comerciante utilizando su dispositivo móvil DV, el usuario UR puede ejecutar o invocar (S220) la aplicación APP1 preinstalada en el dispositivo móvil DV. En la práctica, el usuario UR puede completar el pago activando un botón de pago en la aplicación APP1 del comerciante ejecutada en el dispositivo móvil DV. En respuesta a ello, el dispositivo móvil DV transmite (S222) los datos de tarjeta de la tarjeta de pago móvil C1 a un servidor proveedor de pago CP-SV, es decir, los datos de tarjeta, incluido el testigo de itinerancia R-PAN, que se asignó previamente a la tarjeta de pago móvil C1 para operar en la red de pago en itinerancia R-NT.
En una etapa S224, el servidor CP-SV transmite los datos de la tarjeta incluyendo el testigo de itinerancia R-PAN a un servidor M-SV de un comerciante. El servidor M-SV transmite (S226) a su vez los datos de la transacción junto con el testigo de itinerancia R-PAN al sistema bancario AC del adquirente para proceder con la transacción de pago según ya se ha descrito anteriormente.
Según se puede entender a partir de esta forma de realización, un proceso de transacción en línea dentro de una aplicación se puede aplicar al concepto de la presente invención que se basa en la doble tokenización y doble destokenización.
Las variantes descritas anteriormente con respecto a la figura 12 se pueden aplicar a cualquier forma de realización descrita en el presente documento, incluyendo las formas de realización representadas en las figuras 13, 14 y 15. Es decir, el servidor TSO se puede configurar para llevar a cabo la primera etapa de destokenización por sí mismo para todas las formas de realización descritas en el presente documento.
Los diagramas de flujo y/o diagramas de bloques de las figuras ilustran la configuración, operación y funcionalidad de posibles implementaciones de dispositivos, sistemas, métodos y productos de programas informáticos de acuerdo con varias formas de realización de la presente descripción. En este sentido, cada bloque en los diagramas de flujo o de bloques puede representar un módulo, segmento o parte de código, que comprende una o más instrucciones ejecutables para implementar la(s) función(es) lógica(s) especificada(s).
Habiendo sido descrita la presente invención con formas de realización particulares, es evidente que es susceptible de numerosas modificaciones dentro del alcance de las siguientes reivindicaciones.

Claims (11)

REIVINDICACIONES
1. Un método de procesamiento implementado por un sistema (S1; S2) que comprende un dispositivo móvil (DV), un primer servidor (H-TSP) de un proveedor de servicios de testigo local, un segundo servidor (R-TSP) de un proveedor de servicios de testigos de itinerancia, un tercer servidor (H-SV) de una red bancaria local (H-NT) y un cuarto servidor (R-SV) de una red bancaria en itinerancia (R-NT) que tiene especificaciones que difieren de la red bancaria local, comprendiendo dicho método sucesivamente:
- recibir (S84), por el cuarto servidor (R-SV) de la red bancaria en itinerancia (R-NT), desde un primer sistema bancario (AC) de un adquirente, un testigo de itinerancia (R-PAN) como parte de los datos de transacción que caracterizan una operación de pago llevada a cabo por una aplicación de monedero digital (DWA) utilizando una tarjeta de pago móvil (C1) en la red bancaria en itinerancia (R-NT), estando adaptado dicho testigo de itinerancia para permitir la autentificación en la red bancaria en itinerancia (R-NT) de las transacciones de pago llevadas a cabo por la aplicación de monedero digital (DWA), en donde la aplicación de monedero digital (DWA) es implementada por el dispositivo móvil y el dispositivo móvil implementa una aplicación de pago (PA1) que coopera con la aplicación de monedero digital (DWA) para llevar a cabo una transacción de pago con respecto a la tarjeta de pago móvil (C1) en la red bancaria local (H-NT), y el dispositivo móvil (DV) también implementa una aplicación de pago en itinerancia distinta de la aplicación de pago (PA1), cooperando la aplicación de pago en itinerancia con la aplicación de monedero digital (DWA) para permitir el procesamiento adecuado de una transacción de pago con respecto a la tarjeta de pago móvil (C1) en itinerancia en la red de pago en itinerancia (R-NT);
- recibir (S86), por el segundo servidor (R-TSP) desde el cuarto servidor (R-SV), dicho testigo de itinerancia (R-PAN) asignado a la tarjeta de pago móvil (C1) para operar en la red bancaria en itinerancia (R-NT);
- obtener (S88), por el segundo servidor (R-TSP), basándose en el testigo de itinerancia (R-PAN) y en la información almacenada previamente en asociación con dicho testigo de itinerancia (R-PAN), un testigo local (H-PAN) asignado a la tarjeta de pago móvil para operar en la red bancaria local (H-NT) distinta de dicha red bancaria de itinerancia (R-NT), estando adaptado dicho testigo local (H-PAN) para permitir la autentificación en la red bancaria local (H-NT) de las transacciones de pago llevadas a cabo por la aplicación de monedero digital (DWA);
- recibir (S94), por el primer servidor (H-TSP), el testigo local (H-PAN) obtenido por dicho segundo servidor (R-TSP);
- obtener (S96), por el primer servidor (H-TSP), basándose en el testigo local (H-PAN) y en la información almacenada previamente en asociación con dicho testigo local (H-PAN), un número de tarjeta primario (C-PAN) de la tarjeta de pago móvil (C1) para operar en la red bancaria local (H-NT); y
- enviar, por el tercer servidor (H-SV), a un segundo sistema bancario (IS) de un emisor de la tarjeta de pago móvil (C1), una solicitud de transacción que comprenda el número de tarjeta primario (C-PAN) obtenido por el primer servidor (H-TSP) para permitir la transacción de pago en la red bancaria local (H-NT) utilizando dicha tarjeta de pago móvil (C1),
en donde la obtención (S88) por el segundo servidor (R-TSP) y la obtención (S96) llevada a cabo por el primer servidor (H-TSP) llevan a cabo una doble destokenización para lograr la interoperabilidad entre la red bancaria en itinerancia (R-NT) y la red bancaria local (H-NT), garantizando al mismo tiempo que las transacciones de pago se lleven a cabo con seguridad.
2. Método de la reivindicación 1 que comprende, además, sucesivamente, antes de que el segundo servidor reciba (S86) el testigo de itinerancia:
- recibir (S64a), por el primer servidor (H-TSP), un primer identificador (H-PANID) asociado al testigo local (H-PAN);
- determinar (S64b), por el primer servidor (H-TSP), el testigo local (H-PAN) basado en el primer identificador (H-PANID);
- recibir (S64b), por el segundo servidor (R-TSP), el testigo local (H-PAN) determinado por dicho primer servidor (H-TSP); y
- almacenar (S64e), por el segundo servidor (R-TSP), el testigo local (H-PAN) en asociación con el testigo de itinerancia (R-PAN).
3. Método de la reivindicación 1 o 2, estando dichos servidores tercero y cuarto conectados por medio de una conexión de anfitrión a anfitrión, en donde:
- el testigo local (H-PAN) recibido por el tercer servidor (H-SV) se conduce desde el cuarto servidor (R-SV) utilizando la conexión anfitrión a anfitrión entre los servidores tercero y cuarto (H-SV, R-SV).
4. Método de la reivindicación 3, en donde el número de tarjeta principal (C-PAN) es enviado por el tercer servidor (H-SV) en una solicitud de transacción después de recibir dicho número de tarjeta principal del primer servidor (H-TSP).
5. Método de una cualquiera de las reivindicaciones 1 a 4, en donde el sistema comprende además un quinto servidor (TSO) de un operador de servicios de testigo, comprendiendo dicho método, además:
- conducir el quinto servidor (TSO) una solicitud de transacción que incluye el testigo local (H-PAN) desde el segundo servidor (R-TSP) al primer servidor (H-TSP).
6. Un programa informático (PG3; PG4) que incluye instrucciones para ejecutar las etapas de una cualquiera de las reivindicaciones 1 a 5 cuando dicho programa es ejecutado por un ordenador.
7. Un medio de grabación (42; 52) legible por un ordenador y que tiene grabado en el mismo un programa informático que incluye instrucciones para ejecutar las etapas de un método de acuerdo con una cualquiera de las reivindicaciones 1 a 5.
8. Un sistema (S1; S2) que comprende un dispositivo móvil (DV), un primer servidor (H-TSP) de un proveedor de servicios de testigo local, un segundo servidor (R-TSP) de un proveedor de servicios de testigo de itinerancia, un tercer servidor (H-SV) de una red bancaria local (H-NT) y un cuarto servidor (R-SV) de una red bancaria en itinerancia (R-NT) con especificaciones que difieren de la red bancaria local (H-NT),
en donde el dispositivo móvil implementa: una aplicación de monedero digital (DWA), una aplicación de pago (PA1) que coopera con la aplicación de monedero digital (DWA) para llevar a cabo una transacción de pago con respecto a una tarjeta de pago móvil (C1) en la red bancaria local (H-NT), y una aplicación de pago en itinerancia distinta de la aplicación de pago (PA1) que coopera con la aplicación de monedero digital (DWA para) permitir el procesamiento adecuado de una transacción de pago con respecto a la tarjeta de pago móvil (C1) en itinerancia en la red de pago en itinerancia (R-NT);
en donde el cuarto servidor (R-SV) de la red bancaria en itinerancia (R-NT) se configura para recibir, de un primer sistema bancario (AC) de un adquirente, un testigo de itinerancia (R-PAN) como parte de los datos de transacción que caracterizan una transacción de pago llevada a cabo por la aplicación de monedero digital (DWA) utilizando la tarjeta de pago móvil (C1) en la red bancaria en itinerancia (R-NT), estando adaptado dicho testigo de itinerancia para permitir la autentificación en la red bancaria en itinerancia (R-NT) de las transacciones de pago llevadas a cabo por la aplicación de monedero digital (DWA);
en donde dicho segundo servidor (R-TSP) comprende:
- un primer módulo receptor (MD40) para recibir del cuarto servidor (R-SV) el testigo de itinerancia (R-PAN) asignado a la tarjeta de pago móvil (C1) para operar en la red bancaria en itinerancia (R-NT); y
- un primer módulo de obtención (MD42) para obtener, basándose en el testigo de itinerancia (R-PAN) y en la información almacenada previamente en asociación con dicho testigo de itinerancia (R-PAN), un testigo local (H-PAN) asignado a la tarjeta de pago móvil (C1) para operar en la red de banca domiciliaria (H-NT), estando adaptado dicho testigo local (H-PAN) para permitir la autentificación en la red bancaria local (H-NT) de las transacciones de pago llevadas a cabo por la aplicación de monedero digital (DWA);
en donde el primer servidor (H-TSP) comprende:
- un segundo módulo receptor (MD50) para recibir el testigo local (H-PAN) obtenido por dicho primer módulo de obtención (MD42); y
- un segundo módulo de obtención (MD52) para obtener, basándose en el testigo local (H-PAN) y en la información almacenada previamente en asociación con dicho testigo local (H-PAN), un número de tarjeta primario (C-PAN) de la tarjeta de pago móvil (C1) para operar en la red bancaria local (H-NT); y
en donde el tercer servidor (H-SV) se configura para enviar, a un segundo sistema bancario de un emisor de la tarjeta de pago móvil, una solicitud de transacción que comprende el número de tarjeta primario (C-PAN) obtenido por el segundo módulo de obtención (MD52) para permitir la transacción de pago en la red bancaria local (H-NT) utilizando dicha tarjeta de pago móvil (C1),
en donde la obtención por el segundo servidor (R-TSP) y la obtención llevada a cabo por el primer servidor (H-TSP) llevan a cabo una doble destokenización para lograr la interoperabilidad entre la red bancaria en itinerancia (R-NT) y la red bancaria local (H-NT), garantizando al mismo tiempo que las transacciones de pago se llevan a cabo con seguridad.
9. Sistema de la reivindicación 8, en donde:
- el primer servidor (H-TSP) se configura para recibir un primer identificador (H-PANID) asociado al testigo local (H-PAN) y para determinar el identificador de domicilio (H-PAN) basándose en el primer identificador (H-PANID); y - el segundo servidor (R-TSP) se configura, antes de recibir el testigo de itinerancia (R-PAN), para recibir el testigo local (H-PAN) determinado por dicho primer servidor (H-TSP) y para almacenar el testigo local (H-PAN) en asociación con el testigo de itinerancia (R-PAN) para su posterior recuperación por el primer módulo de obtención (MD42).
10. Sistema (S1) de la reivindicación 8 o 9, estando conectados dichos servidores tercero y cuarto por medio de una conexión de anfitrión a anfitrión, en donde:
- el cuarto servidor (R-SV) se configura para conducir el testigo local (H-PAN) al tercer servidor (H-SV) utilizando la conexión anfitrión a anfitrión entre los servidores tercero y cuarto (H-SV, R-SV).
11. Sistema (S2) de la reivindicación 8 o 9, que comprende un quinto servidor (TSO) de un operador de servicios de testigo, estando configurado dicho quinto servidor (TSO) para conducir una solicitud de transacción que incluya el testigo local (H-PAN) desde el segundo servidor (R-TSP) al primer servidor (H-TSP).
ES18726162T 2017-06-15 2018-05-24 Mobile payment roaming Active ES3033832T3 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP17305734.0A EP3416122A1 (en) 2017-06-15 2017-06-15 Mobile payment roaming
PCT/EP2018/063697 WO2018228798A1 (en) 2017-06-15 2018-05-24 Mobile payment roaming

Publications (1)

Publication Number Publication Date
ES3033832T3 true ES3033832T3 (en) 2025-08-08

Family

ID=59215679

Family Applications (1)

Application Number Title Priority Date Filing Date
ES18726162T Active ES3033832T3 (en) 2017-06-15 2018-05-24 Mobile payment roaming

Country Status (10)

Country Link
US (2) US11403623B2 (es)
EP (2) EP3416122A1 (es)
JP (1) JP7265489B2 (es)
CN (1) CN110753943B (es)
AU (2) AU2018283198A1 (es)
BR (1) BR112019026580A2 (es)
CA (1) CA3066021A1 (es)
ES (1) ES3033832T3 (es)
RU (1) RU2742220C1 (es)
WO (1) WO2018228798A1 (es)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112669165B (zh) * 2019-09-27 2024-06-25 徐蔚 一种应用数字人码链的统一接入方法
EP4298578A4 (en) * 2021-02-25 2024-01-31 Visa International Service Association DIGITAL LABEL WITH INTERACTION REQUEST
EP4414920A1 (en) 2023-02-13 2024-08-14 Giesecke+Devrient ePayments GmbH System and method for enabling multi-channel, multi-currency international transactions for domestic payment schemes

Family Cites Families (52)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI102860B1 (fi) 1995-11-07 1999-02-26 Nokia Telecommunications Oy Menetelmä ja järjestelmä elektronisen maksutapahtuman suorittamiseksi
EP0917119A3 (en) * 1997-11-12 2001-01-10 Citicorp Development Center, Inc. Distributed network based electronic wallet
US7248855B2 (en) * 1998-09-15 2007-07-24 Upaid Systems, Ltd. Convergent communications system and method with a rule set for authorizing, debiting, settling and recharging a mobile commerce account
US7376621B1 (en) 2000-01-26 2008-05-20 Paybyclick Corporation Method and apparatus for conducting electronic commerce transactions using electronic tokens
JP2002123772A (ja) 2000-10-11 2002-04-26 Hewlett Packard Co <Hp> 時間や支払い装置の場所に無関係の種々のネットワーク組織による支払いローミング
US6901429B2 (en) * 2000-10-27 2005-05-31 Eric Morgan Dowling Negotiated wireless peripheral security systems
RO123631B1 (ro) 2001-06-29 2015-03-30 Upaid Systems Ltd. Metodă şi sistem de furnizare de servicii de comerţ mobil printr-o multitudine de comunicaţii convergente
US7640579B2 (en) * 2005-09-09 2009-12-29 Microsoft Corporation Securely roaming digital identities
US7886969B2 (en) * 2005-12-06 2011-02-15 Visa U.S.A. Inc. Method and system for loading and reloading portable consumer devices
EP1821249A1 (en) * 2006-02-14 2007-08-22 Lufthansa AirPlus Servicekarten GmbH Technique for interconnecting card payment networks
US20090070246A1 (en) * 2007-09-10 2009-03-12 First Data Corporation Electronic Financial Transaction Routing
RU2010144623A (ru) 2008-04-21 2012-05-27 Камалини МЭЛХОТРА (AU) Устройство, способ и система для осуществления платежей при денежных транзакциях
US20120271757A9 (en) * 2008-05-09 2012-10-25 Shakkarwar Rajesh G Systems and methods for managing accounts payable
EA022027B1 (ru) * 2009-02-14 2015-10-30 Нет2Текст Лимитед Безопасный платеж и способ выставления счета с использованием номера мобильного телефона или абонентского лицевого счета
US20100258620A1 (en) * 2009-04-10 2010-10-14 Denise Torreyson Methods and systems for linking multiple accounts
CN101646153A (zh) * 2009-09-03 2010-02-10 中兴通讯股份有限公司 支持漫游用户的移动电话支付系统、方法及相关装置
US20130185166A1 (en) * 2010-07-20 2013-07-18 Moqom Limited Cardholder mobile device positioning system and method
US9342832B2 (en) * 2010-08-12 2016-05-17 Visa International Service Association Securing external systems with account token substitution
WO2012142045A2 (en) * 2011-04-11 2012-10-18 Visa International Service Association Multiple tokenization for authentication
US8768830B1 (en) * 2011-09-08 2014-07-01 Citibank, N.A. Method and system for a multi-purpose transactional platform
HK1201965A1 (en) 2011-12-13 2015-09-11 维萨国际服务协会 Integrated mobile trusted service manager
US20130254102A1 (en) * 2012-03-20 2013-09-26 First Data Corporation Systems and Methods for Distributing Tokenization and De-Tokenization Services
WO2013166501A1 (en) * 2012-05-04 2013-11-07 Visa International Service Association System and method for local data conversion
US20140164243A1 (en) * 2012-12-07 2014-06-12 Christian Aabye Dynamic Account Identifier With Return Real Account Identifier
US10043181B2 (en) * 2013-01-15 2018-08-07 Mastercard International Incorporated Systems and methods for processing off-network transaction messages
US10019766B2 (en) * 2013-01-31 2018-07-10 Facebook, Inc. Method, medium, and system for enabling gift card transactions
US10311426B2 (en) * 2013-02-05 2019-06-04 Visa International Service Association Integrated communications network for transactions
US10460307B2 (en) * 2013-03-13 2019-10-29 Rogers Communications Inc. Methods and devices for fraud detection based on roaming status
CN113469670B (zh) * 2013-07-24 2024-04-05 维萨国际服务协会 使用令牌确保数据传送风险的系统和方法
US20150041534A1 (en) * 2013-08-07 2015-02-12 1 Oak Technologies, LLC Electronic payment transponder
US10496986B2 (en) * 2013-08-08 2019-12-03 Visa International Service Association Multi-network tokenization processing
GB201317109D0 (en) * 2013-09-26 2013-11-06 Mastercard International Inc Account Information
CN106464492B (zh) 2013-10-11 2020-02-07 维萨国际服务协会 网络令牌系统
US10515358B2 (en) * 2013-10-18 2019-12-24 Visa International Service Association Contextual transaction token methods and systems
BR112016014106A2 (pt) * 2013-12-19 2017-08-08 Visa Int Service Ass Método para intensificar a segurança de um dispositivo de comunicação, e, dispositivo de comunicação
US9600844B2 (en) * 2014-03-04 2017-03-21 Bank Of America Corporation Foreign cross-issued token
US10002352B2 (en) * 2014-03-04 2018-06-19 Bank Of America Corporation Digital wallet exposure reduction
US9224141B1 (en) * 2014-03-05 2015-12-29 Square, Inc. Encoding a magnetic stripe of a card with data of multiple cards
US9324067B2 (en) * 2014-05-29 2016-04-26 Apple Inc. User interface for payments
US9780953B2 (en) * 2014-07-23 2017-10-03 Visa International Service Association Systems and methods for secure detokenization
US9692752B2 (en) 2014-11-17 2017-06-27 Bank Of America Corporation Ensuring information security using one-time tokens
KR20160112133A (ko) 2015-03-18 2016-09-28 (주)이삭랜드코리아 외국 관광객을 위한 휴대 단말 앱 기반 간편 결제 방법 및 시스템
US9984371B2 (en) * 2015-03-27 2018-05-29 Ca, Inc. Payment de-tokenization with risk evaluation for secure transactions
US10152714B2 (en) * 2015-04-29 2018-12-11 Capital One Services, LLP System to automatically restore payment purchasing power
US10475020B2 (en) * 2015-05-01 2019-11-12 At&T Mobility Ii Llc Mobile device roaming status subscription
US10311423B2 (en) * 2015-06-09 2019-06-04 Zumigo, Inc. System and method for transaction approval based on confirmation of proximity of mobile subscriber device to a particular location
US20170004499A1 (en) * 2015-07-02 2017-01-05 Mastercard International Incorporated Method and system for cross-border travel alerts
EP3136309A1 (en) 2015-08-28 2017-03-01 Samsung Electronics Co., Ltd. Payment information processing method and apparatus of electronic device
SG10201914040YA (en) * 2015-09-10 2020-03-30 Verrency Holdings Ltd Proxy device for representing multiple credentials
US20170186008A1 (en) * 2015-12-29 2017-06-29 Ca, Inc. Methods and apparatus for authenticating and authorizing secondary accounts
US11423395B1 (en) * 2016-12-29 2022-08-23 Wells Fargo Bank, N.A. Pay with points virtual card
SG10201800711VA (en) * 2018-01-26 2019-08-27 Mastercard International Inc Computer system and computer-implemented method for secure e-commerce

Also Published As

Publication number Publication date
RU2742220C1 (ru) 2021-02-03
EP3416122A1 (en) 2018-12-19
BR112019026580A2 (pt) 2020-06-23
US20220245622A1 (en) 2022-08-04
CN110753943A (zh) 2020-02-04
AU2018283198A1 (en) 2019-12-19
AU2024202326A1 (en) 2024-05-02
CA3066021A1 (en) 2018-12-20
EP3639231B1 (en) 2025-04-16
WO2018228798A1 (en) 2018-12-20
EP3639231C0 (en) 2025-04-16
JP7265489B2 (ja) 2023-04-26
EP3639231A1 (en) 2020-04-22
US12475450B2 (en) 2025-11-18
CN110753943B (zh) 2024-01-23
AU2024202326B2 (en) 2025-10-23
JP2020523701A (ja) 2020-08-06
US20200202332A1 (en) 2020-06-25
US11403623B2 (en) 2022-08-02

Similar Documents

Publication Publication Date Title
ES3061238T3 (en) Digital wallet application for mobile payment
AU2016320876B2 (en) Method and apparatus for facilitating electronic payments using a wearable device
ES2971531T3 (es) Aparato para implementar una plataforma de gestión de suscripciones fiable
CA2913456C (en) Communication control apparatus, authentication device, central control apparatus and communication system
AU2024202326B2 (en) Mobile payment roaming
CA3066609C (en) Digital wallet application for mobile payment
BR112019026608B1 (pt) Método implementado por um dispositivo móvel para gerenciar um aplicativo de carteira digital, método de processamento implementado por um primeiro servidor em cooperação com um dispositivo móvel gerenciando um aplicativo de carteira digital, memória legível por computador, dispositivo móvel e primeiro servidor configurado para implementar um método de processamento em cooperação com um dispositivo móvel gerenciando um aplicativo de carteira digital
HK40025697A (en) Digital wallet application for mobile payment
HK40025697B (zh) 用於移动支付的数字钱包应用
KR20130138956A (ko) 자원 할당을 이용한 일회용코드 운영 방법