LU501747B1 - Data processing device for sales terminal - Google Patents

Abstract

Data processing device (10) of a sales terminal, TDV (12), comprising: at least one input port (28) for receiving TDV print data (12) from a TDV (12); data processing means configured to construct, from the TDV print data (12), modified print data, which includes 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 transmitting the modified print data to a printer (14); and a communication module (44) configured to transmit the modified print data to a remote server (1). Also presented are a data processing system and a method of operating a sales system.

Description

Data processing device for sales terminal

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

State of the art

Management of tickets and receipts produced by sales terminals (TDV — in English

Point of Sale, POS) has become increasingly difficult for customers as well as the retailer. The receipts contain important information such as the references of the items purchased, their prices and the total amount; they can also include the date and address of the transaction or even promotions. However, the customer only keeps his ticket for a short time and only digests a minimum of all the information. In addition, it is possible that he loses the ticket, in the form of printed paper, even though he would have liked to keep it.

The retailer/merchant is experiencing similar issues. Promotions indicated 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 no longer want to reveal their personal information.

These problems can be solved by integrating online services into the TDV which would allow the customer to pay online, save their tickets, and the merchant to have a better view of their accounts. The multitude of old TDVs in circulation makes modernizing them difficult and expensive, since it is necessary to modify the TDV software or add expensive computer hardware.

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

General description of the invention

According to 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 comprising 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 communications module configured to transmit the modified print data to a remote server.

The device according to the invention is configured to enrich, or increase, a TDV printing data stream in order to provide additional functionalities. The main function of the DTD according to the invention is to allow payment from a user's mobile terminal (such as a smartphone). The DTD will therefore construct a modified data flow which includes additional data with a view to carrying out a given operation from the printed ticket, in particular carrying out a payment operation.

The DTD also sends the modified print data to a remote server, to store and use the digital tickets, and also to manage 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, this DTD makes it possible to intercept the physical printing flow to first inject a QR code on the ticket in order to access a payment web application, and will also send the modified printing data to the remote server. , in order — to extract the amount to be paid from the ticket and connect the digital ticket to the physical ticket read by the customer's terminal.

Preferably, the additional information defines a URL.

Depending on the variants, the additional information includes information relating to an online payment, a survey, a competition 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 able to be read and decoded by a mobile terminal of a user. The encoded image representation is for example of the QR code type.

According to another aspect, there is provided a data processing system, comprising: at least one data processing device as disclosed in the present text, and a remote server configured to store modified print data received from the at at least one data processing device and to enable the performance of an operation by means of a mobile user terminal having access to a printout of the modified print data.

Thus the DTD will enrich the ticket to provide additional information which will allow, using a mobile terminal, to trigger/carry out a given operation, typically a payment.

According to one embodiment, the remote server is configured to determine the amount of a POS transaction in the modified print data, and to initiate a payment transaction, upon a request from a mobile terminal of user, 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 sales system according to claim 8. Embodiments are specified in claims 9 to 12.

Brief description of the figures

Other particularities and characteristics of the invention will emerge 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, in which a sales terminal is associated with the present data processing device; [Fig. 2]: a flowchart of an embodiment of an operating method 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 one embodiment; and [Fig. 6]: a block diagram of another embodiment of the invention comprising 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 QR code type facilitating payment by a customer's mobile phone. Such a ticket is also called “increased”

The TDV 12 (“Point of sale” in English) is here a conventional terminal configured to generate printing data relating to one or more transactions processed by the TDV 12.

The TDV 12 can be based on any technology. An advantage of DTD 10 is its ability to be associated with any type of TDV 12, because 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 for the execution of computer program modules, in particular data processing modules. As used herein, the term "module" refers to the computer program logic and/or data to provide the specified functionality. A module can be implemented in computer hardware, firmware and/or software.

In the variant of Fig.4, the DTD 10 comprises at least one processor 20 coupled to a bus 22, to which are also coupled a memory 24, a storage device 26 and an input port 28 and an output port 30. The processor 20 may be a general general purpose processor such as an INTEL x86, ARM, Atmel AVR or POW processor.

ERPC compatible-CPU. The storage device 24 is, in one embodiment, a semiconductor memory device but can also be any other device capable of storing data, such as a hard disk, a compact disk (CD) or a

Writable DVD, or solid-state memory device. The memory may be, for example, firmware, read only memory (ROM), non-volatile random access memory (NVRAM), and/or random access memory. 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 processing power used by the unit.

