ES2856696T3 - Contenedor de pago, procedimiento de creación, procedimiento de tratamiento, dispositivos y programas correspondientes - Google Patents

Contenedor de pago, procedimiento de creación, procedimiento de tratamiento, dispositivos y programas correspondientes Download PDF

Info

Publication number
ES2856696T3
ES2856696T3 ES16177234T ES16177234T ES2856696T3 ES 2856696 T3 ES2856696 T3 ES 2856696T3 ES 16177234 T ES16177234 T ES 16177234T ES 16177234 T ES16177234 T ES 16177234T ES 2856696 T3 ES2856696 T3 ES 2856696T3
Authority
ES
Spain
Prior art keywords
payment
container
payment container
user
communication terminal
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
ES16177234T
Other languages
English (en)
Inventor
Pierre Quentin
Vincent Ducrohet
Michel Leger
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.)
Worldline MS France
Original Assignee
Ingenico Group SA
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 Ingenico Group SA filed Critical Ingenico Group SA
Application granted granted Critical
Publication of ES2856696T3 publication Critical patent/ES2856696T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/409—Device specific authentication in transaction processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Theoretical Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Computer Security & Cryptography (AREA)
  • Marketing (AREA)
  • Technology Law (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Procedimiento de puesta en práctica de una transacción de pago por intermedio de una estructura de datos de pago, denominada contenedor de pago, comprendiendo el citado contenedor de pago al menos un dato representativo de un identificador bancario de un usuario, comprendiendo el citado procedimiento: - una fase de creación del citado contenedor de pago, puesta en práctica por un terminal de comunicación, que comprende: - la selección (C20), por el usuario y por intermedio de una interfaz hombre-máquina, de al menos un atributo para el citado contenedor de pago, comprendiendo la citada selección al menos un valor de atributo para al menos uno de los parámetros siguientes: - categoría de beneficiario del contenedor de pago; - beneficiario del contenedor de pago; - la obtención (C30), por el terminal de comunicación, de al menos un dato representativo de una tarjeta bancaria del usuario; - la validación (C40), por el usuario y por intermedio de la citada interfaz hombre-máquina, de la creación del contenedor de pago; - la creación, a continuación de la validación, del citado contenedor de pago, comprendiendo el citado contenedor de pago el citado al menos un atributo seleccionado y el citado al menos un dato representativo de una tarjeta bancaria del usuario; - la transmisión (C50), por el citado terminal de comunicación, del citado contenedor de pago a un servidor de tratamiento de contenedor de pago; - la recepción, por el citado terminal de comunicación, proveniente del citado servidor de tratamiento, de un identificador atribuido al citado contenedor de pago por el servidor de tratamiento de contenedor de pago; - una fase de utilización del citado contenedor de pago para la realización de la transacción de pago en un comerciante que tiene un terminal de pago, que comprende: - la recepción, por el citado terminal de pago proveniente del citado terminal de comunicación, del citado identificador atribuido al citado contenedor de pago por el servidor de tratamiento; - la puesta en práctica, por el terminal de pago, de la transacción de pago en relación con el servidor de tratamiento.

Description

DESCRIPCIÓN
Contenedor de pago, procedimiento de creación, procedimiento de tratamiento, dispositivos y programas correspondientes
1. Ámbito
La presente invención se refiere a la problemática del pago. De modo más particular, la invención se refiere a la problemática del pago por tarjeta bancaria. En Europa, la tarjeta bancaria es el medio de pago más utilizado. La misma es utilizada a la vez físicamente para realizar pagos en las tiendas; Se utiliza igualmente para realizar pagos en línea. Sin embargo, está expuesta también a fraudes.
2. Técnica anterior
Una tarjeta bancaria permite realizar compras según dos tipos de procedimientos diferentes: compas de tipo «tarjeta presente» son realizadas cuando el usuario presenta físicamente su tarjeta bancaria a un comerciante, el cual tiene un terminal de pago físico. En esta configuración, en función de los países, de las legislaciones y de los terminales de pago a disposición, el usuario (el comprador) puede utilizar una tarjeta inteligente (denominada igualmente «smartcard», o bien una tarjeta de banda magnética (este es por ejemplo el caso en los Estados Unidos), o incluso una tarjeta sin contacto. Existen igualmente tarjetas multimodales que comprenden las tres tecnologías anteriormente citadas. Son posibles igualmente compras del tipo de «tarjeta no presente» (CNP) utilizando una tarjeta bancaria. Se trata principalmente de compas en línea e igualmente por teléfono las cuales son realizadas utilizando un ordenador, una tableta, un smartphone o un teléfono. Para realizar este tipo de compras, el usuario introduce, o comunica verbalmente datos visuales de su tarjeta: número de tarjeta, fecha de validez, nombre del titular, criptograma visual. Estos datos son transmitidos, por intermedio de una red de comunicación, a uno o varios servidores, con el fin de que el pago pueda ser realizado.
La diferencia entre estos dos tipos de pago es importante. Tan fácil es utilizar una tarjeta bancaria en modo de «tarjeta presente», como tedioso es tener que introducir datos de tarjetas bancarias en formularios de pagos web. Así, muchas personas almacenan sus datos de tarjeta de crédito en el seno de un archivo para hacer las operaciones de pago más simples. Soluciones permiten gestionar estos datos de manera centralizada (por ejemplo Dashlane™). Estas soluciones informáticas, instaladas en el dispositivo de comunicación (el ordenador o en la tableta) del usuario, permiten introducir automáticamente, en los campos previstos a tal efecto, los datos que han sido introducidos previamente en el software. Sin embargo, por una parte, esto obliga a introducir estos datos en un software de terceros, el cual debe ser previamente instalado en el dispositivo de comunicación del usuario, por otra parte, esta solución necesita confiar en el editor de este software para la conservación de estos datos. Existen igualmente soluciones en línea: estas permiten no tener que instalar software en el dispositivo de comunicación del usuario, pero necesitan igualmente confiar en un editor (por ejemplo Google™) para la conservación de estos datos. Ahora bien, esta confianza ha sido alterada de modo importante estos últimos años. Por otra parte, esta solución de preservación, en el seno del dispositivo de comunicación, de los datos de tarjeta bancaria puede plantear problemas en caso de robo o de pérdida del dispositivo de comunicación.
Otra solución denominada «Card-on File» (en inglés de «Tarjeta en Archivo»), permite realizar un almacenamiento de los datos de esta tarjeta bancaria directamente en la tienda. El comerciante conserva, en el seno de su infraestructura de software, los datos de tarjetas bancarias. Esto simplifica el proceso de pago puesto que una vez que el usuario se haya identificado, es necesario aceptar el pago o la orden para que el pago sea efectivo. Esta solución, sin embargo, no es ventajosa puesto que requiere tener confianza en todos los vendedores en línea susceptibles de disponer de los datos de tarjeta bancaria del usuario (en este caso, hay que confiar sobre todo en las infraestructuras de estos comerciantes, y confiar en el hecho de que las mismas estén protegidas contra el robo y la usurpación). Esta solución no es definitiva puesto que cuando la tarjeta expire (por ejemplo cuando llegue a su fecha de expiración), es necesario actualizar el conjunto de los datos bancarios en los sitios web u organización en los cuales se haya puesto en práctica una solución «Card-on-File» (por ejemplo organismos de crédito, de seguros, etc.). Por último, el problema principal de la técnica «Card-on-File» consiste finalmente en dar sus datos de tarjeta bancaria sin seguridad de su destino o utilización final. El documento WO 2014/162296 A1 describe la posibilidad de generar, a nivel de un terminal de comunicación de un usuario, una ficha de pre-autorización de pago que puede ser comunicada a un comerciante para la realización de una transacción dada, en lugar de los datos bancarios personales del usuario. Sin embargo, esta solución se refiere a la puesta en práctica de una preautorización de pago asociada a un montante dado con un comerciante dado, en una fecha de pago dada. Dicha ficha de preautorización no ofrece por tanto la flexibilidad de un instrumento de pago que permita a un usuario efectuar libremente y en el momento de su elección transacciones a diversos comerciantes en tanto que no se haya agotado el saldo asociado a este instrumento de pago.
De manera general, el fraude en la tarjeta bancaria es realizado principalmente en los pagos en línea. Sin embargo, la pérdida o el robo de una tarjeta bancaria es un suceso que puede tener repercusiones importantes para las personas implicadas: retirada de dinero líquido (sobre todo si el robo de la tarjeta va acompañado del robo del código confidencial que acompaña a la misma), pagos en línea.
3. Resumen
La presente técnica no presenta estos inconvenientes de la técnica anterior. De modo más particular, la presente técnica se refiere a un procedimiento de tratamiento de datos transaccionales de manera segura que ofrece un nivel elevado de utilizabilidad para los consumidores. Gracias a la presente técnica, el pago puede ser realizado con plena seguridad con un bajo nivel de fraude; Por otra parte, la solución propuesta es simple para el usuario y no ralentiza el pago.
De modo más particular en un primer aspecto, se divulga un Procedimiento de creación de una estructura de datos de pago, denominada contenedor de pago, procedimiento de creación puesto en práctica por un terminal de comunicación móvil, comprendiendo el citado contenedor de pago al menos un dato representativo de un identificador bancario de un usuario.
Según la presente técnica, el procedimiento comprende:
- la selección, por un usuario y por intermedio de una interfaz hombre-máquina, de al menos un atributo del citado contenedor;
- la obtención, por el terminal de comunicación, de al menos un dato representativo de la tarjeta bancaria del usuario, - la validación, por el usuario de la creación del contenedor de pago;
- la transmisión, por el citado terminal de comunicación, del citado contenedor de pago a un servidor de tratamiento de contenedor de pago.
De esta manera, el usuario puede definir de manera simple y segura, una suma de dinero que el mismo puede emplear después para efectuar un pago, sin que el usuario tenga necesidad de utilizar su tarjeta bancaria.
Según un modo de realización particular, la citada etapa de obtención por el terminal de pago, de al menos un dato representativo de la tarjeta bancaria del usuario comprende:
- una etapa de transmisión, a la citada tarjeta bancaria, por intermedio de una interfaz de transmisión de datos sin contacto, de una petición de obtención de datos, en forma de una señal;
- una etapa de recepción de una respuesta a la citada petición, en forma de una señal modulada;
- una etapa de descodificación de la citada señal modulada que facilita el citado al menos un dato.
De esta manera, el usuario no tiene necesidad de introducir los datos de su tarjeta bancaria; le es suficiente con colocar la misma sobre su terminal de comunicación.
Según un modo de realización particular, la citada etapa de obtención por el terminal de pago, de al menos un dato representativo de la tarjeta bancaria del usuario comprende:
- una etapa de activación de un dispositivo de toma de vistas del terminal de comunicación;
- una etapa de obtención, con la ayuda del dispositivo de toma de vistas, de una imagen de la tarjeta bancaria; - una etapa de puesta en práctica de un módulo de reconocimiento de caracteres, a partir de la imagen de la tarjeta bancaria, que facilita el citado al menos un dato.
De esta manera, el usuario no tiene necesidad de introducir los datos de su tarjeta bancaria; le es suficiente con tomar una fotografía de la misma con la ayuda de su terminal de comunicación.
Según una característica particular, el procedimiento comprende además una etapa de determinación, por el citado terminal de comunicación, de un valor representativo de un atributo de transmisión del citado contenedor de pago. Según una característica particular, el procedimiento comprende además, cuando el valor representativo del atributo de transmisión del citado contenedor de pago es positivo, una etapa de determinación, por el citado terminal de comunicación, de un valor representativo de un atributo de débito del citado contenedor de pago.
Según una característica particular, el procedimiento de creación está caracterizado por que el mismo comprende, previamente a la selección de un parámetro de contenedor,
- la activación, en el terminal de comunicación del usuario de un módulo de gestión de contenedor de pago, - la selección, en el seno de este módulo, de un modo de funcionamiento denominado de creación de contenedor. Según una característica particular, la activación del módulo de gestión va acompañada de la autenticación del citado usuario al cual pertenecen el citado terminal de comunicación y la citada tarjeta de pago.
Según un modo de realización particular, la selección, por un usuario y por intermedio de una interfaz hombre-máquina, de al menos un atributo del citado contenedor comprende la selección de al menos un valor de atributo para al menos uno de los parámetros siguientes:
- fecha de validez del contenedor de pago;
- duración de la validez del contenedor de pago;
- montante del contenedor de pago;
- categoría de beneficiario del contenedor de pago;
- beneficiario del contenedor de pago;
En otro modo de realización, la técnica se refiere igualmente a un dispositivo de creación de una estructura de datos de pago, denominada contenedor de pago, comprendiendo el citado contenedor de pago al menos un dato representativo de un identificador bancario de un usuario.
Tal dispositivo comprende al menos un módulo configurado para permitir:
- la selección, por un usuario y por intermedio de una interfaz hombre-máquina, de al menos un atributo del citado contenedor;
- la obtención, por el terminal de comunicación, de al menos un dato representativo de la tarjeta bancaria del usuario; - la validación, por el usuario de la creación del contenedor de pago;
- la transmisión, por el citado terminal de comunicación, del citado contenedor de pago a un servidor de tratamiento del contenedor de pago.
Tal módulo puede presentarse en una forma de hardware o de software. En una forma de hardware, dicho módulo toma por ejemplo la forma de un procesador seguro configurado especialmente para poner en práctica la técnica propuesta.
Según un segundo aspecto, se divulga igualmente un procedimiento de tratamiento, por un servidor de tratamiento, de una estructura de datos de pago, denominada contenedor de pago, siendo el citado contenedor de pago objeto de una utilización con un comerciante por un usuario que disponga de un terminal de comunicación vinculado al citado contenedor de pago, procedimiento caracterizado por que el mismo comprende las etapas siguientes:
- recepción de los datos que provienen del terminal de pago, que comprenden el identificador del contenedor de pago;
- obtención de un identificador de comerciante, eventualmente acompañado de un código de categoría de vendedor cuando el mismo no es facilitado por el comerciante,
- en función del identificador del contenedor de pago, determinación de un identificador de un establecimiento bancario al cual está vinculado el contenedor de pago;- en función del identificador bancario del contenedor de pago, obtención de una autorización de pago, y
- cuando se facilite la autorización de pago, una etapa de transmisión, al terminal del comerciante, de un dato representativo de la aceptación de la transacción.
De esta manera, un pago puede ser implementado, con la ayuda de un contenedor de pago, sin necesitar la intervención de una tarjeta bancaria que ha servido para la creación de este contenedor de pago.
Según un modo de realización particular, la citada etapa de obtención de una autorización de pago comprende las etapas siguientes:
- cuando el establecimiento bancario del contenedor de pago es el mismo que el establecimiento bancario del servidor de tratamiento:
- obtención de los atributos del contenedor;
- verificación del saldo restante en el seno del contenedor de pago;
- cuando el saldo restante en el seno del contenedor de pago es superior al montante de la transacción:
- verificación de que ninguno de los atributos del contenedor de pago está en contradicción con los datos de la transacción;
- cuando ninguno de los atributos de pago sea violado, facilitación de la autorización de pago;
- sustracción de un montante de la transacción del saldo restante en el seno del contenedor de pago;
- cuando el saldo restante en el seno del contenedor de pago es inferior al montante de la transacción, transmisión de una ausencia de autorización;
Según un modo de realización particular, la citada etapa de obtención de una autorización de pago comprende las etapas siguientes:
- cuando el establecimiento bancario del contenedor de pago es diferente del establecimiento bancario del servidor de tratamiento:
- identificación del servidor de tratamiento al cual deben ser transmitidos los datos de la transacción;
- transmisión de los datos de la transacción a este servidor de tratamiento;
- recepción de la autorización o de rechazo de pago.
La técnica se refiere igualmente a un servidor de tratamiento de una estructura de datos de pago, denominada contenedor de pago, siendo el contenedor de pago objeto de una utilización con un comerciante por un usuario que disponga de un terminal de comunicación vinculado al citado contenedor de pago. Dicho servidor comprende medios de:
- recepción de los datos que provienen del terminal de pago, que comprenden el identificador del contenedor de pago;
- obtención de un identificador de comerciante, eventualmente acompañado de un código de categoría de vendedor cuando el mismo no es facilitado por el comerciante;
- en función del identificador del contenedor de pago, determinación de un identificador de un establecimiento bancario al cual está vinculado el contenedor de pago;
- en función del identificador bancario del contenedor de pago, obtención de una autorización de pago, y
- cuando es facilitada la autorización de pago, una etapa de transmisión, al terminal del comerciante, de un dato representativo de la aceptación de la transacción;
En la presente se divulgan igualmente otros aspectos de la presente técnica.
Según una implementación preferida, las diferentes etapas de los procedimientos según la técnica propuesta son puestos en práctica por uno o varios softwares o programas de ordenador, que comprenden instrucciones de software destinadas a ser ejecutadas por un procesador de datos de un módulo de relé según la técnica propuesta y que está diseñado para controlar la ejecución de las diferentes etapas de los procedimientos.
En consecuencia, la técnica propuesta tiene también por objeto un programa, susceptible de ser ejecutado por un ordenador o por un procesador de datos, comprendiendo este programa instrucciones para controlar la ejecución de las etapas de un procedimiento tal como el mencionado anteriormente.
Este programa puede utilizar cualquier lenguaje de programación, y estar en forma de código fuente, de código objeto, o de código intermedio entre código fuente y código objeto, tal como en una forma particularmente compilada, o en cualquier otra forma deseable.
La técnica propuesta tiene también por objeto un soporte de informaciones legible por un procesador de datos, y que comprenda instrucciones de un programa tal como el mencionado anteriormente.
El soporte de informaciones puede ser cualquier entidad o dispositivo capaz de almacenar el programa. Por ejemplo, el soporte puede comprender un medio de almacenamiento, tal como una ROM, por ejemplo un CD ROM o una ROM de circuito microelectrónico, o incluso un medio de registro magnético, por ejemplo un disquete (floppy disc) o un disco duro.
Por otra parte, el soporte de informaciones puede ser un soporte transmisible tal como una señal eléctrica u óptica, que pueda ser encaminada a través de un cable eléctrico u óptico, por radio o por otros medios. El programa según la técnica propuesta puede ser en particular descargado en una red de tipo Internet.
Alternativamente, el soporte de informaciones puede ser un circuito integrado en el cual esté incorporado el sistema, estando el circuito adaptado para ejecutar o para ser utilizado en la ejecución de procedimiento en cuestión.
Según un modo de realización, la técnica propuesta es puesta en práctica por medio de componentes de software y/o de hardware. Desde este punto de vista, el término “módulo” puede corresponder en este documento tanto a un componente de software, como a un componente de hardware o a un conjunto de componentes de hardware y de software.
Un componente de software corresponde a uno o varios programas de ordenador, uno o varios subprogramas de un programa, o de manera más general a cualquier elemento de un programa o de un software apto para poner en práctica una función o un conjunto de funciones, según lo que se describe más adelante para el módulo concernido. Dicho componente de software es ejecutado por un procesador de datos de una entidad física (terminal, servidor, pasarela, rúter, etc.) y es susceptible de acceder a los recursos de hardware de esta entidad física (memorias, soportes de registro, buses de comunicación, tarjetas electrónicas de entradas/salidas, interfaces de usuario, etc.).
De la misma manera, un componente de hardware corresponde a cualquier elemento de un conjunto material (o hardware) apto para poner en práctica una función o un conjunto de funciones, según lo que se describe más adelante para el módulo concernido. Puede tratarse de un componente de hardware programable o con procesador integrado para la ejecución de software, por ejemplo un circuito integrado, una tarjeta inteligente, una tarjeta de memoria, una tarjeta electrónica para la ejecución de un microsoftware (firmware), etc.
Naturalmente, cada componente del sistema anteriormente descrito pone en práctica sus propios módulos de software.
Los diferentes modos de realización anteriormente mencionados son combinables entre sí para la puesta en práctica de la técnica propuesta.
4. Figuras
Otras características y ventajas de la técnica propuesta se pondrán de manifiesto de modo más claro en la lectura de la descripción que sigue de un modo de realización preferente, dado a modo de simple ejemplo ilustrativo y no limitativo, y de los dibujos anejos, en los cuales:
- la figura 1 presenta un contenedor de pago según la presente técnica;
- la figura 2 describe las etapas puestas en práctica para crear un contenedor de pago.
- la figura 3 las etapas puestas en práctica, en el lado del servidor, para utilizar un contenedor de pago.
- la figura 4 describe brevemente la arquitectura de un dispositivo de creación y de utilización de contenedor de pago.
- la figura 5 describe brevemente la arquitectura física del servidor de tratamiento.
5. Descripción
Como se expuso anteriormente, el objeto de la presente es simplificar las operaciones de pago en situaciones particulares. La técnica tiene así por objeto responder a una problemática de pago o de transferencia de dinero. La técnica propuesta se aplica particularmente bien a la utilización (pago, transferencia) de una cierta cantidad de dinero sin tener que utilizar su tarjeta bancaria. La técnica se basa especialmente en la puesta en práctica de un contenedor de pago, que comprenda un cierto número de informaciones para efectuar un pago de manera simple y rápida. La técnica descrita se refiere igualmente al tratamiento de pago realizado con el contenedor de pago. Estos tratamientos son realizados principalmente con un servidor de tratamiento de transacción, denominado igualmente servidor de tratamiento. Dicho servidor de tratamiento puede, en función de los modos de realización y de las condiciones operativas, ser un servidor bancario (es decir un servidor de una institución bancaria). El mismo puede ser igualmente un servidor intermedio (por ejemplo un concentrador que se encargue de organizar y de tratar el conjunto de las transacciones de un grupo de comerciantes y/o de vendedores dados. Puede tratarse igualmente de un servidor intermedio, que haga el enlace entre servidores bancarios que pertenezcan a diferentes establecimientos bancarios.
5.1. Contenedor de pago
El contenedor de pago es una estructura de datos, que eventualmente puede estar cifrada (y por tanto segura) y que contiene un cierto número de informaciones relativas a una suma de dinero. Se puede definir el contenedor de pago como una envoltura que contiene una cierta suma de dinero, asociada a una tarjeta bancaria de una cuenta bancaria determinada (en este caso, la cuenta bancaria del usuario que crea el contenedor de pago). La figura 1 ilustra un contenedor de pago (PC).
Según los modos de realización y las puestas en práctica operativas, esta suma de dinero (MNY) va acompañada de un cierto número de atributos: unos atributos son «públicos» (AttrPub) y otros son privados (AttrPriv). Entre los atributos públicos posibles, se encuentran especialmente al menos un dato temporal (TPS), que puede ser una duración de utilización o una fecha límite de utilización, un montante máximo (MAX), un beneficiario (BEN) y/o una categoría de beneficiario (CBEN), la localización de utilización (LOCU). Otros datos, con fines de seguridad y reglamentarios, son privados (AttrPriv): pueden estar incluidos como tales la fecha (DAT) en la cual se creó el contenedor, el lugar (aproximado o no) (LOCC) de esta creación. Los atributos privados permiten garantizar el no repudio del contenedor de pago. Permiten igualmente protegerse del fraude. Un cierto número de atributos privados son insertados por el propio servidor de tratamiento, durante la validación por el terminal, estos atributos privados no son modificables por los usuarios.
Cada atributo del contenedor de pago tiene una función determinada:
- la fecha de validez determina una fecha límite de utilización del contenedor de pago; más allá de esta fecha, el contenedor ya no es utilizable; la fecha límite es sensiblemente igual, en términos de función a la duración límite: una vez transcurrida la duración límite, el contenedor ya no es utilizable;
- el montante máximo no determina el montante del contenedor. El montante máximo determina la suma máxima de dinero para la cual puede ser utilizado el contenedor cada vez; por ejemplo, un contenedor puede contener una suma de 100 € y el montante máximo puede estar fijado en 20 €. Entonces, una transacción que utilice este contenedor estará ilimitada a un montante máximo de 20 €.
- la categoría de beneficiario determina el tipo de comerciante con el cual el contenedor puede ser utilizado. Por ejemplo, el usuario puede elegir limitar la utilización del contenedor a comerciantes de tipo «alimentarios» excluyendo los comerciantes de venta de tabaco; este aspecto se explica en detalle más adelante;
- el beneficiario determina un comerciante en particular con el cual puede ser utilizado el contenedor, este aspecto se explica en detalle más adelante;
- la localización de utilización define una esfera geográfica en el seno de la cual puede ser utilizado el contenedor (ciudad, región país, etc.);
En lo que concierne al beneficiario, o la categoría de beneficiario, se ofrece la posibilidad al usuario, de determinar el tipo de compra permitido con el contenedor. El usuario tiene así la posibilidad de restringir la utilización del contenedor. De esta manera, cuando incluso un individuo malintencionado llegara a hacerse con el terminal de comunicación del usuario y consiguiera lanzar una operación de pago con un contenedor, la verificación del beneficiario o de la categoría de beneficiario del contenedor permite asegurar que el individuo mal intencionado no podrá utilizar el contenedor como desee. Este bloqueo del contenedor de pago es hecho posible comparando el MCC (del inglés «merchand category code») definido para este vendedor con una lista de MCC autorizada por el creador del contenedor de pago.
En lo que respecta al beneficiario, el principio es el mismo que anteriormente: en lugar de seleccionar uno o varios MCC, el usuario selecciona uno o varios identificadores de comerciante con el cual desea que el contenedor sea utilizable.
Una vez creado el contenedor de pago (véase más adelante), el mismo es transmitido al servidor de tratamiento para ser registrado en el mismo. Se considera que un servidor de tratamiento dispone de medidas de seguridad suficientes para que el contenedor de pago quede registrado en el seno del servidor en forma cifrada. Sin embargo, puede ser igualmente que el contenedor de pago no sea transmitido a un servidor de tratamiento sino directamente a otro terminal de comunicación de otro usuario. En este caso, el mismo es transmitido en forma cifrada.
Un contenedor de pago puede igualmente comprender un atributo de rebasamiento, cuya utilización puede estar limitada (por ejemplo no para la transmisión y no para un cargo inmediato): el atributo de rebasamiento permite definir un porcentaje de rebasamiento autorizado, ya sea para el montante del contenedor, o bien para el montante máximo autorizado. Dicho atributo permite fijar una horquilla de montante máximo sin ser demasiado estricto sobre el propio montante.
Se observa que el contenedor de pago según la presente técnica no es una cartera («wallet»), tal como por ejemplo las carteras de Google™ o de Paypal™. En efecto, estas carteras no comprenden los atributos que son definidos para un contenedor de pago. Las mismas no tienen especialmente montante asignado, ni tampoco una duración de utilización o una categoría de beneficiario. Estas carteras se limitan a restablecer el enlace entre un número de cuenta o un número de tarjeta de crédito, de un usuario en el seno de una institución bancaria, y un terminal de comunicación móvil.
Se observa igualmente que el contenedor de pago no es una preautorización de débito. En efecto, el servidor de tratamiento, que conserva el contenedor de pago, no carga inmediatamente la cuenta del usuario durante la creación o la recepción de este contenedor. El mismo tampoco hace la reserva de suma de dinero: esto significa que no hay sustracción efectuada sobre el montante de autorización de la tarjeta bancaria del cliente (como es el caso por ejemplo para el establecimiento de un aval por tarjeta bancaria). Si el contenedor no es utilizado (por ejemplo porque el plazo de utilización del contenedor está rebasado antes de una utilización cualquiera) entonces no se efectúa ningún cargo en la cuenta del cliente y no se efectúa ninguna sustracción en el montante total de autorización de la tarjeta. En una preautorización, por el contrario, aunque no sea cargada ninguna suma de dinero en el momento de la preautorización, se efectúa una sustracción del techo de pago de la tarjeta bancaria. Dicha sustracción no deja por otra parte de plantear numerosos problemas a los titulares de tarjetas puesto que la misma puede provocar el bloqueo de la tarjeta incluso si realmente no se hace ningún pago. Po otra parte, una autorización de pago solo puede ser concretada (por un pago real) por el comerciante que haya efectuado esta preautorización, y no por cualquier comerciante, a diferencia del contenedor de pago.
En un modo de realización específico, el contenedor de pago puede ser objeto de un cargo inmediato de la cuenta bancaria del usuario. Dicha situación puede producirse cuando el contenedor de pago es transmitido a un tercero con miras a una utilización por una persona que no sea el creador del contenedor de pago. Cuando el usuario efectúa la creación de un contenedor de pago destinado a un tercero, el creador puede valorar un atributo específico, denominado atributo de transmisión, que indica que el contenedor no le está destinado. El tercero al cual está destinado el atributo no es necesariamente conocido en el momento de la creación del contenedor de pago. Cuando el atributo de transmisión es valorado como «verdadero», esto abre la posibilidad de valorar un subatributo (un atributo dependiente) denominado atributo de débito. El atributo de débito permite indicar que el contenedor de pago debe ser objeto de un débito inmediato (atributo valorado como «verdadero»), o bien que el contenedor de pago no debe ser objeto de un débito inmediato (atributo valorado como «falso»).
Cuando se requiera un débito inmediato, el montante del contenedor de pago es adeudado de la cuenta bancaria del usuario, por la puesta en práctica de una transacción de tarjeta bancaria de tipo «EMV». Para el usuario creador del contenedor de pago, se trata de una transacción clásica por tarjeta bancaria.
Cuando no se requiere ningún débito inmediato, la cuenta del usuario es adeudada en función de varios parámetros, los cuales se explican en lo que sigue.
5.2 . Creación de un contenedor de pago
5.2.1. Creación de un contenedor en un terminal de comunicación
Se recuerda que uno de los problemas al cual el contenedor de pago intenta responder es permitir a usuarios de terminales de comunicación inteligentes (de tipo smartpfone) disponer permanentemente de un medio de pago simple y seguro que reemplace a la tarjeta bancaria. En efecto, numerosos usuarios se inquietan ante una pérdida o un robo de su tarjeta. El contenedor de pago ofrece dicha posibilidad. Incluso es necesario que el contenedor de pago responda a un cierto número de otras exigencias, especialmente en términos de facilidad de creación. El presente método se describe en relación con la figura 2.
Los inventores han ideado así poner en práctica un método basado en la utilización de un terminal de comunicación inteligente de tipo teléfono inteligente (TC), estando equipado este terminal por una parte con una interfaz de lectura sin contacto (NFC) o equipado con una cámara fotográfica (CAM) y por otra con un módulo de creación de contenedor de pago (MCPC). Según los modos de realización, dicho módulo puede ser un módulo específico, un módulo de cartera (wallet) o un módulo bancario (el módulo bancario del usuario, disponible en su terminal de comunicación). Una ventaja de la utilización de un módulo bancario es que dicho módulo es generalmente muy seguro. Entonces, en la media en que el contenedor de pago esté inmediatamente vinculado con la tarjeta bancaria y/o con la cuenta bancaria del usuario, parece simple (y legítimo) que, en un modo de funcionamiento particular, se utilice el módulo bancario del titular de la tarjeta para crear los contenedores de pago.
La creación de un contenedor de pago comprende:
- la activación, (C10) en el terminal de comunicación del usuario del módulo;
- la selección, (C10-1) en el seno del módulo, de un modo de funcionamiento denominado de creación de contenedor;
- la selección y/o la introducción (C20), por el usuario, de los atributos del contenedor (fecha o duración de validez, montante del contenedor, beneficiario y/o categoría de beneficiario);
- la valoración (eventual) del atributo de transmisión; por defecto, el atributo de transmisión toma el valor de «falso», y en el caso en que este atributo esté situado en «verdadero», la valoración de un identificador de un destinatario;
- la valoración (eventual) del atributo de débito; por defecto, el atributo de débito toma el valor de «falso»;
- la obtención (C30) de un dato de tarjeta bancaria (por ejemplo la colocación, sobre el terminal de comunicación, de la tarjeta bancaria del usuario; alternativamente a la colocación de la tarjeta (caso del NFC), se puede utilizar el aparato fotográfico del terminal de comunicación para tomar un cliché de la tarjeta bancaria del usuario y efectuar un reconocimiento de caracteres);
- la validación (C40), por el usuario de la creación del contenedor de pago; esto pasa por ejemplo por la presión sobre el botón de validación.
- la transmisión (C50), del contenedor de pago a un servidor de tratamiento (SRVT).
5.2.2. Tratamiento, por el servidor de tratamiento, del contenedor creado por el terminal de comunicación.
Una vez creado en el terminal de comunicación del usuario, el contenedor de pago es transmitido, en una forma segura, al servidor de tratamiento. El servidor de tratamiento pone en práctica un procedimiento de tratamiento que comprende:
- la recepción del contenedor de pago, que comprende una etapa de descifrado, con una o varias claves en posesión del servidor de tratamiento;
- la atribución de un identificador que sirve para identificar el contenedor de manera única;
- la retransmisión de este identificador al terminal de comunicación del usuario creador;
- el almacenamiento, en una estructura de datos adaptada, de este contenedor.
- el tratamiento del contenedor, que comprende especialmente, en caso de posicionamiento del atributo de débito en «verdadero», una etapa de débito del montante del contenedor.
El contenedor de pago está entonces listo para ser utilizado, ya sea por el terminal de comunicación que ha efectuado su creación, o bien por otro canal.
5.2.3. Transmisión, por el servidor de tratamiento, a un destinatario, del contenedor creado por el terminal de comunicación.
El tratamiento del contenedor de pago puede igualmente comprender una etapa de transmisión del contenedor de pago, por el servidor de tratamiento (por ejemplo el servidor bancario), a una entidad receptora (por ejemplo otro servidor de tratamiento o un servidor bancario). La etapa de transmisión del contenedor de pago interviene cuando el contenedor de pago está destinado a ser utilizado por otra persona. Esto se efectúa utilizando un atributo «destinatario», el cual comprende un identificador del usuario al que el contenedor de pago está destinado. Este identificador puede tomar varias formas, dos de las cuales se concretan en lo que sigue. El identificador es utilizado por el servidor de tratamiento ya sea directamente para efectuar una transmisión del contenedor de pago al destinatario (caso más simple correspondiente a un destinatario conocido del servidor de tratamiento) o bien indirectamente para obtener datos complementarios que permitan efectuar una transmisión del contenedor de pago.
En una primera alternativa, el identificador del destinatario es un identificador bancario, conocido del terminal de comunicación que efectúa la creación del contenedor de pago. Este identificador bancario puede ser por ejemplo el identificador bancario correspondiente a un destinatario próximo al usuario (un pariente, un hijo, etc.). El identificador bancario puede presentarse igualmente en forma de un simple número de cuenta (caso en que el creador del contenedor y el destinatario compartan el mismo establecimiento bancario). El identificador bancario puede ser igualmente un BIC o un IBAN (cuando creador y el destinatario no compartan el mismo establecimiento bancario)
Entonces, en esta primera alternativa, el servidor de tratamiento efectúa ya sea el desplazamiento del contenedor (es decir la asignación del contenedor a otra cuenta) cuando el creador y el destinatario son gestionados por el mismo establecimiento bancario, o bien la transmisión del contenedor de pago a un servidor del establecimiento bancario del destinatario.
En una segunda alternativa, el identificador es un dato representativo de un contacto del terminal de comunicación del usuario: el identificador es obtenido después de la selección, por el usuario, de un destinatario en la lista de contactos. Entonces, el identificador puede ser un número de teléfono móvil, una dirección de correo electrónico, un identificador de mensajería instantánea, etc.
Entonces, en esta segunda alternativa, el servidor de tratamiento efectúa al menos las acciones siguientes:
- creación de un mensaje de información; el mensaje contiene una dirección a la cual debe conectarse el destinatario (por ejemplo una URL); la dirección comprende un identificador de transmisión que es por ejemplo el resultado de una función hash cuyos parámetros son el identificador del destinatario y un identificador del contenedor de pago;
- la transmisión del mensaje de información hacia el destinatario utilizando el identificador del contenedor de pago (por ejemplo el mensaje es un correo electrónico cuando el identificador es una dirección de correo electrónico, el mensaje es un SMS o un MMS cuando el identificador es un número de teléfono móvil, etc.);
A la recepción de este mensaje, el destinatario se conecta a la dirección que el mismo contiene y efectúa los pasos necesarios para la transmisión del contenedor de pago. Con el fin de garantizar la seguridad del intercambio, los pasos implican procesos de aseguramiento, de los cuales procesos de doble identificación y procesos de cifrado. De manera complementaria, pueden ser puestos en práctica igualmente procesos de radiación de identificador.
5.2.4. Transmisión, por el terminal de comunicación, del contenedor creado por el terminal de comunicación, a un destinatario
El tratamiento del contenedor de pago puede igualmente comprender una etapa de transmisión del contenedor de pago, por el propio terminal de comunicación, hacia el terminal de comunicación del usuario destinatario.
Para hacerlo, cuando el usuario haya validado un contenedor de pago que comprenda un atributo de transmisión situado como «verdadero», la selección del destinatario ofrece la posibilidad de seleccionar una transmisión denominada «local». La transmisión local consiste en transferir localmente, a un segundo terminal de comunicación que se sitúe en la proximidad, el contenedor de pago. Este segundo terminal de comunicación es aquél del destinatario. El proceso es el siguiente:
- el terminal de comunicación del usuario creador es aproximado al terminal de comunicación del destinatario; eventualmente, esta etapa va precedida del lanzamiento del proceso por un botón de validación;
- el terminal de comunicación del usuario creador emite una petición, por ejemplo una petición NFC o Bluetooth, con destino al terminal del usuario destinatario;
- el terminal del usuario destinatario responde a esta petición transmitiendo un identificador «destinatario» (este es por ejemplo un identificador del módulo bancario instalado en el terminal de comunicación del destinatario, que el usuario destinatario puede por ejemplo encargarse de lanzar, o bien que se lance automáticamente);
- el identificador «destinatario» es insertado en el contenedor de pago, en el atributo «destinatario»;
- el contenedor de pago es cifrado y después transmitido, por NFC o Bluetooth, al terminal del destinatario.
Esta transmisión va seguida o precedida de una transmisión, al servidor de tratamiento, del contenedor de pago con el fin de que el servidor de tratamiento pueda igualmente tratar éste. Accesoriamente, el contenedor de pago comprende igualmente un dato representativo del servidor de tratamiento, con el fin de que el terminal de comunicación del destinatario pueda estar en condiciones de localizar el contenedor. En efecto, esta transmisión al terminal del destinatario es completada por un intercambio de datos a nivel del o de los servidores de tratamiento, como se ha descrito anteriormente.
5.3. Utilización de un contenedor de pago.
En función de los datos que el mismo contiene, de los modos de realización y de las condiciones operativas, el contenedor de pago puede ser utilizado después para efectuar pagos a los comerciantes. Este puede ser utilizado igualmente para efectuar pagos en línea.
La utilización de un contenedor de pago en una tienda comprende:
- la activación, en el terminal de comunicación del usuario, de un módulo; puede tratarse de un módulo bancario (es decir el módulo de la banca en la cual el contenedor de pago está registrado), o de un módulo de tipo cartera (del inglés «wallet»);
- la selección, en el seno de este módulo, de un modo de funcionamiento denominado de pago sin contacto; - eventualmente, la selección de un contenedor de pago que haya que utilizar (cuando varios contenedores pueden ser utilizados);
- la presentación del terminal de comunicación delante del lector sin contacto del terminal de pago del comerciante; durante esta presentación, el terminal de pago detecta la utilización del contenedor de pago y pone en práctica, en enlace con el servidor de tratamiento al cual está conectado, un proceso de pago que se explica más adelante (proceso de tratamiento puesto en práctica por el servidor).
De esta manera, la utilización de un contenedor de pago en una tienda es una operación simple, que no necesita esfuerzo particular por parte del usuario. En efecto, en lugar de tener que introducir su tarjeta bancaria, le es suficiente con colocar su terminal de comunicación sobre el terminal de pago. En lugar de introducir un código PIN, le basta con introducir una contraseña en el módulo de gestión de los contenedores de pago (por ejemplo el módulo bancario). La utilización de un contenedor de pago para un pago en línea comprende:
- la activación, en el terminal de comunicación del usuario, de un módulo; puede tratarse de un módulo bancario (es decir el módulo de la banca en la cual está registrado el contenedor de pago), o de un módulo de tipo cartera (del inglés «wallet»);
- la selección, en el seno de este módulo, de un modo de funcionamiento denominado de pago en línea;
- eventualmente, la selección de un contenedor de pago que haya que utilizar (cuando pueden ser utilizados varios contenedores);
- la generación, por el módulo, de un dato de pago;
- la introducción, en el seno de una zona de introducción dada del sitio web (zona de introducción específica, vinculada con el tipo de pago por contenedor de pago), del dato de pago facilitado por el módulo; posteriormente a esta introducción, el vendedor pone en práctica, en enlace con el servidor de tratamiento al cual está conectado, un proceso de pago que se explica más adelante.
De esta manera, la utilización de un contenedor de pago en línea es una operación simple, que tampoco necesita esfuerzo por parte del usuario. En efecto, en lugar de introducir datos de tarjeta bancaria, el usuario introduce un dato representativo de un contenedor de pago.
Las ventajas proporcionadas por la utilización de un contenedor de pago son numerosas. En efecto, el usuario no tiene necesidad de utilizar su tarjeta bancaria; los usuarios muy prudentes, pueden por tanto por ejemplo dejar su tarjeta bancaria en un lugar seguro y asegurarse de que ésta no podrá ser perdida o robada. Un caso de utilización típica de un contenedor de pago es aquél de un usuario que no desee llevar su tarjeta bancaria, por ejemplo durante una tarde en la playa, por miedo a que se la roben y que haya creado, en su terminal de comunicación, un contenedor. El mismo crea este contenedor para un día, con un montante de 20 € por ejemplo. Si el usuario desea a continuación efectuar una compra en la playa, por ejemplo una bebida, puede utilizar entonces su terminal de comunicación para efectuar esta compra. Otra ventaja es que en caso de pérdida del terminal de comunicación, el montante máximo que podrá ser utilizado por una persona malintencionada está limitado al montante del contenedor. Por otra parte, conviene tener en mente que los terminales de comunicación de tipo teléfono inteligente son geolocalizables. En efecto, cada vez más constructores y proveedores de servicios integran directamente en el seno del teléfono inteligente tecnologías que permiten encontrarle en caso de pérdida o de robo. Esto significa que incluso en caso de pérdida, el usuario tiene grandes probabilidades de encontrar su teléfono.
Otro caso de utilización del contenedor de pago es aquél de una transferencia de dinero entre dos usuarios. Cuando un usuario desee trasmitir una suma de dinero a otro, crea, en su terminal de comunicación, un contenedor de pago de la suma que dese transmitir. Valora el atributo de transmisión en «verdadero» y el atributo de débito en «verdadero» o «falso» en función de la voluntad del usuario. Valida la creación del contenedor de pago.
Este es transmitido al servidor de tratamiento el cual detecta que el contenedor debe ser transferido y que debe ser objeto de un débito inmediato. El servidor de tratamiento identifica entonces el destinatario (el cual en este caso puede ser valorado en el atributo «destinatario», por ejemplo utilizando un número de teléfono u otro identificador, como se ha presentado anteriormente). Con la ayuda de este identificador, el servidor de tratamiento informa al usuario destinatario que se beneficia de una transferencia de dinero por intermedio de un contenedor de pago, y después pone en práctica el procedimiento de transmisión, por el servidor de tratamiento, a un destinatario, del contenedor creado por el terminal de comunicación.
5.4. Tratamiento de un contenedor de pago en un servidor de tratamiento.
Se trata en primer lugar del caso del tratamiento de un contenedor de pago por un servidor de tratamiento cuando se efectúe una operación de pago con la ayuda de un contenedor de pago en una tienda. Se supone, como requisito previo, que el terminal de pago está en condiciones de aceptar un pago por intermedio de un contenedor. Como regla general, esto supone una actualización del software del terminal de pago (en su gran mayoría, los terminales disponen de módulos de pago sin contacto, no es por tanto necesario un cambio de terminal de pago).
En el momento del pago, el usuario indica al comerciante que el mismo desea pagar con la ayuda de un contenedor de pago. El comerciante activa el terminal para que este pueda recibir este tipo de pago y después el usuario pone en práctica el método descrito anteriormente. Cuando presenta el terminal de comunicación delante del terminal de pago, el terminal de comunicación transmite, al terminal de pago, el identificador del contenedor de pago. Los intercambios de datos entre el terminal de pago y el terminal de comunicación son realizados por ejemplo con la ayuda de la norma de intercambio ISO/IEC 14443-4:2008. El identificador del contenedor de pago es por tanto transmitido utilizando esta norma. Una vez obtenido este identificador, el terminal de pago pone en práctica una transacción de pago, en relación con el servidor de tratamiento al cual está conectado. Los datos transmitidos al servidor de tratamiento son sensiblemente idénticos a los datos transmitidos para un pago por tarjeta bancaria con la exclusión del PAN de la tarjeta bancaria, el cual es reemplazado por el identificador del contenedor de pago. Por otra parte, el terminal del comerciante puede igualmente incluir, en los datos transmitidos, un dato representativo de su código MCC («merchant category code»). Si este dato no está incluido en los datos transmitidos por el terminal de pago, el mismo es buscado por el servidor de tratamiento.
En el lado del servidor bancario, el procedimiento de tratamiento es el siguiente:
- recepción (T01) de los datos que provienen del terminal de pago, que comprenden el identificador del contenedor de pago;
- obtención (T02) de un identificador de comerciante, eventualmente acompañado de un código de categoría de vendedor cuando el mismo no es facilitado por el comerciante;
- en función del identificador del contenedor de pago, determinación (T03) de un identificador de un establecimiento bancario al cual está vinculado el contenedor de pago;
- en función del identificador bancario del contenedor de pago, obtención (T04) de una autorización de pago, y
- cuando la autorización de pago es facilitada, una etapa de transmisión (T05), al terminal del comerciante, de un dato representativo de la aceptación de la transacción;
- cuando la autorización de pago es negativa, una etapa de transmisión (T06), al terminal del comerciante, de un dato representativo de un rechazo de la transacción.
De esta manera, desde el punto de vista del comerciante, la transacción se desarrolla de la misma manera que una transacción realizada por tarjeta bancaria. Como se explicó anteriormente, la autorización de pago es obtenida en función del identificador del establecimiento bancario:
- cuando el establecimiento bancario del contenedor de pago es el mismo que el establecimiento bancario de servidor de tratamiento (T041):
- obtención (T0411) de los atributos del contenedor;
- verificación (T0412) del saldo restante en el seno del contenedor de pago;
- cuando el saldo restante en el seno del contenedor de pago es superior al montante de la transacción (T0413): - verificación (T0414) de que ninguno de los atributos del contenedor de pago está en contradicción con los datos de la transacción (montante máximo, categoría de comerciante autorizada, etc.);
- cuando ninguno (T0415) de los atributos de pago es violado, facilitación de la autorización de pago;
- sustracción (T0416) de un montante de la transacción del saldo restante en el seno del contenedor de pago; - cuando el saldo restante en el seno del contenedor de pago es inferior al montante de la transacción (T0417), transmisión de una ausencia de autorización;
- cuando el establecimiento bancario del contenedor de pago es diferente del establecimiento bancario del servidor de tratamiento (T042):
- identificación (T0421) del servidor de tratamiento al cual deben ser transmitidos los datos de transacción;
- transmisión (T0422) de las datos de la transacción a este servidor de tratamiento;
- recepción (T0423) de la autorización o del rechazo de pago.
Las etapas puestas en práctica por el servidor de tratamiento receptor de datos de transacción son sensiblemente idénticas a las descritas anteriormente.
5.5 Otros modos de utilización de un contenedor de pago
Se presentan seguidamente otros modos de utilización de un contenedor de pago de acuerdo con la presente técnica. Estos otros modos de utilización tienden a suprimir la utilización de un terminal de comunicación para la utilización. Según una primera variante, la utilización del contenedor de pago por el usuario es realizada por intermedio de una autenticación biométrica en la tienda. En un primer tiempo el usuario crea un contenedor de pago, este contenedor de pago puede estar limitado geográficamente, temporalmente o por su montante (como se explicó anteriormente). A continuación el usuario se dirige a una tienda. En el momento del pago, el usuario indica que desea efectuar un pago por contenedor de pago y que desea autenticarse por biometría.
El usuario se somete a una identificación biométrica (típicamente, una lectura de huella digital), lo que activa el pago. El sistema choca con una dificultad técnica: cuando el número de usuarios aumenta, la identificación del titular en la tienda resulta molesta (puesto que los tiempos de tratamiento se alargan) y también fuente de errores. En efecto, la entidad que efectúa la comparación biométrica (un servidor por ejemplo) debe comparar la huella recogida en la tienda con todas aquéllas que están en la base de datos. De esta manera, en el lado del servidor, se propone acelerar esta comparación por varias técnicas:
(a) haciendo componer a usuario un código PIN de 4 cifras: entonces se divide por 10000 el esfuerzo de comparación; (b) haciendo introducir al vendedor en el terminal de pago una información «El cliente es un hombre» o «el cliente es una mujer»: se divide entonces por dos el esfuerzo de comparación;
(c) suponiendo que el usuario lleva consigo su terminal de comunicación móvil se puede limitar la comparación solo a las huellas de los titulares de teléfonos móviles que se encuentran en la proximidad del terminal de pago del comerciante;
(d) requiriendo, por parte del usuario, la introducción de las iniciales (primera letra del apellido, primera letra del nombre), con el fin de limitar los esfuerzos de comparación en la base de datos; esta información permite dividir el esfuerzo de comparación por 262 = 676 si se supone que la distribución de las primeras letras de los apellidos y nombres es uniforme. En la práctica, este no es necesariamente el caso, pero la reducción es igualmente importante.
Tal utilización supone una eventual modificación del proceso de creación del contenedor de pago, con el fin de que el mismo comprenda un nuevo atributo, relacionado con la huella digital del creador. La huella digital, como tal, puede estar ya disponible en el terminal de comunicación o bien estar registrada previamente a nivel del servidor de tratamiento.
Según una segunda variante, el contenedor de pago, creado con la ayuda de un terminal de comunicación, puede ser utilizado por dos personas diferentes: en este caso, se trate del creador y de otra persona de su elección, o se trate de dos personas diferentes del creador. Entonces, el atributo destinatario puede comprender una identificación de varias personas. La utilización del contenedor se hace entonces exclusivamente en la cuenta del creador (sin transmisión posible). En caso de doble autenticación biométrica (como se propuso en la variante precedente), se utilizan dos datos representativos de huellas digitales en lugar de uno solo.
Naturalmente, el número de usuarios no está limitado a dos.
Tal utilización supone una eventual modificación del proceso de creación del contenedor de pago, con el fin de que este comprenda un nuevo atributo, relacionado con las huellas digitales del creador y de la persona autorizada. La huella digital, como tal, puede estar ya disponible en el terminal de comunicación, o bien estar registrada previamente a nivel del servidor de tratamiento.
Según una tercera variante, el contenedor de pago puede ser recurrente. Esto significa que el contenedor de pago comprenda un atributo de periodicidad, que permita al servidor de tratamiento crear un nuevo contenedor de pago, de manera autónoma, realizando una copia de un contenedor de pago corriente. Esta utilización es por ejemplo interesante durante la utilización regular de un bien o un servicio, sin que sea necesario utilizar su tarjeta bancaria para hacerlo. Tómese por ejemplo el caso de un empleado que almuerce cada mediodía cerca del trabajo. El servidor de tratamiento es creado, cada día, de lunes a viernes, con el fin de que el usuario pueda efectuar su compra sin utilizar su tarjeta de pago.
Según una cuarta variante, la utilización del contenedor de pago es vigilada por el servidor de tratamiento con el fin de que este pueda poner en práctica medidas antifraude. Cuando un contenedor de pago, por ejemplo periódico, es utilizado de manera diferente (por ejemplo en términos de localización o de horquilla de montante) de las costumbres del creador, puede ser requerida al usuario una confirmación de pago o puede ser puesto en práctica un bloqueo del contenedor por el servidor de tratamiento.
5.6. Dispositivos de puesta en práctica.
En relación con la figura 4, se describe un dispositivo de creación y de utilización de contenedor de pago que comprende medios que permiten la ejecución de los procedimientos descritos previamente.
Por ejemplo, el dispositivo de tratamiento comprende una memoria 41 constituida de una memoria tampón, una unidad de tratamiento 42, equipada por ejemplo con un microprocesador, y controlada por el programa de ordenador 43, que pone en práctica las etapas necesarias para la creación por una parte de contenedor de pago y por otra para su utilización.
A la inicialización, las instrucciones de código del programa del ordenador 43 están por ejemplo cargadas en una memoria antes de ser ejecutadas por el procesador de la unidad de tratamiento 42. La unidad de tratamiento 42 recibe en entrada por ejemplo un conjunto de lexemas iniciales o de datos de diccionarios existentes. El microprocesador de la unidad de tratamiento 42 pone en práctica las etapas del procedimiento, según las instrucciones del programa de ordenador 43 para permitir el acceso al bien o al servicio.
Para esto, el dispositivo de tratamiento comprende, además de la memoria tampón 41, medios de obtención de una información externa al dispositivo, como un conjunto de datos accesibles en base; estos medios pueden presentarse en forma de un módulo de acceso a una red de comunicación tal como una tarjeta de red. El dispositivo comprende igualmente medios de tratamiento, de estos datos para facilitar datos que permitan seleccionar o introducir atributos de contenedor de pago; estos medios de tratamiento comprenden por ejemplo un procesador especializado en esta tarea; el dispositivo comprende igualmente uno o varios medios de acceso a una o varias bases de datos, tal como bases de datos de contacto y/o bases de datos de cuentas bancarias y/o bases de datos de tarjetas bancarias. El dispositivo comprende igualmente un módulo de lectura sin contacto y/o un módulo de toma de vistas tal como una cámara fotográfica.
Estos medios pueden ser controlados por el procesador de la unidad de tratamiento 42 en función del programa de ordenador 43.
En relación con la figura 5, se describe un dispositivo de tratamiento de contenedor de pago que comprende medios que permiten la ejecución de los procesos anteriormente descritos, refiriéndose a la creación de contenedor de pago o al tratamiento de la utilización de contenedor de pago por un usuario.
Por ejemplo, el dispositivo de verificación comprende una memoria 51 constituida de una memoria tampón, una unidad de tratamiento 52, equipada por ejemplo con un microprocesador, y controlada por el programa de ordenador 53, que ponen en práctica lo necesario para la puesta en práctica de las funciones de verificación.
A la inicialización, las instrucciones de código de programa de ordenador 53 están por ejemplo cargadas en una memoria antes de ser ejecutadas por el procesador de la unidad de tratamiento 52. La unidad de tratamiento 52, recibe en entrada por ejemplo una petición de creación o de utilización de un contenedor de pago. El microprocesador de la unidad de tratamiento 52 pone en práctica las etapas del procedimiento de creación, según las instrucciones del programa de ordenador 53 para permitir la creación o la utilización de dicho contenedor.
Para esto, el dispositivo comprende, además de una memoria tampón 51, medios de tratamiento adaptados; estos medios pueden presentarse en forma de un procesador o de un conjunto de recursos seguros que permitan asegurar la creación y el tratamiento de contenedor de pago. El dispositivo comprende igualmente medios de tratamiento criptográficos; estos medios de tratamiento comprenden por ejemplo un procesador de cifrado específico y claves de cifrado, como claves de sesión derivada de una clave inicial.
Estos medios pueden ser controlados por el procesador de la unidad de tratamiento 52 en función del programa de ordenador 53.

Claims (14)

REIVINDICACIONES
1. Procedimiento de puesta en práctica de una transacción de pago por intermedio de una estructura de datos de pago, denominada contenedor de pago, comprendiendo el citado contenedor de pago al menos un dato representativo de un identificador bancario de un usuario, comprendiendo el citado procedimiento:
- una fase de creación del citado contenedor de pago, puesta en práctica por un terminal de comunicación, que comprende:
- la selección (C20), por el usuario y por intermedio de una interfaz hombre-máquina, de al menos un atributo para el citado contenedor de pago, comprendiendo la citada selección al menos un valor de atributo para al menos uno de los parámetros siguientes:
- categoría de beneficiario del contenedor de pago;
- beneficiario del contenedor de pago;
- la obtención (C30), por el terminal de comunicación, de al menos un dato representativo de una tarjeta bancaria del usuario;
- la validación (C40), por el usuario y por intermedio de la citada interfaz hombre-máquina, de la creación del contenedor de pago;
- la creación, a continuación de la validación, del citado contenedor de pago, comprendiendo el citado contenedor de pago el citado al menos un atributo seleccionado y el citado al menos un dato representativo de una tarjeta bancaria del usuario;
- la transmisión (C50), por el citado terminal de comunicación, del citado contenedor de pago a un servidor de tratamiento de contenedor de pago;
- la recepción, por el citado terminal de comunicación, proveniente del citado servidor de tratamiento, de un identificador atribuido al citado contenedor de pago por el servidor de tratamiento de contenedor de pago;
- una fase de utilización del citado contenedor de pago para la realización de la transacción de pago en un comerciante que tiene un terminal de pago, que comprende:
- la recepción, por el citado terminal de pago proveniente del citado terminal de comunicación, del citado identificador atribuido al citado contenedor de pago por el servidor de tratamiento;
- la puesta en práctica, por el terminal de pago, de la transacción de pago en relación con el servidor de tratamiento.
2. Procedimiento según la reivindicación 1, caracterizado por que la citada etapa de obtención (C30) por el terminal de comunicación, de al menos un dato representativo de la tarjeta bancaria del usuario comprende:
- una etapa de transmisión, a la citada tarjeta bancaria, por intermedio de una interfaz de transmisión de datos sin contacto, de una petición de obtención de datos, en forma de una señal;
- una etapa de recepción de una respuesta a la citada petición, en forma de una señal modulada;
- una etapa de descodificación de la citada señal modulada que facilita el citado al menos un dato.
3. Procedimiento según la reivindicación 1, caracterizado por que la citada etapa de obtención (C30) por el terminal de comunicación, de al menos un dato representativo de la tarjeta bancaria del usuario comprende:
- una etapa de activación de un dispositivo de toma de vistas del terminal de comunicación;
- una etapa de obtención, con la ayuda del dispositivo de toma de vistas, de una imagen de la tarjeta bancaria; - una etapa de puesta en práctica de un módulo de reconocimiento de caracteres, a partir de la imagen de la tarjeta bancaria, que facilita el citado al menos un dato.
4. Procedimiento según la reivindicación 1, caracterizado por que comprende además una etapa de determinación, por el citado terminal de comunicación, de un valor representativo de un atributo de transmisión del citado contenedor de pago.
5. Procedimiento según la reivindicación 4, caracterizado por que cuando el valor representativo del atributo de transmisión del citado contenedor de pago es positivo, el procedimiento comprende además una etapa de determinación, por el citado terminal de comunicación, de un valor representativo de un atributo de débito del citado contenedor de pago.
6. Procedimiento según la reivindicación 1, caracterizado por que comprende, previamente a la selección de un parámetro de contenedor,
- la activación (C10), en el terminal de comunicación del usuario de un módulo de gestión de contenedor de pago; - la selección (C10-1), en el seno de este módulo, de un modo de funcionamiento denominado de creación de contenedor.
7. Procedimiento según la reivindicación 6, caracterizado por que la activación del módulo de gestión va acompañada de la autenticación del citado usuario al cual pertenecen el citado terminal de comunicación y la citada tarjeta de pago.
8. Procedimiento según la reivindicación 1, caracterizado por que la selección, por un usuario y por intermedio de una interfaz hombre-máquina, de al menos un atributo del citado contenedor, comprende la selección de al menos un valor de atributo para al menos uno de los parámetros siguientes:
- fecha de validez del contenedor de pago;
- duración de la validez del contenedor de pago;
- montante del contenedor de pago
9. Procedimiento según una de las reivindicaciones 1 a 8, estando caracterizado el citado procedimiento por que comprende además las etapas siguientes, puestas en práctica por el servidor de tratamiento:
- recepción (T01) de los datos que provienen del terminal de pago, que comprenden el identificador del contenedor de pago;
- obtención (T02) de un identificador de comerciante, eventualmente acompañado de un código de categoría de vendedor cuando el mismo no es facilitado por el comerciante;
- en función del identificador del contenedor de pago, determinación (T03) de un identificador de un establecimiento bancario al cual está vinculado el contenedor de pago;
- en función del identificador bancario del contenedor de pago, obtención (T04) de una autorización de pago, comprendiendo la citada etapa de obtención de una autorización de pago una etapa de verificación de que los citados identificador de comerciante y/o código de categoría de vendedor forman parte de los valores de atributo de los parámetros siguientes de citado contenedor de pago:
- categoría de beneficiario del contenedor de pago, para el citado código de vendedor;
- beneficiario del contendor de pago, para el citado identificador de comerciante; y
- cuando la autorización de pago es facilitada, una etapa de transmisión (T05), al citado terminal de pago, de un dato representativo de la aceptación de la transmisión;
10. Procedimiento según la reivindicación 9, caracterizado por que la citada etapa de obtención (T04) de una autorización de pago comprende las etapas siguientes:
- cuando el establecimiento bancario del contenedor de pago es el mismo que el establecimiento bancario del servidor de tratamiento (T041):
- obtención (T0411) de los atributos del contenedor;
- verificación (T0412) del saldo restante en el seno del contenedor de pago;
- cuando el saldo restante en el seno del contenedor de pago es superior al montante de la transacción (T0413): - verificación (T0414) de que ninguno de los atributos del contenedor de pago está en contradicción con los datos de la transacción (montante máximo, etc.);
- cuando ninguno (T0415) de los atributos de pago es violado, facilitación de la autorización de pago;
- sustracción (T0416) de un montante de la transacción del saldo restante en el seno del contenedor de pago; - cuando el saldo restante en el seno del contenedor de pago es inferior al montante de la transacción (T0417), transmisión de una ausencia de autorización.
11. Procedimiento según la reivindicación 10, caracterizado por que la citada etapa de obtención (T04) de una autorización de pago comprende las etapas siguientes:
- cuando el establecimiento bancario del contenedor de pago es diferente del establecimiento bancario del servidor de tratamiento (T042):
- identificación (T0421) del servidor de tratamiento al cual deben ser transmitidos los datos de la transacción; - transmisión (T0422) de los datos de la transacción a este servidor de tratamiento;
- recepción (T0423) de la autorización o del rechazo de pago.
12. Terminal de comunicación que comprende medios de puesta en práctica de una transacción de pago por intermedio de un módulo de creación de una estructura de datos de pago, denominada contenedor de pago, comprendiendo el citado contenedor de pago al menos un dato representativo de un identificador bancario de un usuario, y de un módulo de utilización del citado contenedor de pago para la realización de la transacción de pago en un comerciante que tiene un terminal de pago,
estando configurado el citado módulo de creación de la estructura de datos de pago para permitir:
- la selección (C20), por el usuario y por intermedio de una interfaz hombre-máquina, de al menos un atributo para el citado contenedor de pago, comprendiendo la citada selección la selección de al menos un valor de atributo para al menos uno de los parámetros siguientes:
- categoría de beneficiario del contenedor de pago;
- beneficiario del contenedor de pago;
- la obtención (C30), por el terminal de comunicación, de al menos un dato representativo de una tarjeta bancaria del usuario;
- la validación (C40), por el usuario y por intermedio de la citada interfaz hombre-máquina, de la creación del contenedor de pago;
- la creación, a continuación de la citada validación, del citado contenedor de pago, comprendiendo el citado contenedor de pago el citado al menos un atributo seleccionado y el citado al menos un dato representativo de una tarjeta bancaria del usuario;
- la transmisión (C50), por el citado terminal de comunicación, del citado contenedor de pago a un servidor de tratamiento de contenedor de pago;
- la recepción, por el citado terminal de comunicación, proveniente del citado servidor de tratamiento, de un identificador atribuido al citado contenedor de pago por el servidor de tratamiento de contenedor de pago; estando configurado el citado módulo de creación de la estructura de datos de pago para permitir:
- la transmisión, al citado terminal de pago, del citado identificador atribuido al citado contenedor de pago por el servidor de tratamiento;
- la puesta en práctica, por el terminal de pago, de la transacción de pago en relación con el servidor de tratamiento.
13. Sistema de puesta en práctica de una transacción de pago por intermedio de una estructura de datos de pago, denominada contenedor de pago, comprendiendo el citado contenedor de pago al menos un dato representativo de un identificador bancario de un usuario, comprendiendo el citado sistema:
- un terminal de comunicación según la reivindicación 12, vinculado al citado contenedor de pago;
- un terminal de pago;
- un servidor de tratamiento del citado contenedor de pago, siendo el citado contenedor de pago objeto de una utilización en un comerciante que tiene el citado terminal de pago por un usuario que dispone del citado terminal de comunicación vinculado al citado contenedor de pago, comprendiendo el citado servidor de tratamiento medios de: - recepción (T01) de los datos que provienen del terminal de pago, que comprenden el identificador del contenedor de pago;
- obtención (T02) de un identificador de comerciante, eventualmente acompañado de un código de categoría de vendedor cuando el mismo no es facilitado por el comerciante;
- en función del identificador bancario del contenedor de pago, determinación (T03) de un identificador de un establecimiento bancario al cual está vinculado el contenedor de pago;
- en función del identificador bancario del contenedor de pago, obtención (T04) de una autorización de pago, comprendiendo la citada obtención de una autorización de pago la verificación de que los citados identificador de comerciante y/o código de categoría de vendedor forman parte de los valores de atributo de los parámetros siguientes del citado contenedor de pago:
- categoría de beneficiario del contenedor de pago, para el citado código de categoría de vendedor;
- beneficiario de contenedor de pago, para el citado identificador de comerciante;
y
- cuando la autorización de pago es facilitada, una etapa de transmisión (T05), al citado terminal de pago, de un dato representativo de la aceptación de la transacción;
14. Producto programa de ordenador descargable desde una red de comunicación y/o almacenado en un soporte legible por ordenador y/o ejecutable por un microprocesador, caracterizado por que el mismo comprende instrucciones de código de programa para la ejecución de un procedimiento de puesta en práctica de una transacción de pago según la reivindicación 1, cuando el mismo es ejecutado en un procesador.
ES16177234T 2015-07-03 2016-06-30 Contenedor de pago, procedimiento de creación, procedimiento de tratamiento, dispositivos y programas correspondientes Active ES2856696T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1556349A FR3038429B1 (fr) 2015-07-03 2015-07-03 Conteneur de paiement, procede de creation, procede de traitement, dispositifs et programmes correspondants

Publications (1)

Publication Number Publication Date
ES2856696T3 true ES2856696T3 (es) 2021-09-28

Family

ID=55236444

Family Applications (1)

Application Number Title Priority Date Filing Date
ES16177234T Active ES2856696T3 (es) 2015-07-03 2016-06-30 Contenedor de pago, procedimiento de creación, procedimiento de tratamiento, dispositivos y programas correspondientes

Country Status (5)

Country Link
US (1) US10997602B2 (es)
EP (1) EP3113099B1 (es)
CA (1) CA2934716C (es)
ES (1) ES2856696T3 (es)
FR (1) FR3038429B1 (es)

Families Citing this family (108)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2881429C (en) 2012-02-29 2017-05-02 Mobeewave, Inc. Method, device and secure element for conducting a secured financial transaction on a device
US10546444B2 (en) 2018-06-21 2020-01-28 Capital One Services, Llc Systems and methods for secure read-only authentication
US10769299B2 (en) 2018-07-12 2020-09-08 Capital One Services, Llc System and method for dynamic generation of URL by smart card
US10542036B1 (en) 2018-10-02 2020-01-21 Capital One Services, Llc Systems and methods for signaling an attack on contactless cards
US11210664B2 (en) 2018-10-02 2021-12-28 Capital One Services, Llc Systems and methods for amplifying the strength of cryptographic algorithms
KR20210066798A (ko) 2018-10-02 2021-06-07 캐피탈 원 서비시즈, 엘엘씨 비접촉식 카드의 암호화 인증을 위한 시스템 및 방법
US10607214B1 (en) 2018-10-02 2020-03-31 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10511443B1 (en) 2018-10-02 2019-12-17 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
WO2020072670A1 (en) 2018-10-02 2020-04-09 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10949520B2 (en) 2018-10-02 2021-03-16 Capital One Services, Llc Systems and methods for cross coupling risk analytics and one-time-passcodes
US10581611B1 (en) 2018-10-02 2020-03-03 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10582386B1 (en) 2018-10-02 2020-03-03 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
WO2020072694A1 (en) 2018-10-02 2020-04-09 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
CA3115084A1 (en) 2018-10-02 2020-04-09 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
AU2019355436A1 (en) 2018-10-02 2021-04-15 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
WO2020072552A1 (en) 2018-10-02 2020-04-09 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10565587B1 (en) 2018-10-02 2020-02-18 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
WO2020072529A1 (en) 2018-10-02 2020-04-09 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
WO2020072474A1 (en) 2018-10-02 2020-04-09 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10771254B2 (en) 2018-10-02 2020-09-08 Capital One Services, Llc Systems and methods for email-based card activation
US10505738B1 (en) 2018-10-02 2019-12-10 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10680824B2 (en) 2018-10-02 2020-06-09 Capital One Services, Llc Systems and methods for inventory management using cryptographic authentication of contactless cards
US10579998B1 (en) 2018-10-02 2020-03-03 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
WO2020072583A1 (en) 2018-10-02 2020-04-09 Capital One Services, Llc Systems and methods for establishing identity for order pick up
US10489781B1 (en) 2018-10-02 2019-11-26 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
JP2022508026A (ja) 2018-10-02 2022-01-19 キャピタル・ワン・サービシーズ・リミテッド・ライアビリティ・カンパニー 非接触カードの暗号化認証のためのシステムおよび方法
US10909527B2 (en) 2018-10-02 2021-02-02 Capital One Services, Llc Systems and methods for performing a reissue of a contactless card
US10771253B2 (en) 2018-10-02 2020-09-08 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10592710B1 (en) 2018-10-02 2020-03-17 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
US10554411B1 (en) 2018-10-02 2020-02-04 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
KR20210068028A (ko) 2018-10-02 2021-06-08 캐피탈 원 서비시즈, 엘엘씨 비접촉식 카드의 암호화 인증을 위한 시스템 및 방법
WO2020072575A1 (en) 2018-10-02 2020-04-09 Capital One Services, Llc Systems and methods for cryptographic authentication of contactless cards
KR20210065109A (ko) 2018-10-02 2021-06-03 캐피탈 원 서비시즈, 엘엘씨 비접촉식 카드의 암호화 인증을 위한 시스템 및 방법
US20200226581A1 (en) 2019-01-11 2020-07-16 Capital One Services, Llc Systems and methods for touch screen interface interaction using a card overlay
US11037136B2 (en) 2019-01-24 2021-06-15 Capital One Services, Llc Tap to autofill card data
US10510074B1 (en) 2019-02-01 2019-12-17 Capital One Services, Llc One-tap payment using a contactless card
US11120453B2 (en) 2019-02-01 2021-09-14 Capital One Services, Llc Tap card to securely generate card data to copy to clipboard
US10467622B1 (en) 2019-02-01 2019-11-05 Capital One Services, Llc Using on-demand applications to generate virtual numbers for a contactless card to securely autofill forms
US10425129B1 (en) 2019-02-27 2019-09-24 Capital One Services, Llc Techniques to reduce power consumption in near field communication systems
US11082229B2 (en) 2019-03-18 2021-08-03 Capital One Services, Llc System and method for pre-authentication of customer support calls
US10643420B1 (en) 2019-03-20 2020-05-05 Capital One Services, Llc Contextual tapping engine
US10984416B2 (en) 2019-03-20 2021-04-20 Capital One Services, Llc NFC mobile currency transfer
US10535062B1 (en) 2019-03-20 2020-01-14 Capital One Services, Llc Using a contactless card to securely share personal data stored in a blockchain
US10438437B1 (en) 2019-03-20 2019-10-08 Capital One Services, Llc Tap to copy data to clipboard via NFC
US10970712B2 (en) 2019-03-21 2021-04-06 Capital One Services, Llc Delegated administration of permissions using a contactless card
US11521262B2 (en) 2019-05-28 2022-12-06 Capital One Services, Llc NFC enhanced augmented reality information overlays
US10516447B1 (en) 2019-06-17 2019-12-24 Capital One Services, Llc Dynamic power levels in NFC card communications
US11392933B2 (en) 2019-07-03 2022-07-19 Capital One Services, Llc Systems and methods for providing online and hybridcard interactions
US10871958B1 (en) 2019-07-03 2020-12-22 Capital One Services, Llc Techniques to perform applet programming
US11694187B2 (en) 2019-07-03 2023-07-04 Capital One Services, Llc Constraining transactional capabilities for contactless cards
US12086852B2 (en) 2019-07-08 2024-09-10 Capital One Services, Llc Authenticating voice transactions with payment card
US10713649B1 (en) 2019-07-09 2020-07-14 Capital One Services, Llc System and method enabling mobile near-field communication to update display on a payment card
US10885514B1 (en) 2019-07-15 2021-01-05 Capital One Services, Llc System and method for using image data to trigger contactless card transactions
US11182771B2 (en) 2019-07-17 2021-11-23 Capital One Services, Llc System for value loading onto in-vehicle device
US10733601B1 (en) 2019-07-17 2020-08-04 Capital One Services, Llc Body area network facilitated authentication or payment authorization
US10832271B1 (en) 2019-07-17 2020-11-10 Capital One Services, Llc Verified reviews using a contactless card
US11521213B2 (en) 2019-07-18 2022-12-06 Capital One Services, Llc Continuous authentication for digital services based on contactless card positioning
US10506426B1 (en) 2019-07-19 2019-12-10 Capital One Services, Llc Techniques for call authentication
US10541995B1 (en) 2019-07-23 2020-01-21 Capital One Services, Llc First factor contactless card authentication system and method
AU2019469080A1 (en) 2019-10-02 2022-04-21 Capital One Services, Llc Client device authentication using contactless legacy magnetic stripe data
US10733283B1 (en) 2019-12-23 2020-08-04 Capital One Services, Llc Secure password generation and management using NFC and contactless smart cards
US11113685B2 (en) 2019-12-23 2021-09-07 Capital One Services, Llc Card issuing with restricted virtual numbers
US11651361B2 (en) 2019-12-23 2023-05-16 Capital One Services, Llc Secure authentication based on passport data stored in a contactless card
US10862540B1 (en) 2019-12-23 2020-12-08 Capital One Services, Llc Method for mapping NFC field strength and location on mobile devices
US10657754B1 (en) 2019-12-23 2020-05-19 Capital One Services, Llc Contactless card and personal identification system
US10885410B1 (en) 2019-12-23 2021-01-05 Capital One Services, Llc Generating barcodes utilizing cryptographic techniques
US11615395B2 (en) 2019-12-23 2023-03-28 Capital One Services, Llc Authentication for third party digital wallet provisioning
US10853795B1 (en) 2019-12-24 2020-12-01 Capital One Services, Llc Secure authentication based on identity data stored in a contactless card
US11200563B2 (en) 2019-12-24 2021-12-14 Capital One Services, Llc Account registration using a contactless card
US10664941B1 (en) 2019-12-24 2020-05-26 Capital One Services, Llc Steganographic image encoding of biometric template information on a card
US10757574B1 (en) 2019-12-26 2020-08-25 Capital One Services, Llc Multi-factor authentication providing a credential via a contactless card for secure messaging
US10909544B1 (en) 2019-12-26 2021-02-02 Capital One Services, Llc Accessing and utilizing multiple loyalty point accounts
US11038688B1 (en) 2019-12-30 2021-06-15 Capital One Services, Llc Techniques to control applets for contactless cards
US11455620B2 (en) 2019-12-31 2022-09-27 Capital One Services, Llc Tapping a contactless card to a computing device to provision a virtual number
US10860914B1 (en) 2019-12-31 2020-12-08 Capital One Services, Llc Contactless card and method of assembly
US11210656B2 (en) 2020-04-13 2021-12-28 Capital One Services, Llc Determining specific terms for contactless card activation
US11030339B1 (en) 2020-04-30 2021-06-08 Capital One Services, Llc Systems and methods for data access control of personal user data using a short-range transceiver
US11222342B2 (en) 2020-04-30 2022-01-11 Capital One Services, Llc Accurate images in graphical user interfaces to enable data transfer
US10915888B1 (en) 2020-04-30 2021-02-09 Capital One Services, Llc Contactless card with multiple rotating security keys
US10861006B1 (en) 2020-04-30 2020-12-08 Capital One Services, Llc Systems and methods for data access control using a short-range transceiver
US11823175B2 (en) 2020-04-30 2023-11-21 Capital One Services, Llc Intelligent card unlock
US10963865B1 (en) 2020-05-12 2021-03-30 Capital One Services, Llc Augmented reality card activation experience
US11063979B1 (en) 2020-05-18 2021-07-13 Capital One Services, Llc Enabling communications between applications in a mobile operating system
US11100511B1 (en) 2020-05-18 2021-08-24 Capital One Services, Llc Application-based point of sale system in mobile operating systems
US11216623B1 (en) 2020-08-05 2022-01-04 Capital One Services, Llc Systems and methods for controlling secured data transfer via URLs
US11062098B1 (en) 2020-08-11 2021-07-13 Capital One Services, Llc Augmented reality information display and interaction via NFC based authentication
US11683325B2 (en) 2020-08-11 2023-06-20 Capital One Services, Llc Systems and methods for verified messaging via short-range transceiver
US11482312B2 (en) 2020-10-30 2022-10-25 Capital One Services, Llc Secure verification of medical status using a contactless card
US11165586B1 (en) 2020-10-30 2021-11-02 Capital One Services, Llc Call center web-based authentication using a contactless card
US11373169B2 (en) 2020-11-03 2022-06-28 Capital One Services, Llc Web-based activation of contactless cards
US11216799B1 (en) 2021-01-04 2022-01-04 Capital One Services, Llc Secure generation of one-time passcodes using a contactless card
US11682012B2 (en) 2021-01-27 2023-06-20 Capital One Services, Llc Contactless delivery systems and methods
US11687930B2 (en) 2021-01-28 2023-06-27 Capital One Services, Llc Systems and methods for authentication of access tokens
US11562358B2 (en) 2021-01-28 2023-01-24 Capital One Services, Llc Systems and methods for near field contactless card communication and cryptographic authentication
US11792001B2 (en) 2021-01-28 2023-10-17 Capital One Services, Llc Systems and methods for secure reprovisioning
US11438329B2 (en) 2021-01-29 2022-09-06 Capital One Services, Llc Systems and methods for authenticated peer-to-peer data transfer using resource locators
US11777933B2 (en) 2021-02-03 2023-10-03 Capital One Services, Llc URL-based authentication for payment cards
US11637826B2 (en) 2021-02-24 2023-04-25 Capital One Services, Llc Establishing authentication persistence
US11245438B1 (en) 2021-03-26 2022-02-08 Capital One Services, Llc Network-enabled smart apparatus and systems and methods for activating and provisioning same
US11961089B2 (en) 2021-04-20 2024-04-16 Capital One Services, Llc On-demand applications to extend web services
US11935035B2 (en) 2021-04-20 2024-03-19 Capital One Services, Llc Techniques to utilize resource locators by a contactless card to perform a sequence of operations
US11902442B2 (en) 2021-04-22 2024-02-13 Capital One Services, Llc Secure management of accounts on display devices using a contactless card
US11354555B1 (en) 2021-05-04 2022-06-07 Capital One Services, Llc Methods, mediums, and systems for applying a display to a transaction card
US12041172B2 (en) 2021-06-25 2024-07-16 Capital One Services, Llc Cryptographic authentication to control access to storage devices
US12061682B2 (en) 2021-07-19 2024-08-13 Capital One Services, Llc System and method to perform digital authentication using multiple channels of communication
US12062258B2 (en) 2021-09-16 2024-08-13 Capital One Services, Llc Use of a payment card to unlock a lock
US11943259B2 (en) * 2021-09-22 2024-03-26 Bank Of America Corporation System and method for security management of application information
US12069173B2 (en) 2021-12-15 2024-08-20 Capital One Services, Llc Key recovery based on contactless card authentication

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040019571A1 (en) * 2002-07-26 2004-01-29 Intel Corporation Mobile communication device with electronic token repository and method
JP2007531100A (ja) * 2004-03-22 2007-11-01 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ コンテンツの電子支払
US8453226B2 (en) * 2010-07-16 2013-05-28 Visa International Service Association Token validation for advanced authorization
EP2649745A4 (en) * 2010-12-10 2014-05-07 Electronic Payment Exchange TOKENS TRANSLATED CONTACTLESS PAYMENTS FOR MOBILE DEVICES
US8533123B2 (en) * 2010-12-13 2013-09-10 Magtek, Inc. Systems and methods for conducting contactless payments using a mobile device and a magstripe payment card
KR20120105296A (ko) * 2011-03-15 2012-09-25 한국정보통신주식회사 일회용 카드 결제 처리방법 및 시스템과 이를 위한 서버, 스마트폰
US10482457B2 (en) * 2011-10-17 2019-11-19 Capital One Services, Llc System and method for token-based payments
AU2014246711A1 (en) * 2013-04-04 2015-10-29 Visa International Service Association Method and system for conducting pre-authorized financial transactions
US20150254647A1 (en) * 2014-03-04 2015-09-10 Bank Of America Corporation Flexible funding account token associations

Also Published As

Publication number Publication date
CA2934716A1 (en) 2017-01-03
EP3113099A1 (fr) 2017-01-04
FR3038429B1 (fr) 2018-09-21
EP3113099B1 (fr) 2021-01-13
FR3038429A1 (fr) 2017-01-06
CA2934716C (en) 2023-10-10
US20170004502A1 (en) 2017-01-05
US10997602B2 (en) 2021-05-04

Similar Documents

Publication Publication Date Title
ES2856696T3 (es) Contenedor de pago, procedimiento de creación, procedimiento de tratamiento, dispositivos y programas correspondientes
ES2904552T3 (es) Método de procesamiento de una transacción a partir de un terminal de comunicación
ES2732564T3 (es) Sistema y procedimientos de aprovisionamiento de datos cifrados de servidor remoto
US20200005295A1 (en) Secure location based electronic financial transaction methods and systems
JP6445031B2 (ja) 高スループットの料金支払い及びシステムアクセスを可能にするバイオメトリックソリューション
ES2502341T3 (es) Sistema de pago seguro en una red de comunicaciones inalámbricas
US10055740B2 (en) Payment selection and authorization
ES2856552T3 (es) Procedimiento de ayuda a la autenticación de un usuario, servidor y programa de ordenador correspondientes
US20130041831A1 (en) Secure and shareable payment system using trusted personal device
US20140289130A1 (en) Secure remotely configurable point of sale terminal
KR20230129566A (ko) 거래 승인
BR112016003819B1 (pt) Método para autenticar e autorizar uma transação envolvendo um provedor de terminal de um produto ou um serviço
TR201808160T4 (tr) Açık iletişim ağları üzerinden iletime yönelik ödeme verilerinin güvence altına alınmasına yönelik yöntem, cihaz ve sistem.
US20180018661A1 (en) Virtual point of sale
US9721252B2 (en) User authentication method and device for credentials back-up service to mobile devices
KR20220031573A (ko) 비접촉식 카드의 거래 기능 제한
US20160063481A1 (en) System and Method of Electronic Authentication at a Computer Initiated Via Mobile
US10318850B1 (en) Smart card holder
US20200160329A1 (en) Systems and methods using a primary account number to represent identity attributes
US20220374896A1 (en) Identity, Payment and Access Control System
CA2943854A1 (en) Remote transaction system, method and point of sale terminal
ES2261666T3 (es) Procedimiento para la realizacion de transaciones seguras mediante tarjetas electronicas de pago.
ES2971660T3 (es) Procedimiento para llevar a cabo una transacción, terminal, servidor y programa informático correspondiente
US20240232858A1 (en) Authentication using non-fungible token as proof of account ownership