ES1307889U

ES1307889U - Dispositivo de tratamiento de datos para un terminal de venta

Info

Publication number: ES1307889U
Application number: ES202330233U
Authority: ES
Inventors: Harry Hagege
Original assignee: Fyre S A
Current assignee: Fyre S A
Priority date: 2022-03-29
Filing date: 2023-02-15
Publication date: 2024-05-24
Anticipated expiration: 2033-02-15
Also published as: LU501747B1; GB2618208A; DE202023101103U1; NL2034465A; ES1307889Y

Abstract

Dispositivo de procesamiento de datos (10) de un terminal de punto de venta, TPV (12), que incluye: como mínimo un puerto de entrada (28) para recibir datos de impresión de TPV (12) procedentes de un TPV (12); medios de procesamiento de datos configurados para construir, a partir de los datos de impresión del TPV (12), datos de impresión modificados, que incluyen información adicional, y dicha información adicional contiene a su vez un número que identifica el dispositivo de procesamiento de datos y un número de serie generado por el dispositivo de procesamiento de datos; como mínimo un puerto de salida (30) para transmitir los datos de impresión modificados a una impresora (14); y un módulo de comunicación (44) configurado para transmitir los datos de impresión modificados a un servidor remoto (1).

Description

DESCRIPCIÓN

Dispositivo de tratamiento de datos para un terminal de venta

La invención corresponde al campo de la gestión de transacciones por un terminal de venta y, en particular, a la integración de servicios en línea en un terminal de venta sin afectar a su integridad.

Estado de la técnica

La gestión de los tickets y recibos generados por los terminales de punto de venta (TPV - en inglés: Point of Sale, POS) se ha convertido en algo cada vez más difícil tanto para los clientes como para el minorista. Los tickets de caja contienen información importante, como las referencias de los artículos comprados, su precio y el importe total; también pueden incluir la fecha y la dirección de la transacción o incluso promociones. Sin embargo, el cliente sólo conserva su ticket durante muy poco tiempo y sólo "digiere" una mínima parte de todos los datos. Además, puede perder el ticket, en forma de papel impreso, cuando le hubiera gustado conservarlo.

El minorista/comerciante tiene problemas similares. Las promociones indicadas en los tickets se ignoran y la gestión y el análisis de los mismos son laboriosos. Además, los programas de fidelización de clientes no tienen mucho éxito: los clientes están saturados de tarjetas de fidelización y no desean revelar sus datos personales.

Estos problemas pueden resolverse integrando servicios en línea en el TPV, lo que permitiría al cliente pagar en línea, guardar sus tickets, y al comerciante tener una visión más precisa de sus cuentas. El gran número de TPV antiguos en circulación dificulta y encarece su modernización, ya que hay que modificar el software del TPV o añadir equipo informático costoso.

El objeto de la presente invención es ofrecer un dispositivo y un sistema que modernice un TPV evitando las desventajas arriba mencionadas.

Descripción general de la invención

Según la invención, un dispositivo de tratamiento de datos (DTD) de un terminal de punto de venta (TPV) incluye:

como mínimo un puerto de entrada para recibir datos de impresión de TPV procedentes de un TPV;

medios de tratamiento de datos configurados para construir, a partir de los datos de impresión de TPV, datos de impresión modificados, que incluyen información adicional, y dicha información adicional contiene un número que identifica el DTD y un número de serie generado por el DTD;

como mínimo un puerto de salida para transmitir los datos de impresión modificados a una impresora; y

un módulo de comunicación configurado para transmitir los datos de impresión modificados a un servidor remoto.

El dispositivo, según la invención, está configurado para enriquecer, o aumentar, un flujo de datos de impresión TPV para proporcionar funcionalidades adicionales. La función principal del DTD, según la invención, es permitir el pago desde el terminal móvil de un usuario (como un smartphone). Por lo tanto, el DTD construirá un flujo de datos modificados que incluirá datos adicionales para realizar una operación determinada a partir del ticket impreso, como por ejemplo realizar una operación de pago.

El DTD también envía los datos de impresión modificados a un servidor remoto, para almacenar y procesar los tickets digitales, y gestionar el pago en línea.

La relación («matching) entre el ticket impreso (ticket físico) y el digital en el servidor se realiza mediante el número DTD y el número de serie del ticket.

