ES2856552T3 - Procedimiento de ayuda a la autenticación de un usuario, servidor y programa de ordenador correspondientes - Google Patents

Procedimiento de ayuda a la autenticación de un usuario, servidor y programa de ordenador correspondientes Download PDF

Info

Publication number
ES2856552T3
ES2856552T3 ES16198205T ES16198205T ES2856552T3 ES 2856552 T3 ES2856552 T3 ES 2856552T3 ES 16198205 T ES16198205 T ES 16198205T ES 16198205 T ES16198205 T ES 16198205T ES 2856552 T3 ES2856552 T3 ES 2856552T3
Authority
ES
Spain
Prior art keywords
transaction
user
operating information
server
merchant
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
ES16198205T
Other languages
English (en)
Inventor
Vincent Ducrohet
Hiba Koudoussi
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 ES2856552T3 publication Critical patent/ES2856552T3/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/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
    • G06F21/35—User authentication involving the use of external additional devices, e.g. dongles or smart cards communicating wirelessly
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/40—User authentication by quorum, i.e. whereby two or more security principals are required
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/105—Multiple levels of security

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Procedimiento de ayuda a la autenticación de un usuario, procedimiento implementado en el seno de un servidor de prestación de servicios de pago, denominado servidor de pago, comprendiendo dicho procedimiento: - una fase de recopilación (10), sin intervención del citado usuario, de al menos una información de funcionamiento relativa al menos a un objeto conectado previamente asociado a dicho usuario; - una fase de gestión (11) de una transacción que involucra a datos bancarios del citado usuario y a un comerciante, que comprende las siguientes etapas: - tratamiento (110) de la citada al menos una información de funcionamiento recopilada durante dicha fase de recopilación, comprendiendo dicha etapa de tratamiento las subetapas siguientes: comparación de la citada al menos una información de funcionamiento recopilada con al menos una información de funcionamiento de referencia, que facilita un resultado de comparación; actualización de un nivel de confianza asociado a dicha transacción en función del citado resultado de comparación; entrega de al menos un dato representativo de un nivel de confianza asociado a dicha transacción; - transmisión (111), a al menos un servidor bancario del citado comerciante, del citado al menos un dato representativo del nivel de confianza asociado a dicha transacción para decidir si la transacción del citado usuario puede ser validada.

Description

