IT201800006536A1 - A method of collecting personal purchasing information about a customer through a POS terminal and related electronic devices - Google Patents

Description

"Method for collecting personal purchase information relating to a customer through a POS terminal and related electronic devices" DESCRIPTION FIELD OF THE INVENTION

The present invention relates to a method of collecting personal purchasing information relating to a customer through a POS terminal, as well as a POS terminal and a server.

STATE OF THE TECHNIQUE

POS terminals have been known for many years and very popular at point of sale.

POS terminals are mainly used for the electronic payment of goods and services, and therefore the term "POS terminal" is often used to indicate a "payment POS terminal".

Long before the introduction of electronic payment instruments, the practice of applying discounts to encourage sales was widespread among retailers. The discount could be applied to a single customer or to an entire category of customers. At certain times of the year, the discount was applied to all customers, so-called "balances".

For some years, ie after the spread of electronic payment instruments, "loyalty / fidelity programs" have become common. Typically, for example, a store or chain of stores provides its customers with personal identification cards; to benefit from the program, the customer provides, at the time of purchase at a point of sale, the card to the merchant and the merchant disburses the benefit, for example a discount on the price and / or registers the purchase on the card to enjoy benefits in the future.

This system has proved very effective.

However, it is inconvenient for a consumer to have to keep a plurality of personal purchase identification cards in his wallet, one for each "loyalty / fidelity program" he can benefit from; these cards are added to payment cards and other personal identification cards (identity card, passport, driving license, health card, public transport card, employee card). Furthermore, the current "loyalty / fidelity program" management system at the points of sale is not particularly easy for a retailer or a distributor or a manufacturer and offers limited flexibility (basically the program is the same for all customers or for an entire category of customers).

SUMMARY

The general purpose of the present invention is to improve the management system of "loyalty / fidelity programs".

This object is achieved thanks to the method having the characteristics expressed in the appended claims which form an integral part of the present description.

The idea behind the present invention is to manage the "loyalty / fidelity program" directly through the POS terminals, in particular the payment POS terminals.

Preferably, the following are used as personal identification cards for purchase:

- debit or credit cards,

- prepaid payment cards,

- identity cards,

- health cards.

Also object of the present invention is a POS terminal and a server.

LIST OF FIGURES

The present invention will become clearer from the detailed description that follows to be considered together with the drawings attached hereto in which: Fig. 1 shows a block diagram of an example of system embodiment according to the present invention comprising, by way of example, a server and a POS terminal (Internet and payment circuit is not part of the system), e

Fig. 2 shows a flow diagram (very schematic) of an example of embodiment of a method according to the present invention.

As can be easily understood, there are various ways of practicing the present invention which is defined in its main advantageous aspects in the appended claims and is not limited either by the following detailed description or by the appended drawings.

DETAILED DESCRIPTION

In Fig. 1, the system is indicated as a whole with the numerical reference 1000.

The system 1000 comprises a payment POS terminal 100 and a server 300. Obviously, in general, there will be a plurality of POS terminals at various points of sale.

In Fig. 1, schematically indicated: a payment circuit 200, Internet 400, a card 500, a shopkeeper 600 and a customer 700.

POS terminal 100, payment circuit 200 and server 300 are connected to the Internet 400.

Fig. 1 refers to the situation in which a customer 700 who has a payment card 500 at his disposal is at a point of sale and is preparing to make a purchase by paying through the POS terminal 100 made available by the shopkeeper 600.

As regards the POS terminal 100, the following are highlighted: a processor and memories (and active processes) 110, a keyboard 120, a screen 130, a card reader 140; keyboard 120 and screen 130 are used for interaction with users, typically shopkeeper (and / or shop assistants) and customers.

As regards the server 300, the following are highlighted: a processor and memories (and active processes) 310, a database 390.

As regards the card 500, a memory 510 (magnetic and / or electronic) is highlighted which could also be associated with a processor (depending on the type of card).