Por lo tanto, el presente DTD permite interceptar el flujo físico de impresión para inyectar primero un código QR en el ticket con el fin de acceder a una aplicación web de pago, y también comunicará al servidor remoto los datos de impresión modificados, para extraer el importe a pagar del ticket y vincular el ticket digital al ticket físico leído por el terminal del cliente.

Preferiblemente, la información adicional define una url.

Según las variantes, la información adicional incluye información relativa a un pago en línea, una encuesta, un concurso y/o una promoción.

Ventajosamente, la información adicional se añade a los datos de impresión en forma de una representación de imagen codificada con la información adicional, y la imagen codificada puede ser leída y descodificada por el terminal móvil de un usuario. La representación de la imagen codificada es, por ejemplo, del tipo de código QR.

Según otro aspecto, se propone un sistema de procesamiento de datos que incluye:

como mínimo un dispositivo de procesamiento de datos, tal como se describe en el presente texto, y

un servidor remoto configurado para almacenar datos de impresión modificados recibidos de al menos un dispositivo de procesamiento de datos y para permitir la realización de una operación mediante el terminal móvil de un usuario que tenga acceso a una impresión de los datos de impresión modificados.

De este modo, el DTD enriquecerá el ticket para aportarle información adicional que permita, mediante un terminal móvil, activar/realizar una operación determinada, típicamente un pago.

Según un modo de realización, el servidor remoto está configurado para determinar el importe de una transacción de un PDV en los datos de impresión modificados, y para iniciar una operación de pago, en el momento de una petición del terminal móvil de un usuario, tras la autenticación de los datos de impresión en base al número que identifica el dispositivo de procesamiento de datos y el número de serie.

Breve descripción de las figuras

Otras particularidades y características de la invención se desprenderán de la descripción detallada de al menos una realización ventajosa presentada a continuación, a modo de ilustración, con referencia a los dibujos adjuntos. Éstos muestran:

[Fig. 1]: un diagrama de principio de un modo de realización de la invención, en el que un terminal de venta está asociado al presente dispositivo de procesamiento de datos; [Fig. 2]: un organigrama de un modo de realización de un procedimiento de funcionamiento del presente dispositivo de procesamiento de datos;

[Fig. 3]: a) una vista de un ticket modificado por el dispositivo de procesamiento de datos de un terminal de venta y b) una vista que detalla la creación del ticket modificado;

[Fig. 4]: un diagrama del dispositivo de procesamiento de datos de la figura 1;

[Fig. 5]: un diagrama funcional que ilustra los módulos del dispositivo de procesamiento de datos de un terminal de venta según un modo de realización; y

[Fig. 6]: un diagrama de principio de otro modo de realización de la invención que incluye un terminal de venta asociado al presente dispositivo de procesamiento.

Descripción detallada de los modos de realización preferidos

A continuación se describirá, con referencia a las figuras 1 a 5, un modo de realización del presente dispositivo de procesamiento de datos 10 en su entorno de uso típico. El dispositivo de procesamiento de datos 10 está diseñado para asociarse a un terminal de venta 12 y su impresora 14 para generar tickets modificados 16 que con información adicional, en particular del tipo código QR que facilita el pago mediante un teléfono móvil de un cliente. Un ticket de este tipo también se denomina «aumentado».

Aquí el TPV 12 («Point of sale» en inglés) es un terminal convencional configurado para generar datos de impresión relativos a una/varias transacciones procesadas por el TPV 12.

El TPV 12 puede basarse en cualquier tecnología. Una ventaja del DTD 10 es la posibilidad de asociarlo a cualquier tipo de TDV 12, ya que no requiere interoperabilidad. De hecho, el DTD 10 no se comunica con el TDV 12, simplemente recibe de él un flujo de datos de impresión.

El dispositivo de procesamiento de datos 10, denominado DTD, es una unidad informática configurada para la ejecución de módulos de programas informáticos, en particular módulos de procesamiento de datos. Tal como se utiliza en este documento, el término "módulo" hace referencia a la lógica del programa informático y/o a los datos que permiten proporcionar la funcionalidad especificada. Un módulo puede implementarse en un material informático, un microprograma y/o software.