So, for example, the DTD computer system may be a microcontroller-based embedded computer system, a single board computer, or a standard personal computer (PC). In particular, an ARM-type single-board computer with 4 1.5 GHz cores, 8 GB of RAM and 64 GB of storage and using a specific optimized Linux distribution called 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 (eg. USB port, Ethernet port etc.) or wireless (e.g. a wireless port such as Wifi, Wireless USB, Bluetooth, Wireless Ethernet, GPRS, EDGE,

HSPA, LTE, WiMax) or other communications port technology. The TDV print data is intended for printer 14, but is intercepted by DTD 10.

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

Advantageously, the analysis module 40 identifies the end of the ticket in the printing flow represented by a characteristic element (or sequence) in the printing data, e.g. the character V defines the end of ticket in the SPOS language. We actually want to add additional data after the end of the ticket body, so as not to modify its integrity. Protecting the integrity of the ticket during augmentation is imperative, as any modification of the original ticket would likely be considered fraudulent.

The data processing means of the DTD 10 further comprise 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. The original printing data is thus modified or increased by the enrichment module 42 by adding additional information. The modified print data will be sent to printer 14 and printed instead of the original data. DTD 10 — selects the information to be added according to instructions provided by the user.

In a variant, the instructions of the enrichment module 42 are based on the information extracted from the printing data, for example if the printing data contains a certain article the enrichment module 42 will add certain additional information.

In practice, additional information may include information relating to an online payment, a survey, a competition, a promotion or defining 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 couple. The serial number is unique, generated by a ticket counter of the

DTD, and does not necessarily correspond to the ticket number that can be generated by the

TDV itself.

