ES2952773T3 - Método de transmisión de datos, dispositivo y programa correspondiente - Google Patents
Método de transmisión de datos, dispositivo y programa correspondiente Download PDFInfo
- Publication number
- ES2952773T3 ES2952773T3 ES18150876T ES18150876T ES2952773T3 ES 2952773 T3 ES2952773 T3 ES 2952773T3 ES 18150876 T ES18150876 T ES 18150876T ES 18150876 T ES18150876 T ES 18150876T ES 2952773 T3 ES2952773 T3 ES 2952773T3
- Authority
- ES
- Spain
- Prior art keywords
- message
- content
- payment
- transmitted
- data
- 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
Links
- 230000005540 biological transmission Effects 0.000 title claims abstract description 71
- 238000000034 method Methods 0.000 title claims abstract description 65
- 238000004891 communication Methods 0.000 claims abstract description 42
- 238000012545 processing Methods 0.000 claims abstract description 28
- 238000002360 preparation method Methods 0.000 claims abstract description 14
- 230000002123 temporal effect Effects 0.000 claims description 4
- 238000004590 computer program Methods 0.000 claims description 3
- 238000007726 management method Methods 0.000 description 10
- 230000008901 benefit Effects 0.000 description 9
- 230000015654 memory Effects 0.000 description 6
- 230000006870 function Effects 0.000 description 5
- 230000003993 interaction Effects 0.000 description 4
- 230000009471 action Effects 0.000 description 3
- 230000008569 process Effects 0.000 description 3
- 230000000295 complement effect Effects 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000013459 approach Methods 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000001010 compromised effect Effects 0.000 description 1
- 230000001143 conditioned effect Effects 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 238000013479 data entry Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000011423 initialization method Methods 0.000 description 1
- 238000004377 microelectronic Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000002604 ultrasonography Methods 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
- 238000012800 visualization Methods 0.000 description 1
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
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/0601—Electronic shopping [e-shopping]
- G06Q30/0641—Shopping interfaces
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/95—Retrieval from the web
- G06F16/957—Browsing optimisation, e.g. caching or content distillation
- G06F16/9577—Optimising the visualization of content, e.g. distillation of HTML documents
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/95—Retrieval from the web
- G06F16/958—Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
-
- 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/18—Payment architectures involving self-service terminals [SST], vending machines, kiosks or multimedia terminals
-
- 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/327—Short range or proximity payments by means of M-devices
- G06Q20/3278—RFID or NFC payments by means of 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/352—Contactless payments by cards
-
- 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
- G06Q30/00—Commerce
- G06Q30/02—Marketing; Price estimation or determination; Fundraising
- G06Q30/0207—Discounts or incentives, e.g. coupons or rebates
- G06Q30/0238—Discounts or incentives, e.g. coupons or rebates at point-of-sale [POS]
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F19/00—Complete banking systems; Coded card-freed arrangements adapted for dispensing or receiving monies or the like and posting such transactions to existing accounts, e.g. automatic teller machines
- G07F19/20—Automatic teller machines [ATMs]
- G07F19/206—Software aspects at ATMs
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F19/00—Complete banking systems; Coded card-freed arrangements adapted for dispensing or receiving monies or the like and posting such transactions to existing accounts, e.g. automatic teller machines
- G07F19/20—Automatic teller machines [ATMs]
- G07F19/211—Software architecture within ATMs or in relation to the ATM network
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Databases & Information Systems (AREA)
- Development Economics (AREA)
- Marketing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Economics (AREA)
- Data Mining & Analysis (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Entrepreneurship & Innovation (AREA)
- Game Theory and Decision Science (AREA)
- Microelectronics & Electronic Packaging (AREA)
- Information Transfer Between Computers (AREA)
- Communication Control (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
La invención se refiere a un método de transmisión de datos, método implementado por un dispositivo electrónico autónomo para procesar transacciones de pago, denominado terminal de pago (BP), comprendiendo dicho terminal de pago (BP) un procesador de procesamiento (Prc) conectado a al menos una oferta de venta. medios de restitución (Scr), y conectados a al menos una interfaz de comunicación (CI) y a al menos un terminal de pago sin contacto (TPNfc). Según la invención, dicho método comprende: - una etapa de transmisión (10), por un navegador (Nav) instalado dentro de dicho terminal de pago (BP), de una solicitud de obtención de contenidos (RqOC) a un servidor de contenidos (SrvCnt) ; - una etapa de recepción (20), por dicho navegador (Nav), desde el servidor de contenidos (SrvCnt), de contenidos html (HCnt) que comprenden al menos una etiqueta de intercambio (HEElt); - una etapa de procesamiento (30) de dicho contenido html (HCnt), que proporciona una vista (Aff) de dicho contenido html (HCnt) en dicho al menos un medio de restitución (Scr); - una etapa de preparación (40), por parte del terminal de pago sin contacto (TPNfc), de al menos una transmisión de mensaje basada en datos de atributos de dicha al menos una etiqueta de intercambio (HEElt). (Traducción automática con Google Translate, sin valor legal)
Description
DESCRIPCIÓN
Método de transmisión de datos, dispositivo y programa correspondiente
1. CAMPO TÉCNICO
La presente técnica se refiere a la gestión de dispositivos para el suministro de bienes y servicios no supervisados. Dichos dispositivos también se denominan "desatendidos" en la literatura de referencia. Más en concreto, la presente técnica se refiere a un método de transmisión de mensajes por intermedio de dichos dispositivos. Más en concreto aún, se presenta un método de transmisión de mensajes destinado a un terminal de comunicación (de un usuario) así como un dispositivo configurado para la puesta en práctica de dicho método.
2. TÉCNICA ANTERIOR
Se conocen dispositivos cuyo objetivo es permitir a un usuario realizar una compra de bienes o servicios de forma independiente, es decir sin la supervisión de un comerciante. Dichos dispositivos también se denominan "desatendidos" (sin vigilancia). Por ejemplo, las estaciones de servicio, los terminales de emisión de entradas de cine. Estos terminales convencionales son de pequeño tamaño y permiten realizar pagos utilizando un terminal de pago que acepta varias formas de pago, a saber, pago con tarjeta de circuito integrado y pago con tarjeta magnética.
Más recientemente han aparecido grandes terminales. Se trata por lo general de terminales multimedia, formados por pantallas de gran tamaño (por lo general de 46 pulgadas de diagonal), que también pueden ser sensibles al tacto. Aparte de que son relativamente caros, los problemas técnicos que presentan estos terminales son numerosos. El primero de ellos es que estos terminales multimedia son de tipo propietario. Esto significa que un terminal multimedia comprende un conjunto de componentes (pantalla, unidad central, sensores de presencia, sistema operativo, aplicación de gestión del terminal) que se disponen de manera conjunta para formar el terminal. Incluso más recientemente, también se han desarrollado terminales multimedia que incorporan funcionalidades de pago. Estos terminales multimedia comprenden de forma global los mismos componentes que un terminal multimedia convencional pero, además, incorporan un terminal de pago, por lo general sin contacto. El documento US 2004/205491 A1 describe por ejemplo, un terminal multimedia de este tipo.
En dicho terminal multimedia, también denominado terminal de pago con referencia a los terminales más pequeños presentados con anterioridad, se utiliza un terminal de pago de tipo NFC (Near Field Channel), por ejemplo, también denominado transmisión de mensajes en campos cercanos. En concreto, para realizar un pago con un terminal de pago de este tipo, el usuario fija su medio de pago compatible con NFC en un lugar muy específico del terminal para realizar el pago de lo que se muestra en pantalla. Puede ser un pago por un bien o por un servicio. Puede ser, por ejemplo, el pago de entradas para espectáculos o una donación a una asociación. En algunos casos, esto puede implicar el pago de un bien (que luego se entrega en una dirección acordada).
Este tipo de terminal es complicado de construir y de poner en práctica. De hecho, por regla general, las ofertas de productos o de servicios que se muestran en el terminal están más o menos preprogramadas. Asimismo, además del hecho de que dichos terminales son relativamente impersonales, también tienen la inconveniente de que no pueden interactuar ampliamente con los usuarios del cliente; en particular, aunque la compra se puede realizar sin problemas, utilizando el terminal sin contacto, la experiencia del usuario “post-compra” suele ser decepcionante. Por ejemplo, cuando la compra se refiera a un bien que deba ser entregado en una determinada dirección de entrega, esta podrá requerir el ingreso, a través de una pantalla táctil, de la dirección de entrega, y ello por parte del propio usuario. Además de hecho de tener que introducir esta dirección puede resultar complejo para el usuario, esto último plantea problemas de seguridad y de confidencialidad ya que por definición, al estar el terminal de pago en un lugar público, la información introducida por el usuario puede ser vista por todos, lo cual no es deseable. Este ejemplo de introducción pospago es representativo de la falta de fluidez de las operaciones a realizar después de la compra. Dichas situaciones también pueden ocurrir antes de la compra y también causar problemas.
Por lo tanto, existe la necesidad de proporcionar una solución simple, eficaz y ampliamente utilizable para simplificar la puesta en práctica de dichos terminales y su interacción con el usuario. Más por lo general, existe la necesidad de facilitar la interacción entre un dispositivo electrónico y un terminal de comunicación de un usuario, en particular cuando se dispone de un dispositivo electrónico programable.
3. SUMARIO
La invención no plantea estos problemas de la técnica anterior. Más en concreto, la invención proporciona una solución más sencilla a los problemas previamente identificados. En efecto, la presente técnica permite ofrecer una solución para agilizar el intercambio de datos entre el vendedor y el cliente, una vez realizada la compra.
Más en concreto, la presente técnica se refiere a un método de transmisión de datos según la reivindicación 1.
De este modo, un dispositivo electrónico autónomo de tratamiento de transacciones de pago es capaz de transmitir mensajes, incluidos en el contenido HTML que recibe del servidor, a usuarios y/o clientes que han utilizado sus terminales de comunicación para recibir dicho mensaje.
Según una característica particular, la solicitud de obtención de contenido comprende al menos un dato de identificación del terminal de pago.
De este modo, el servidor es capaz de identificar los contenidos que están destinados a este terminal de pago. Esto facilita enormemente la personalización del contenido transmitido por el servidor de contenidos al dispositivo electrónico autónomo de tratamiento de transacciones de pago. Asimismo, la estación de pago puede, a su absoluta discreción, transmitir datos, en forma de mensaje, al usuario. El terminal de comunicación del usuario recibe estos datos por intermedio de su interfaz sin contacto y realiza la acción o acciones relacionadas con estos datos. Más concretamente, los datos transmitidos por el terminal de pago pueden comprender, por ejemplo, una URL a la que se puede conectar el terminal de comunicación para realizar un determinado número de tareas, tal como mostrar una página de entrada directamente en el terminal de comunicación del usuario.
Según una característica particular, la etapa de tratamiento del contenido html comprende una etapa de determinación, dentro de la vista a restituir, una localización de un dato representativo de la baliza de intercambio, en función de una posición de un antena sin contacto de dicho al menos un terminal de pago dentro de dicha estación de pago.
Según una característica particular, dicha baliza de intercambio comprende al menos un atributo de definición de un mensaje a transmitir.
Según una característica particular, dicho atributo de definición del mensaje a transmitir es una dirección de localización de un mensaje, con un servidor transaccional, comprendiendo dicha dirección de localización un parámetro de identificación del mensaje y al menos un identificador de un terminal de pago perteneciente a dicha estación de pago.
Según una forma de realización particular, el método comprende una etapa de anulación de dicha al menos una transmisión de mensajes, poniéndose en práctica dicha etapa de anulación cuando la duración de la visualización de un mensaje es igual a un parámetro temporal determinado y cuando no se ha realizado ninguna transmisión durante el período temporal que comienza al final de la preparación de la transmisión y finaliza en el tiempo definido por dicho parámetro temporal.
Según una forma de realización particular, el método comprende, previamente en la etapa de recepción por el navegador, un contenido que comprende dicha al menos una baliza de intercambio, a nivel del servidor de contenido:
- una etapa de recepción de la solicitud del navegador;
- una etapa de identificación, por intermedio de esta solicitud, de dicha estación de pago, que proporciona un identificador de dicha estación de pago;
- una etapa de obtención, dentro de una base de datos, en función del identificador, de un contenido a transmitir a dicha estación, comprendiendo dicho contenido al menos un mensaje a transmitir que comprende datos de mensaje;
- una etapa de obtención, para cada mensaje a transmitir identificada en dicho contenido, un par de datos que comprenden un identificador del terminal de pago y un mensaje cifrado a transmitir;
- creación, por parte del servidor de contenidos, de una dirección de localización de información, hacia un servidor transaccional que comprende el identificador del terminal de pago y el mensaje cifrado a transmitir;
- creación, a partir de dicho contenido y de las direcciones de localización de información, de contenido html que comprende una baliza de intercambio por mensaje a transmitir.
Según una forma de realización particular, el método comprende, previamente en la etapa de recepción por el navegador, contenidos que comprenden dicha al menos una baliza de intercambio, a nivel del servidor de contenidos:
- una etapa de recepción de la solicitud procedente del navegador;
- una etapa de identificación, por intermedio de esta solicitud, de dicha estación de pago, que proporciona un identificador de dicha estación de pago;
- una etapa de obtención, dentro de una base de datos, en función del identificador de la estación de pago, de un contenido a transmitir a dicha estación, comprendiendo dicho contenido al menos un mensaje a transmitir que incluye datos de mensaje;
- una etapa opcional de obtención, para cada mensaje a transmitir que se identifica en dicho contenido, de un servidor transaccional, de un dato representativo de un reto asociado con el mensaje a transmitir;
- una etapa de creación, a partir de dicho contenido y datos del mensaje a transmitir, del contenido html que comprende una baliza de intercambio para el mensaje a transmitir, que incluye la reto opcional.
La invención también se refiere a un dispositivo electrónico autónomo de tratamiento de transacciones de pago, denominado estación de pago, según la reivindicación 9.
Según una forma de realización preferida, las diversas etapas de los métodos, según la invención, se ponen en práctica mediante uno o más software o programas informáticos, que comprenden instrucciones de software destinadas a ser ejecutadas por un procesador de datos de un módulo retransmisor, según la invención, y que están diseñadas para controlar la ejecución de las diversas etapas de los métodos.
En consecuencia, la invención también se refiere a un programa, capaz de ser ejecutado por un ordenador o por un procesador de datos, comprendiendo dicho programa instrucciones para controlar la ejecución de las etapas de un método tal como el mencionado con anterioridad.
Este programa puede utilizar cualquier lenguaje de programación y estar bajo la forma de código fuente, código objeto o código intermedio entre el código fuente y el código objeto, tal como en forma parcialmente compilada, o en solamente cualquier otra forma deseable.
La invención también se refiere a un soporte de información legible por un procesador de datos y que comprende instrucciones de un programa tal como se mencionó con anterioridad.
El soporte de información puede ser cualquier entidad o dispositivo capaz de almacenar el programa. Por ejemplo, el soporte puede incluir un medio de almacenamiento, tal como una memoria ROM, por ejemplo, un CD ROM o un memoria ROM de circuito microelectrónico, o incluso un medio de grabación magnética, por ejemplo, un disquete (floppy disk) o un disco duro.
Por otro lado, el soporte de información puede ser un medio transmisible tal como una señal eléctrica u óptica, que puede enrutarse por intermedio de un cable eléctrico u óptico, por radio o por otros medios. En particular, el programa, según la invención, puede descargarse desde una red de tipo Internet.
De manera alternativa, el soporte de información puede ser un circuito integrado en donde se incorpora el programa, estando el circuito adaptado para ejecutar o para ser utilizado en la ejecución del método en cuestión.
De conformidad con una forma de realización, la invención se pone en práctica 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 un conjunto de componentes de hardware y software.
Un componente de software corresponde a uno o más programas informáticos, una o más subrutinas de un programa, o más por lo general, a cualquier elemento de un programa o software capaz de poner en práctica una función o un conjunto de funciones, tal como se describe a continuación para el módulo en cuestión. Dicho componente de software es ejecutado por un procesador de datos de una entidad física (terminal, servidor, pasarela, enrutador, etc.) y es probable que acceda a los recursos de hardware de esta entidad física (memorias, soportes de registro, bus de comunicación, tarjetas electrónicas de entradas/salidas, interfaces de usuario, etc.).
Del mismo modo, un componente de hardware corresponde a cualquier elemento de un conjunto material (o hardware) capaz de poner en práctica una función o un conjunto de funciones, según lo que se describe a continuación para el módulo en cuestión. Puede ser un componente de hardware que se pueda programar o que tenga un procesador integrado para ejecutar software, por ejemplo, un circuito integrado, una tarjeta inteligente, una tarjeta de memoria, una tarjeta electrónica para ejecutar microsoftware (firmware), etc.
Por supuesto, cada componente del sistema descrito con anterioridad pone en práctica sus propios módulos de software.
Las diversas formas de realización mencionadas con anterioridad se pueden combinar entre sí para la puesta en práctica de la invención.
4. DIBUJOS
Otras características y ventajas de la invención aparecerán más claramente con la lectura de la siguiente descripción de una forma de realización preferente, proporcionada a modo de ejemplo sencillo, ilustrativo y no limitativo, y de los dibujos adjuntos, entre los cuales:
- las Figuras 1A y 1B muestran una estación de pago objeto de este último;
- la Figura 2 presenta, con mayor detalle, los componentes de dicha estación de pago;
- la Figura 3 muestra, en general, la obtención de datos a transmitir por el navegador integrado a una estación de pago objeto de este documento;
- la Figura 4 describe la puesta en práctica de una baliza de intercambio en una forma de realización específica;
- la Figura 5 describe la puesta en práctica de una baliza de intercambio en otra forma de realización.
5. DESCRIPCIÓN
5.1. Descripción general
Tal como se ha explicado con anterioridad, en general, la técnica propone la sustitución de la aplicación “propietaria” para poner en práctica la estación de pago. Esta sustitución se realiza en beneficio de un navegador (también denominado “Browser” en inglés). Esta sustitución permite tener solamente un número muy limitado de tipos de aplicaciones de gestión de estación de pago. En principio, suponiendo que una estación de pago pueda poner en práctica un sistema de Windows™ o un sistema de Linux™, solamente se necesitan dos versiones del navegador: una para el entorno Windows™ y otra para el entorno Linux™.
Otra ventaja es dejar que el servidor se encargue de mostrar las ofertas en la estación. En efecto, puesto que la aplicación de gestión “convencional” se sustituye por un navegador, este último simplemente muestra los datos que se le transmiten, según un formato que también se le transmite. De este modo, según la presente invención, el navegador recibe, del servidor, un documento de tipo “html”, al que se le añaden uno o varios recopiladores de hojas de estilo y una o varias bibliotecas de código “javascript”. La adición de estos datos se puede realizar insertando enlaces a recursos o directamente insertando los datos en el documento de tipo "html".
Sin embargo, aunque dicha puesta en práctica es interesante desde un punto de vista técnico y económico, no permite resolver todo el problema. Más allá del tema de la gestión de la plataforma, también está la gestión del postpago o prepago realizado por intermedio de la estación de pago. Conviene señalar que la estación es capaz de realizar pagos, por intermedio de uno o más terminales de pago integrados directamente en la estación. El uso de una aplicación “propietaria” en un entorno “controlado” tiene la ventaja de una gestión igualmente controlada del terminal de pago. La sustitución de esta aplicación "propietaria" por un navegador plantea problemas a resolver, y en particular el del control de los terminales de pago y la forma de transmitir los datos de pre o postpago al usuario (al cliente).
Para resolver este problema, se pone en práctica una nueva baliza, denominada baliza de intercambio, de conformidad con la presente técnica. Esta baliza, conocida por el navegador, incluye datos relativos al tratamiento de pre o pospago a realizar por la estación de pago. El funcionamiento de esta baliza se detalla a continuación. Durante la recepción por el navegador de la estación (procedente del servidor), del documento de tipo html, el navegador muestra este documento en la pantalla de la estación, adornado con los estilos de las hojas de estilo e incluyendo el código del "javascript". Al menos una baliza de intercambio está presente dentro de este documento, una baliza de intercambio que el navegador interpreta, para realizar las acciones requeridas por dicha baliza, y esto último en relación con el(los) terminal(es) de pago de la estación, con el objetivo de transmitir datos, por ejemplo, después del propio pago (además, el pago se gestiona por intermedio de una baliza de pago). La transmisión de mensajes previo pago no es obligatoria. Los datos también se pueden transmitir antes del pago, según las necesidades de interacción con el usuario. Dicho de otro modo, la baliza de intercambio de datos se utiliza para transmitir al usuario datos que pueden utilizarse para promover la interacción entre el usuario y el comerciante (es decir, el que vende el producto o el servicio ofrecido en la estación de pago). En particular, la baliza de intercambio permite modificar el modo de comunicación entre el comerciante y el usuario (el cliente). Si tomamos el ejemplo de la introducción de datos, que el usuario debía completar en la gran pantalla de la estación de pago, el uso de la baliza de intercambio de datos permite transmitir, al terminal de comunicación del usuario, un mensaje (que comprende, por ejemplo, una URL generada por el comerciante), mensaje que es procesado por el terminal de comunicación que lo recibe y que puede, por ejemplo, conectarse a un servidor dedicado a la introducción de los datos a partir de su terminal de comunicación, que es mucho más discreto, seguro y no requiere que el usuario permanezca frente a la estación de pago para realizar esta introducción.
También se pueden transmitir otros mensajes, tales como recibos digitales, comprobantes de compra digitales, datos que permiten la ejecución de una aplicación específica instalada en el terminal de comunicación del usuario, comprobantes de compras y promociones. Una promoción, por ejemplo, puede consistir en un dato representativo de una rebaja en el producto a comprar (y por lo tanto, transmitidos antes de la compra). Lo mismo ocurre con el lanzamiento de una aplicación específica, que puede realizarse antes de la compra (y pago) realizada en la estación de pago. Los ejemplos se detallan a continuación.
De todos modos, según la invención, el mensaje que contiene los datos es transmitido por la estación de pago al terminal de comunicación del usuario por intermedio de una interfaz NFC, que está presente dentro de la estación de pago. Tal como se describe a continuación, el uso de esta interfaz NFC para la transmisión de los datos al terminal de pago tiene muchas ventajas.
Asimismo, la invención tiene un efecto significativo relacionado con la capacidad del comerciante (es decir, aquel cuyos productos se muestran en la estación de pago para interactuar con el cliente (el que compra los productos) por intermedio de dicha estación de pago, que a su vez es accionada por un operador especializada en la estación de pago (por ejemplo, una autoridad de transporte u otro).
Se describe en relación a las Figuras 1A y 1B, una estación de pago objeto de la presente invención. Dicha estación de pago se presenta bajo la forma de una carcasa, que comprende un medio de restitución de información, tal como una pantalla y/o un altavoz. El medio de restitución de información está conectado por intermedio de uno o más buses de datos a un procesador de tratamiento. Este procesador puede ser cualquier tipo de procesador destinado habitualmente a este tipo de tareas, tales como procesadores de tipo PC o procesadores destinados a terminales más compactos (tales como sistemas en circuito integrado, "SOC" de la abreviatura en inglés "System on Chip"). El procesador de tratamiento comprende un bus de acceso a una memoria de acceso aleatorio, un bus de acceso a una memoria masiva, un bus de acceso a una o más interfaces de comunicación de red (WiFi, Bluetooth, interfaz de red de tipo RJ45) y uno o más buses de acceso a interfaces de comunicación de tipo serie ("USB" en inglés "Universal Serial Bus"). Además, el procesador comprende un bus de acceso a al menos un terminal de comunicación que se presenta bajo la forma de terminal de pago del tipo sin contacto. Dicho terminal de pago sin contacto comprende un procesador de tratamiento seguro, una memoria segura, un bus de acceso a un procesador NFC, y una antena NFC conectada al procesador NFC. El terminal de pago también puede incluir una o más interfaces de comunicación dedicadas. Dependiendo de las formas de realización, las interfaces de comunicación del terminal de pago pueden compartirse con las interfaces de comunicación del procesador de tratamiento. El procesador de tratamiento y los distintos módulos que componen la estación de pago están controlados por un sistema operativo. El sistema operativo es estándar y puede basarse en una versión derivada del sistema Linux™. Incluye módulos para la gestión de los distintos componentes de la estación de pago, a excepción del o de los terminales de pago. El sistema operativo, por su parte, opera un navegador adaptado a la puesta en práctica de la presente invención, y en particular adaptado a la gestión y explotación de balizas de pago. Un terminal de pago, por su parte, también está controlado por un sistema operativo, de tipo propietario (esto no cambia respecto a las estaciones de pago de la técnica anterior). Sin embargo, los datos transmitidos al terminal de pago y recibidos del terminación de pago son significativamente diferentes de los de la técnica anterior, tal como se describe a continuación.
Se presenta, en relación con la Figura 2, la arquitectura de una estación de pago según la presente técnica. Dicha estación de pago (BP) comprende una pantalla (Scr), preferiblemente una pantalla táctil. Una pantalla de este tipo tiene un tamaño suficiente para poder mostrar, de manera visible para los transeúntes, uno o varios mensajes publicitarios. De este modo, la pantalla suele tener un tamaño comprendido de entre 32 y 55 pulgadas en diagonal. Un mensaje publicitario típico mostrado por una pantalla de este tipo incluye, por ejemplo, un video y/o fotografías y/o texto.
Según el entorno de destino de la estación de pago (BM), este última también puede incluir un módulo de reproducción de sonido (MSon): el módulo de reproducción de sonido está destinado a generar sonidos que pueden acompañar a los mensajes publicitarios emitidos, cuando dichos sonidos pueden ser percibidos por los usuarios.
La pantalla (Scr) y el módulo de reproducción de sonido (si está presente) están conectados por uno o dos buses de transporte de datos a un procesador de tratamiento (Proc). Dicho procesador (Proc) incluye suficientes capacidades de tratamiento para realizar diversas tareas de tratamiento multimedia, tal como mostrar vídeo de alta calidad y/o mostrar imágenes de mayor resolución. El procesador (Proc) también puede recibir datos por intermedio del bus de transporte de datos que conecta el procesador (Proc) al módulo NFC (si este último no está gestionado directamente por los terminales de pago integrados) o también a los módulos de comunicación inalámbrica (tal como el módulo WiFi o el módulo Bluetooth, BLE).
El procesador (Proc) también está, de manera opcional conectado, por intermedio de un bus de datos, a sensores (ultrasonidos US, infrarrojos IR o incluso una cámara CAM) para recibir las señales emitidas por estos sensores con el fin de detectar posiblemente la presencia de uno o más usuarios. Estas señales son transformadas por el procesador y suministradas al sistema operativo (SO). El procesador también incluye memoria de acceso aleatorio (RAM) y memoria de almacenamiento (MAS).
El sistema operativo es responsable de ejecutar el navegador y de gestionar los intercambios de datos entre los distintos componentes y el navegador. En otras formas de realización, la estación de pago puede adoptar la forma de un terminal del tipo ordenador, tableta o teléfono inteligente, que incorpore componentes idénticos o similares en sus funciones y que sea capaz de poner en práctica los métodos aquí descritos, en cuyo caso la expresión estación de pago será sustituida por una expresión más apropiada.
Se describe, con relación a la Figura 3, el funcionamiento general de una estación de pago para realizar un tratamiento de transmisión de mensajes por medio de una baliza de intercambio representativa de un mensaje a transmitir. Inicialmente, la estación de pago debe recibir, desde el servidor, datos a visualizar e información relativa a los mensajes a transmitir. El proceso puesto en práctica en esta ocasión es el siguiente:
- una etapa de transmisión (10), al servidor de contenidos (SrvCnt), de una solicitud de obtención de contenido (RqOC), comprendiendo dicha solicitud de obtención de contenido al menos un pago de datos de identificación de la estación de pago (iBP);
o esta solicitud se pone en práctica desde la estación; es por tanto, dicha estación la que solicita los datos a visualizar, y esto último para permitir la correcta forma de realización del intercambio de datos, tal como se describe a continuación;
- una etapa de recepción (20), desde el servidor de contenidos (SrvCnt), de al menos un contenido html (HCnt) a visualizar, comprendiendo dicho contenido al menos una baliza de intercambio (HEElt);
- una etapa de tratamiento (30) de dicho contenido html (HCnt), que proporciona una vista (Aff) de dicho contenido html (HCnt) en dicho al menos un medio de restitución (Scr), que comprende en particular la visualización, por dicho navegador, de dicho contenido, visualizándose datos representativos de la baliza de intercambio (indicación por la cual el usuario puede aproximarse a su terminal de comunicación para recibir el mensaje transmitido por la estación) en las proximidades de una antena NFC de un terminal de pago de la estación de pago. Esto último se pone en práctica, por ejemplo, determinando, dentro de la vista que se va a restituir, una localización de un dato representativo de la baliza de intercambio, en función de una posición de una antena sin contacto de dicho al menos un terminal de pago dentro de dicha estación de pago.
De manera complementaria, el contenido del documento de tipo html también incluye un dato representativo de un tiempo de visualización del contenido. Transcurrido este tiempo de visualización, se vuelve a ejecutar el método anterior, para mostrar nuevos contenidos en pantalla. El objeto de esta última etapa es doble: permite no mostrar de forma permanente contenidos "estáticos" que tendrían como consecuencia, por un lado, reducir la vida útil del dispositivo de visualización y, por otro lado, tener un efecto relativamente engañoso (esencialmente debido al hecho de que una pantalla fija no atrae la atención y, por lo tanto, no mejora las ofertas de bienes y servicios que se muestran en dicha estación).
En segundo lugar, después o concomitantemente con la visualización del contenido en la pantalla, el terminal de pago prepara (40), por adelantado (de manera anticipada), el(los) mensaje(s) a transmitir. El número de posibles transmisiones de mensajes depende, por un lado, del número de terminales de pago instalados en la estación y, por otro lado, del número de balizas presentes en el contenido. Por ejemplo, si existen cuatro terminales de pago y solamente tres balizas, solamente se preparan tres transmisiones de mensajes. Por el contrario, si se instalan tres terminales de pago en la estación correspondiente y existen presentes cuatro balizas de transmisión de mensajes, solamente se preparan tres transmisiones de mensajes (ordenadas por orden de aparición y/o localización del terminal de pago).
La preparación de una transmisión de mensajes también está condicionada: o bien esta preparación se realiza con independencia de un pago, y por tanto se realiza con antelación, es decir antes de que un usuario haya manifestado su intención de comprar un bien o un servicio (independientemente de la preparación de una transacción de pago), o bien, la transmisión de datos está condicionada a una compra (y por lo tanto se lleva a cabo después de la transacción de pago). En este segundo caso, o bien la baliza de intercambio de datos es condicional, y la transmisión de los datos no necesariamente se prepara de antemano (puede serlo, pero la transmisión en sí solamente ocurre después de la validación de la transacción de pago), o bien la baliza de intercambio de datos es recibida después del pago, durante una actualización del contenido html, en cuyo caso, el método puesto en práctica es independiente y no requiere, por parte del servidor que transmite la baliza, una confirmación de pago por el bien o por el servicio.
La preparación de una transmisión de mensajes (con antelación, es decir, antes de que un usuario haya manifestado su intención de adquirir un bien o un servicio) tiene dos finalidades: por un lado, no tener que detectar la presencia del usuario (para iniciar la transmisión) y por otro lado permitir una transmisión inmediata del mensaje.
La preparación de una transmisión de mensajes destinada a un terminal de comunicación se realiza esencialmente gracias a la(s) baliza(s) de intercambio contenida(s) en el documento html.
Una baliza de intercambio, según la presente invención, es esencialmente una instrucción, destinada al navegador, que permite a este último preparar la transmisión de un mensaje y esto, cualquiera que sea la naturaleza de este mensaje, porque el tipo de mensaje a transmitir es introducido como un atributo de la baliza. Una baliza de intercambio es una especie de interfaz universal entre el servidor, que transmite el contenido, y el terminal de pago. La baliza de intercambio se pone en práctica junto con el navegador. La baliza de intercambio adopta de manera global la siguiente forma y representa el mensaje a transmitir a un terminal de comunicación:
<intercambio de datos> </intercambio de datos>
La baliza de intercambio incluye una pluralidad de atributos, incluyendo los atributos de identificación habituales ("id", "nombre", "imagen") y estilos que permiten mostrar el contenido de la baliza cuando sea necesario. La baliza de intercambio también incluye atributos específicos que permiten preparar la transmisión del mensaje al terminal de comunicación. Esencialmente, se utilizan dos métodos, exclusivos (entre sí) o complementarios, según la puesta en práctica, lo que permite preparar la transacción. Como parte de la técnica reivindicada, la baliza incluye el siguiente atributo:
- registro: especifica el mensaje a transmitir, por ejemplo, en forma de un registro NDEF.
Otros posibles atributos de la baliza son los siguientes:
- enlace: especifica una dirección de localización del mensaje a transmitir; se trata de un atributo que permite obtener el mensaje a transmitir desde un lugar diferente al del contenido (por ejemplo, directamente de un comerciante, comerciante que no es necesariamente el operador de la estación de pago);
- tipo: especifica el tipo de mensaje a transmitir;
- comerciante: especifica los parámetros del comerciante (operador de la estación de pago);
o los parámetros del comerciante pueden (y lo son con mayor frecuencia) cifrarse: corresponde al terminal de pago descifrar esta información a partir de los datos de los que tiene conocimiento;
- reto: especifica un reto operativo: el reto proviene, por ejemplo, de un servidor remoto, diferente del servidor de contenido, y permite que al terminal de pago realizar una autenticación mutua al preparar la transmisión de los datos.
En el caso de que el mensaje (por ejemplo, un registro NDEF) se transmita después de una transacción de pago, se muestran los datos de contenido html y los terminales de pago de la estación preparan las transacciones (con anticipado), con el fin de permitir la forma de realización de pagos por parte de los usuarios mediante la fijación de sus terminales de comunicación NFC en los lugares indicados por las balizas de pago, de las que al menos determinados datos se muestran en pantalla (por ejemplo, el precio y/o un logotipo de pago sin contacto). Pueden ocurrir dos eventos al final de la preparación de la transacción: un usuario realiza un pago por una de las ofertas mostradas y (el mensaje se transmite al final de la transacción al terminal de comunicación del usuario), o bien, no se realiza ningún pago (dentro de un período temporal determinado). En este caso, el método comprende una etapa de anulación de las operaciones de pago iniciadas con anterioridad, realizándose la anulación cuando una duración de visualización de la oferta es mayor o igual a un parámetro temporal determinado y cuando no se ha realizado ningún pago durante el período temporal que comienza al final de la preparación de la transacción y que finaliza en el tiempo definido por dicho parámetro temporal. Si se produce esta anulación, se vuelve a poner en práctica el método descrito con anterioridad (etapas 10 a 40), dando como resultado la visualización de (nuevos) datos y la preparación de nuevas transacciones de pago y nuevos mensajes a transmitir con antelación.
En el caso de que los datos se transmitan de manera independiente de la realización de una transacción, se visualizan los datos de contenido html y los terminales de pago de la estación preparan la transmisión de los mensajes contenidos en las balizas de intercambio de datos.
5.2 Puesta en práctica de una baliza de intercambio
Existen principalmente dos métodos para poner en práctica esta baliza de intercambio: uno utilizando el atributo de enlace (“link”) y otro utilizando atributos descriptivos. La distinción entre la puesta en práctica del primer método y el segundo método puede tener en cuenta los parámetros físicos de la estación de pago, pero también parámetros relacionados con los mensajes a transmitir o incluso parámetros específicos del operador que gestiona las estaciones de pago (que gestiona un conjunto de estaciones de pago). Por lo tanto, la puesta en práctica de uno u otro método a menudo está predefinida. La puesta en práctica de la baliza de intercambio permite que al terminal de pago transmitir mensajes asociados con las ofertas presentes en el contenido y/o con las compras realizadas por el usuario.
5.2.1 Primer método de puesta en práctica
Un primer método, que no es objeto de la presente invención, consiste en proporcionar, al terminal de pago, de mensajes a transmitir por intermedio de una URL. En este caso, la baliza utiliza el atributo “link” que, si se valora, incluye un enlace (una URL) a un recurso seguro que contiene el mensaje a transmitir. Esta URL puede ser una dirección, bien se hacia el servidor de contenido (el que entregó el contenido html para visualizar) o bien hacia un servidor de terceros (un servidor de un comerciante que vende el producto, diferente del operador de la estación de pago).
Esta URL permite, por ejemplo, que el navegador (según el material criptográfico que incorpore) de la estación de pago tenga conocimiento de los mensajes a transmitir y configure el terminal de pago para preparar la transmisión de estos mensajes por intermedio de su interfaz NFC. Sin embargo, de manera más eficaz, esta URL permite directamente al terminal de pago seleccionado que tenga conocimiento de los mensajes a transmitir y se configure en consecuencia y se autentifique con un servidor: el interés es asegurarse de que los mensajes transmitidos no sean usurpados por una modificación no deseada del navegador.
De este modo, para poner en práctica dicho método, a partir de la baliza de enlace ≤link>, según al menos un ejemplo, descrito en relación con la Figura 4, cuando el navegador (Nav) transmite una solicitud para obtener contenido al servidor de contenido (SrvCnt), el servidor de contenido (SrvCnt) pone en práctica el siguiente proceso:
- la recepción (S01) de la solicitud (RqOC) desde el navegador (Nav);
- la identificación (S02), por intermedio de esta solicitud, de dicha estación de pago (BP), que proporciona un identificador (iBP) de dicha estación de pago;
- la obtención (S03), dentro de una base de datos (BD), en función del identificador (iBP) de la estación de pago (BP), de un contenido (Cnt) para ser transmitido a dicha estación (BP), comprendiendo dicho contenido al menos un mensaje a transmitir (MTi) que comprende parámetros (datos, tipo de datos, una fecha, una duración y parámetros del comerciante);
- la obtención (S04), para cada mensaje a transmitir (MTi) identificado en dicho contenido, un par de datos que comprenden un identificador del terminal de pago (vxi) y un mensaje cifrado a transmitir (MTCi), comprendiendo esta obtención:
- la transmisión del mensaje a transmitir (MTi) a un servidor transaccional (CTO);
- la determinación, entre los terminales de pago (vx1,...vx6) de la estación de pago, de un identificador del terminal de pago (vxi) asociado a este mensaje a transmitir (MTi);
- la creación, a partir de los parámetros del mensaje a transmitir (MTi) y/u otros parámetros, de un mensaje cifrado a transmitir (MTCi);
- este dato se cifra utilizando la clave pública del terminal de pago a cargo (vxi);
- cuando el terminal de pago tiene conocimiento de este dato, puede autenticarlo como generado por el servidor de transacciones (véase a continuación);
- el atributo "reto" ("challenge") también puede ser generado por el servidor de transacciones en esta ocasión (para permitir al terminal de pago asumir el reto generado por el servidor antes de que se transmitan los datos);
- la transmisión, por parte del servidor transaccional (CTO), al servidor de contenidos (SrvCnt), del par formado por el identificador del terminal de pago (vxi) y el mensaje cifrado a transmitir (MTCi);
- la creación (S05), por parte del servidor de contenidos (SrvCnt), de una dirección de localización de información (@LRli), hacia el servidor transaccional (CTO) que comprende el identificador del terminal de pago (vxi) y el mensaje cifrado a transmitir (MTCi);
- la creación (S06), a partir de dicho contenido (Cnt) y de las direcciones de localización de información (@LRli), del contenido html (HCnt) que comprende una baliza de intercambio (HEElt) por mensaje a transmitir (MTi). Este método tiene la ventaja de no requerir el suministro de datos "secretos" al navegador. De hecho, con este método, el navegador no sabe qué mensajes intercambiar con el terminal de comunicación. Estos mensajes son encriptados y transmitidos directamente por el navegador (y la API correspondiente) al terminal de pago cuyo identificador está presente en la URL. De este modo, incluso si el navegador está comprometido (es decir, está sujeto a vigilancia para alterar su funcionamiento o para alterar las transacciones de pago), no es posible modificar los datos contenidos en los mensajes a intercambiar con el terminal de comunicación, mensajes que están encriptados y descifrables solamente por el terminal de pago designado (vxi) para el intercambio de dichos datos. Sin embargo, este método tiene la desventaja, para el navegador, de tener que obtener potencialmente datos del mensaje a transmitir desde el terminal de pago y, por lo tanto, de requerir intercambios adicionales entre el terminal de pago y el navegador (intercambios que, por supuesto, son seguros). De este modo, este método es más efectivo en términos de seguridad, pero más restrictivo en términos de puesta en práctica.
De manera ventajosa, cuando el mensaje se transmite tras la forma de realización efectiva de una transacción, por el servidor transaccional (CTO), el servidor del comerciante al que se le compró el bien o servicio y que, dotado de un
identificador de transacción (y/o un número de pedido) es capaz de establecer un vínculo entre la transacción y el tipo de mensaje que se transmitirá al usuario del cliente, para por ejemplo, permitir entradas adicionales y/o proporcionar un comprobante de compra, etc. Lo que antecede también es válido para el segundo modo de puesta en práctica descrita a continuación.
5.2.2 Segundo método de puesta en práctica
Un segundo método de puesta en práctica de la baliza de intercambio, que es objeto de la presente invención, consiste en proporcionar, al terminal de pago, mensajes a transmitir por intermedio de los atributos de la baliza de intercambio. En este caso, el atributo de enlace no se utiliza necesariamente. Además, obtener mensajes del servidor de contenido (SrvCnt) es diferente del método anterior.
Para poner en práctica dicho método, a partir de las balizas de intercambio, según la presente invención, en al menos una forma de realización, descrita en relación con la Figura 5, cuando el navegador (Nav) transmite una solicitud de obtención de contenido al servidor de contenido (SrvCnt), el servidor de contenido (SrvCnt) pone en práctica el siguiente proceso:
- la recepción (S11) de la solicitud (RqOC) desde el navegador (Nav);
- la identificación (S12), por intermedio de esta solicitud, de dicha estación de pago (BP), que proporciona un identificador (iBP) de dicha estación de pago;
- la obtención (S13), dentro de una base de datos (BD), según el identificador (iBP) de la estación de pago (BP), de un contenido (Cnt) para ser transmitido a dicha estación (BP), comprendiendo dicho contenido al menos un mensaje a transmitir (MTi) que incluye parámetros (registro, tipo de registro, una fecha, una duración y parámetros del comerciante);
- la obtención (S14), de manera opcional, para cada mensaje a transmitir (MTi) identificado en dicho contenido, desde un servidor transaccional (CTO), de un "reto" (Chal) asociado al mensaje a transmitir (MTi) que comprende: - la transmisión del mensaje a transmitir (MTi) al servidor transaccional (CTO);
- la creación, a partir de los parámetros del mensaje a transmitir y/u otros parámetros, de un dato cifrado de reto (Chal);
- la transmisión, por parte del servidor transaccional (CTO), de dichos datos de reto cifrados (Chal);
- la creación (S15), a partir de dicho contenido (Cnt) y de los datos del mensaje a transmitir (MTi), de contenido html (HCnt) que comprende una baliza de intercambio (HEElt) para el mensaje a transmitir (MTi), que comprende el reto opcional (Chal).
Esta forma de realización tiene la ventaja de permitir que el navegador integre directamente, dentro de la vista, los mensajes a transmitir, sin necesidad de decodificación. Esta puesta en práctica es menos segura que la primera, pero también es más flexible. De hecho, el navegador toma conocimiento directo de los datos de los mensajes que se van a transmitir, sin tener que llamar al terminal de pago y, por lo tanto, puede preparar la vista con mayor rapidez. El terminal de pago también recibe, desde el navegador, los datos que le son destinados (registro). En base a los datos recibidos, el terminal de pago transmite una solicitud al servidor de transacciones y se realizan una serie de intercambios para permitir la autenticación del terminal, del servidor de transacciones, y de los datos a transmitir. El método puesto en práctica comprende las siguientes etapas:
- una etapa de recepción, por parte del terminal de pago, de los parámetros del mensaje a transmitir; siendo transmitidos por el navegador por intermedio de una interfaz API;
- una etapa de obtención de un dato representativo del servidor transaccional; que puede almacenarse en una memoria protegida del terminal de pago o ser proporcionado por el navegador;
- una etapa de creación, a partir de los datos del mensaje a transmitir y de una clave privada del terminal de pago, de un dato cifrado representativo del mensaje a transmitir: el terminal de pago encripta los datos con su clave privada y posiblemente con la clave pública del servidor transaccional; por lo tanto, solamente el servidor transaccional, que tiene tanto la clave pública del terminal como su clave privada, puede descifrar los datos transmitidos por el terminal de pago;
- una etapa de transmisión de una solicitud de tratamiento a dicho servidor transaccional, comprendiendo dicha solicitud de tratamiento el dato cifrado representativo del mensaje a transmitir y un identificador del terminal; y
- cuando el servidor transaccional acepta los datos transmitidos por el terminal de pago, una etapa de recepción, desde el servidor transaccional, de un dato representativo de una aceptación del tratamiento de estos datos por el terminal de pago.
De este modo, solamente un terminal de pago y un servidor transaccional auténticos son capaces de preparar la transmisión de mensajes que también son auténticos. Conviene señalar que el uso de la baliza de intercambio permite, de manera ventajosa, "pasar" datos al terminal de pago de forma transparente para el servidor de contenidos. Lo que antecede permite tener una gestión mucho más sencilla de los contenidos a transmitir a las estaciones de pago: ya no es necesario tener contenido "propietario" y se puede utilizar contenido estandarizado, sin que ello repercuta en la seguridad del conjunto de las transmisiones de datos realizadas por las estaciones de pago.
5.3. Puesta en práctica de una transmisión de mensajes por anticipado (antes de un pago)
El primer método para preparar la transmisión de mensajes comprende, tal como se describió con anterioridad, el uso de una dirección en la baliza "link". Esta forma de realización se pone en práctica más bien cuando el terminal de pago tiene sus propios recursos de comunicación hacia los servidores (pago y/o comerciante), como por ejemplo, su propia interfaz de red, pero esto no es de ninguna manera obligatorio. En esta forma de realización, el terminal de pago recupera los datos a transmitir de una URL de la baliza, siendo dicha URL (segura, del tipo 'https://') transmitida por el navegador. El terminal de pago transmite una solicitud al servidor, que lo identifica (por ejemplo, gracias al agente de usuario o a otro parámetro añadido por el terminal a la URL) y verifica (o incluso facilita) los datos a transmitir.
Utilizando esta información, el terminal prepara la transmisión, es decir inicia la transmisión y espera la presentación de un terminal de comunicación. Dicho de otro modo, el terminal actúa como si el comerciante ya hubiera identificado un usuario a quien transmitir estos datos. La diferencia es que a priori ni el comerciante ni el terminal tienen información sobre la presencia o ausencia de un usuario. Por lo tanto, la transmisión del mensaje permanece "abierta" durante un tiempo predeterminado. Tal como se ha descrito con anterioridad, si un cliente presenta su terminal de comunicación frente a la antena sin contacto del terminal de pago, la transmisión del mensaje se realiza por el terminal de pago de la estación correspondiente. La ventaja de esta forma de hacer las cosas es que la transmisión del mensaje es rápida, que no existe la necesidad de detectar la presencia del usuario (del cliente) puesto que es el mismo quien se manifiesta presentando su terminal de comunicación sin contacto ante el terminal. Lo que antecede resuelve, gracias a esta baliza y a esta forma de transmisión, uno de los problemas con anterioridad expuestos con las estaciones de pago de la técnica anterior, a saber, la necesidad de detectar la presencia del usuario con sensores de presencia.
En el segundo método de preparación para la transmisión comprende la configuración, por parte del navegador, del terminal de pago para el que prepara la transmisión. Esta forma de realización se pone en práctica más bien cuando el terminal de pago no dispone de recursos de comunicación propios y el sistema operativo de la estación de pago actúa como puerta de enlace a los servidores (pago y/o comerciante), pero no es obligatorio. En esta forma de realización, el navegador recupera los datos de la baliza de intercambio (registro, tipo, parámetros del comerciante, fecha, "challenge" ) y transmite estas informaciones al terminal de pago por intermedio de una interfaz API de dicho terminal de pago, permitiendo la interfaz API al sistema operativo intercambiar la información con el terminal de pago. Por lo demás, el método de inicialización de la transmisión es el mismo que el anterior y las ventajas obtenidas son idénticas.
5.4. Desarrollo de la transmisión
Una vez preparada la transmisión, la finalización de la misma es sencilla. Para ello, basta que el usuario fije su terminal de comunicación en el lugar indicado para que el terminal de pago pueda transmitir el registro (datos de “record” de la baliza de intercambio, por ejemplo, un registro NDEF). Para ello, justo después de inicializar la transmisión, el terminal de pago envía una solicitud de transmisión. La transmisión de esta solicitud se realiza de forma cíclica, mientras dure la visualización, en la pantalla de indicación de transmisión. Cuando el usuario coloca su terminal de comunicación en el lugar indicado, el registro es inmediatamente obtenido por el terminal de comunicación, que luego realiza las operaciones requeridas por el registro (en función del tipo y de los datos contenidos en el registro NDEF).
Claims (10)
1. Método de transmisión de datos, método puesto en práctica por un dispositivo electrónico autónomo de tratamiento de transacciones de pago, denominado estación de pago (BP), comprendiendo dicha estación de pago (BP) un procesador de tratamiento (Prc) conectado a al menos un medio de restitución de oferta de venta (Scr), y conectado a al menos una interfaz de comunicación (CI) y a al menos un terminal de pago sin contacto (TPNfc), comprendiendo dicho método:
- una etapa de transmisión (10), mediante un navegador (Nav) instalado dentro de dicha estación de pago (BP), de una solicitud de obtención de contenido (RqOC) a un servidor de contenido (SrvCnt);
- una etapa de recepción (20), por parte de dicho navegador (Nav), procedente del servidor de contenidos (SrvCnt), de un contenido html (HCnt) que comprende al menos una baliza de intercambio (HEElt);
- una etapa de tratamiento (30) de dicho contenido html (HCnt), que proporciona una vista (Aff) de dicho contenido html (HCnt) en dicho al menos un medio de restitución (Scr);
estando dicho método caracterizado porque comprende, además, una etapa de preparación (40), por parte del terminal de pago sin contacto (TPNfc), de al menos una transmisión de mensaje a un terminal de comunicación, dependiendo de los datos de atributo de dicha al menos una baliza de intercambio (HEElt), comprendiendo dicha etapa de preparación:
- una inicialización de dicha al menos una transmisión de mensaje que comprende la visualización, en dichos medios de restitución, de una indicación de transmisión;
- la obtención, a partir de dichos datos de atributo de dicha al menos una baliza de intercambio, un registro que especifique dicho mensaje;
- la transmisión, de manera cíclica, durante el tiempo de visualización de dicha indicación de transmisión, de una solicitud de transmisión que comprende dicha registro.
2. Método según la reivindicación 1, caracterizado porque la solicitud de obtención de contenido (RqOC) comprende al menos un dato de identificación del terminal de pago.
3. Método según la reivindicación 1, caracterizado porque la etapa de tratamiento (30) del contenido html (HCnt) comprende una etapa de determinación, dentro de la vista a restaurar, una localización de un dato representativo de la baliza de intercambio, en función de una posición de una antena sin contacto de dicho al menos un terminal de pago dentro de dicha estación de pago.
4. Método según la reivindicación 1, caracterizado porque dicha baliza de intercambio comprende al menos un atributo de definición de un mensaje a transmitir.
5. Método según la reivindicación 4, caracterizado porque dicho atributo de definición del mensaje a transmitir es una dirección de localización (@LR) de un mensaje, con un servidor transaccional, comprendiendo dicha dirección de localización un parámetro de identificación del mensaje y al menos un identificador de un terminal de pago perteneciente a dicha estación de pago.
6. Método según la reivindicación 1, caracterizado porque comprende una etapa de anulación de dicha al menos una transmisión de mensajes, poniéndose en práctica dicha etapa de anulación cuando la duración de la visualización de un mensaje es igual a un parámetro temporal determinado y cuando no se ha realizado ninguna transmisión durante el período temporal que comienza al final de la preparación de la transmisión y finaliza en el tiempo definido por dicho parámetro temporal.
7. Método según la reivindicación 1, caracterizado porque comprende, previamente en la etapa de recepción (20) por parte del navegador (Nav), del contenido (html) que comprende dicha al menos una baliza de intercambio, al nivel del servidor de contenido (SrvCnt):
- una etapa de recepción (S01) de la solicitud (RqOC) procedente del navegador (Nav);
- una etapa de identificación (S02), por intermedio de esta solicitud, de dicha estación de pago (BP), que proporciona un identificador (iBP) de dicha estación de pago;
- una etapa de obtención (S03), dentro de una base de datos (DB), según el identificador (iBP), del contenido (Cnt) a transmitir a dicha estación (BP), comprendiendo dicho contenido al menos un mensaje a transmitir (MTi) que comprende datos de mensajes;
- una etapa de obtención (S04), para cada mensaje a transmitir (MTi) identificada en dicho contenido, un par de datos que comprenden un identificador de terminal de pago (vxi) y un mensaje cifrado a transmitir (MTCi);
- creación (S05), por parte del servidor de contenidos (SrvCnt), de una dirección de localización de información (@LRIi), hacia un servidor transaccional (CTO) que comprende el identificador del terminal de pago (vxi) y el mensaje a transmitir encriptado (MTCi);
- creación (S06), a partir de dicho contenido (Cnt) y de las direcciones de localización de información (@LRIi), contenido html (HCnt) que comprende una baliza de intercambio (HEElt) por mensaje a transmitir (MTi).
8. Método según la reivindicación 1, caracterizado porque comprende, previamente en la etapa de recepción (20) por parte del navegador (Nav), del contenido (html) que comprende dicha al menos una baliza de intercambio, a nivel servidor de contenido (SrvCnt):
- una etapa de recepción (S11) de la solicitud (RqOC) del navegador (Nav);
- una etapa de identificación (S12), por intermedio de esta solicitud, de dicha estación de pago (BP), que proporciona un identificador (iBP) de dicha estación de pago;
- una etapa de obtención (S13), dentro de una base de datos (DB), según el identificador (iBP) de la estación de pago (BP), del contenido (Cnt) a transmitir a dicha estación (BP), comprendiendo dicho contenido en al menos un mensaje a transmitir (MTi), que incluye datos de mensaje;
- una etapa opcional de obtención (S14), para cada mensaje a transmitir (MTi) identificada en dicho contenido, de un servidor transaccional (CTO), de un dato representativo de un reto (Chal) asociado al mensaje a transmitir (MTi);
- una etapa de creación (S15), a partir de dicho contenido (Cnt) y datos del mensaje a transmitir (MTi), del contenido html (HCnt) que comprende una baliza de intercambio (HEElt) para el mensaje a transmitir (MTi), que incluye el reto opcional (Chal).
9. Dispositivo electrónico autónomo de tratamiento de transacciones de pago, denominado estación de pago (BP), comprendiendo dicha estación de pago (BP) un procesador de tratamiento (Prc) conectado a al menos un medio de restitución de oferta de venta (Scr), y conectado a al menos una interfaz de comunicación (CI) y a al menos un terminal de pago sin contacto (TPNfc), comprendiendo dicho dispositivo:
- medios de transmisión de una solicitud de obtención de contenido (RqOC) a un servidor de contenido (SrvCnt), puesto en práctica por un navegador (Nav) instalado dentro de dicha estación de pago (BP);
- medios de recepción, destinados al navegador (Nav), procedentes del servidor de contenidos (SrvCnt), de un contenido html (HCnt) que comprende al menos una baliza de intercambio (HEElt);
- medios de tratamiento de dicho contenido html (HCnt), que proporciona una vista (Aff) de dicho contenido html (HCnt) en dicho al menos un medio de restitución (Scr);
estado dicho dispositivo caracterizado porque, además, comprende medios de preparación, por anticipado y por parte del terminal de pago sin contacto (TPNfc), de al menos una transmisión de mensajes con destino a un terminal de comunicaciones, dependiendo de los datos de atributos de dicha al menos una baliza de intercambio (HEElt), comprendiendo dichos medios de preparación:
- medios de inicialización de dicha al menos una transmisión de mensajes que ponen en práctica la visualización, en dichos medios de restitución, de una indicación de transmisión;
- medios de obtención, a partir de dichos datos de atributos de dicha al menos una baliza de intercambio, de un registro que especifique dicho mensaje;
- medios de transmisión, de manera cíclica, durante el tiempo de visualización de dicha indicación de transmisión, de una solicitud de transmisión que comprende dicho registro.
10. Producto de programa informático descargable desde una red de comunicación y/o almacenado en un medio legible por ordenador y/o ejecutable por un microprocesador, caracterizado porque comprende instrucciones de código de programa para la ejecución de un método de tratamiento según la reivindicación 1 a 8, cuando es ejecutado por un procesador.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1750356A FR3062008B1 (fr) | 2017-01-17 | 2017-01-17 | Procede de transmission de donnees, dispositif et programme correspondant. |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2952773T3 true ES2952773T3 (es) | 2023-11-06 |
Family
ID=58547662
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES18150876T Active ES2952773T3 (es) | 2017-01-17 | 2018-01-09 | Método de transmisión de datos, dispositivo y programa correspondiente |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US20180204273A1 (es) |
| EP (1) | EP3349160B1 (es) |
| CA (1) | CA2992195A1 (es) |
| ES (1) | ES2952773T3 (es) |
| FR (1) | FR3062008B1 (es) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR3061975B1 (fr) * | 2017-01-17 | 2019-10-18 | Ingenico Group | Procede de traitement d’une transaction de paiement, borne de paiement et programme correspondant. |
| CN109871354B (zh) * | 2019-01-16 | 2023-08-22 | 平安科技（深圳）有限公司 | 一种文件处理的方法及装置 |
| CN110428556A (zh) * | 2019-07-26 | 2019-11-08 | 深圳市脸谱科技有限公司 | 一种自动售卖和换电一体的系统及方法 |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20040205491A1 (en) * | 2001-05-30 | 2004-10-14 | Aravinda Korala | Software and method for self-service applications |
| WO2014077882A1 (en) * | 2012-11-19 | 2014-05-22 | Avery Dennison Corporation | Nfc security system and method for disabling unauthorized |
| US9424568B2 (en) * | 2014-05-29 | 2016-08-23 | Apple Inc. | Financial-transaction notifications |
-
2017
- 2017-01-17 FR FR1750356A patent/FR3062008B1/fr active Active
-
2018
- 2018-01-09 EP EP18150876.3A patent/EP3349160B1/fr active Active
- 2018-01-09 ES ES18150876T patent/ES2952773T3/es active Active
- 2018-01-17 CA CA2992195A patent/CA2992195A1/fr active Pending
- 2018-01-17 US US15/873,341 patent/US20180204273A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| CA2992195A1 (fr) | 2018-07-17 |
| FR3062008A1 (fr) | 2018-07-20 |
| FR3062008B1 (fr) | 2019-05-31 |
| EP3349160A1 (fr) | 2018-07-18 |
| EP3349160B1 (fr) | 2023-05-31 |
| US20180204273A1 (en) | 2018-07-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2904552T3 (es) | Método de procesamiento de una transacción a partir de un terminal de comunicación | |
| US20200104837A9 (en) | Wireless beacon comunications through magnetic card readers | |
| ES2952773T3 (es) | Método de transmisión de datos, dispositivo y programa correspondiente | |
| ES2762227T3 (es) | Sistema y método de información de producto que usa una etiqueta y un dispositivo móvil | |
| KR102399440B1 (ko) | 컨텐츠 제공 시스템 및 전자 장치의 컨텐츠 제공 방법 | |
| KR102496877B1 (ko) | 전자 지갑 결제시 보안이 강화된 방법으로 와이파이에 자동 접속하는 전자 장치 및 방법 | |
| US11062297B2 (en) | Validation using key pairs and interprocess communications | |
| US10643204B2 (en) | Cryptography method and system for securing data via electronic transmission | |
| KR20160033409A (ko) | 전자 장치 및 전자 장치에서 데이터를 처리하는 방법 | |
| US20160364701A1 (en) | System and method for third party payment at point of sale terminals | |
| US20160086142A1 (en) | Information provision apparatus, information provision method, and storage medium | |
| US20160105760A1 (en) | Method and apparatus for information exchange, and delivery terminal | |
| TWI691902B (zh) | 應用程式中業務快速啟動方法及裝置和電子設備 | |
| TW201528183A (zh) | 用於資料處理的裝置、系統及方法 | |
| EP3298535B1 (en) | Electronic apparatus and controlling method thereof | |
| ES2952995T3 (es) | Método para procesar una transacción de pago, estación de pago y programa correspondiente | |
| JP4983182B2 (ja) | 来店促進キャンペーンシステム、携帯端末、来店証明書込装置及び来店促進キャンペーン方法 | |
| US20200266991A1 (en) | Cryptography method and system for securing data via electronic transmission | |
| ES2841905T3 (es) | Procedimiento de tratamiento de datos en consola multimedia de pago, dispositivos y programas de ordenador correspondientes | |
| ES2884032T3 (es) | Procedimiento de procesamiento de datos de transacción, terminal de comunicación, lector de tarjetas y programa correspondiente | |
| JP4858044B2 (ja) | 来店促進キャンペーンシステム、及び来店促進キャンペーン方法 | |
| ES2865380T3 (es) | Método de realización de una transacción, terminal y programa informático correspondiente | |
| JP6756433B2 (ja) | データ転送システム及びデータ転送方法 | |
| KR101547937B1 (ko) | 단말기, 이를 이용한 카드 정보 처리 방법 및 카드 리더 | |
| KR20170109396A (ko) | 결제 처리 방법 |