NL2034465A

NL2034465A - Data processing device for sales terminal

Info

Publication number: NL2034465A
Application number: NL2034465A
Authority: NL
Inventors: Hagege Harry
Original assignee: Fyre S A
Priority date: 2022-03-29
Filing date: 2023-03-29
Publication date: 2023-10-12
Also published as: ES1307889U; GB2618208A; DE202023101103U1; LU501747B1

Abstract

A data processing device (10) of a sales terminal, TDV (12), comprising: at least one input port (28) for receiving TDV print data from a TDV (12); data processing means configured to construct, from the TDV print data (12), modiﬁed print data, which includes additional information, said additional information including a number identifying the data processing device and a serial number generated by the data processing device; at least one output port (30) for transmitting the modified print data to a printer (14); and a communication module (44) conﬁgured to transmit the modiﬁed print data to a remote server (1). Also presented are a data processing system and a method for operating a sales system. (Fig. 1)

Description

P134608NL00

Title: Data processing device for sales terminal

The invention relates to the field of transaction management by a sales terminal, and in particular to the integration of online services to a sales terminal without impacting its integrity.

State of the art

The management of receipts and tickets produced by Point of Sale (POS) terminals has become increasingly difficult for both the customer and the retailer. Receipts contain important information such as item numbers, prices and total amounts; they may also include the date and address of the transaction or even promotions. However, the customer only keeps the receipt for a short time and only digests a minimum of all the information.

In addition, the customer may lose the ticket, in the form of printed paper, when he or she would have liked to keep it.

The retailer/merchant has similar problems. Promotions on tickets are ignored and ticket management and analysis is laborious. In addition, customer loyalty programs are not very successful: customers are tired of loyalty cards and do not want to reveal their personal information.

These problems can be solved by integrating online services into the VDT that would allow the customer to pay online, save their tickets, and the merchant to have a better view of their accounts. The large number of older VDTs in circulation makes upgrading them difficult and costly, as it requires modifying the VDT software or adding expensive hardware.

The object of the present invention is to provide a device and system that modernizes a TDV avoiding the above named disadvantages.

General description of the invention

In accordance with the invention, a data processing device (DTD) of a sales terminal (TDV) comprises: at least one input port for receiving TDV print data from a TDV ;

data processing means configured to construct, from the TDV print data, modified print data, which includes additional information, said additional information including a number identifying the DTD and a serial number generated by the DTD; at least one output port for transmitting the modified print data to a printer; and a communication module configured to transmit the modified print data to a remote server.

The device according to the invention is configured to enrich, or augment, a TDV print data stream to provide additional functionality. The primary function of the DTD according to the invention is to enable payment from a user's mobile terminal (such as a smartphone). The DTD will therefore construct a modified data stream that includes additional data in order to perform a given operation from the printed ticket, in particular perform a payment operation.

The DTD also sends the modified print data to a remote server to store and process the digital tickets and to manage the online payment.

The relationship ("matching") between the printed ticket (physical ticket) and the digital ticket on the server is done by means of the DTD number and the ticket serial number.

Thus, the present DTD allows to intercept the physical printing flow to first inject a QR code on the ticket in order to access to a payment web application, and will also send back to the remote server the modified printing data, in order to extract the amount to be paid from the ticket and to link the digital ticket to the physical one read by the customer terminal.

Preferably, the additional information defines a url.

According to variants, the additional information includes information related to an online payment, a survey, a contest and/or a promotion.

Advantageously, the additional information is added to the print data in the form of an image representation encoded with the additional information, the encoded image being capable of being read and decoded by a mobile terminal of a user. The encoded image representation is, for example, a QR code.

According to another aspect, a data processing system is proposed, comprising: at least one data processing device as disclosed herein, and a remote server configured to store modified print data received from the at least one data processing device and to enable an operation to be performed by a user's mobile terminal having access to print the modified print data.

Thus, the DTD will enrich the ticket with additional information that will allow, with the help of a mobile terminal, to trigger/perform a given operation, typically a payment.

According to an embodiment, the remote server 1s configured to determine the amount of a POS transaction in the modified print data, and to initiate a payment transaction, upon request from a user's mobile terminal, after authentication of the print data based on the number identifying the data processing device and the serial number.

According to another aspect, the invention relates to a method of operating a vending system according to claim 8. Embodiments are specified in claims 9 to 12.

Brief description of the figures