In a variant, the data processing means of the DTD 10 comprise an encryption module 54 configured to encrypt the serial number and/or the number identifying the DTD, and it is the encrypted number(s) which 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 (therefore 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 able to be read and decoded by a terminal mobile 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 home page, the customer may be asked to indicate or sign up for loyalty programs to benefit from discounts. In addition, the home page can be located on the Internet and displayed in a browser or displayed in a mobile application installed on the customer's smartphone. The merchant can display its promotions, competitions or surveys through the home page or the mobile application.

The DTD 10 includes at least one output port 30 for transmitting the modified print data to the printer 14. Depending on the variants, the DTD 10 is connected to the printer in a wired or wireless manner (same technological possibilities as for the port of entry28.

The printer produces a modified ticket 16 which can be read and decoded by a mobile terminal (typically a mobile phone/smartphone) of a customer. This will allow the merchant to integrate online services, such as online payment, even if the

TDV 12 does not integrate such functionality natively.

In this context, the ticket serial numbers and/or the DTD identifier number, integrated into the ticket, will make it possible to find the corresponding information on the remote server, therefore to find the corresponding operation and validate it. Once the digital version of the receipt has been found/identified online based on these numbers, we can move on to the payment phase.

An example of modified ticket construction 16 is presented in Fig. 3. The print data generated by the TDV 12 includes instructions corresponding to ticket part 13: this is the original or existing part. The part created in the

DTD 10, called the injected or enriched part, is indicated 11 and here takes the form of a QR code. The injected part 11 is added to the end of the original ticket 13, forming the augmented ticket 16 (Fig.3 a) produced by the printer 14. As indicated previously, the data corresponding to the QR code encoding the ticket serial numbers and DTDs are for example injected into the original print data at the end of the part of code corresponding to the original ticket and before the cut instruction.

As shown in Fig. 1, the DTD 10 advantageously comprises a communication module 44 configured to transmit the modified/augmented printing data in their raw format to a remote server1 via an Internet connection. 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 a .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 xt and .html formats to the QR code of the printed augmented ticket. The .txt format is analyzed by a “Parser” module in the remote server 1 which identifies the various information in the ticket, such as the items purchased, their number, the total, etc. The syntactic analysis of the ticket as well as the .html version of the ticket makes it possible to direct the customer's mobile terminal 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 connecting the physical augmented ticket to the digital ticket allows the DTD 10 to continue printing 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 remote server 1 reconnects and links the digital ticket to the URL.

An embodiment of a method of operating a vending system including the TDV 12, the DTD 10 and the printer 14 is illustrated in FIG. 2. The method mainly comprises the following steps: — Following a sale, the TDV 12 records a transaction and generates a print data stream including transaction information. DTD 10 receives this print data from TDV 12, step 100; — in the next step 102, the DTD 10 processes the print data. It analyzes/reads the content/code/instructions of the print data, and generates modified print data, which includes additional information (with the URL, and the ticket/DTD number 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 base transaction/ticket data 60.

Although in Fig. 2 we show step 104 first then step 106, they can be carried out 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 bar code, in particular of the QR code type, can be chosen as a coded image capable of being read and deciphered by a user's mobile terminal.

As stated above, the TDV 12 is designed to manage transactions (sales), for example: list items purchased, calculate subtotal, taxes and total, add transaction information, such as transaction number or business name, and generate and transmit the print data to the printer.

The TDV 12 typically includes a component generating print data as a print data stream encoded using a print control language and transmitted over a communications port. The print data flow can use any print control language, such as

Epson ESC/POS, JavaPOS, OPOS, Starline, PostScript, PCL, or others. The point of sale 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 sales terminal application such as MICROS RES or a web browser such as MICROSOFT INTERNET EXPLORER that allows the end user to manage sales terminal transactions using a Cloud or web-based sales terminal 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, optionally having entry and exit points, written in a language programming such as, for example, Java, Ruby, Ruby on Rails, Lua, C, C#, and/or C++. They may be compiled and linked into an executable program, installed into a dynamic link library, or may be written in an interpreted programming language such as, for example, BASIC, Perl, or Python. Note that these modules can be called by others and/or by themselves, and/or they can be invoked in response to detected events or interruptions.

In one embodiment, these modules are stored in the storage device 26 and loaded into the memory 24 to be executed by the processor 20.

As shown in Fig. 5, the DTD 10 includes an analysis module 40 which reads the intercepted print data stream in raw format, most often in ESC/POS format, and identifies characteristic elements/codes/instructions (e.g. cutting line or the end of the 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, by analyzing the printing data, the analysis module 40 also identifies the existence of characters/instructions/codes likely to indicate that it is printing data which does not correspond to a action, operation or transaction that must give rise to action on the part of a customer. For example, TDVs typically generate so-called “Z” tickets, which constitute transaction summaries and are intended for the merchant, therefore do not require an increase.

The DTV 10 includes a graphics code generator module 46 configured to generate a graphics code. The graphics code may be a 1D barcode, a 2D barcode, or another type of barcode/image suitable for embedding 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 can be generated using any 2D code symbology such as QR code, Datamatrix, high color barcode capacity, the

ShotCode, the 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) a coded representation of a call to action asking a customer receiving the receipt to use their mobile phone to scan a 2D barcode printed on the receipt in order to enroll in the program loyalty of the merchant or to earn loyalty rewards or gifts if already registered, (2) an encoded representation of a 2D barcode, and (3) an encoded representation of instructions directing the customer receiving the ticket to download a 2D barcode scanner for their mobile phone if they do not already have a 2D barcode scanner. The enrichment module 42 therefore produces enriched information, typically corresponding to the original information of the ticket, to which additional information has been added (including in particular an URL, the ticket serial number and the DTD number).

The DTD 10 includes a print language encoding module 48 configured to encode additional information generated by the module 42 into a particular printer language defined format, for insertion into the intercepted print data. The information to be encoded can be text data or image data. For example, the print language encoding module 48 is configured to encode the enriched information in the printer language format

Epson ESC/POS. Additionally, the encoding module 48 may be configured to convert print data from one printer language to another printer language, thereby facilitating interoperability.

Due to the difference in speed between the processor and the peripheral, the data sent to a peripheral is most often stored in buffer memories or buffer 50 waiting for their actual sending to the peripheral, to spare the DTD 10 the waiting due unlike the difference in flow rates. Likewise, data received from the outside are often collected in buffers 50, awaiting their processing by the DTD 10 for reasons of efficiency, and also to avoid their loss.

The communication module 44 is configured to transfer the incoming print data to the buffer memory 50, and the modified print data to the remote server 1 and to the printer 14. The communication module 44 thus manages the communication, resp. the transfer of data/information, in DTD 10 and outwards. In a variant, it is possible to connect several printers 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 saving of various data used by the DTD 10 and the other modules, such as information used by the graphic code generator module 46.

It will appear to those skilled in the art that other embodiments may include modules different and/or other than those described here, and that the functionalities may be distributed between 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 transceivers

NFC to transmit data to a terminal (mobile phone) of the customer, without printing the physical ticket. The customer receives the receipt data by holding their NFC-compatible mobile device close to the NFC transceiver. This data typically includes an internet address (url) which arrives on a home page (landing page) allowing downloading of the ticket and payment.

In another variant, the DTD 10 includes a display unit (integrated into the DTD housing or separate) to display the QR code. Printing the physical receipt is avoided, since the customer can read and decode the QR code with their mobile terminal from

the screen.

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

Tickets produced by different TDV 12s can have different structures, for example the number of items can be placed before the item or after the item just before the price and other variations of the structure are possible. The use of the so-called “Parser” software allows the syntactic analysis of the ticket, making it possible to identify the different information on the ticket, such as the nature of the items purchased, their reference, the number of items, the total etc., those -these are used in the creation of the landing page of the url in the QR code. In addition, the “Parser” module in the 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 structure initial. 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 identifier of the transaction for which the receipt is printed, item descriptions, item quantities, item charges, subtotal, tax lines (VAT or other), and 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 the TDV 12 is deployed. The .xml or JSON version can be reused to build database 60.

The different elements of information are matched with the corresponding fields. For example, the store name may be matched to a store name field, the name of a purchased item may be matched to a purchased item field, the price of an item may be matched match to an item price field, a tax can be matched to a tax field, a total can be matched to a total field, etc. Thus, ticket information can be received into server 1, analyzed and stored, without the merchant, customer or other entity optically scanning a physical ticket.

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

Parse in DTD 10.

The information thus collected may then be presented to a user (e.g., the customer, the merchant and/or another authorized party) via a user interface provided by a computer terminal. Different types of data can 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, through 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 telephone. 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 and/or user data so that it can be recalled and queried later.

Alternatively, the website or application is configured to allow the user to query statistical information about all or selected portions of the information collected from tickets for a customer, a merchant and/or a private store. For example, optionally, automated personal finance tools are provided through this information, which may include graphics (lines, histograms, etc.). For example, charts can provide a user, such as a consumer, with purchasing information broken down into categories such as automotive, dining, groceries, entertainment, housing expenses, and so on. Optionally, the system also allows merchants to view, query and generate reports that summarize purchasing information on a store-by-store basis, for all stores, etc. The consumer may receive aggregated information about their spending habits, possibly over a selected period of time. Likewise, 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 relating to online transactions/purchases. The basic configuration is that of 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 printing data of this receipt to the DTD 10, which sends them to the printer. If necessary, the DTD 10 converts the print data from the e-pos format to the ESC/POS format before sending to the printer 14. In a variant, in which the DTD 10 is connected with several printers, it is possible configure DTD 10 to send online orders to a dedicated printer and orders from the TDV to another printer. This allows, for example, orders to be delivered from a restaurant to be sent to a printer located in the kitchen instead of the main printer.

The printing data of online orders does not necessarily have to be modified because payment for these orders is made immediately through the website or "dedicated mobile application.

Print data is processed similarly to other data in server 1 and is sent through DTD 10 to printer 14.

Claims (12)

Claims 1. Data processing device (10) of a sales terminal, TDV (12), comprising: at least one input port (28) for receiving TDV printing data (12) from a TDV (12); data processing means configured to construct, from the TDV print data (12), modified print data, which includes 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 transmitting the modified print data to a printer (14); and a communication module (44) configured to transmit the modified print data to a remote server (1). 2. Device according to any one of the preceding claims, in which the additional information defines a URL. 3. Device according to claim 1 or 2, in which the additional information comprises information relating to an online payment, a survey, a competition and/or a promotion. 4. Device according to claim 1, 2 or 3, wherein the additional information is added to the print data in the form of an encoded image representation (11) with the additional information, the encoded image being able to be read and decoded by a user's mobile terminal. 5. Device according to claim 4, in which the encoded image representation is of the QR code type. 6. Data processing system, comprising: 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 carried out by means of a mobile user terminal having access to a printout of the modified print data. 7. System according to claim 6, wherein the remote server is configured to determine the amount of a POS transaction in the modified print data, and to initiate a payment transaction, upon request from a mobile user terminal, after authentication of the print data based on the number identifying the data processing device and the serial number. 8. Method of operating a sales system comprising a sales terminal, TDV (12), a data processing device, DTD, (10), in particular according to any one of the preceding claims, a remote server ( 1) and a printer (14), in which; the DTD (10) receives print data including transaction information from the TDV (12); the DTD (10) processes the print data and generates, from the print data, modified print data comprising additional information, the additional information comprising a number identifying the data processing device and a number of series generated by the data processing device; the modified print data is sent to the printer (14) for printing a ticket as well as to a database (60) on the remote server (1). 9. Method according to claim 8, in which the additional information comprises information relating to an online payment, a survey, a competition and/or a promotion; and 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. 10. Method according to claim 9, wherein the encoded image representation is a two-dimensional bar code, in particular a QR code. 11. Method according to claim 8, 9 or 10, wherein the remote server is configured to determine the amount of a POS transaction in the modified print data, and to initiate a payment transaction, upon a 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. 12. Method according to any one of claims 8 to 11, wherein the DTD is configured to receive printing data relating to online transactions (62), and transmit them to the database (60).