En la variante de la Fig.4, el DTD 10 incluye como mínimo un procesador 20, acoplado a un bus 22, al que también están acoplados una memoria 24, un dispositivo de almacenamiento 26, así como un puerto de entrada 28 y un puerto de salida 30. El procesador 20 puede ser un procesador polivalente general, como un INTEL x86, ARM, Atmel AVR o POW ERPC compatible-CPU. El dispositivo de almacenamiento 24 es, en un modo de realización, un dispositivo de memoria de semiconductores, pero también puede ser cualquier otro dispositivo capaz de almacenar datos, como un disco duro, un disco compacto (CD) o un DVD grabable, o un dispositivo de memoria de semiconductores. La memoria puede ser, por ejemplo, un microprograma, una memoria muerta o de solo lectura (ROM), una memoria de acceso aleatorio no volátil (NVRAM), y/o una memoria de acceso aleatorio. El dispositivo de almacenamiento y/o la memoria pueden contener instrucciones, módulos y datos utilizados por el procesador. Los tipos de sistemas informáticos utilizados por el DTD 10 pueden variar en función del modo de realización y de la potencia de procesamiento utilizada por la unidad. De este modo, por ejemplo, el sistema informático del DTD puede ser un sistema informático integrado basado en microcontrolador, un ordenador monoplaca o un ordenador personal estándar (PC). En particular, un ordenador monoplaca tipo ARM con 4 núcleos de 1,5 GHz, 8 GB de RAM y 64 GB de almacenamiento y que utilice una distribución Linux específica optimizada denominada Stellar OS.

El DTD 10 incluye como mínimo un puerto de entrada 28 para recibir datos de impresión de TPV procedentes del TPV 12. El DTD 10 (a través de su puerto de entrada 28) está conectado al TPV de forma alámbrica (por ej. puerto USB, puerto Ethernet, etc.) o inalámbrica (por ej. un puerto inalámbrico como Wifi, USB inalámbrico, Bluetooth, Ethernet inalámbrico, GPRS, EDGE, HSPA, LTE, WiMax) u otra tecnología de puerto de comunicación. Los datos de impresión del TPV están destinados a la impresora 14, pero son interceptados por el DTD 10.

El DTD 10 contiene medios de procesamiento de datos, en particular un módulo de análisis 40 configurado para leer los datos de impresión TPV en su formato bruto e identificar determinadas características, como caracteres o códigos. Estos caracteres pueden ser específicos del lenguaje de impresión o de la creación del código, y están destinados a identificar elementos de código/caracteres o secuencias/combinaciones, para determinar la posición de inserción de datos adicionales.

Ventajosamente, el módulo de análisis 40 identifica el final del ticket en el flujo de impresión representado por un elemento característico (o secuencia) en los datos de impresión, por ejemplo, el carácter V define el final del ticket en el lenguaje SPOS. En realidad, la intención es añadir datos adicionales después del final del cuerpo del ticket, para no modificar el cuerpo del ticket, para no modificar su integridad. La protección de la integridad del ticket durante el aumento es imprescindible, ya que cualquier modificación del ticket original sería susceptible de ser considerada fraudulenta.

Los medios de procesamiento de datos del DTD 10 incluyen además un módulo de enriquecimiento 42 configura para crear datos de impresión modificados a partir de los datos de impresión. En particular, el módulo de enriquecimiento inyecta en los datos de impresión información adicional. De este modo, el módulo de enriquecimiento 42 modifica o aumenta los datos de impresión originales con información adicional. Los datos de impresión modificados se enviarán a la impresora 14 y se imprimirán en lugar de los datos originales. El DTD 10 selecciona la información que se debe añadir según las instrucciones proporcionadas por el usuario. En una variante, las instrucciones del módulo de enriquecimiento 42 se basan en la información extraída de los datos de impresión, por ejemplo, si los datos de impresión contienen un determinado artículo, el módulo de enriquecimiento 42 añadirá determinada información adicional.

En la práctica, la información adicional puede incluir información relativa a un pago en línea, una encuesta, un concurso, una promoción o definir una url.

Para permitir la autenticación posterior de los datos de impresión correspondientes a un ticket emitido por el TPV, la información adicional incluye un número que identifica al DTD y un número de serie generado por el DTD. Estos dos números forman un binomio único. El número de serie es único, generado por un contador de tickets en el DTD, y no necesariamente se corresponde con el número de ticket que pueda generar el propio TPV.

En una variante, los medios de procesamiento de datos del DTD 10 incluyen un módulo de encriptación 54, configurado para encriptar el número de serie y/o el número que identifica al DTD, y es el número o los números encriptados los que forman parte de la información adicional. Por lo tanto, no es posible que un tercero adivine los binomios de autenticación asociados a los datos de impresión modificados.