Suppose that customer 700 is at a sales point, has identified a product of his interest and has gone to the cashier of the point of sale with the payment card 500 to make the purchase. At the checkout, customer 700 finds shopkeeper 600 with the POS 100 payment terminal.

Merchant 600 asks customer 700 for a payment card, and customer 700 provides card 500 to merchant 600.

The shopkeeper 600 makes the terminal 100 read the card 500 by means of the reader 140 (this corresponds to block 2400 of the flow chart of Fig. 2); the terminal 100 obtains at least one identification code from the card 500; typically, in the case of a payment card, the code obtained is the so-called PAN code ("payment card number" or "primary account number"). Typically, the card 500 is of the electronic and / or magnetic type; but, at the limit, it could also be of the optical type with graphically reproduced the code of interest (for example a QR code).

In the terminal 100 of the point of sale a management application is active (which "runs" thanks to the processor and memories 110) which is able to verify, for example, if the customer 700 adheres to a "loyalty program" offered by the point sale.

The management application of the terminal 100 can be done in such a way that this check is made only if requested by the shopkeeper 600 (for example by means of an appropriate command supplied to the terminal 100 by the shopkeeper 600 through the keyboard 120) or always at each reading of a paper.

This check can proceed for example as follows.

The terminal 100 calculates a digest of the code read by the card 500 by means of a suitable hash function (this corresponds to block 2500 of the flow diagram of Fig. 2) thanks to the processor and memories 110.

Subsequently, the terminal 100 queries a purchasing database through the digest obtaining personal purchasing information from it (this corresponds to block 2600 of the flow chart of Fig. 2) thanks to the processor and memories 110. Typically, the bank purchase data is remote with respect to the point of sale and therefore with respect to terminal 100.

In the example of Fig. 1, the purchase database 390 is located at the server 300; a special application is active in the server (which "runs" thanks to the processor and memories 310) able to receive requests from POS terminals and to send replies. In the example of Fig. 1, the communications between terminals 100 and server 300 take place through the Internet 400; such communications are preferably carried out using an HTTPS or SFTP or FTPS protocol; for greater security, such communications can be made by signing and / or encrypting transferred information. For security, before the actual query, the terminal management application can authenticate itself with the server application, for example through its certificate, and possibly the server application can authenticate itself with the terminal management application through his certificate.

The main search key in the server database is typically the hash of the identification code; as explained below, secondary search keys may be provided.

The purchase information contained in the database is "personal" as it is associated with a card of a certain person. However, it cannot be ruled out that two different cards may be associated in the database with totally or partially identical information; according to a first example, if the two cards are of two people of the same "category" the associated purchase information in the database could be partially the same (for example, equal percentage discount, but different monetary bonus); according to a second example, if the two cards are two payment cards of the same person, it is logical that the associated purchase information in the database is exactly the same.

The purchase information contained in the database can be of various types: percentage discount to be applied to the customer for all or part of his purchases, purchase monetary bonus that can be used by the customer for all or part of his purchases, points or amounts accumulated by the customer in the course of his purchases, customer prizes or gifts, etc. It should be noted that, for example, the discount percentage may depend on the product purchased; for example, the SA discount is provided for products in the PA category, the SB discount is provided for products in the PB category, and so on; in this case, for example, the product category could be a secondary search key. It should also be noted that the server could manage multiple "loyalty programs", for example "loyalty programs" offered by different points of sale and / or by different chains of points of sale; in this case, for example, a "loyalty program" code could be a secondary search key; alternatively, for example, the server could manage several databases, one for each "loyalty program".

The query by the POS terminal typically takes place in the following way: the POS terminal transmits a question / request message to the server through the Internet that receives it, then the server processes the question / request message according to its content (typically this processing consists in directly querying the local database), then the server transmits a response message to the POS terminal via the Internet that receives it (typically the content of the response message depends on the result of the query).

The question / request message contains at least the digest of the identification code; it may also contain other codes, such as a query type code and / or a product category code and / or a "loyalty program" code and / or a store or chain store code and / or etc.