Other features and characteristics of the invention will become apparent from the detailed description of at least one advantageous embodiment presented below, by way of illustration, with reference to the appended drawings. These show:

[Fig. 1]: A block diagram of an embodiment of the invention, wherein a sales terminal is associated with the present data processing device; [Fig. 2]: A flow chart of an embodiment of a method of operation of the present data processing device; [Fig. 3]: a) a view of a ticket modified by the data processing device of a sales terminal and b) a view detailing the construction of the modified ticket; [Fig. 4]: a diagram of the data processing device of Figure 1; [Fig. 5]: a functional diagram illustrating the modules of the data processing device of a sales terminal according to an embodiment; and [Fig. 6]: a block diagram of another embodiment of the invention including a sales terminal associated with the present processing device.

Detailed description of preferred embodiments

An embodiment of the present data processing device 10 in its typical environment of use will now be described with reference to Figures 1 to 5. The data processing device 10 is designed to be associated with a sales terminal 12 and its printer 14 in order to generate modified tickets 16 comprising additional information, in particular of the type of a QR code facilitating payment by a customer's cell phone. Such a ticket is also called "increased".

The TDV 12 ("Point of Sale") is here a conventional terminal configured to generate print data related to a transaction(s) processed by the TDV 12. The TDV 12 can be based on any technology. An interest of the

DTD 10 is its ability to be associated with any type of TDV 12, as no interoperability is required. Indeed, the DTD 10 does not communicate with the TDV 12, it simply receives a print data stream from it.

The data processing device 10, denoted DTD, is a computer unit configured to execute computer program modules, in particular data processing modules. As used herein, the term "module" refers to the computer program logic and/or data for providing the specified functionality.

A module may be implemented in hardware, firmware and/or software.

In the embodiment shown in Fig. 4, the DTD 10 includes at least one processor 20 coupled to a bus 22, to which a memory 24, a storage device 5 26, and an input port 28 and an output port 30 are also coupled. The processor 20 may be a general purpose processor such as an INTEL x86,

ARM, Atmel AVR, or POW ERPC compatible-CPU processor. The storage device 24 is, in one embodiment, a solid state memory device but may also be any other device capable of storing data, such as a hard disk drive, compact disc (CD) or writable DVD, or a solid state memory device. The memory may be, for example, firmware, read-only memory (ROM), non- volatile random access memory (NVRAM), and/or RAM. The storage device and/or memory may contain instructions, modules, and data used by the processor. The types of computer systems used by the DTD 10 may vary depending on the embodiment and the processing power used by the unit.

Thus, for example, the DTD's computer system may be a microcontroller- based integrated computer system, a single board computer, or a standard personal computer (PC). In particular, a single board computer of the ARM type with 4 1.5 GHz cores, 8 GB of RAM and 64 GB of storage and using a specific optimized Linux distribution named Stellar OS.

The DTD 10 includes at least one input port 28 for receiving TDV print data from the TDV 12. The DTD 10 (via its input port 28) is connected with the TDV in a wired manner (e.g., USB port, Ethernet port etc.) or wirelessly (e.g., a wireless port such as Wifi, wireless USB, Bluetooth, wireless Ethernet, GPRS, EDGE, HSPA, LTE, WiMax) or other communication port technology. The TDV print data is destined for the printer 14, but is intercepted by the DTD 10.

The DTD 10 includes data processing means, in particular, an analysis module 40 configured to read the TDV print data in its raw format and identify certain characteristics such as characters or codes. These characters can be specific to the printing language or code creation, and aim to identify code elements/characters, or sequences/combinations, to determine the insertion position of additional data.

Advantageously, the analysis module 40 identifies the end of the ticket in the print flow represented by a characteristic element (or sequence) in the print data, e.g. the character V defines the end of the ticket in the

SPOS language. One actually wants to add additional data after the end of the ticket body, so as not to change its integrity. It 1s imperative to protect the integrity of the ticket when adding it, as any modification of the original ticket could be considered fraudulent.

The data processing means of the DTD 10 further includes an enrichment module 42 configured to construct modified print data from the print data. In particular, the enrichment module injects additional information into the print data. Thus, the original print data is modified or augmented by the enrichment module 42 with additional information. The modified print data will be sent to the printer 14 and printed instead of the original data. The DTD 10 selects the information to be added according to instructions provided by the user. In one embodiment, the instructions of the enrichment module 42 are based on the information extracted from the print data, for example if the print data contains a certain item the enrichment module 42 will add some additional information.