Típicamente, la información adicional también incluye además una dirección de Internet (url), que permitirá acceder a una página de Internet para realizar una operación en línea, basada en una impresión de los datos de impresión modificados (es decir, el ticket impreso correspondiente a los datos de impresión modificados).

Preferiblemente, la información adicional se añade a los datos de impresión en forma de una representación de imagen codificada con la información adicional, en particular del tipo código QR, de manera que la imagen codificada puede ser leída y descodificada por el terminal móvil de un cliente.

Cuando se lee y descodifica el código QR, el terminal del cliente se dirige a una página de inicio (basada en la url) que muestra la información del ticket. En la página de inicio, se puede invitar al cliente a indicar o registrarse en programas de fidelización para beneficiarse de descuentos. Además, la página de inicio puede estar en Internet y visualizarse en un navegador o en una aplicación móvil instalada en el smartphone del cliente. El comerciante puede mostrar sus promociones, concursos o encuestas a través de la página de inicio o la aplicación móvil.

El DTD 10 incluye como mínimo un puerto de salida 30 para transmitir los datos de impresión modificados a la impresora 14. Según las variantes, el DTD 10 se conecta a la impresora de forma alámbrica o inalámbrica (mismas posibilidades de tecnologías que en el caso del puerto de entrada 28.

La impresora produce un ticket modificado 16, que puede ser leído y descodificado por el terminal móvil del cliente (normalmente un teléfono móvil/smartphone). Esto permitirá que el comerciante integre servicios en línea, como el pago en línea, aunque el TPV 12 no incluya dicha funcionalidad de forma nativa.

En este contexto, los números de serie del ticket y/o el número de identificación de DTD, integrados en el ticket, permitirán recuperar la información correspondiente en el servidor remoto y, por tanto, recuperar y validar la operación correspondiente. Una vez recuperada/identificada en línea la versión digital del ticket de caja en base a estos números, se podrá pasar a la fase de pago.

La Fig. 3 muestra un ejemplo de creación de ticket modificado 16. Los datos de impresión generados por el TPV 12 incluyen instrucciones correspondientes a la parte de ticket 13: se trata de la parte original o existente. La parte creada en el DTD 10, denominada parte inyectada o enriquecida, se indica con 11 y adopta aquí la forma de un código QR. La parte inyectada 11 se añade al final del ticket original 13, formando el ticket aumentado 16 (Fig.3 a) producida por la impresora 14. Tal como se ha indicado más arriba, los datos correspondientes al código QR, que codifica los números de serie de ticket y de DTD se inyectan, por ejemplo, en los datos de impresión originales al final de la parte del código correspondiente al ticket original y antes de la instrucción de corte.

T al como se indica en la Fig. 1, el DTD 10 incluye ventajosamente un módulo de comunicación 44, configurado para transmitir los datos de impresión modificados/aumentados en su formato bruto a un servidor remoto1 a través de una conexión a Internet. El servidor remoto 1 se conecta al DTD a través de cualquier puerto adecuado (por ejemplo, USB, Ethernet o un puerto inalámbrico como USB inalámbrico, Bluetooth, Ethernet inalámbrico).

En el servidor remoto 1, los datos de impresión modificados se convierten a un formato .txt, que puede ser leído y analizado por otros programas informáticos, y a un formato .html para mostrar el ticket aumentado. El binomio único vinculado al ticket y la url del código QR se utilizan en el servidor remoto 1 para vincular el ticket en formatos .txt y .html al código QR del ticket aumentado impreso. El formato .txt es analizado por un módulo «Parser» en el servidor remoto 1, que identifica los distintos datos del ticket, tales como los artículos comprados, su número, el total etc. El análisis sintáctico del ticket, así como la versión .html del mismo permiten dirigir el terminal móvil del cliente a una página de aterrizaje (landing page), en la que aparece el ticket y permite el pago en línea, cuando se lee y descodifica el código QR. La utilización del binomio único que vincula el ticket aumentado físico al ticket digital permite al DTD 10 una impresión continua, aunque el servidor remoto 1 esté desconectado, ya que la url que contiene el binomio único está codificada en el código QR, independientemente del servidor remoto 1. La url se vuelve funcional, cuando el servidor remoto 1 se vuelve a conectar y vincula el ticket digital a la url.

La Fig. 2 muestra un modo de realización de un procedimiento de funcionamiento de un sistema de venta que incluye el TPV 12, el DTD 10 y la impresora 14. El procedimiento incluye principalmente las siguientes etapas:

- tras una venta, el TPV 12 registra una transacción y genera un flujo de datos de impresión que incluye información sobre la transacción. El DTD 10 recibe estos datos de impresión del TPV 12, etapa 100;

- en la siguiente etapa 102, el DTD 10 procesa los datos de impresión. Analiza/lee el contenido/código/instrucciones de los datos de impresión, y genera datos de impresión modificados, que incluyen información adicional (con la url, y el binomio de números de ticket/DTD);

- en la etapa 106, los datos de impresión modificados se envían a la impresora 14 para imprimir un ticket

- los datos de impresión modificados también se envían - etapa 104 - al servidor remoto 1, que incluye una base de datos de transacciones/tickets 60.

Aunque en la Fig. 2 se ha representado en primero lugar la etapa 104 y luego la 106, pueden realizarse en orden inverso o en paralelo.

La información adicional se añade a los datos de impresión en forma de una representación de imagen codificada con la información adicional. Se puede elegir un código de barras bidimensional, en particular del tipo código QR, como imagen codificada, apta para ser leída y descifrada por el terminal móvil de un usuario.

Tal como se ha indicado más arriba, el TPV 12 está diseñado para gestionar transacciones (ventas), por ejemplo: enumerar los artículos comprados, calcular el subtotal, los impuestos y el total, añadir información sobre la transacción, como el número de transacción o el nombre del comercio, así como generar y transmitir los datos de impresión a la impresora. Típicamente, el TPV 12 incluye un componente que genera datos de impresión como un flujo de datos de impresión codificado mediante un lenguaje de control de impresión y transmitido por un puerto de comunicación. El flujo de datos de impresión puede utilizar cualquier lenguaje de control de impresión, como Epson ESC/POS, JavaPOS, OPOS, StarLine, PostScript, PCL u otros. El puerto de comunicación del punto de venta puede ser, por ejemplo, un puerto RS-232, un puerto USB, un puerto paralelo, un puerto Ethernet o un puerto inalámbrico como USB inalámbrico, Bluetooth, Ethernet inalámbrico, GPRS, EDGE, HSPA, LTE, WiMax u otra tecnología de puerto de comunicación. El sistema informático, por ejemplo, puede ser un ordenador personal que ejecute una aplicación de terminal de venta, como MICROS RES o un navegador web como MICROSOFT INTERNET EXPLORER, que permita que el usuario final gestione las transacciones del terminal de venta utilizando una aplicación de terminal de venta basada en la nube o en la web, como VIVONET HALO.

La Fig. 5 muestra un esquema funcional que ilustra los módulos del DTD 10. 5. Los módulos arriba descritos generalmente hacen referencia a una lógica incorporada al material y/o microprogramas, y/o a una colección de instrucciones de software, que eventualmente tengan puntos de entrada y salida, escritas en un lenguaje de programación como, por ejemplo, Java, Ruby, Ruby on Rails, Lua, C, C#, y/o C++. Pueden compilarse y vincularse en un programa ejecutable, instalarse en una biblioteca de enlaces dinámicos o escribirse en un lenguaje de programación interpretado como, por ejemplo, BASIC, Perl o Python. Se hace constar que estos módulos pueden ser llamados por otros y/o por ellos mismos, y/o pueden ser invocados en respuesta a acontecimientos detectados o interrupciones. En un modo de realización, estos módulos se almacenan en el dispositivo de almacenamiento 26 y se cargan en la memoria 24 para ser ejecutados por el procesador 20.

Tal como se ilustra en la Fig. 5, el DTD 10 incluye un módulo de análisis 40, que lee el flujo de datos de impresión interceptado en formato bruto, en la mayoría de los casos en formato ESC/POS, e identifica elementos/códigos/instrucciones característicos (por ejemplo, línea de corte o fin de ticket) en los datos de impresión. Al identificar el final del ticket, se puede aumentar el ticket sin alterar el ticket original. Preferiblemente, al analizar los datos de impresión, el módulo de análisis 40, también identifica la existencia de caracteres/instrucciones/códigos susceptibles de indicar que se trata de datos de impresión que no corresponden a una acción, operación o transacción que deba dar lugar a una acción por parte de un cliente. Por ejemplo, típicamente los TPV suelen generar los denominados tickets «Z», que son resúmenes de transacciones, y están destinados al comerciante, por lo que no requieren ningún aumento.

El DTD 10 incluye un módulo generador de código gráfico 46, configurado para generar un código gráfico. El código gráfico puede ser un código de barras 1D, un código de barras 2D u otro tipo de código de barras/imagen adaptado a la incorporación de información que pueda escanearse e interpretarse ópticamente. Cuando el módulo generador de código gráfico 46 está configurado para generar un código de barras 2D, el código de barras 2D se puede generar utilizando cualquier simbología de código 2D, como el código QR, Datamatrix, el código de barras de color de alta capacidad, el ShotCode, el SPARQCode o cualquier otra simbología de código 2D.

El módulo de enriquecimiento 42 está configurado para añadir la información complementaria/adicional a los datos de impresión brutos cuando el módulo de análisis 40 lo solicite. En un modo de realización, los datos complementarios incluyen uno o varios de los siguientes elementos: (1) una representación codificada de una llamada a la acción, en la que se solicita al cliente que recibe el recibo que utilice su teléfono móvil para escanear un código de barras 2D impreso en el recibo para inscribirse en el programa de fidelización del comerciante o para ganar premios o regalos de fidelización si ya está inscrito, (2) una representación codificada de un código de barras 2D, y (3) una representación codificada de instrucciones en las que se solicita al cliente que recibe el ticket que descargue un lector de códigos de barras 2D para su teléfono móvil, si aún no posee un lector de códigos de barras 2D. De este modo, el módulo de enriquecimiento 42 produce información enriquecida, que típicamente suele corresponder a la información original del ticket, a la que se ha añadido información adicional (incluida una url, el número de serie del ticket y el número del DTD). El DTD 10 incluye un módulo de codificación de lenguaje de impresión 48, configurado para codificar la información adicional generada por el módulo 42 en un formato de lenguaje de impresión particular definido, para su inserción en los datos de impresión interceptados. La información a codificar puede consistir en datos de texto o datos de imagen. Por ejemplo, el módulo de codificación de lenguaje de impresión 48 está configurado para codificar la información enriquecida en el formato de lenguaje de impresora ESC/POS de Epson. Además, el módulo de codificación 48 puede configurarse para convertir datos de impresión de un lenguaje de impresión a otro lenguaje de impresión, lo que facilita la interoperabilidad.

Debido a la diferencia de velocidad entre el procesador y el periférico, los datos enviados a un periférico suelen almacenarse en memorias tampón o buffer 50, a la espera de ser enviados efectivamente al periférico, para ahorrar al DTD 10 la espera debida a la diferencia de velocidades. Del mismo modo, los datos recibidos del exterior con frecuencia se recogen en buffers 50, a la espera de ser procesados por el DTD 10 por razones de eficacia, y también para evitar su pérdida.

El módulo de comunicación 44 está configurado para transferir los datos de impresión entrantes a la memoria tampón 50, y los datos de impresión modificados al servidor remoto 1 y a la impresora 14. De este modo, el módulo de comunicación 44 gestiona la comunicación, es decir, la transferencia de datos/información, dentro del DTD 10 y hacia el exterior. En una variante, se pueden conectar varias impresoras al DTD 10 y el módulo de comunicación 44 gestiona el envío de los datos de impresión a las distintas impresoras.

El módulo de configuración de almacenamiento 52 gestiona el almacenamiento de diversos datos utilizados por el DTD 10 y los demás módulos, como información utilizada por el módulo generador de código gráfico 46.

Para un experto en la materia será evidente que otros modos de realización pueden incluir módulos diferentes y/o distintos a los aquí descritos, y que las funcionalidades pueden estar distribuidas entre los módulos de manera diferente.

En una variante, se puede instalar un módulo NFC (en inglés «near-field communication») en el DTD 10. Este módulo NFC permitiría la utilización de emisor-receptor NFC para transmitir datos a un dispositivo (teléfono móvil) del cliente, sin imprimir el ticket físico. El cliente recibe los datos del recibo acercando su dispositivo móvil con NFC al emisor-receptor NFC. Típicamente, estos datos suelen incluir una dirección internet (url) que llega en una página de inicio (landind page) permitiendo la descarga del ticket y el pago.

En otra variante, el DTD 10 incluye una unidad de visualización (integrada en la arcasa del DTD o separada) para mostrar el código QR. Se evita la impresión del recibo físico, ya que el cliente puede leer y descodificar el código QR con su dispositivo móvil desde la pantalla.

Otra ventaja de la invención es que permite recopilar información sobre las transacciones en una base de datos 60. Tal como se ha indicado más arriba, los datos de impresión modificados en formato bruto, típicamente ESC/POS, se convierten a un formato .txt y un formato .html en el servidor 1. La versión .html se utiliza para mostrar el ticket digital en la página de inicio, hacia la que se dirige el dispositivo del cliente cuando se lee y descodifica el código QR. La versión .txt puede ser utilizada por otros softwares, especialmente softwares de análisis sintáctico.

Los tickets producidos por diferentes TDV 12 pueden tener diferentes estructuras, por ejemplo el número de artículo puede colocarse antes o después del artículo justo antes del precio, y otras variaciones de la estructura también son posibles. La utilización del denominado «Parser» permite el análisis sintáctico del ticket, y de esta manera la identificación de las diferentes informaciones del ticket, como la naturaleza de los artículos comprados, su referencia, el número de artículos, el total etc. Éstas se utilizan en la creación de la landing page de la url en el código QR. Además, el módulo «Parser» en el servidor remoto 1 permite la conversión del archivo .txt, en el que el ticket puede estar estructurado de diferentes maneras, a un archivo .xml o preferiblemente JSON, que tendrá una estructura única independiente de la estructura inicial. El Parser intentará «entender» (o interpretar) el ticket basándose en las posiciones de texto, pero el software se adapta cuando existen variaciones. De este modo el Parser puede reconocer un conjunto de elementos de datos, entre ellos (sin que esta enumeración tenga un carácter limitado) la fecha y la hora impresas como parte del ticket, el terminal de venta desde el que se imprimió el ticket, la entidad para la que se imprimió el ticket, la identidad del personal responsable de la transacción, el número de mesa o el número de invitado para el que se imprimió el ticket, el número de serie del ticket, el identificador de la transacción para la que se imprimió el ticket, las descripciones de los artículos, las cantidades de los artículos, los gastos de los artículos, el subtotal, las líneas de impuestos (IVA u otros) y el importe total. Los elementos reconocidos por el Parser se reestructuran y se crea el archivo .xml / JSON correspondiente. Son posibles otros elementos de datos de transacción en función del tipo de entorno minorista/servicio en el que se despliegue el TPV 12. La versión .xml o JSON puede reutilizarse para construir la base de datos 60.

Los distintos elementos de información se asignan a los campos correspondientes. Por ejemplo, el nombre de la tienda se puede asignar a un campo de nombre de tienda, el nombre de artículo comprado puede asignarse a un campo de artículo comprado, el precio de artículo puede asignarse a un campo de precio de artículo, el impuesto puede asignarse a un campo de impuesto, el total puede asignarse a un campo de total, etc. De este modo, la información de los tickets puede recibirse en el servidor 1, analizarse y almacenarse, sin que el comerciante, el cliente u otra entidad escanee ópticamente un ticket físico.

Por otro lado, un especialista en datos puede utilizar los archivos .xml o JSON para construir la base de datos asignando diferentes etiquetas únicas a artículos, de manera que las etiquetas se cuenten en todos los archivos .xml o JSON de los tickets en el servidor 1. Como existen muchas formas de escribir estas etiquetas, se puede entrenar una red neuronal para que detecte nuevas formas de etiquetas y las una con las etiquetas del sistema para el mismo artículo. En una variante, el Parser se instala como módulo Parser en el DTD 10.

Posteriormente la información así recogida se puede presentar a un usuario (por ejemplo, el cliente, el comerciante y/u otra parte autorizada) a través de una interfaz de usuario proporcionada par un dispositivo informático. Se pueden mostrar diferentes tipos de datos á diferentes tipos de usuarios. Por ejemplo, un usuario puede acceder a determinados o todos los datos y visualizarlos en forma de tabla y/o gráfico a través de un sitio Web en Internet, mediante un navegador alojado en un dispositivo informático del usuario o a través de una aplicación (por ejemplo, una aplicación para teléfono) cargada en un dispositivo informático como un teléfono. De forma opcional, el sitio web permite que el usuario añada metadatos relativos a los datos presentados. Por ejemplo, el usuario eventualmente puede categorizar y anotar los datos del recibo, a nivel de recibo y/o de línea de recibo. Estos metadatos generados por el usuario también se almacenan en la base de datos 60 en combinación con los datos del recibo y/o el usuario para poder ser recuperados o consultados posteriormente.

En una variante, el sitio web o la aplicación están configurados para permitir que el usuario consulte información estadística sobre todas las partes o partes seleccionadas de la información recopilada a partir de los tickets para un cliente, un comerciante y/o una tienda particular. Por ejemplo, de forma opcional, se proporcionan herramientas automatizadas de economía personal a través de esta información, que pueden incluir gráficos (curvas, histogramas, etc.). Por ejemplo, los gráficos pueden proporcionar a un usuario, como un consumidor, información sobre las compras desglosada en categorías como automóvil, restauración, ultramarinos, ocio, gastos de vivienda, etc. De forma opcional, el sistema también permite que los comerciantes muestren, consulten y generen informes que resumen la información de compra tienda por tienda, para todas las tiendas, etc. El consumidor puede recibir información agregada sobre sus hábitos de gasto, eventualmente durante un período seleccionado. Del mismo modo, un comerciante puede ver quiénes son sus mejores clientes, cuánto gastan durante un período determinado y en qué tipo de artículos gastan su dinero.

La Fig.6 ilustra un modo de realización en el que el DTD 10 está configurado para recibir datos relativos a transacciones/compras en línea. La configuración básica es la de la Fig. 1, y el entorno incluye además una plataforma de pedido/compra en línea 62 operada por el servidor remoto 1. Los pedidos en línea 62 se realizan a través un sitio web o una aplicación móvil específica.

Además, cuando el cliente realiza un pago en línea y desea obtener un recibo, el servidor remoto 1 envía los datos de impresión de este recibo al DTD 10, que lo envía a la impresora. En su caso, el DTD 10 convierte los datos de impresión del formato e-pos al formato ESC/POS antes de enviarlos a la impresora 14. En una variante, en la que el DTD 10 está conectado con varias impresoras, es posible configurar el DTD 10 para que envíe los pedidos en línea a una impresora específica y los pedidos del TPV a otra impresora. Esto permite, por ejemplo, que los pedidos de un restaurante se envíen a una impresora de la cocina en lugar de la impresora principal.

Los datos de impresión de los pedidos en línea no necesariamente se deben modificar, ya que el pago de estos pedidos se realiza inmediatamente a través del sitio web o la aplicación móvil específica. Los datos de impresión se procesan de forma similar a los demás datos en el servidor 1 y se envían a través del DTD 10 a la impresora 14.

Claims

REIVINDICACIONES

1. Dispositivo de procesamiento de datos (10) de un terminal de punto de venta, TPV (12), que incluye:

como mínimo un puerto de entrada (28) para recibir datos de impresión de TPV (12) procedentes de un TPV (12);

medios de procesamiento de datos configurados para construir, a partir de los datos de impresión del TPV (12), datos de impresión modificados, que incluyen información adicional, y dicha información adicional contiene a su vez un número que identifica el dispositivo de procesamiento de datos y un número de serie generado por el dispositivo de procesamiento de datos;

como mínimo un puerto de salida (30) para transmitir los datos de impresión modificados a una impresora (14); y

un módulo de comunicación (44) configurado para transmitir los datos de impresión modificados a un servidor remoto (1).

2. Dispositivo según cualquiera de las reivindicaciones arriba mencionadas, en el que la información adicional define una url.

3. Dispositivo según la reivindicación 1 ó 2, en el que la información adicional incluye información relativa a un pago en línea, una encuesta, un concurso y/o una promoción.

4. Dispositivo según la reivindicación 1, 2 ó 3, en el que la información adicional añadida a los datos de impresión está en forma de una representación de imagen codificada (11) con la información adicional, apta para ser leída y descodificada por el dispositivo móvil de un usuario.

5. Dispositivo según la reivindicación 4, en el que la representación de imagen codificada es del tipo código QR.

6. Sistema de procesamiento de datos, que comprende:

al menos un dispositivo de procesamiento de datos (10) según cualquiera de las reivindicaciones arriba mencionadas;

un servidor remoto (1) configurado para almacenar datos de impresión modificados recibidos del al menos un dispositivo de procesamiento de datos; y

un dispositivo móvil de un usuario con acceso a una impresión de los datos de impresión modificados.

7. Sistema según la reivindicación 6, en el que la información procedente del servidor remoto comprende (a) el importe de una transacción de PDV en los datos de impresión modificados, y (b) una transacción de pago, incluyendo la autenticación de los datos de impresión en base al número que identifica el dispositivo de procesamiento de datos y el número de serie.