The reply message contains one or more personal purchase information associated with the digest (and therefore with the identification code and therefore with the card) in the database, for example a percentage discount and / or a monetary bonus and / or a number of points accumulated and / or an accumulated sum and / or a prize identifier and / or a gift identifier and / or etc.

It should be noted from the outset that the conversation between the POS terminal and the server is generally not limited to the question / request message and the response message; in later stages, there may be other exchanges of messages. In its simplest form, the method according to the present invention could stop here, i.e. with the obtaining of personal purchase information and, for example, their display on the screen 130 of the terminal 100 (and / or their printing thanks to a terminal device). Typically, however, the method according to the present invention provides for one or more further and subsequent steps (see for example blocks 2700 and 2800 in the flow chart of Fig.2).

According to a first further and subsequent step (see for example block 2700 in the flow diagram of Fig. 2), the POS terminal 100 uses the personal purchase information received from the server to make a payment. For example, the terminal management application 100 asks the shopkeeper 600 to enter the price of the product and then calculates the amount to be paid by applying the discount percentage or (totally or partially) the monetary bonus received by the server at the price entered by the shopkeeper. Typically the actual payment is made thanks to a payment application of the terminal 100 which "receives" the calculated amount.

According to a second further and subsequent phase (see for example block 2800 in the flow diagram of Fig. 2), the POS terminal 100 updates the database 390 of the server 300. Typically, but not necessarily, this occurs in the light of the payment outcome. The management application of the terminal 100 could transmit an update message to the server 300 to update, for example, the discount received and / or the monetary bonus and / or the points accumulated and / or the accumulated sum and / or the reward received and / or the gift received, etc. In response, the server application 300 could simply transmit a confirmation message.

A possible operation of the method according to the present invention has just been described on the occasion of a purchase at a sales point. Naturally, the steps of the method described are typically repeated with each purchase and therefore many times in a day when the store is open.

There are also phases of the method that take place with different timing. There will typically be a phase in which the management application is activated in the POS terminal 100 (see for example block 2300 in the flow diagram of Fig. 2). This phase is typically triggered by the shopkeeper 600 at the beginning of a store opening day; the trigger could derive from the switching on of terminal 100.

There will typically be a phase in which a management application is installed in the POS terminal 100 (see for example block 2200 in the flow diagram of Fig. 2). This phase is typically triggered "one-off" by an installer who goes to the point of sale; it should be noted that this installation typically takes place on a POS terminal already in place at a point of sale.

What has just been described is summarized in the flow chart 2000 of Fig. 2 in which:

- block 2100 indicates the start.

- block 2200 indicates installation of the application

- block 2300 indicates the activation of the application

- block 2400 indicates the reading of the card

- block 2500 indicates the calculation of the digest

- block 2600 indicates the database query

- block 2700 indicates payment

- block 2800 indicates the updating of the database

- block 2900 indicates the end

In general, the method according to the present invention is used to collect personal purchase information relating to a customer through a POS terminal, and provides that the customer has a card available, this card being electronic and / or magnetic and memorizing a code of identification; according to the method:

C) the POS terminal reads at least the identification code from the card afterwards

D) the POS terminal calculates a digest of the identification code using a hash function

afterwards

E) the POS terminal queries a purchase database through the digest obtaining personal purchase information.

The POS terminal is typically a payment POS terminal and is adapted to connect to a payment circuit separate from the purchase database.

The card is preferably of the following type:

T1) a debit or credit card and the identification code is a debit or credit card PAN,

or

T2) a prepaid payment card and the identification code is a PAN of the prepaid payment card,

or

T3) an identity card and the identification code is a tax code, or

T4) a health card and the identification code is a tax code. Preferably, the POS terminal is adapted to read cards of different types. Typically, the method provides after phase E a phase F in which the POS terminal uses the personal purchase information to make a payment.

Typically, the method provides after phase E, in particular after phase F, a phase G in which the POS terminal updates the purchase database.

Typically, the method involves a first preliminary phase A in which a management application is installed in the POS terminal to manage phases C, D and E, and