In practice, the additional information may include information related to an online payment, a survey, a contest, a promotion or define a url.

In order to enable subsequent authentication of the print data corresponding to a ticket issued by the TDV, the additional information includes a number identifying the DTD and a serial number generated by the DTD. These two numbers form a unique pair. The serial number is unique, generated by a ticket counter of the DTD, and does not necessarily correspond to the ticket number that may be generated by the TDV itself.

In one embodiment, the data processing means of the DTD 10 includes an encryption module 54 configured to encrypt the serial number and/or the number identifying the DTD, and it is the encrypted number(s) that form part of the additional information. It is therefore not possible for a third party to guess the authentication pairs associated with the modified print data.

Typically, the additional information also includes an internet address (url), which will allow access to an internet page for carrying out an online operation based on a printout of the modified print data (i.e. the printed ticket corresponding to the modified print data).

Preferably, the additional information is added to the print data in the form of an image representation encoded with the additional information, in particular of the QR code type, the encoded image being adapted to be read and decoded by a mobile terminal of a customer.

When the QR code is read and decoded, the customer's terminal is directed to a home page (based on the url) displaying the ticket information.

On the homepage, the customer can be invited to indicate or register for loyalty programs to benefit from discounts. In addition, the homepage can be on the internet and displayed in a browser or displayed in a mobile application installed on the customer's smartphone. The merchant can display 1ts promotions, contests or surveys through the homepage or the mobile application.

The DTD 10 includes at least one output port 30 for transmitting the modified print data to the printer 14. According to embodiments, the