DESCRIPCIÓN
Procedimiento de ayuda a la autenticación de un usuario, servidor y programa de ordenador correspondientes
1. Ámbito
La técnica propuesta se refiere al aseguramiento de las transacciones de pago implementadas utilizando datos bancarios sin la presencia de una tarjeta de pago, es decir, en modo de « tarjeta no presente”, como por ejemplo transacciones efectuadas por Internet.
La técnica propuesta se refiere más específicamente a la autenticación del usuario durante tales transacciones.
2. Técnica anterior
Durante las transacciones implementadas para compras efectuadas por Internet (por ejemplo a través de un ordenador, un teléfono móvil o cualquier otro dispositivo capaz de llevar a cabo dichas transacciones) y cuando la tarjeta bancaria del usuario no esté presente (es decir, que la tarjeta no se haya insertado en un lector de tarjetas y por lo tanto los datos que contiene no se leen a través de un lector de tarjetas, sino introducidos por el usuario a través de una interfaz de pago), diferentes técnicas permiten la autenticación del usuario que lleva la tarjeta bancaria, a fin de verificar que la utilización de los datos bancarios correspondientes a esta tarjeta no es fraudulenta (por ejemplo después de un robo de la tarjeta, o de una copia fraudulenta de los datos de la misma).
Por ejemplo, se conoce utilizar un mecanismo de autenticación titulado « 3D SEGURO® » el cual permite, en particular, limitar los riesgos de fraude en Internet, vinculados a los intentos de usurpación de identidad. El mismo consiste en asegurar, durante cada pago en línea, que la tarjeta es utilizada por su verdadero titular. Así, en el caso en que, tanto el comerciante como el banco del portador de la tarjeta estén equipados, tiene lugar una etapa suplementaria en el momento del pago. Además del número de tarjeta bancaria, de la fecha de caducidad de la tarjeta y de los tres dígitos del código de seguridad (impresos en la parte posterior de la tarjeta), el usuario debe introducir una contraseña, tal como su fecha de nacimiento (autenticación simple) o un código dinámico de una sola utilización recibido, por ejemplo, en su teléfono móvil (autenticación fuerte).
Ahora bien, este mecanismo degrada en gran medida la ergonomía de dicha transacción por Internet para el usuario, a quien se le solicita que introduzca un código recibido a través de su teléfono móvil o que introduzca datos personales como su fecha de nacimiento. Esta degradación de la ergonomía tiene por efecto incrementar enormemente las tasas de transacciones interrumpidas debido a un proceso considerado demasiado complicado para el usuario.
Ahora bien, esta autenticación del portador de la tarjeta es fundamental para asegurar la transacción y permite, en particular, asignar un nivel de riesgo o de confianza a una transacción, generando este nivel costes de tratamiento más o menos elevados para el comerciante. Los documentos (WO 2015/071707 A1) y (US 2015/294306 A1) constituyen documentos relevantes de la técnica anterior.
Existe por tanto una necesidad de proporcionar una solución que permita asegurar dichas transacciones en modo de « tarjeta no presente » que responda a los problemas de complejidad, de ergonomía y de rapidez para el usuario, así como de coste y de seguridad para todos los actores involucrados (especialmente comerciantes y organismos bancarios).
3. Sumario
La técnica propuesta no presenta al menos algunos de los problemas de la técnica anterior. La invención queda definida por las reivindicaciones independientes adjuntas.
Más particularmente, la técnica propuesta se refiere a un procedimiento de ayuda a la autenticación de un usuario, procedimiento implementado en el seno de un servidor de prestación de servicios de pago, llamado servidor de pago, y que comprende:
• una fase de recopilación de al menos una información de funcionamiento relativa al menos a un objeto conectado previamente asociado al usuario;
• una fase de gestión de una transacción que involucra a datos bancarios del usuario y a un comerciante, que comprende las etapas siguientes:
o tratamiento de la citada al menos una información de funcionamiento recopilada durante la fase de recopilación, que facilita al menos un dato representativo de un nivel de confianza asociado a transacción;
o transmisión, hacia a al menos un servidor bancario del comerciante, del nivel de confianza asociado a la transacción.
Así, la invención propone una solución nueva e inventiva para ayudar a autenticar a un usuario en el marco de una transacción, y más particularmente de una transacción en modo de « tarjeta no presente », que especialmente permita mitigar la ausencia de lectura de los datos de la tarjeta bancaria del usuario en este tipo de transacción, al tiempo que evite requerir una o varias acciones específicas suplementarias del usuario.
En efecto, de acuerdo con los diferentes modos de realización de la invención, la ayuda a la autenticación del usuario se basa en el seguimiento « automático » de objetos conectados asociados al usuario para aumentar el nivel de confianza de la transacción (nivel de confianza que por otra parte está ya estimado según técnicas conocidas). De esta manera, el nivel de confianza otorgado a una transacción que involucra a un usuario dado se ve reforzado por la verificación de que los objetos conectados asociados a este usuario están en efecto cerca de la localización de la transacción.
Para ello, la invención prevé, de acuerdo con sus diferentes modos de realización, recopilar (periódicamente, durante una fase llamada de recopilación) informaciones de funcionamiento (por ejemplo la presencia o no de un objeto conectado, su localización. ...) de uno o varios objetos conectados asociados al usuario, con el fin de utilizarlos, en el momento de la transacción propiamente dicha (durante una fase llamada de gestión de una transacción), para ayudar a la autenticación del usuario determinando un nivel de confianza asociado a la transacción. Este nivel de confianza asociado a la transacción se transmite después, con las informaciones necesarias para la transacción tradicionalmente transmitidas también, al servidor bancario del comerciante a cargo de la transacción.
De esta manera, las informaciones que sirven para la ayuda a la autenticación del usuario se recopilan « automáticamente » sin intervención del usuario, únicamente a partir de objetos conectados que previamente le han sido asociados, mitigando así los inconvenientes de las técnicas clásicas de autenticación de un usuario que por su parte requieren por ejemplo la introducción de un código confidencial recibido previamente en su teléfono inteligente.
Además, la invención, de acuerdo con sus diferentes modos de realización, prevé que el procedimiento sea implementado por un servidor de prestación de servicios de pago o de transacciones por Internet, que gestione las transacciones de este tipo (en modo de « tarjeta no presente »), y que especialmente comunique con el servidor bancario del comerciante y el comerciante (o sitio del comerciante) involucrados en la transacción.
Por ejemplo, un objeto conectado predeterminado pertenece al grupo que comprende al menos:
• un ordenador ;
• un asistente digital personal;
• una tableta ;
• un teléfono inteligente;
• un reloj conectado;
• una pulsera conectada.
Así, de acuerdo con este modo de realización de la invención, el o los objetos conectados vigilados para ayudar a la autenticación de un usuario corresponden a objetos utilizados tradicionalmente por un usuario, en su domicilio o en movilidad, y que pueden serle asociados como estando cerca la mayor parte del tiempo. Además, los objetos conectados denominados « transportables » (« wearable » en Inglés) en el sentido de un reloj, de una pulsera, un sensor de salud, por ejemplo, son tanto más útiles y relevantes para la ayuda a la autenticación de un usuario cuanto que la mayor parte del tiempo sean llevados realmente « físicamente » por el usuario.
Cabe señalar que cuanto mayor es el número de objetos conectados asociados al usuario que se pueden vigilar (por ejemplo, a la vez un ordenador doméstico, una tableta, un teléfono inteligente y un reloj conectado), más relevante es el nivel de confianza asociado a la transacción.
Según un aspecto particular de la invención, una información de funcionamiento recopilada pertenece al grupo que comprende al menos:
• una información de activación del objeto conectado;
• una información de localización del objeto conectado;
• una información de conexión del objeto conectado;
• una combinación de al menos dos de las citadas informaciones de funcionamiento.
Así, según este modo de realización de la invención, la o las informaciones de funcionamiento recopiladas son relativas a un « estatus » del objeto conectado, estatus considerado relevante para la ayuda a la autenticación del usuario como por ejemplo une información de activación (o de presencia), de conexión a una red local a la cual está conectado igualmente el dispositivo a través del cual se efectúa la transacción, o incluso una información de localización (que debe ser comparada con la localización del dispositivo utilizado para la transacción en línea).
En efecto, la presencia o la ausencia de los objetos conectados asociados al usuario constituye un índice que permite reforzar o no la probabilidad de que el usuario involucrado en la transacción es el que se espera, es decir aquél cuyas informaciones de tarjeta bancaria hayan sido comunicadas para la transacción en cuestión.
Se observará que las informaciones de funcionamiento utilizadas varían dependiendo del tipo de objeto conectado, siendo, sin embargo, una información de localización probablemente más relevante, que una información de presencia o de conexión.
Se observará igualmente que una combinación de una o varias informaciones de funcionamiento relativas a un objeto conectado pueden permitir determinar más concretamente un nivel de confianza. En particular, por ejemplo, en el caso de que la información de localización pueda reforzar la información de presencia, o por el contrario reducir su relevancia, por ejemplo cuando se detecte un objeto conectado como estando conectado a la red local doméstica pero cuya localización no corresponde a la del dispositivo utilizado para la transacción.
Según una característica particular, la etapa de tratamiento de una información de funcionamiento recopilada comprende las subetapas siguientes:
• comparación de la información de funcionamiento recopilada con una información de funcionamiento de referencia, que proporciona un resultado de comparación;
• actualización de un nivel de confianza asociado a la transacción en función del resultado de comparación, que proporción el dato representativo de un nivel de confianza asociado a la transacción.
Así, según este modo de realización de la invención, la o las informaciones de funcionamiento recopiladas (durante la fase de recopilación) permiten la actualización (en el momento de la transacción) de un nivel de confianza asociado a la transacción, a través de su comparación con una o unas informaciones de funcionamiento de referencia.
Por ejemplo, una información de referencia corresponde a un estado « portado », a un estado « conectado a una red predeterminada », o incluso a una localización del dispositivo a través del cual se implementa la transacción (un teléfono inteligente o un ordenador, por ejemplo).
De esta manera, cuando la información de funcionamiento recopilada, para un objeto conectado dado, indique que el mismo está presente o conectado a la red local doméstica, y que el dispositivo utilizado para la transacción esté conectado también a esta misma red, esto refuerza el nivel de confianza de la transacción. Asimismo, cuando la información de funcionamiento recopilada, correspondiente a la localización de un objeto conectado dado, sea similar o cercana a la localización del dispositivo a través del cual se realiza la transacción, esto refuerza el nivel de confianza de la transacción.
Por el contrario, si un objeto conectado asociado al usuario está ausente, o es localizado a una distancia mayor que un umbral predeterminado del dispositivo en el que el usuario realiza su transacción, esto reduce el nivel de confianza de la transacción.
Según un aspecto particular, la actualización del nivel de confianza tiene en cuenta también al menos un criterio perteneciente al grupo que comprende:
• un dato representativo de la transacción;
• una categoría de pertenencia del objeto conectado;
• un contexto de implementación de la transacción;
• una combinación de al menos dos de los citados criterios anteriores.
De esta manera, de acuerdo con este modo de realización de la invención, la actualización del nivel de confianza asociado a la transacción no solo tiene en cuenta la o las informaciones de funcionamiento recopiladas para el o los objetos conectados considerados, sino también:
• uno o varios datos de la transacción del comerciante (o del sitio del comerciante), por ejemplo (la cuantía de la transacción, el tipo de producto de que se trate, la dirección de entrega, el tipo de tarjeta bancaria utilizada ...), utilizados tradicionalmente para evaluar un nivel de confianza (también llamado « puntuación de riesgo ») de una transacción. El nivel de confianza facilitado por la etapa de tratamiento corresponde entonces a un nivel de confianza calculado y actualizado tradicionalmente gracias al procedimiento de la invención;
• la categoría del o de los objetos conectados de los cuales se ha recopilado la información de funcionamiento. De esta manera, se pueden definir varias categorías de objetos conectados que haya que vigilar, como por ejemplo:
o los objetos « esenciales », o muy relevantes, para la implementación del procedimiento de autenticación de acuerdo con la invención, ya que son los objetos más cercanos al usuario, idealmente objetos llevados « físicamente » por el usuario (por ejemplo, un reloj conectado),
o los objetos « no esenciales », o menos relevantes, pero que permiten afinar el nivel de confianza, no llevados « físicamente » por el usuario pero que por ejemplo pueden asociarse al mismo en funcionamiento clásico a domicilio (por ejemplo, un ordenador o una tableta);
• un contexto/una utilización de transacción: a domicilio (la localización es entonces una información de funcionamiento fácilmente utilizable), en movilidad (la localización es entonces menos fiable pero un dato complementario relativo, por ejemplo, al vehículo utilizado puede ser de interés).
Según una característica particular, la fase de recopilación comprende:
• una etapa de registro, en al menos una base de datos adjunta al servidor de pago, de al menos un identificador y de al menos una característica de recopilación para el objeto conectado, y
al menos una iteración de las etapas siguientes:
• recopilación de la citada al menos una información de funcionamiento asociada al citado al menos un objeto conectado asociado al usuario, utilizando la recopilación la citada al menos una característica de recopilación registrada;
• marcado de fecha y hora de la citada al menos una información de funcionamiento recopilada y actualizar la citada base de datos con la citada al menos una información de funcionamiento recopilada con fecha y hora.
De esta manera, según este modo de realización de la invención, una etapa previa de registro de los objetos conectados utilizados para la ayuda a la autenticación de un usuario permite almacenar, en una base de datos, el identificador de un objeto conectado y una característica asociada a este objeto, de manera que permita después la recopilación de informaciones de funcionamiento asociadas a los objetos conectados previamente registrados en la base de datos.
A continuación, durante la fase de recopilación propiamente dicha, la base de datos se actualiza con informaciones de funcionamiento recopiladas (por ejemplo, periódicamente o a petición del servidor de pago) marcadas con fecha y hora para su utilización durante la fase de transacción.
Para ello, la o las características asociadas a un objeto conectado durante la etapa previa de registro permiten definir las « modalidades de recopilación » de la o de las informaciones de funcionamiento asociadas a este objeto. Por ejemplo, una característica de recopilación corresponde a una dirección IP de un ordenador, un número SIM (de « Subscriber Identity Module » en Inglés) de un teléfono móvil, datos de emparejamiento para una conexión de tipo Bluetooth®, datos de punto de acceso WI-FI® ...., variable según el tipo de objeto conectado y que permite obtener la información de funcionamiento correspondiente : presencia del objeto, conexión del objeto, localización del objeto ...
La marca de fecha y hora permite a su vez verificar que las informaciones de funcionamiento recopiladas sean relevantes con respecto a la hora de la transacción.
Por ejemplo, la fase de gestión de una transacción se activa por la recepción de al menos un mensaje que provenga de un dispositivo que implemente la transacción que involucra a los datos bancarios del usuario.
Así, según este modo de realización de la invención, cuando el servidor de pago recibe los datos relativos a una transacción en curso (por ejemplo de tipo cuantía, tipo de tarjeta utilizada, número de tarjeta y fecha de vencimiento, código de seguridad, sitio del comerciante de que se trate ....) y los datos de la tarjeta se corresponden con una tarjeta que se beneficia del procedimiento de ayuda a la autenticación del usuario objeto de la presente invención, se activa la fase de transacción propiamente dicha de este procedimiento.
Por consiguiente a la recepción de un mensaje del servidor de pago, se tratan los datos recopilados durante la fase de recopilación previa.
La invención se refiere también a un servidor de prestación de servicios de pago que implementa el procedimiento de ayuda a la autenticación de un usuario como se describió anteriormente, comprendiendo el servidor de prestación de servicios de pago:
• un módulo de recopilación, que comprende al menos un receptor capaz de recopilar al menos una información de funcionamiento relativa al menos a un objeto conectado previamente asociado al usuario;
• un módulo de gestión de una transacción que involucra a datos bancarios del usuario y a un comerciante, que comprende:
o un módulo de tratamiento de la citada al menos una información de funcionamiento recopilada, que facilita al menos un dato representativo de un nivel de confianza asociado a la transacción;
o un módulo de transmisión, que comprende al menos un emisor capaz de transmitir, a al menos un servidor bancario del comerciante, el nivel de confianza asociado a la transacción.
Un servidor de pago de este tipo, también llamado servidor de prestaciones de transacciones por Internet, corresponde a un servidor a cargo de las transacciones en línea y también de los métodos de aseguramiento suplementarios que a veces se requieren para una transacción, como la técnica 3D SEGURO®.
Según una implementación preferida, las diferentes etapas de los procedimientos de acuerdo con la técnica propuesta son implementadas 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é de acuerdo con 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 está dirigida también a un programa, de ordenador que pueda ser descargado de una red de comunicación y/o almacenado en un soporte legible por ordenador y/o ejecutable por un microprocesador, 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 la forma de código fuente, código objeto, o código intermedio entre código fuente y código objeto, tal como en una forma parcialmente compilada, o en cualquier otra forma deseable.
La técnica propuesta está dirigida también a un soporte de informaciones legible por un procesador de datos, y que comprende instrucciones de un programa 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 bien un medio de registro magnético, por ejemplo un disquete (floppy disc) o un disco duro.
Por otro lado, el soporte de informaciones puede ser un soporte transmisible como una señal eléctrica u óptica, que puede 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 se puede descargar en particular de una red de tipo Internet.
Alternativamente, el soporte de informaciones puede ser un circuito integrado en el que se incorpora el programa, estando el circuito adaptado para ejecutar o para ser utilizado en la ejecución del procedimiento en cuestión.
Según un modo de realización, la técnica propuesta se implementa por medio de componentes de software y/o hardware. Desde esta perspectiva, 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 software.
Un componente de software corresponde a uno o varios programas de ordenador, a uno o varios sub-programas de un programa, o más en general a cualquier elemento de un programa o de un software capaz de implementar una función o un conjunto de funciones, como se describe a continuación 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 capaz de acceder a los recursos materiales 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 de hardware) capaz de implementar una función o un conjunto de funciones, según 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.
Cada componente del sistema descrito anteriormente implementa obviamente sus propios módulos de software.
Los diferentes modos de realización mencionados anteriormente se pueden combinar entre sí para la implementación de la técnica propuesta.
4. Figuras
Otras características y ventajas surgirán más claramente de la lectura de la siguiente descripción de un modo de realización particular de la divulgación, dado a modo de simple ejemplo ilustrativo y no limitativo, y de los dibujos adjuntos, en los cuales:
- la figura 1 ilustra las etapas principales del procedimiento de ayuda a la autenticación de un usuario, según un modo de realización particular de la invención;
- la figura 2 representa un ejemplo de sistema en el cual se puede implementar la invención, según un modo de realización particular;
- la figura 3 ilustra un diagrama de secuencias de un modo de realización particular de la invención;
- las figuras 4 y 5 ilustran dos ejemplos de arquitecturas simplificados de un servidor de prestación de servicios de pago, para la implementación del procedimiento de ayuda a la autenticación de un usuario, de acuerdo con un modo de realización particular de la 'invención.
5. Descripción
5.1. Principio general
El principio general de la técnica propuesta consiste en utilizar objetos conectados asociados a un usuario para ayudar a su autenticación durante una transacción que involucra a datos bancarios asociados a una de sus tarjetas bancarias o a una de sus cuentas bancarias, transacción implementada en modo de « tarjeta no presente ».
Más concretamente, el principio general se basa en la verificación de que los objetos conectados, previamente asociados a un usuario dado, están presentes o cerca de la localización de la transacción (es decir, cerca del dispositivo a través del cual se hace una transacción), en el momento de esta transacción, y por lo tanto que el portador de la tarjeta es el esperado.
En efecto, si un usuario U utiliza su tarjeta bancaria para efectuar una compra en línea, y se puede verificar que su reloj conectado está en su muñeca, que su teléfono inteligente está en su bolsillo, y que el ordenador en el cual tiene lugar la transacción es el ordenador asociado a este usuario, entonces es probable que la tarjeta bancaria sea utilizada válidamente por el usuario U.
Por el contrario, si la tarjeta bancaria de este usuario U ha sido robada, o si las informaciones relativas a esta tarjeta se han recuperado de manera fraudulenta, entonces es probable que en el momento de la utilización de estas informaciones para una transacción, por ejemplo por un tercero malintencionado que efectúe esta transacción en su propio ordenador, los objetos conectados asociados al usuario portador de esta tarjeta bancaria no están presentes o cerca de la localización de la transacción.
Para ello, la invención, de acuerdo con sus diferentes modos de realización, se implementa por un servidor de prestación de servicios de pago (o de transacción por Internet), llamado en lo sucesivo servidor de pago, que comunica a la vez con los diferentes objetos conectados asociados al usuario, con el comerciante que propone la transacción y con el servidor bancario de este comerciante.
De esta manera, informaciones, llamadas de funcionamiento, asociadas a objetos conectados de un usuario, se utilizan, por ejemplo, para saber si un objeto conectado está presente, o conectado a una red determinada, o localizado a una distancia cercana al lugar de la transacción.
La invención prevé por tanto una fase previa a la transacción propiamente dicha, lo que permite recopilar estas informaciones de funcionamiento relativas a estos diferentes objetos conectados asociados al usuario.
Esta primera fase, denominada de recopilación, comprende especialmente una etapa de registro de todos los objetos conectados asociados al usuario, por ejemplo en una base de datos del servidor de pago que implementa el procedimiento, que no solamente permita referir estos objetos conectados sino también asociarles características útiles y necesarias para la recopilación de informaciones de funcionamiento relativas a los mismos.
A continuación, durante una fase de gestión de la transacción propiamente dicha, las informaciones de funcionamiento recopiladas se tratan para actualizar un nivel de confianza asociado a la transacción, siendo transmitido después este nivel de confianza, con informaciones de transacción « clásicas », al servidor bancario del comerciante. Este último evalúa entonces la transacción, por ejemplo en la forma de un « perfil de riesgo », destinado a ser utilizado después por el servidor de pago, el cual, a partir de informaciones proporcionadas por el sitio del comerciante, determina un « coste de transacción » que permite decidir si la transacción es suficientemente segura o no. Para ello, el sitio del comerciante define por ejemplo un nivel de coste aceptable (un umbral), por encima del cual el servidor de pago debe implementar una seguridad suplementaria, o bien una transacción debe ser denegada (puede haber dos umbrales, por ejemplo).
5.2. Descripción de un modo de realización
Se describen ahora, en relación con las figuras 1 a 3, las principales etapas del procedimiento de ayuda a la autenticación de acuerdo con un primer modo de realización de la invención, para un usuario dado (indicado por U en lo que sigue) al cual están asociados objetos conectados 20 a 23 (ilustrados en la figura 2).
De esta manera, en el presente ejemplo, se considera que el usuario U tiene los objetos conectados siguientes: un teléfono inteligente 20, un ordenador 21, una tableta 22 y un reloj conectado 23, siendo estos objetos conectados capaces de ser utilizados para ayudar a la autenticación del usuario durante transacciones posteriores utilizando una de sus tarjetas bancarias.
Como ya se indicó anteriormente, las etapas principales del procedimiento de la invención se agrupan en dos fases: una fase de recopilación 10 y una fase de gestión de una transacción 11.
La fase de recopilación 10 permite recoger las informaciones de funcionamiento asociadas a los diferentes objetos conectados del usuario, después de haberlos registrado previamente, por ejemplo en una base de datos del servidor de pago 200.
Así, este registro permite definir cuáles son los objetos asociados a un usuario dado, en este ejemplo el usuario U, así como las « modalidades » de recopilación de las informaciones de funcionamiento relativas a estos objetos conectados.
Por ejemplo, los mencionados objetos conectados 20 a 23 están referidos, en el seno del servidor 200, con las características siguientes, que permiten la recopilación posterior de las informaciones de funcionamiento relevantes para la ayuda a la autenticación del usuario U:
• el teléfono inteligente 20 está caracterizado por un identificador (por ejemplo, el número IMSI (de « International Mobile Subsciber Identity » en inglés) de la tarjeta SIM (de « Subscriber Identity Module » en inglés), permitiendo este identificador, en particular, conocer la localización del teléfono inteligente 20, a través de la red de comunicación a la cual está conectado;
• el ordenador 21 está caracterizado por un número de serie y una dirección IP (de « Internet Protocol » en inglés), permitiendo la dirección IP, en particular, saber si el ordenador está conectado o no, así como conocer su localización;
• la tableta 22 está caracterizada también por un número de serie y una dirección IP;
• el reloj conectado 23 está caracterizado por el hecho de que esté activado (por lo tanto en la muñeca del usuario) y por el emparejamiento de datos (por ejemplo, con el teléfono inteligente 20) para las comunicaciones Bluetooth®, permitiendo en particular estos datos de emparejamiento con el teléfono inteligente saber si el usuario lleva el reloj correctamente (o incluso entrar en comunicación con él para averiguar su localización); en efecto, un reloj conectado no portado no está activo. Por el contrario, cuando el usuario se lo pone en la muñeca, el reloj detecta que es llevado (generalmente a través de un sensor de biometría) y luego muestra un código (por ejemplo cuatro dígitos) que el usuario debe introducir en su teléfono inteligente. Cada vez que se quite el reloj y se le vuelva a poner, se debe realizar la misma operación. Debido a esto, es posible comprobar que el reloj está bien llevado (ya que está sincronizado con el teléfono inteligente, que es el del usuario).
Para llevar a cabo esta etapa previa de registro, el usuario U puede, por ejemplo, descargar, a propuesta del organismo bancario que gestiona sus tarjetas y cuentas bancarias, una aplicación en uno o varios dispositivos (por ejemplo, su teléfono inteligente, su ordenador y/o su tableta), que permita referir sus objetos conectados.
Esta etapa de registro puede ir seguida de una etapa de verificación, por ejemplo mediante una prueba de las modalidades de recopilación, para iniciar una primera recopilación de informaciones de funcionamiento relativas a los objetos conectados registrados.
Así, la aplicación implementa una primera « interrogación » de los distintos objetos conectados referidos, a través de las características asociadas, para comprobar si estas permiten efectivamente recopilar las informaciones de funcionamiento para cada objeto. Así, por ejemplo, la aplicación verifica que a partir de la dirección IP registrada para el ordenador, es efectivamente posible detectar que el ordenador está presente y determinar su localización. Lo mismo ocurre con la tableta, por ejemplo. En cuanto al teléfono inteligente, la aplicación puede verificar que el identificador registrado corresponde a un dispositivo existente y permite localizar este dispositivo. Finalmente, en lo que concierne al reloj conectado, la aplicación puede intentar entrar en comunicación Bluetooth®, a través de los datos registrados de emparejamiento, con el fin de verificar que el reloj está conectado correctamente (es decir, llevado por el usuario), o incluso que responde a una solicitud predeterminada.
Además, esta aplicación también puede permitir al usuario configurar la fase de recopilación, por ejemplo en lo que respecta a la frecuencia de recopilación de las informaciones de funcionamiento. En efecto, la frecuencia de actualización de las informaciones de funcionamiento se puede configurar, por ejemplo, en función de criterios tales como la frecuencia de pagos en línea realizadas por el usuario, o incluso el grado de movilidad de este usuario, de manera que, cuando se inicie una transacción, las informaciones recopiladas sean las más relevantes posibles (siendo evidentemente una información de localización de hace varias horas menos relevante que una información de localización obtenida por ejemplo en los minutos que preceden a la transacción).
Según las utilizaciones de cada usuario, esta aplicación puede ser instalada preferentemente en un dispositivo móvil cuando el usuario realiza principalmente compras en línea en movilidad, o en un dispositivo tal como un ordenador doméstico, cuando el usuario realiza principalmente compras en línea a domicilio.
Cabe señalar que esta etapa de registro se puede repetir en cualquier momento, por ejemplo, cuando el usuario desee referir otro objeto conectado, o eliminar un objeto referido conectado que ya no sea utilizado .... La fase de recopilación propiamente dicha tiene entonces en cuenta cada actualización de la base de datos.
Una vez realizada esta primera etapa de registro, se implementa la fase de recopilación 10 propiamente dicha, según la periodicidad configurada (por ejemplo cada hora, o 3 veces al día ....).
Cuando se recopila una información de funcionamiento, para un objeto conectado dado, se marca la fecha y la hora y se almacena en la base de datos del servidor de pago. Así, esto da, por ejemplo, para los objetos conectados previamente registrados para el usuario U:
Figure imgf000009_0001
La base de datos puede presentar, como se ilustra en la tabla anterior, un histórico de las informaciones de funcionamiento recopiladas, en función de la periodicidad, o mantener solo la última información de funcionamiento recopilada. Esto, por ejemplo, puede formar parte de la configuración propuesta al usuario cuando el mismo instala la aplicación antes mencionada.
A continuación, cuando se implican una tarjeta bancaria, o datos bancarios, previamente asociados al usuario U en una transacción en modo de « tarjeta no presente », por ejemplo une transacción en línea, se implementa la fase de gestión de la transacción 11.
Se describen a continuación dos casos de utilización de dicha transacción, en los cuales los datos bancarios del usuario U son utilizados por el mismo (primer caso de utilización) o utilizados por un tercero malintencionado después de una usurpación (robo de tarjeta o copia de los datos bancarios) (segundo utilización caso).
a) Descripción de un primer caso de utilización
En este primer caso de utilización, se considera que el usuario U realiza una transacción en línea en su ordenador 21. Como se ilustra en la figura 1, la fase 11 de gestión de la transacción comprende una primera etapa de tratamiento 110 de una o varias informaciones de funcionamiento previamente recopiladas durante la fase 10 de recopilación, para uno o varios de los objetos conectados asociados al usuario, de modo que se facilite un dato representativo de un nivel de confianza asociado a la transacción en curso.
Esta etapa de tratamiento 110 puede incluir varias subetapas (no ilustradas) que permiten calcular este dato representativo de un nivel de confianza, teniendo en cuenta también, eventualmente, otros parámetros ligados a la transacción propiamente dicha (parámetros a menudo facilitados por el comerciante o el sitio del comerciante, descritos con más detalle más adelante).
Así, en este ejemplo, los datos de localización recopilados para los primeros tres objetos conectados 20 a 22 se comparan con la localización del dispositivo a través del cual se realiza la transacción, en este caso el ordenador 21 del usuario U.
Cuando la localización de uno de los objetos conectados asociados al usuario se corresponde o está cerca del ordenador 21, se facilita un resultado de comparación positivo. La comparación de localizaciones puede implementar clásicamente un umbral predeterminado, por debajo del cual se estima que las localizaciones están próximas, y por encima del cual, por el contrario, se estima que las localizaciones están demasiado alejadas para el objetivo de la presente invención.
Con respecto al reloj conectado, si la información de funcionamiento recopilada indica que el reloj es portado (lo que corresponde a la información de referencia para este tipo de objeto), se facilita entonces también un resultado de comparación positivo.
Estos resultados de comparación se utilizan después para actualizar un nivel de confianza asociado a la transacción y así facilitar el dato representativo de un nivel de confianza.
Por ejemplo, si se considera un nivel de confianza correspondiente a un número entre cero y diez (siendo diez el nivel máximo de confianza), se puede considerar que cada resultado de comparación positivo aumenta en una unidad un nivel de confianza por defecto igual a cinco, y que por el contrario, cada resultado de comparación negativo reduce el nivel de confianza en una unidad. En este caso, el dato representativo de un nivel de confianza puede corresponder también a una cifra entre cero y diez. También es posible, según el algoritmo implementado, que ciertos resultados de comparación representen una mayor « ponderación » que otros, por ejemplo en función de la categoría del objeto conectado, como se describe más adelante.
Se puede definir cualquier otro modo de actualización del nivel de confianza que permita tener en cuenta informaciones de funcionamiento recopiladas para los objetos conectados asociados al usuario U. Así, el dato representativo de un nivel de confianza puede corresponder a un porcentaje que refleja el riesgo.
Cualquiera que sea la forma que pueda tomar el nivel de confianza, el comerciante define a partir de qué nivel decide aceptar las transacciones, rechazarlas o solicitar un control suplementario, como se detalla más adelante en relación con la figura 3.
Por otra parte, el nivel de confianza actualizado de acuerdo con los resultados de comparación descritos anteriormente puede tener en cuenta también criterios/parámetros complementarios tales como:
• un dato representativo de la transacción: por ejemplo uno o varios datos del comerciante o del sitio del comerciante (la cuantía de la transacción, el tipo de producto de que se trate, la dirección de entrega, el tipo de tarjeta bancaria utilizada ....), utilizados tradicionalmente para evaluar un nivel de confianza (también llamado « puntuación de riesgo ») de una transacción;
• una categoría de pertenencia del objeto conectado: por ejemplo, un objeto conectado realmente llevado por el usuario (como un reloj o una pulsera) puede ser clasificado como un objeto « prioritario », cuyo resultado de comparación puede tener más importancia en la actualización del nivel de confianza que el de un objeto « no prioritario » (como un teléfono inteligente); en este caso y según el ejemplo descrito anteriormente, el resultado de comparación para un objeto « prioritario » podría incrementar el nivel de confianza en dos unidades;
• un contexto de implementación de la citada transacción: por ejemplo, datos suplementarios de identificación del vehículo en el que el usuario se encuentra en el momento de una transacción en movilidad (identidad del propietario, localización con respecto a trayectos predeterminados (domicilio - lugar de trabajo, por ejemplo)).
Por supuesto, se puede utilizar una combinación de varios de los parámetros/criterios complementarios descritos anteriormente, para reforzar la relevancia del nivel de confianza.
Además, estos parámetros/criterios complementarios pueden, por ejemplo, permitir determinar el nivel de confianza « por defecto », es decir antes de la puesta en práctica de la invención y la utilización de las informaciones de funcionamiento recopiladas, o ser utilizados para incrementar o disminuir un nivel de confianza por defecto predeterminado.
Finalmente, estos parámetros/criterios complementarios pueden provenir de sensores o de fuentes de datos predeterminadas, implementados en el marco de la presente invención, como por ejemplo sensores que permitan localizar el vehículo del usuario.
Una vez facilitado este dato representativo de un nivel de confianza, el mismo se transmite, durante una etapa 111 de transmisión, al servidor bancario del comerciante. Este dato representativo de un nivel de confianza puede transmitirse al mismo tiempo que los datos de transacción transmitidos tradicionalmente por el servidor de pago al servidor bancario del comerciante.
En efecto, durante una transacción « clásica » conocida en modo de « tarjeta no presente », un servidor de pago transmite al servidor bancario del comerciante informaciones de transacciones tales como el comerciante, la cuantía, los datos de la tarjeta (nombre y apellido del titular, número, fecha de caducidad, el código de seguridad), fecha y hora de la transacción, tipo de la transacción (autorización, captura, etc.), así como una « puntuación de seguridad » que resulta de un cálculo que tiene en cuenta parámetros proporcionados principalmente por el comerciante o el sitio del comerciante (el tipo de producto en cuestión, la dirección de entrega, el tipo de tarjeta bancaria utilizada). Como se describe a continuación en relación con la figura 3, estas informaciones son utilizadas por el servidor bancario del comerciante para evaluar un coste de tratamiento de la transacción, que el servidor bancario reenvía al servidor de pago. Este último utiliza estas informaciones para determinar un coste de tratamiento de la transacción, a partir de datos proporcionados previamente por el comerciante o el sitio del comerciante. Por ejemplo, estas informaciones corresponden a uno o varios umbrales por encima del cual o de los cuales el coste de tratamiento se considera demasiado alto para aceptar la transacción tal cual.
De esta manera, existen, por ejemplo, varias posibilidades de gestión de la transacción, según el coste de tratamiento evaluado por el servidor de pago:
• el riesgo es bajo, entonces el servidor de pago envía los detalles de la transacción (cuantía, número de tarjeta ....) al servidor bancario;
• el riesgo es alto, entonces el servidor de pago comienza una etapa suplementaria tipo 3D SECURE® con el consumidor;
• el riesgo es demasiado alto, entonces el servidor de pago rechaza la transacción y se advierte al consumidor.
El procedimiento de ayuda a la autenticación de la invención, de acuerdo con sus diferentes modos de realización, permite por tanto reforzar el nivel de confianza asociado a la transacción, a fin de perfeccionar el coste de tratamiento calculado por el servidor bancario del comerciante, sin intervención suplementaria del usuario, garantizando así la ergonomía de la transacción en línea, a diferencia de las técnicas conocidas de la técnica anterior.
Así pues, se describen ahora con más detalle los diferentes intercambios implementados entre el consumidor, el comerciante o el sitio del comerciante, el servidor de pago que implementa la invención y el servidor bancario del comerciante, en relación con la figura 3.
En primer lugar, el usuario U proporciona, tradicionalmente, los datos necesarios para el pago de un objeto o un servicio en un sitio comercial, y en particular los datos de la tarjeta bancaria (número, fecha de caducidad, código de seguridad). Estos datos se transmiten al servidor de pago (secuencia A), activando así la fase de transacción propiamente dicha del procedimiento de ayuda a la autenticación según este modo de realización de la invención.
Para ello, el servidor de pago detecta que los datos bancarios transmitidos corresponden a los del usuario U previamente registrado, y que se beneficia del servicio de ayuda a la autenticación según la presente invención. El servidor de pago interroga entonces a la base de datos (internamente o a través de una red que permita acceder a esta base de datos « externalizada ») que comprende especialmente las informaciones de funcionamiento con fecha y hora recopiladas para los objetos conectados asociados a este usuario U. El servidor de pago implementa entonces la primera etapa de esta fase de transacción, la cual consiste en tratar estas informaciones de funcionamiento previamente recopiladas para los objetos conectados asociados al usuario U. Como se describió anteriormente, este tratamiento permite determinar un dato representativo de un nivel de confianza asociado a la transacción (secuencia B), el cual es utilizado, por el servidor de pago, para llevar a cabo la transacción creando el mensaje de pago que será transmitido al servidor bancario del comerciante (también llamado « comprador bancario » del comerciante).
A continuación, se transmite esta transacción (secuencia C) al servidor bancario del comerciante, con el dato representativo del nivel de confianza asociado. Como recordatorio, este dato representativo del nivel de confianza asociado a la transacción puede tomar una forma clásica de un nivel de confianza, también llamado « puntuación de riesgo », reforzado/afinado por la utilización de los objetos conectados asociados al usuario, de acuerdo con la presente invención.
El servidor bancario del comerciante implementa entonces una evaluación de la transacción recibida del servidor de pago, siendo esta evaluación en sí conocida. Como se describió anteriormente, esto da como resultado un coste de tratamiento de la transacción destinado a aclarar al servidor de pago en cuanto a un eventual aseguramiento suplementario que haya que implementar para la transacción en curso. Este coste de tratamiento se transmite por tanto (secuencia D) al servidor de pago por el servidor bancario del comerciante.
El servidor de pago a continuación analiza este coste de tratamiento de la transacción, a partir en particular de informaciones proporcionadas por el sitio del comerciante o el comerciante, y decide si la transacción se puede validar (secuencia E), lo que corresponde a este primer caso de utilización, o si es necesario implementar un aseguramiento suplementario (de tipo 3D SECURE® por ejemplo) (secuencia E') (segundo caso de utilización descrito más adelante), o si se rechaza la transacción.
De acuerdo con este primer caso de utilización, la transacción es, por tanto, validada, sin que se requiera un aseguramiento suplementario, y el usuario se beneficia entonces de un servicio de pago en línea que es seguro, rápido y práctico que no requiere etapa suplementaria para introducir datos complementarios como con la implementación de la 3D s Ec URE® por ejemplo.
b) Descripción de un segundo caso de utilización
Si se toma esta vez un segundo ejemplo en el que los datos bancarios del usuario U son usurpados por un tercero malintencionado, las secuencias de la figura 3 tienen lugar como se describe a continuación.
Los datos bancarios del usuario, usurpados, se introducen en el sitio del comerciante y se transmiten (secuencia A) al servidor de pago, como en el primer caso de utilización. Esta recepción, por parte del servidor de pago, desencadena la fase de transacción del procedimiento de la invención, la cual comienza con el tratamiento de las informaciones de funcionamiento recopiladas para los objetos conectados asociados al usuario U.
Según una primera variante, la localización del dispositivo a través del cual se realiza la transacción (es decir, el ordenador o el teléfono inteligente del tercero malintencionado que ha usurpado los datos bancarios del usuario U) no es posible. Por ejemplo, la dirección IP de este dispositivo no es accesible o no permite una localización o se desconoce el número de serie. Esto genera resultados negativos para las comparaciones de proximidad de objetos conectados, a través de sus informaciones de funcionamiento recopiladas previamente, facilitando un bajo nivel de confianza, incluso nulo, para la transacción en curso. En efecto, dado que no hay información de referencia disponible para la localización de la transacción, cualquier comparación de una localización de un objeto conectado con una información de referencia no disponible facilita un resultado de comparación negativo. En el caso del usuario U y de los objetos conectados 20 a 22, varias comparaciones facilitan, por tanto, resultados negativos y, por tanto, el nivel de confianza asociado a la transacción se degrada en gran medida, o incluso es nulo.
Según una segunda variante, la dirección IP del dispositivo a través del cual se realiza la transacción (es decir, el ordenador o el teléfono inteligente del tercero malintencionado que haya usurpado los datos bancarios del usuario U) permite determinar su localización. Esta localización, que no corresponde al dispositivo registrado por el usuario U, puede por tanto servir como referencia para las comparaciones con las localizaciones recopiladas de los objetos conectados asociados al usuario. Por supuesto, estas comparaciones también son negativas porque es poco probable que el dispositivo del tercero malintencionado esté cerca de los objetos conectados del usuario U. Aquí nuevamente, el nivel de confianza asociado con la transacción en curso es bajo, incluso nulo.
Se determina por tanto el dato representativo de un nivel de confianza asociado a la transacción (secuencia B) y el servidor de pago lo utiliza después para llevar a cabo la transacción.
Como en el primer caso de utilización descrito anteriormente, esta transacción, con el dato representativo del nivel de confianza asociado, se transmite (secuencia C) al servidor bancario del comerciante.
El servidor bancario del comerciante implementa entonces una evaluación de la transacción recibida del servidor de pago, siendo esta evaluación en sí conocida. Esto da como resultado un coste de tratamiento de la transacción destinado a aclarar al servidor de pago en cuanto a un eventual aseguramiento suplementario que haya que implementar para la transacción en curso. Este coste de tratamiento es por tanto transmitido (secuencia D) al servidor de pago por el servidor bancario del comerciante.
En este segundo caso de utilización, siendo el nivel de confianza asociado a la transacción en curso bajo, incluso nulo, debido a la no autenticación de usuario U a través de sus objetos conectados, el coste de tratamiento de la transacción es muy elevado. El servidor de pago decide entonces que este coste es demasiado elevado y requiere (secuencia E'), un aseguramiento suplementario o entonces rechaza la transacción.
En el caso de una solicitud de aseguramiento suplementario, por ejemplo, se implanta un aseguramiento del tipo 3D SECURE®, mediante la transmisión de un código de una sola utilización en un dispositivo previamente registrado como perteneciente al usuario U, para que este último, al recibirlo, lo introduzca en el sitio del comerciante. Ahora bien, en este segundo caso de utilización, este código no puede ser recibido por el tercero malintencionado que haya iniciado el pago, el cual por tanto no podrá responder al aseguramiento requerido. Por tanto, la transacción no puede completarse.
En este caso de usurpación de los datos bancarios del usuario U, el procedimiento de ayuda a la autenticación del usuario de la invención permite por tanto evitar una transacción fraudulenta, gracias a la utilización de las informaciones de funcionamiento recopiladas para los objetos conectados asociados al usuario U.
Diferentes variantes de realización de la invención, relativas por ejemplo a los objetos conectados, a las informaciones de funcionamiento recopiladas, al tratamiento de las informaciones de funcionamiento recopiladas o incluso al tipo de nivel de confianza utilizado, se pueden implementar y no se describen en la presente solicitud, en la medida en que las mismas permitan responder a la problemática del aseguramiento de transacciones en el modo de « tarjeta no presente » al tiempo que respondan a los problemas de complejidad, de ergonomía y de rapidez para el usuario, así como de coste y de seguridad de todos los actores involucrados (especialmente comerciantes y organismos bancarios).
5.3. Servidor de prestación de servicios de pago
En relación con las figuras 4 y 5, se presentan ahora dos ejemplos de arquitecturas simplificadas de un servidor de prestación de servicios de pago 400 para la ejecución del procedimiento de ayuda a la autenticación de un usuario según uno de los modos de realización de la invención.
Por ejemplo, dicho servidor de pago 400, denominado servidor de pago, comprende:
• un módulo de recopilación 40, que comprende al menos un receptor 401 de al menos una información de funcionamiento relativa al menos a un objeto conectado previamente asociado al usuario; por ejemplo, un receptor 401 de este tipo puede recibir datos a través de una red de comunicación inalámbrica o por cable a la que están conectados tanto el servidor de pago 400 como los objetos conectados del usuario;
• un módulo de gestión 41 de una transacción que implica datos bancarios del usuario y un comerciante, que comprende:
o un módulo de tratamiento 410 de al menos una información de funcionamiento recopilada, que facilita al menos un dato representativo de un nivel de confianza asociado a la transacción; por ejemplo, tal módulo de tratamiento 410 es capaz de recuperar datos de una base de datos y comparar informaciones de localización;
o un módulo de transmisión, que comprende al menos un emisor 411, a al menos un servidor bancario del comerciante, del nivel de confianza asociado a la transacción; por ejemplo, tal emisor 411 es capaz de transmitir datos, a través de una red de comunicación inalámbrica o por cable a la que están conectados tanto el servidor de pago 400 como el servidor bancario del comerciante.
Tal servidor de pago 400 corresponde, por ejemplo a un servidor de pago implementado tradicionalmente en el contexto de las transacciones en línea, en particular en modo de “tarjeta no presente”, adecuado para implementar el procedimiento de ayuda a la autenticación de un usuario de la invención, de acuerdo con sus diferentes modos de realización.
Tal servidor de pago 400 comprende, por ejemplo, como se ilustra en la figura 5, una memoria 51 constituida por una memoria intermedia, una unidad de tratamiento 52, equipada por ejemplo con un microprocesador, y controlada por el programa de ordenador 53, necesarias para la aplicación del procedimiento de ayuda a la autenticación de un usuario, según los diferentes modos de realización de la invención.
En la inicialización, las instrucciones de código de programa de ordenador 53 se cargan, por ejemplo en una memoria antes de ser ejecutadas por el procesador de la unidad de tratamiento 52. La unidad de tratamiento 52 recibe como entrada, por ejemplo, una o varias informaciones de funcionamiento, asociadas a uno o varios objetos conectados previamente asociados al usuario. El microprocesador de la unidad de tratamiento 52 implementa las etapas del procedimiento de ayuda a la autenticación de un usuario, de acuerdo con las instrucciones del programa de ordenador 53 para permitir la recopilación de estas informaciones de funcionamiento y luego la gestión de una transacción que involucra a datos bancarios del usuario (tratamiento de las informaciones de funcionamiento recopiladas, y luego determinación de un nivel de confianza asociado a la transacción y transmisión de un dato representativo de este nivel de confianza a un servidor bancario del comerciante).
Para esto, el servidor de pago comprende, además de la memoria intermedia 51, un módulo de recopilación 40, que comprende al menos un receptor 401, un módulo de gestión 41 de una transacción, que comprende un módulo de tratamiento 410 y un módulo de transmisión, que comprende al menos una emisor 411, como los descritos anteriormente.
Estos módulos pueden ser controlados por el procesador de la unidad de tratamiento 52 según el programa de ordenador 53.

Claims (8)

REIVINDICACIONES
1. Procedimiento de ayuda a la autenticación de un usuario, procedimiento implementado en el seno de un servidor de prestación de servicios de pago, denominado servidor de pago, comprendiendo dicho procedimiento:
• una fase de recopilación (10), sin intervención del citado usuario, de al menos una información de funcionamiento relativa al menos a un objeto conectado previamente asociado a dicho usuario;
• una fase de gestión (11) de una transacción que involucra a datos bancarios del citado usuario y a un comerciante, que comprende las siguientes etapas:
o tratamiento (110) de la citada al menos una información de funcionamiento recopilada durante dicha fase de recopilación, comprendiendo dicha etapa de tratamiento las subetapas siguientes:
■ comparación de la citada al menos una información de funcionamiento recopilada con al menos una información de funcionamiento de referencia, que facilita un resultado de comparación;
■ actualización de un nivel de confianza asociado a dicha transacción en función del citado resultado de comparación;
■ entrega de al menos un dato representativo de un nivel de confianza asociado a dicha transacción;
o transmisión (111), a al menos un servidor bancario del citado comerciante, del citado al menos un dato representativo del nivel de confianza asociado a dicha transacción para decidir si la transacción del citado usuario puede ser validada.
2. Procedimiento de ayuda a la autenticación de un usuario según reivindicación 1, caracterizado por que el citado al menos un objeto conectado predeterminado pertenece al grupo que comprende al menos:
• un ordenador;
• un asistente digital personal;
• una tableta;
• un teléfono inteligente;
• un reloj conectado;
• una pulsera conectada.
3. Procedimiento de ayuda a la autenticación de un usuario según la reivindicación 1, caracterizado por que dicha información de funcionamiento recopilada pertenece al grupo que comprende al menos:
• una información de activación del citado objeto conectado;
• una información de localización del citado objeto conectado;
• una información de conexión del citado objeto conectado;
• una combinación de al menos dos de las citadas informaciones de funcionamiento.
4. Procedimiento de ayuda a la autenticación de un usuario según reivindicación 1, caracterizado por que la citada actualización del citado nivel de confianza tiene en cuenta igualmente al menos un criterio perteneciente al grupo que comprende:
• un dato representativo de la citada transacción;
• una categoría a la que pertenece el citado objeto conectado;
• un contexto de implementación de la citada transacción;
• una combinación de al menos dos de los citados criterios anteriores.
5. Procedimiento de ayuda a la autenticación de un usuario según reivindicación 1, caracterizado por que la citada fase de recopilación comprende:
• una etapa de registro, en al menos una base de datos adjunta al citado servidor de pago, de al menos un identificador y de al menos una característica de recopilación para el citado objeto conectado, y
al menos una iteración de las etapas siguientes:
• recopilación de la citada al menos una información de funcionamiento asociada al citado al menos un objeto conectado asociado al citado usuario, utilizando la citada recopilación la citada al menos una característica de recopilación registrada;
marcado de fecha y hora de la citada al menos una información de funcionamiento recopilada y actualizar la citada base de datos con la citada al menos una información de funcionamiento recopilada con marca de fecha y hora.
6. Procedimiento de ayuda a la autenticación de un usuario según reivindicación 1, caracterizado por que la citada fase de gestión de una transacción se activa por la recepción de al menos un mensaje procedente de un dispositivo que realiza la citada transacción que involucra a los citados datos bancarios del citado usuario.
7. Servidor (400) de prestación de servicios de pago que implementa el procedimiento de ayuda a la autenticación de un usuario según una cualquiera de las reivindicaciones 1 a 6, comprendiendo el citado servidor de prestación de servicios de pago:
• un módulo de recopilación (40), que comprende al menos un receptor (401) capaz de recopilar, sin la intervención del citado usuario, al menos una información de funcionamiento relativa a al menos a un objeto conectado previamente asociado a dicho usuario;
• un módulo de gestión (41) de una transacción que involucra a datos bancarios del citado usuario y a un comerciante, que comprende:
o un módulo de tratamiento (410) de la citada al menos una información de funcionamiento recopilada, siendo el citado módulo de tratamiento capaz de:
■ comparar dicha información de funcionamiento recopilada con una información de funcionamiento de referencia, facilitando un resultado de comparación;
■ actualizar un nivel de confianza asociado a dicha transacción en función del citado resultado de comparación;
■ facilitar al menos un dato representativo de un nivel de confianza asociado a dicha transacción;
o un módulo de transmisión, que comprende al menos un emisor (411) capaz de transmitir, a al menos un servidor bancario del citado comerciante, el citado al menos un dato representativo de un nivel de confianza asociado a la citada transacción para decidir si la transacción del citado usuario puede ser validada.
8. Producto programa de ordenador descargable de una red de comunicación y/o almacenado en un soporte legible por ordenador y/o ejecutable por un microprocesador, caracterizado por que comprende instrucciones de código de programa para la ejecución de un procedimiento de ayuda a la autenticación de un usuario según las reivindicaciones 1 a 6 cuando el mismo es ejecutado por un procesador.
ES16198205T 2015-11-13 2016-11-10 Procedimiento de ayuda a la autenticación de un usuario, servidor y programa de ordenador correspondientes Active ES2856552T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1560896A FR3043819B1 (fr) 2015-11-13 2015-11-13 Procede d'aide a l'authentification d'un utilisateur, serveur et programme d'ordinateur correspondants

Publications (1)

Publication Number Publication Date
ES2856552T3 true ES2856552T3 (es) 2021-09-27

Family

ID=55646692

Family Applications (1)

Application Number Title Priority Date Filing Date
ES16198205T Active ES2856552T3 (es) 2015-11-13 2016-11-10 Procedimiento de ayuda a la autenticación de un usuario, servidor y programa de ordenador correspondientes

Country Status (5)

Country Link
US (1) US20170140381A1 (es)
EP (1) EP3168769B1 (es)
CA (1) CA2948576A1 (es)
ES (1) ES2856552T3 (es)
FR (1) FR3043819B1 (es)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018102588A1 (en) 2016-12-02 2018-06-07 Swift Health Systems Inc. Indirect orthodontic bonding systems and methods for bracket placement
US10430566B2 (en) * 2016-12-27 2019-10-01 Paypal, Inc. Vehicle based electronic authentication and device management
CN115024842A (zh) 2017-01-31 2022-09-09 斯威夫特健康系统有限公司 混合正畸弓丝
US11196747B2 (en) 2017-12-07 2021-12-07 Bank Of America Corporation Automated event processing computing platform for handling and enriching blockchain data
US20190180276A1 (en) 2017-12-07 2019-06-13 Bank Of America Corporation Automated Event Processing Computing Platform for Handling and Enriching Blockchain Data
US11354655B2 (en) * 2020-04-29 2022-06-07 Capital One Services, Llc Enhancing merchant databases using crowdsourced browser data
US20230070165A1 (en) * 2021-09-03 2023-03-09 Swift Health Systems Inc. Method of administering adhesive to bond orthodontic brackets
US20230267113A1 (en) * 2022-02-23 2023-08-24 Dell Products L.P. Dcf confidence score aging

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3036675B1 (en) * 2013-08-23 2021-03-10 IDEMIA Identity & Security USA LLC Method for identity management
US10548007B2 (en) * 2013-11-15 2020-01-28 Here Global B.V. Security operations for wireless devices
US10121142B2 (en) * 2014-04-11 2018-11-06 Bank Of America Corporation User authentication by token and comparison to visitation pattern

Also Published As

Publication number Publication date
CA2948576A1 (en) 2017-05-13
US20170140381A1 (en) 2017-05-18
EP3168769B1 (fr) 2021-01-06
EP3168769A1 (fr) 2017-05-17
FR3043819B1 (fr) 2017-12-15
FR3043819A1 (fr) 2017-05-19

Similar Documents

Publication Publication Date Title
ES2856552T3 (es) Procedimiento de ayuda a la autenticación de un usuario, servidor y programa de ordenador correspondientes
ES2856696T3 (es) Contenedor de pago, procedimiento de creación, procedimiento de tratamiento, dispositivos y programas correspondientes
ES2894480T3 (es) Procedimiento para realizar la autenticación
JP7279973B2 (ja) 指定ポイント承認における身元識別方法、装置及びサーバ
US11080380B2 (en) Decentralized biometric identity authentication
ES2904552T3 (es) Método de procesamiento de una transacción a partir de un terminal de comunicación
EP3138265B1 (en) Enhanced security for registration of authentication devices
ES2951585T3 (es) Autenticación de transacciones usando un identificador de dispositivo móvil
ES2498893T3 (es) Dispositivo autónomo de entrada segura de PIN para habilitar transacciones con tarjeta EMV con lector de tarjetas separado
EP3537362A1 (en) Method and apparatus for performing payment
US10575179B2 (en) System and method for device fraud prevention
WO2016037415A1 (zh) 一种移动支付方法、系统、设备及计算机存储介质
KR20160101635A (ko) 보안 회로를 통한 데이터의 저장 및 이용
KR20190090732A (ko) 생체 인식 기반의 결제 방법 및 이를 이용하는 사용자 디바이스 및 결제 시스템
US9466060B1 (en) System and method for validating identity for international use of an electronic payment card
US20210217024A1 (en) System and Method of Consolidating Identity Services
US10672003B2 (en) Method and device for facilitating supply of a requested service
ES2972228T3 (es) Autenticación de firma manuscrita digitalizada
ES2878161T3 (es) Método de gestión de un procedimiento de un modo de emergencia de transacción y dispositivo asociado
ES2690973T3 (es) Procedimiento de refuerzo de la seguridad de una transacción realizada mediante tarjeta bancaria
ES2971660T3 (es) Procedimiento para llevar a cabo una transacción, terminal, servidor y programa informático correspondiente
US10812459B2 (en) Method for verifying identity during virtualization
RU137838U1 (ru) Идентифицирующий центр платежной системы
ES2790883T3 (es) Servidor de autenticación para el control de acceso a un servicio
US11108769B2 (en) Cryptobionic system and associated devices and methods