Typically, the method provides for a second preliminary phase B in which the management application is activated in the POS terminal.

Preferably, the management application is adapted to take (possibly total) control of the POS terminal.

Preferably, the management application is adapted to release (possibly total) control of the POS terminal at the request of a user (in particular the shopkeeper) of the POS terminal.

Typically, the POS terminal is equipped with a payment application, and the management application uses one or more functions of the payment application. The payment application can be used for example to carry out step D. The payment application can be used for example to make a payment. Typically, communications between the POS terminal and the server that manages the purchasing database are carried out via the Internet. Preferably, such communications are made using an HTTPS or SFTP or FTPS protocol.

Communications between the POS terminal and the server that manages the purchasing database can be made by signing and / or encrypting the information transferred.

In general, the POS terminal according to the present invention is able to carry out at least the phases C, D, E and possibly F; it can typically be a normal payment POS terminal in which a suitable application with the related configuration data has been installed.

In general, the server according to the present invention comprises a purchase database which stores personal purchase information, and is adapted to be interrogated by digesting an identification code of a card, in particular a debit or credit card and / or a prepaid payment card and / or an identity card and / or a health card.

Claims (16)

CLAIMS 1. Method of collecting personal purchasing information relating to a customer (700) through a POS terminal (100), said customer (700) having a card (500), said card (500) being electronic and / or magnetic and by storing an identification code, in which: - C) (2400) said POS terminal (100) reads (140) from said card (500) at least said identification code afterwards - D) (2500) said POS terminal (100) calculates a digest of said identification code by means of a hash function afterwards - E) (2600) said POS terminal (100) queries a purchase database (390) through said digest obtaining said personal purchase information. Method according to claim 1, wherein said POS terminal (100) is a payment POS terminal, and said POS terminal (100) is adapted to connect to a payment circuit (200) distinct from said purchase database (390). Method according to claim 1 or 2, wherein said paper (500) is of the following type: T1) a debit or credit card and said identification code is a PAN of the debit or credit card, or T2) a prepaid payment card and said identification code is a PAN of the prepaid payment card, or T3) an identity card and said identification code is a tax code, or T4) a health card and said identification code is a tax code. Method according to claim 3, wherein said POS terminal (100) is adapted to read cards of different types. Method according to any one of the preceding claims, which provides after step E (2600) a step F (2700) in which said POS terminal (100) uses said personal purchase information to make a payment. Method according to any one of the preceding claims, comprises a first preliminary step A (2200) of installing in said POS terminal (100) a management application able to manage steps C (2300), D (2400) and E (2500 ), and a second preliminary step B (2300) of activating said management application in said POS terminal (100). Method according to claim 6, wherein said management application is adapted to take control of the POS terminal (100). Method according to claim 6, wherein said management application is adapted to release control of the POS terminal (100) upon request of a user (600) of the POS terminal (100). Method according to claim 6 or 7 or 8, wherein said POS terminal (100) is equipped with a payment application, and wherein said management application uses one or more functions of said payment application. Method according to claim 9, wherein said management application uses a function of said payment application to perform step D (2500). Method according to claim 9 or 10, wherein said management application uses a function of said payment application to make a payment. Method according to any one of the preceding claims, wherein communications between said POS terminal (100) and a server (300) which manages said purchase database (390) are carried out via the Internet (400). Method according to claim 12, wherein said communications are made using an HTTPS or SFTP or FTPS protocol. Method according to any one of the preceding claims, wherein communications between said POS terminal (100) and a server (300) which manages said purchase database (390) are carried out by signing and / or encrypting transferred information. POS terminal (100) suitable for carrying out at least the steps C (2400), D (2500), E (2600) and possibly F (2700) of the method according to the preceding claims. 16. Server (300) comprising a purchasing database (390) which stores personal purchasing information, and capable of being queried by digesting a card identification code (500), in particular a debit card or credit and / or a prepaid payment card and / or an identity card and / or health card.