DTD 10 is connected to the printer in a wired or wireless manner (same technology options as for the input port28.

The printer produces a modified ticket 16 that can be read and decoded by a customer's mobile terminal (typically a mobile phone/smartphone). This will allow the merchant to integrate online services, such as online payment, even though the TDV 12 does not natively incorporate such functionality.

In this context, the serial numbers of the ticket and/or the DTD identification number, integrated in the ticket, will allow to retrieve the corresponding information on the remote server, and therefore to retrieve the corresponding transaction and to validate it. Once the digital version of the receipt has been found/identified online on the basis of these numbers, we can proceed to the payment phase.

An example of a modified ticket construction 16 is shown in Fig. 3.

The print data generated by the TDV 12 includes instructions corresponding to the ticket part 13: this is the original or existing part. The part created in the DTD 10, the so-called injected or enriched part, is indicated 11 and here takes the form of a QR code. The injected part 11 is added at the end of the original ticket 13, forming the augmented ticket 16 (Fig.3 a) produced by the printer 14. As mentioned before, the data corresponding to the QR code encoding the ticket serial and DTD numbers are for example injected into the original print data at the end of the code part corresponding to the original ticket and before the cutting instruction.

As shown in Fig. 1, the DTD 10 advantageously includes a communication module 44 configured to transmit the modified/augmented print data in its raw format to a remote server 1 over an Internet connection. The remote server 1 is connected to the DTD through any suitable port, (e.g., USB, Ethernet or a wireless port such as wireless USB,

Bluetooth, wireless Ethernet).

In the remote server 1, the modified print data is converted to a .txt format, which can be read and analyzed by other computer programs, and an .html format to display the augmented ticket. The unique pair linked to the ticket and the url in the QR code are used in the remote server 1 to link the ticket in .txt and html formats to the QR code of the printed augmented ticket. The .txt format is parsed by a "Parser" module in the remote server 1 which identifies the different information in the ticket, such as the items purchased, their number, the total ete. The syntactic analysis of the ticket as well as the html version of the ticket allows the customer's mobile terminal to be directed to a landing page displaying the ticket and allowing online payment, when the QR code is read and decoded. The use of the unique pair linking the physical augmented ticket to the digital ticket allows the DTD 10 to print continuously even if the remote server 1 is disconnected, since the url comprising the unique pair is encoded in the QR code independently of the remote server 1. The url becomes functional when the remote server 1 reconnects and links the digital ticket to the url.

An embodiment of a method of operating a vending system comprising the TDV 12, the DTD 10 and the printer 14 is illustrated in Fig. 2. The method primarily comprises the following steps: - following a sale, the TDV 12 records a transaction and generates a print data stream including transaction information. The DTD 10 receives this print data from the TDV 12, step 100 ; - 1n the next step 102, the DTD 10 processes the print data. It parses/reads the content /code/instructions of the print data, and generates modified print data, which includes additional information (along with the url, and the ticket number / DTD pair) ; - in step 106, the modified print data is sent to the printer 14 for printing a ticket - the modified print data is also sent - step 104 - to the remote server 1, which includes a transaction/ticket database 60.

Although in Fig. 2 step 104 and then step 106 are shown first, they can be performed in reverse order or in parallel.

The additional information is added to the print data in the form of an image representation encoded with the additional information. A two-

dimensional barcode, in particular of the QR code type, can be chosen as the encoded image that can be read and deciphered by a user's mobile terminal.

As noted above, the TDV 12 is designed to handle transactions (sales), such as: listing purchased items, calculating subtotal, taxes, and total, adding transaction information, such as transaction number or business name, and generating and transmitting print data to the printer.

The TDV 12 typically includes a component that generates print data as a print data stream encoded using a print control language and transmitted through a communication port. The print data stream can use any print control language, such as Epson ESC/POS, JavaPOS, OPOS, StarLine,

PostScript, PCL, or others. The POS communication port may be, for example, an RS-232 port, a USB port, a parallel port, an Ethernet port, or a wireless port such as wireless USB, Bluetooth, wireless Ethernet, GPRS,

EDGE, HSPA, LTE, WiMax, or other communication port technology. The computer system, for example, may be a personal computer running a POS application such as MICROS RES or a web browser such as MICROSOFT

INTERNET EXPLORER that allows the end user to manage POS transactions using a cloud-based or web-based POS application such as

VIVONET HALO.

A block diagram illustrating the modules of DTD 10 is shown in

Fig. 5. The modules described below generally refer to logic embedded in hardware and/or firmware, and/or a collection of software instructions, possibly having entry and exit points, written in a programming language such as, for example, Java, Ruby, Ruby on Rails, Lua, C, C#, and/or C++.

They can be compiled and linked into an executable program, installed in a dynamic link library, or can be written in an interpreted programming language such as, for example, BASIC, Perl or Python. It should be noted that these modules may be called by others and/or by themselves, and/or may be invoked in response to detected events or interrupts. In one embodiment, these modules are stored in storage device 26 and loaded into memory 24 for execution by processor 20.

As illustrated in Fig. 5, the DTD 10 includes an analysis module 40 that reads the intercepted print data stream in raw format, most often in

ESC/POS format, and identifies characteristic elements/codes/instructions (e.g., cut line or end of ticket) in the print data. By identifying the end of the ticket, it is possible to increase the ticket without altering the original ticket. Preferably, in analyzing the print data, the analysis module 40 also identifies the existence of characters/instructions/codes that may indicate that it is print data that does not correspond to a customer action, operation, or transaction that should be acted upon. For example, TDVs typically generate so-called "Z" tickets, which are transaction summaries and are intended for the merchant, so they do not require augmentation.

The DTV 10 includes a graphic code generator module 46 configured to generate a graphic code. The graphic code may be a 1D barcode, a 2D barcode, or another type of barcode/image suitable for incorporating information that can be scanned and optically interpreted.

When the graphic code generator module 46 is configured to generate a 2D barcode, the 2D barcode may be generated using any 2D code symbology such as QR code, Datamatrix, high capacity color barcode, ShotCode,

SPARQCode, or any other 2D code symbology.

The enrichment module 42 is configured to add the additional/additional information to the raw print data when called to do so by the analysis module 40. In one embodiment, the additional data includes one or more of the following: (1) an encoded representation of a call to action requesting a customer receiving the receipt to use their cell phone to scan a 2D barcode printed on the receipt to enroll in the merchant's loyalty program or to earn loyalty rewards or gifts if already enrolled, (2) a coded representation of a 2D barcode, and (3) a coded representation of instructions for the customer receiving the receipt to download a 2D barcode scanner for his or her cell phone if he or she does not already own a 2D barcode scanner. The enrichment module 42 thus produces enriched information, typically corresponding to the original ticket information, to which additional information (including, but not limited to, a url, the ticket serial number, and the DTD number) has been added.

The DTD 10 includes a print language encoding module 48 configured to encode the additional information generated by the module 42 into a particular defined printer language format for insertion into the intercepted print data. The information to be encoded may be text data or image data. For example, the print language encoding module 48 is configured to encode the enhanced information in the Epson ESC/POS printer language format. In addition, the encoding module 48 may be configured to convert print data from one printer language to another printer language, thereby facilitating interoperability.

Because of the difference in speed between the processor and the peripheral, data sent to a peripheral is most often stored in buffers 50 while waiting to be sent to the peripheral, to spare the DTD 10 the wait due to the difference in data rates. Similarly, data received from the outside is often collected in buffers 50, waiting to be processed by the DTD 10 for reasons of efficiency, and also to avoid its loss. The communication module 44 is configured to transfer incoming print data to the buffer 50, and modified print data to the remote server 1 and to the printer 14. The communication module 44 thus manages the communication, resp. transfer of data/information, within the DTD 10 and to the outside. In one embodiment, several printers can be connected to the DTD 10 and the communication module 44 manages the sending of print data to the different printers.

The storage configuration module 52 manages the storage of various data used by the DTD 10 and the other modules, such as information used by the graphics code generator module 46.

It will be apparent to the skilled person that other embodiments may have different and/or different modules than those described here, and that the functionality may be distributed among the modules in a different manner.

In a variant, an NFC (near-field communication) module can be installed in the DTD 10. This NFC module would allow the use of NFC transceivers to transmit data to a customer's cell phone, without printing the physical ticket. The customer receives the receipt data by approaching their NFC-enabled mobile device to the NFC transceiver. This data typically includes an internet address (url) that leads to a landing page for downloading the ticket and paying. In another embodiment, the DTD 10 includes a display unit (integrated into the DTD housing or separate) for displaying the QR code. The printing of the physical receipt is avoided, since the customer can read and decode the QR code with his mobile terminal from the display.

Another interest of the invention is to allow the collection of transaction information in a database 60. As previously mentioned, the modified print data in raw format, typically ESC/POS, is converted to a .txt format and an .html format in the server 1. The .html version is used to display the digital ticket on the home page, to which the customer's terminal 1s directed when the QR code is read and decrypted. The .txt version can be used by other computer software, especially parsing software.

The tickets produced by different TDV 12 can have different structures, for example the number of articles can be placed before the article or after the article just before the price and other variations of the structure are possible. The use of the software called "Parser" allows the syntactic analysis of the ticket, allowing to identify the different information of the ticket, such as the nature of the purchased articles, their reference, the number of articles, the total etc., these are used in the creation of the landing page of the url in the QR code. In addition, the "Parser" module in remote server 1 allows the conversion of the .txt file, in which the ticket can be structured in different ways, to an .xml or preferably JSON file, which will have a unique structure independent of the initial structure. The Parser will try to "understand" (or interpret) the ticket based on the text positions, but the software adapts when there are variations. In this way the Parser can recognize a set of data elements including, but not limited to, the date and time printed as part of the ticket, the sales terminal from which the ticket was printed, the entity for which the ticket was printed, the identity of the staff member responsible for the transaction the table number or guest number for which the ticket is printed, the serial number of the ticket, the transaction ID of the transaction for which the ticket is printed, the item descriptions, the item quantities, the item charges, the subtotal, the tax lines (VAT or other) and the total amount. The elements recognized by the

Parser are restructured and a corresponding .xml / JSON file is created.

Other transaction data elements are possible depending on the type of retail/service environment in which TDV 12 is deployed. The .xml or JSON version can be reused to build the 60 database.

Different pieces of information are mapped to corresponding fields.

For example, the store name can be mapped to a store name field, the name of a purchased item can be mapped to a purchased item field, the price of an item can be mapped to an item price field, a tax can be mapped to a tax field, a total can be mapped to a total field, etc. Thus, ticket information can be received in Server 1, analyzed and stored, without the merchant, customer or other entity optically scanning a physical ticket.

Moreover, a data scientist can use the .xml or JSON files to build the database by assigning different unique labels to items, so that the labels are counted across all the .xml or JSON files of the tickets on server 1. Since there are a multitude of ways to write these labels, a neural network can be trained to detect new forms of labels and reunite them with the system labels for the same item. In one embodiment, the Parser is installed as a

Parser module in DTD 10.

The information thus collected can then be presented to a user (e.g., customer, merchant and/or other authorized party) via a user interface provided by a computer terminal. Different types of data may be displayed to different types of users. For example, a user may be able to access and view some or all of the data in tabular and/or graphical form via a website on the Internet, via a browser hosted on a computing device of the user, or via an application (e.g., a phone application) loaded on a computing device such as a phone. Optionally, the website allows the user to add metadata regarding the data presented. For example, the user can optionally categorize and annotate the receipt data, at the receipt and/or receipt line level. This user-generated metadata is also stored in the database 60 in association with the receipt data and/or the user so that it can be recalled and queried later.

In one embodiment, the website or application is configured to allow the user to query statistical information about all or selected portions of the information collected from the tickets for a particular customer, merchant and/or store. For example, optionally, automated personal finance tools are provided through this information, which may include graphs (curves, histograms, etc.). For example, the graphs can provide a user, such as a consumer, with information on purchases broken down into categories such as automotive, dining, groceries, entertainment, housing expenses, etc.

Optionally, the system also allows merchants to display, query and generate reports that summarize purchase information on a store-by-store basis, for all stores, etc. Consumers can receive aggregate information about their spending habits, possibly over a selected period of time. Similarly, a merchant can see who their best customers are, how much they spend over a given period of time, and what types of items they spend their money on.

Fig.6 illustrates an embodiment in which the DTD 10 is configured to receive data related to online transactions/purchases. The basic configuration is as shown in Fig. 1, and the environment further includes an online ordering/purchasing platform 62 operated by the remote server 1.

Online orders 62 are made through a dedicated website or mobile application.

Furthermore, when the customer makes an online payment and wishes to receive a receipt, the remote server 1 sends the print data of this receipt to the DTD 10, which sends it to the printer. If necessary, the DTD 10 converts the print data from e-pos format to ESC/POS format before sending to the printer 14. In one embodiment, where the DTD 10 is connected with multiple printers, it is possible to configure the DTD 10 to send online commands to a dedicated printer and commands from the TDV to another printer. This allows, for example, the sending of orders to be delivered from a restaurant to a printer located in the kitchen instead of the main printer.

The print data for online orders does not necessarily need to be modified because payment for these orders is made immediately through the website or dedicated mobile app. The print data is processed in a similar way to other data in server 1 and is sent through DTD 10 to printer 14.

Claims

CONCLUSIONS

A data processing device (10) of a sales terminal, TDV (12), comprising: at least one input port (28) for receiving TDV print data from a TDV (12); data processing means configured to construct, from the TDV print data (12), modified print data comprising additional information, said additional information comprising a number identifying the data processing device and a serial number generated by the data processing device; at least one output port (30) for sending the modified print data to a printer (14); and a communications module (44) configured to send the modified print data to a remote server (1).

2. Device according to any one of the preceding claims, wherein the additional information defines a URL.

Device according to claim 1 or 2, wherein the additional information comprises information related to an online payment, survey, competition and/or promotion.

Apparatus according to claim 1, 2 or 3, wherein the additional information is added to the print data in the form of a coded image display (11) with the additional information, wherein the coded image is arranged to be read and decoded by a a user's mobile terminal.

5. Device according to claim 4, wherein the coded image display is of the QR code type 1s.

6. Data processing system, including:

at least one data processing device (10) according to any one of the preceding claims, and a remote server (1) configured to store modified print data received from the at least one data processing device and to enable an operation to be performed by means from a mobile terminal of a user that has access to printing the modified print data.

The system of claim 6, wherein the remote server is configured to determine the number of a POS transaction in the modified print data, and to initiate a payment transaction, upon request from a user's mobile terminal, upon authentication of the prints data based on the number identifying the data processing device and the serial number.

Method of operating a sales system comprising a sales terminal, TDV (12), a data processing device, DTD, (10), in particular according to one of the preceding claims, a remote server (1) and a printer (14), whereby; the DTD (10) receives print data including transaction information from the TDV (12); the DTD (10) processes the print data and, from the print data, generates modified print data including additional information, the additional information including a number identifying the data processing device and a serial number generated by the data processing device; wherein the modified print data is sent to the printer (14) for printing a card and to a database (60) on the remote server (1).

9. Method according to claim 8, wherein the additional information comprises information related to an online payment, survey, competition and/or promotion; and wherein the additional information is added to the print data in the form of an image display encoded with the additional information, the encoded image being capable of being read and decoded by a user's mobile terminal.

10. Method according to claim 9, wherein the coded image representation is a two-dimensional barcode, in particular a QR code.

The method of claim 8, 9 or 10, wherein the remote server is configured to determine the number of a POS transaction in the modified print data, and to initiate a payment transaction, upon request from a user's mobile terminal, after authenticating the print data based on the number identifying the data processing device and the serial number.

A method according to any one of claims 8 to 11, wherein the DTD is configured to receive print data related to online transactions (62) and send it to the database (60).