METHOD FOR MANAGING LOYALTY IDENTIFIERS, METHOD FOR PROCESSING LOYALTY DATA, SERVER, TRANSACTION DEVICE AND CORRESPONDING PROGRAMS

Description

1. Scope of the invention

[0001] The present invention relates to the field of payment operations and more particularly to the optimized management of customer loyalty data. 2. Prior Art

[0002] Throughout history, customer loyalty has been a way for retailers to ensure regular revenue, and therefore to grow and sustain their business. For several years now, however, two main types of technologies have coexisted in order to ensure customer loyalty.

[0003] The first type, the most basic, consists of issuing a "physical" loyalty card, for example in the form of a "paper" or "plastic" loyalty card, stampable or not, or featuring a barcode intended to be scanned.

[0004] The stampable loyalty card allows customers to collect one or more stamps at checkout, depending, for example, on the amount of their purchase. Such a loyalty card can be combined with the distribution of discount coupons or loyalty vouchers to customers, usually by mail.

[0005] The barcode loyalty card, for example, allows users to benefit from an immediate discount on a purchase they are currently making, or to accumulate loyalty points associated with the purchase transaction in order to later obtain a reward for their loyalty. This barcode loyalty card can also be linked to the distribution of discount coupons or loyalty vouchers to customers, usually via email and / or SMS.

[0006] These physical loyalty cards must be presented to the merchant by the user, either to be stamped or scanned, if they wish to benefit from the loyalty program they have subscribed to. Furthermore, this type of physical loyalty card often requires the user to provide the merchant with additional information to identify them within the loyalty program, such as their contact details (name and address), email address, and / or mobile phone number.

[0007] The second type of customer loyalty implementation involves using existing technological communication solutions. This second type relies, for example, on a "virtual" loyalty card associated with a specific number (for example, a specific identifier corresponding to a membership number). This specific number is used extensively, along with the customer's contact information (email address, telephone number, social networks), to offer the customer, via various communication channels, not only the management of a specific loyalty program but also the transmission of commercial offers and discount coupons.For example, this information can be transmitted via email, SMS, or in-app messages (a technology that sends notifications to an application installed on a smartphone when the user is using that application). More recently, the integration of loyalty management into smartphones has been improved thanks to digital wallets.

[0008] However, even with this second type of "virtual" loyalty card, the user must open a dedicated loyalty management application on their smartphone to select and display the loyalty card corresponding to the merchant with whom they are making a transaction, either for the merchant to scan the associated barcode (a bit like a "physical" loyalty card), or for the merchant to enter the membership number into their customer loyalty management system.

[0009] Therefore, there is a need to provide users with an optimal loyalty solution in terms of user-friendliness, while also being simple and inexpensive for the merchant. US patent application US2013 / 282468 A1 and US patent US8892474 B1 disclose prior art loyalty management solutions.

[0010] The invention is defined by the independent claims. Additional embodiments are defined by the dependent claims. 3. Summary

[0011] The proposed technique does not present these drawbacks of the prior art. More specifically, in one respect, the proposed technique relates to a method for managing loyalty identifiers. This method is implemented in a loyalty identifier management server and includes an initialization phase comprising a step for generating a general loyalty identifier for a previously identified user.

[0012] Thus, according to this first aspect of the proposed technique, the loyalty identifier management process makes it possible to associate, in a prior initialization phase, a general loyalty identifier with a previously identified user, in order to simplify the management of the different specific loyalty programs to which the user in question has subscribed.

[0013] To do this, the loyalty ID management server therefore creates, for example in a database, a general loyalty ID, in order to centrally manage all loyalty data associated with this user, regardless of the merchants involved.

[0014] This preliminary initialization phase is preferably implemented outside of a purchase made by the user, so that the user's general loyalty identifier is available at the time of these subsequent purchases.

[0015] In one particular aspect, the initialization phase also includes the following steps, respectively before and after the generation step: reception, from a user's communication terminal, of a request to generate a general loyalty identifier associated with the user, the generation request including at least one user identification data; transmission, to the user's communication terminal, of a response including the generated general loyalty identifier.

[0016] According to a particular embodiment, the initialization phase is implemented following the receipt of a request issued by a user communication terminal (for example a smartphone or tablet, or even a computer).

[0017] This request can, for example, be issued by a loyalty application previously installed on the user's device, through which the user can manage their various loyalty programs. During the initialization phase, the request includes at least one piece of data that identifies the user, so that the loyalty account management server can generate a unique general identifier for that user. Such user identification data might be, for example, their first and / or last name, a username, and / or a unique number generated by the application itself.

[0018] Furthermore, once the general loyalty identifier is generated, the loyalty identifier management server transmits it, in response to the request, to the user's communication device. If a dedicated loyalty application has issued the request, this application receives the general loyalty identifier associated with the user and uses it to simplify loyalty management locally on the user's communication device.

[0019] According to a particular embodiment, the process further comprises the following steps: reception, from the user's communication terminal or a merchant's transaction device, of a request to update the user's general loyalty identifier, the update request including the user's general loyalty identifier and at least one specific user loyalty identifier for the merchant; updating of the general loyalty identifier by association between the at least one specific user loyalty identifier for the merchant and the user's general loyalty identifier.

[0020] According to this embodiment, the proposed process makes it possible to associate a plurality of specific user loyalty identifiers, for a plurality of merchants, with his general loyalty identifier.

[0021] The user's general loyalty identifier can therefore be updated, for example, via the loyalty application installed on the user's communication terminal, to add a merchant-specific loyalty card.

[0022] To do this, the loyalty ID management server receives an update request containing both the user's general loyalty ID (generated during the initial setup phase) and a specific loyalty ID for the user at the given merchant, such as a membership number. The server can then associate this specific loyalty ID with the user's general loyalty ID. In this way, the general loyalty ID enables the management of the user's loyalty program for the relevant merchant.

[0023] Again, these steps to update the user's general loyalty identifier are preferably implemented outside of a purchase made by the user.

[0024] However, these steps can also be implemented at the time of purchase from a merchant, via the transaction device used for that purchase. This "smart" update allows a user to benefit from loyalty rewards for a purchase in progress, even if they were not a member of the merchant's loyalty program before making the purchase. This implementation further simplifies loyalty management for the user.

[0025] According to a particular feature, the process further includes a step of transmitting, to the user's communication terminal, information representative of the updated general loyalty identifier.

[0026] Thus, according to this embodiment, when the loyalty application installed on the user's communication terminal has issued a request to update the user's general loyalty identifier, it receives a response to its request from the loyalty identifier management server.

[0027] Furthermore, even when the request originates from a merchant's transaction device (for example, at the time of purchase), rather than from the loyalty app itself, the app still receives notification of the update. This ensures that users always have access to an up-to-date status of their overall loyalty ID, and therefore their specific loyalty programs, via the app installed on their mobile device.

[0028] According to a particular embodiment, the process further comprises the following steps: reception, from a transaction device associated with a merchant, of a request to obtain a specific user loyalty identifier for the merchant, the request including the user's general loyalty identifier; obtaining at least one merchant identification data; searching, from the merchant identification data and the user's general loyalty identifier, for the user's specific loyalty identifier for the merchant: ∘ when the search is successful, transmission, to the transaction device, of a response including the user's specific loyalty identifier for the merchant; ∘ when the search is unsuccessful, transmission, to the transaction device, of a negative response.

[0029] According to this embodiment, the proposed method allows a transaction device (an electronic payment terminal, a cash register, etc.) to retrieve a specific loyalty identifier for a merchant from the loyalty ID management server, based on the user's general loyalty identifier. In this way, when a user wishes to benefit from a loyalty program linked to a purchase made at a merchant, they only need to provide their general loyalty identifier, without having to search for their specific loyalty identifier. This greatly simplifies loyalty management, especially when this general loyalty identifier can be provided to the transaction device automatically, for example, via the payment method used by the user to make their purchase or via their communication terminal, as described in more detail below.

[0030] To do this, the transaction device sends a request to the loyalty ID management server to obtain the specific loyalty ID associated with the user for the given merchant. This request must contain at least the user's general loyalty ID, obtained in various ways detailed below.

[0031] Upon receiving this request, the loyalty ID management server obtains an identification of the merchant, for example via data also present in the request (a public key of the transaction device, an identifier of the merchant or of the transaction device) or via location information of the transaction device allowing it to find the associated merchant.

[0032] From these two pieces of information (the user's general loyalty identifier and the merchant's identification), the loyalty identifier management server can search for whether the user's general loyalty identifier is associated with a specific user loyalty identifier for that merchant.

[0033] If so, the server returns this specific loyalty identifier in response to the request.

[0034] Otherwise, the server returns a negative response, indicating that the user's general loyalty identifier does not allow managing the user's specific loyalty for that merchant.

[0035] These steps for using the user's general loyalty identifier are implemented, for example, at the time of a purchase made by the user, typically at the beginning or end of the transaction (such as when the user presents a "physical" loyalty card to be stamped or scanned).

[0036] From another perspective, the proposed technique relates to a loyalty data processing method. This method is implemented in a merchant's transaction system and comprises the following steps: obtaining, from a user, a general user loyalty identifier; sending, to a loyalty identifier management server, a request to obtain a specific user loyalty identifier for the merchant, the request including at least the general user loyalty identifier; receiving, from the loyalty identifier management server, a response to the request and, if the response includes the specific user loyalty identifier for the merchant: processing at least one loyalty data associated with the specific user loyalty identifier for the merchant.

[0037] Thus, according to this second aspect of the proposed technique, implemented in a transaction device (an electronic payment terminal, a cash register, etc.) at the time of a purchase made by the user, the loyalty data processing procedure allows this transaction device to retrieve, from the loyalty identifier management server, a specific loyalty identifier for the merchant associated with the transaction device, from the general loyalty identifier of the user, in order to be able to manage the user's loyalty data specific to the merchant in question.

[0038] To do this, the transaction device obtains the user's general loyalty identifier, for example via the payment method used by the user (their payment card, their smartphone, etc.) and sends a request to the loyalty identifier management server to retrieve the user's specific loyalty identifier for the given merchant.

[0039] If the user is indeed enrolled in the merchant's loyalty program and has updated their general loyalty ID with their specific loyalty ID, then the loyalty ID management server transmits this specific loyalty ID in response to the transaction device's request. The transaction device can then use this specific loyalty ID to manage the user's specific loyalty program, in relation to the purchase made.

[0040] Depending on one particular aspect, the process includes the following steps, if the answer is negative: obtaining a specific user loyalty identifier for the merchant; sending a request to the loyalty identifier management server to update the user's loyalty identifier, the update request including the user's general loyalty identifier and the user's specific loyalty identifier for the merchant; processing at least one loyalty data associated with the user's specific loyalty identifier for the merchant.

[0041] Thus, according to this embodiment, if the user is not affiliated / member of the merchant's loyalty program, or if he has not previously updated his general loyalty identifier with his specific loyalty identifier, then the loyalty identifier management server cannot find the required specific loyalty identifier, and transmits a negative response to the transaction device.

[0042] In this case, the transaction system can request an update to the user's general loyalty identifier to reflect the specific loyalty program for the merchant in question. This update can be made after authorization from the user, either at the time of the update request itself, or beforehand through a "general" authorization granted by the user (for example, via the loyalty application installed on their mobile device).

[0043] To perform this update, the transaction device sends a request to the loyalty ID management server containing the user's general loyalty ID and the user's specific loyalty ID for the merchant in question. This specific ID, if it already exists, can be provided to the transaction device by the user (for example, via their payment method) or it can be created and provided by a specific loyalty server of the merchant at the time of purchase.

[0044] In parallel with this update request, the transaction device uses the user's specific loyalty identifier to manage their specific loyalty program, in relation to the purchase made.

[0045] For example, the steps of obtaining a specific user loyalty identifier for the merchant and processing are implemented via a specific loyalty program management server associated with the merchant.

[0046] Thus, according to this embodiment, the transaction device does not manage the merchant's loyalty programs internally and therefore communicates with a specific loyalty server of the merchant, to manage the user's specific loyalty program, as well as to obtain, if it does not already exist, the user's specific loyalty identifier for the merchant in question.

[0047] According to a particular characteristic, the step of obtaining a general user loyalty identifier is implemented via means of communication with a user communication terminal belonging to the group comprising: NFC; Bluetooth; MST (magnetic stripe emulation).

[0048] Thus, according to this embodiment, the transaction device can obtain the user's general loyalty identifier by various means.

[0049] For example, the user can display their loyalty ID on their smartphone (via the loyalty app), where it can be scanned. The ID can also be transmitted wirelessly over very short distances (Bluetooth) or via contactless communication (such as NFC) between the user's smartphone and the transaction device. In yet another variation, the ID can be provided by emulating the magnetic field generated by a magnetic stripe card, for example, through secondary data transmission. In another variation, the general loyalty ID can take the form of a QR code, displayed, for example, on the user's smartphone and read by the transaction device. In yet another variation, the general loyalty ID can be manually entered by the user or the merchant on the transaction device.

[0050] According to a preferred implementation, the various steps of the processes described above, according to the proposed technique, are implemented by one or more software or computer programs, comprising software instructions intended to be executed by a data processor of a relay component according to the proposed technique and designed to control the execution of the various steps of the processes.

[0051] Consequently, the proposed technique also aims at a program, capable of being executed by a computer or by a data processor, this program comprising instructions to control the execution of the steps of a process as mentioned above.

[0052] This program can use any programming language, and be in the form of source code, object code, or code somewhere between source code and object code, such as in a partially compiled form, or in any other desirable form.

[0053] The proposed technique also aims for an information support readable by a data processor, and containing instructions from a program as mentioned above.

[0054] The information medium can be any entity or communication terminal capable of storing the program. For example, the medium can include a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording means, for example a floppy disk or a hard disk drive.

[0055] On the other hand, the information medium can be a transmissible medium such as an electrical or optical signal, which can be transmitted via an electrical or optical cable, by radio, or by other means. The program, according to the proposed technique, can in particular be downloaded from a network such as the Internet.

[0056] Alternatively, the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the process in question.

[0057] In one embodiment, the proposed technique is implemented using software and / or hardware components. In this context, the term "component" may refer to a software component, a hardware component, or a set of hardware and software components.

[0058] A software component corresponds to one or more computer programs, one or more subroutines of a program, or more generally to any element of a program or software capable of implementing a function or set of functions, as described below for the component in question. Such a software component is executed by a data processor of a physical entity (terminal, server, gateway, router, etc.) and is capable of accessing the hardware resources of that physical entity (memory, storage media, communication buses, input / output cards, user interfaces, etc.).

[0059] Similarly, a hardware component corresponds to any element of a hardware assembly capable of implementing a function or set of functions, as described below for the component in question. This could be a programmable hardware component or one with an integrated processor for software execution, for example, an integrated circuit, a smart card, a memory card, an electronic board for running firmware, etc.

[0060] Each component of the system described above naturally implements its own software components.

[0061] The proposed technique also relates to a loyalty identifier management server including means for generating a general loyalty identifier for a previously identified user, for the implementation of the loyalty identifier management process as described above.

[0062] In another respect, the proposed technique also relates to a transaction device comprising, for the implementation of the steps of the loyalty data processing procedure as described above: means of obtaining, from a user, a general user loyalty identifier; means of sending, to a loyalty identifier management server, a request to obtain a specific user loyalty identifier for the merchant, the request including at least the user's general loyalty identifier; means of receiving, from the loyalty identifier management server, a response to the request and, if the response includes the user's specific loyalty identifier for the merchant: means of processing at least one loyalty data associated with the user's specific loyalty identifier for the merchant.

[0063] The different embodiments mentioned above can be combined with each other for the implementation of the proposed technique. 4. Figures

[0064] Other features and advantages of the invention will become clearer upon reading the following description of a preferred embodiment, given by way of simple illustrative and non-limiting example, and the accompanying drawings, among which: there figure 1 illustrates the main steps in a loyalty ID management process, according to a specific implementation; the figures 2 And 3 present two sequence diagrams showing the main steps of a loyalty identifier management process and a loyalty data processing process, according to two specific embodiments; the figure 4 describes a simplified architecture of a loyalty ID management server capable of implementing a loyalty ID management process, according to a particular embodiment; the figure 5describes a simplified architecture of a transaction device capable of implementing a loyalty data processing method, according to a particular embodiment. 5. Description 5.1. General principle

[0065] The general principle of the proposed technique is to associate, for a given user, a unique, general loyalty identifier with the loyalty programs of different merchants. This association, as well as the subsequent updating of the general loyalty identifier, is implemented by a loyalty identifier management server.

[0066] The proposed technique therefore allows the implementation of a centralized system for managing a plurality of specific loyalty programs for a user, via a general loyalty identifier.

[0067] Thus, each time a user wishes to benefit from loyalty advantages linked to a specific loyalty program to which they have subscribed, they provide this general loyalty identifier instead of providing the appropriate specific loyalty identifier.

[0068] From a user's perspective, loyalty management is therefore greatly simplified, as the proposed technique optimizes the use of virtual loyalty cards, as described in relation to the prior art, by seamlessly grouping them "behind" a general loyalty identifier. For example, a dedicated loyalty application installed on the user's communication device can provide them with their general loyalty identifier, which they can then use when needed, regardless of the merchant involved.

[0069] According to a first aspect of the proposed technique, the management of a general loyalty identifier for a user is therefore implemented by a loyalty identifier management server, which is able to translate this general loyalty identifier of the user into a specific loyalty identifier previously associated, which can then be used by a merchant's transaction device for specific management of loyalty linked to that merchant.

[0070] According to a second aspect of the proposed technique, a merchant's transaction device is able to communicate with the loyalty ID management server, to transmit to it the general loyalty ID provided by a user and to receive in return the specific loyalty ID of that user for the merchant in question, in order to then manage the specific loyalty program of the user for that merchant.

[0071] Finally, according to a third aspect of the proposed technique, a dedicated loyalty application installed on a user's communication terminal (for example, a smartphone, tablet, or computer) can provide them with an interface allowing them to centrally manage their various loyalty programs, configure their loyalty profile, etc. According to this third aspect, this dedicated application is also able to communicate with the loyalty ID management server, firstly to request the creation / generation of the general loyalty ID for the user and, secondly, to update this general loyalty ID of the user with the various specific loyalty programs of the user, via specific loyalty IDs.

[0072] These three aspects of the proposed technique are described in detail below. 5.2. Loyalty ID Management Process

[0073] From one perspective, the proposed technique relates to a loyalty ID management process, implemented in a loyalty ID management server, the main steps of which are illustrated in Figures 1 And 2 , in a particular embodiment.

[0074] This loyalty ID management process begins with an initialization phase, during which a user's general loyalty ID U1 is created / generated. Thus, during generation step 11, the loyalty ID management server generates (for example, in a database, which can be manipulated / managed using a software library, or in a flat file (Text or XML)) a general loyalty ID ID_Gen_U1, associated with a previously identified user U1.

[0075] This initialization phase can be triggered at the user's request, via their communication terminal, as illustrated in figure 2 .

[0076] Thus, according to this embodiment, the loyalty identifier management server SIF receives a Req request (U1) for generating a general loyalty identifier from the user's communication terminal U1, the request including at least one piece of information allowing the user to be identified U1 (for example, a name, surname, nickname, etc.). For example, this request is issued via a dedicated application. APP installed on the user's communication terminal, allowing the user to have an interface for managing their loyalty data.

[0077] The general loyalty identifier is then updated, during one or more successive update steps 12, to associate it with one or more specific user loyalty identifiers: ID_A_U1 for merchant A, ID_B_U1 for merchant B, ID_C_U1 for merchant C.... In this way, these specific loyalty identifiers are accessible from a single "entry point" consisting of the general loyalty identifier, which can be enriched with other specific loyalty identifiers as these updates occur.

[0078] These update steps can also be triggered at the user's request, via their communication terminal, either simultaneously with the generation of a general loyalty identifier, or subsequently, as illustrated in figure 2 .

[0079] Thus, according to this embodiment, the SIF loyalty ID management server receives one or more MAJ update requests ( ID_Gen_U1, ID_A_U1), UPDATE ( ID_Gen_U1, ID_B_U1), UPDATE ( ID_Gen_U1, ID_C_U1 ) .... of the general loyalty identifier ID_Gen_U1, from the user's communication terminal U1 (for example, via the application) APP). Each request includes at least the user's general loyalty identifier ID_Gen_U1 and the specific loyalty identifier of the merchant to be associated ID_A_U1, ID_B_U1, ID_C_U1...

[0080] There figure 2 illustrates three successive update steps, successfully completed by the loyalty ID management server SIF, which, for example, returns an "OK" to the application that originated the requests.

[0081] On the other hand, if the SIF loyalty ID management server could not implement the required update, either because the specific ID is already associated with the general ID, or because the general ID does not yet exist, a failure response may be sent by the loyalty ID management server to the application that originated the request (case not illustrated).

[0082] As previously described, a user's general loyalty identifier allows for simplified loyalty management, regardless of the specific loyalty program and therefore the merchant. This simplified management involves using this general loyalty identifier in all situations where the user must provide information identifying them as having joined a merchant's specific loyalty program.

[0083] For example, if a user wishes to benefit from the advantages of their loyalty program when making a purchase at a given merchant, they simply need to provide their general loyalty ID (using various methods described in more detail below). ID_Gen_U1 to the transaction device implementing this purchase. The transaction device needs a specific loyalty identifier from a user (for the merchant in question) to manage a specific loyalty program, the transaction device must obtain the specific loyalty identifier from the general loyalty identifier provided by the user.

[0084] To do this, and as illustrated in figure 2 , the transaction device implementing the purchase transmits the general loyalty identifier provided by the user, in a Req_A request ( ID_Gen_U1, ID_A), to the loyalty ID management server, in order to obtain in return, the user's specific loyalty ID for the merchant.

[0085] During step 13 of the search, the loyalty ID management server checks its database, for example, to see if a specific loyalty ID for the given user and merchant is associated with the general loyalty ID transmitted by the transaction device. To do this, the loyalty ID management server needs not only the general loyalty ID but also data that allows it to identify the merchant.

[0086] According to one variant, this merchant identification data is obtained via the request issued by the transaction device, which includes, for example, a merchant identifier. (ID_A), as illustrated in Figures 1 And 2 .The request may also include a transaction device identifier, or a transaction device public key, enabling the merchant associated with the transaction device to be uniquely identified.

[0087] According to a second variant, the loyalty ID management server can obtain the merchant identification data by means other than the request itself, such as via location information of the transaction device, obtained outside the request, which then allows, via means internal to the server, to uniquely identify the merchant associated with the transaction device.

[0088] Furthermore, the loyalty ID management server can recognize a specific loyalty ID from a merchant's identification data, for example, by converting the merchant's identification data into a loyalty ID with a predetermined format. Thus, search step 13 can include a substep for converting a merchant's identification data into a format that can be compared to specific loyalty IDs that might be associated with the user's general loyalty ID.

[0089] If a specific loyalty identifier for the given user and merchant is associated with the user's general loyalty identifier, the loyalty identifier management server responds to the transaction device's request by transmitting the specific loyalty identifier found (for example ID_A_U1), as illustrated in Figures 1 And 2 .

[0090] If, on the other hand, the loyalty ID management server did not find the specific loyalty ID for the given user and merchant during search step 13, the server returns a negative response (for example, " KO " to the transaction device.

[0091] According to variant implementations, the server can of course indicate the reason for the failure in its negative response, so that the transaction device can, if necessary, implement an appropriate action.

[0092] For example, the failure may be due to the fact that this specific loyalty identifier has not been previously associated with the user's general loyalty identifier (as illustrated by the figure 3 , described below), or the fact that the user's general loyalty identifier does not exist, or that the loyalty identifier management server failed to identify the merchant.

[0093] The loyalty ID management server, through its various implementations, enables centralized management of a user's unique identification data—known as specific loyalty IDs—across all loyalty programs they have joined, using a single general loyalty ID. This significantly simplifies loyalty management for the user, who no longer needs to search for program-specific data to access program benefits but simply provides their general loyalty ID. 5.3. Loyalty data processing method

[0094] According to a second aspect, the proposed technique therefore relates to a process for processing loyalty data, implemented in a merchant's transaction device, for example at the time of a purchase, according to a particular embodiment.

[0095] According to this embodiment, this process allows a user to benefit from advantages related to their membership in a specific loyalty program, for a given merchant, without having to provide data specific to this program but by using a general loyalty identifier (previously generated and updated according to the loyalty identifier management process described above).

[0096] Typically, the processing of loyalty data within a transaction device (such as an electronic payment terminal or a cash register) allows merchants to reliably and efficiently manage user payment information. This data processing must be carried out securely to prevent theft or misuse. Therefore, a merchant's transaction device has features designed to ensure the reliable and secure processing of this data. In practice, this loyalty data processing usually occurs after the transaction is confirmed, based on the data remaining in the terminal's possession (i.e., the data the terminal has stored securely in its memory).In addition, the transaction device typically communicates with a specific loyalty program management server associated with the merchant.

[0097] As previously described, the principle of using a general loyalty identifier (which greatly simplifies the management of users' various loyalty programs) relies on the transmission of this general loyalty identifier from a merchant's transaction system to a loyalty identifier management server. In return, the system retrieves the user's specific loyalty identifier for that particular merchant. Once this specific loyalty identifier is obtained, the transaction system can process this loyalty data in a standard way, for example, by communicating with a local server.

[0098] The first step, illustrated for example in figure 2 , Therefore, for the transaction system of a merchant A, this consists of obtaining this general loyalty identifier ID_GEN_U1 for the user U1 making a purchase.

[0099] This acquisition step can be implemented, for example, using the following different methods: The user provides their general loyalty identifier to the merchant: for example, the user has displayed their general loyalty identifier on their smartphone, via the dedicated loyalty application previously installed, and the merchant enters it manually or scans it into their transaction device. Manual entry can also be done by the user themselves. The general loyalty identifier can also take the form of a QR code, displayed for example on the user's smartphone and read by the transaction device; the user presents their smartphone near the transaction device and the transmission of their general loyalty identifier is implemented automatically, for example via the dedicated loyalty application previously installed on their smartphone communicating with the transaction device by contactless means (such as NFC) or very short range (Bluetooth);The transaction device automatically obtains the general loyalty identifier via a magnetic field emulation technique generated by a magnetic stripe card, allowing the transmission, along with the user's payment card information, of so-called secondary data intended, for example, to confirm, enrich or complete the payment transaction carried out (such as secondary data relating to the user's membership in a loyalty program of that brand, and more specifically their general loyalty identifier).

[0100] Thus, depending on the implementation variant, loyalty management can be made fully automatic for the user, making it optimal and efficient, both in terms of ergonomics and security, as the exchanges between the user's communication terminal and the transaction device can be secured (by techniques known in themselves and not detailed here).

[0101] Once this general loyalty identifier is obtained, the transaction device then sends a request, in a second step, to the loyalty identifier management server in order to obtain the specific identifier that allows it to manage the user's loyalty for the merchant in question. For example, as illustrated in figure 2 and already described previously, the Req_A query ( ID_Gen_U1, ID_A) also includes a merchant identifier (in the form of an identifier of the transaction device itself, a public key of this transaction device, or a standardized identifier of the merchant ....).

[0102] In return, the transaction device receives the required specific loyalty identifier and processes it, in a third processing step 22 which may include the following sub-steps: a step of transmitting the user's specific loyalty identifier to a specific loyalty program management server associated with the merchant, for example a local server intended to manage the merchant's loyalty programs for all its customers / users; a step of managing the response from the specific server, which can take the following classic forms: printing on the till receipt of the recognition of loyalty, displaying on the screen of the transaction device of the recognition of loyalty, printing a discount coupon, sending by SMS (or email or other) a discount coupon or promotional offers....

[0103] Thus, based on a general loyalty identifier provided by a user, the transaction device can implement a loyalty data management process allowing the user to benefit from the advantages offered by their membership in the merchant's loyalty program.

[0104] However, the request transmitted by the transaction device to the loyalty ID management server may fail, for various reasons described above.

[0105] The second embodiment, illustrated in figure 3 , This corresponds, for example, to one of these situations, in which a specific loyalty identifier for merchant D has not been previously associated with the user's general loyalty identifier. Thus, when merchant D's transaction system, at the time of a purchase made by the user U1, issues a Req_D request ( ID_Gen_U1, ID_D) in order to obtain a specific loyalty identifier, it receives a negative response from the loyalty identifier management server, indicating the reason for the failure.

[0106] The proposed method addresses this situation by offering an update to the user's general loyalty identifier, initiated by the transaction device (and no longer, as in the most frequent case described previously in relation to the figure 2 , initiated by a user communication terminal, via an application for example).

[0107] To do this, the transaction system obtains, during step 21, a specific loyalty identifier for the user. For example, this retrieval is implemented via the specific loyalty program management server associated with the merchant, which is able to create a specific identifier for a new member (i.e., the user).

[0108] This specific loyalty identifier is then transmitted to the loyalty identifier management server by the transaction device, along with the user's general loyalty identifier. For example, this transmission is carried out by issuing an update request (MaJ). ID_Gen_U1, ID_D_U1 ), as described previously in relation to the first embodiment.

[0109] A 12th update step is then implemented in the loyalty ID management server, as already described in relation to the first embodiment, with the difference that the update is not initiated by a user's communication terminal but by a merchant's transaction device. However, for the loyalty ID management server, the implementation is identical for this update; that is, it associates an additional specific loyalty ID with the general loyalty ID (which is now associated with four specific loyalty IDs for merchants A, B, C, and D, respectively).

[0110] Finally, after this update step, the loyalty ID management server communicates with the user's communication terminal, for example via the application. APPdedicated, to confirm the update of the user's general loyalty identifier. In this way, even if the application did not initiate this update, it is aware of it in order to provide the user with an up-to-date view of their loyalty.

[0111] It should be noted that this update of the user's general loyalty identifier, initiated by a merchant's transaction device, requires prior authorization from the user, since this general loyalty identifier is personal data whose use and update they must be able to control.

[0112] In one scenario, user authorization is required at the time of the update, or just before, when the transaction device receives a negative response from the loyalty account management server. For example, the user may be asked to confirm the update by entering information on the transaction device's keypad (such as pressing the OK key in response to a question), or verbally by the merchant, who will then confirm the user's agreement on their transaction device. In another scenario, the transaction device communicates with the user's communication terminal (using one of the methods described above), for example, via the loyalty application, and it is this application that requests user authorization (for example, via a specific screen displayed on the communication terminal).Once the authorization is confirmed by the user on their communication terminal, it is transmitted to the transaction device so that it can forward its update request to the loyalty ID management server. These means of communication between the transaction device and the user's communication terminal include, for example, those described above in relation to the transaction device obtaining the user's general loyalty ID, or any other means of communication allowing for secure transmission.

[0113] In a second scenario, the user has previously granted general authorization to update their general loyalty identifier, for example, by configuring their loyalty profile via the dedicated application installed on their communication device. The user can thus confirm that any update to their general loyalty identifier can be performed, whether initiated by their loyalty application or a merchant's transaction device, provided that the latter is authenticated, for example, using a public key or a unique identifier (according to established protocols). In this second scenario, this general update authorization can be, for example, an attribute of the general loyalty identifier, this attribute being created at the same time as the identifier or added later when the user chooses.This attribute can be understood, recognized, or decoded by the transaction device from the general loyalty identifier itself. In this way, the transaction device knows it does not need to request authorization from the user and can therefore directly transmit its update request to the loyalty identifier management server.

[0114] In parallel, the transaction device can implement a processing step 22 (already described above and not detailed again here) of the specific loyalty identifier obtained, in order to allow the user to benefit from the advantages linked to their membership in the merchant's loyalty program.

[0115] Thus, according to this second embodiment, the transaction system can implement, using a general loyalty identifier provided by a user, a loyalty data management process that allows the user to benefit from the advantages offered by their membership in the merchant's loyalty program, even if this membership takes place at the time of the transaction. A user's membership in a loyalty program can therefore be taken into account simply and instantly at the time of purchase. 5.4. Loyalty app

[0116] As already described above in relation to the two embodiments of the proposed technique, the user can install an application dedicated to managing their loyalty programs on their communication terminal.

[0117] Such a communication terminal can, for example, be a smartphone or tablet type communication terminal, a dedicated standalone electronic device, or an electronic device intended to be coupled to a communication terminal (the electronic device can then, for example, be integrated into a protective case of the communication terminal).

[0118] Such an application can notably be an electronic wallet type application (also called a " wallet » (in English), which notably allows the storage of information associated with several cards as well as additional information.

[0119] Through this application, the user has the option to choose the payment information to use for a payment transaction on a case-by-case basis. They also have the option to configure "default" payment information, which will be the data used by default for a payment transaction (unless the user specifies otherwise).

[0120] Through this application, the user can therefore also, according to the proposed and already described technique, create a general loyalty identifier, on the basis of which a loyalty identifier management server is able to find a specific loyalty identifier of the user to be used in the context of a given payment operation.

[0121] The user can also update this general loyalty identifier, via this dedicated application, when they wish, for example, to add a new specific loyalty program, such as a new physical loyalty card, whose barcode they can scan to integrate it into the centralized management of their loyalty via the application, or a specific loyalty identifier obtained following membership in a merchant's loyalty program.

[0122] This application also allows the user to create and update a loyalty profile, for example to confirm a general betting authorization as described above in relation to the second embodiment. 5.5. Other features and benefits

[0123] We describe, in relation to the figure 4 , a loyalty ID management server including means for executing a loyalty ID management process, described above in relation to particular embodiments.

[0124] For example, the loyalty ID management server includes a memory 41 consisting of a buffer, a processing unit 42, equipped, for example, with a microprocessor, and controlled by the computer program 43, which implements, in particular, a loyalty ID management process. At initialization, the code instructions of the computer program 43 are, for example, loaded into memory before being executed by the processor of the processing unit 42. The processing unit 42 receives, for example, as input E at least one request to generate a general loyalty ID for a previously identified user. The microprocessor of the processing unit 42 then implements the steps of the loyalty ID management process, according to the instructions of the computer program 43, in order to generate, as output S, a general loyalty ID for the user in question.

[0125] For this purpose, the loyalty ID management server includes, in addition to buffer 41, means, for example in the form of one or more modules, for generating a general loyalty ID for a previously identified user.

[0126] All of these means / modules can take the form of a specific processor implemented within the loyalty ID management server, said processor being a secure processor, capable of processing data of a confidential nature, such as payment method data or bank authentication tokens.

[0127] The proposed technique also relates to a transaction device enabling the execution of a loyalty data processing method described previously, according to specific embodiments. Such a transaction device is described in particular in relation to the figure 5in a particular embodiment, and it includes the following means, for example in the form of modules: means of obtaining, from a user, a general user loyalty identifier; means of sending, to a loyalty identifier management server, a request to obtain a specific user loyalty identifier for the merchant, the request including at least the user's general loyalty identifier; means of receiving, from the loyalty identifier management server, a response to the request and, if said response includes the user's specific loyalty identifier for the merchant: means of processing at least one loyalty data associated with the user's specific loyalty identifier for the merchant.

[0128] For example, the transaction device includes a memory 51 consisting of a buffer, a processing unit 52, equipped, for example, with a microprocessor, and controlled by the computer program 53, which implements, in particular, a loyalty data processing method. At initialization, the code instructions of the computer program 53 are, for example, loaded into memory before being executed by the processor of the processing unit 52. The processing unit 52 receives, for example, as input E, a general loyalty identifier for the user. The microprocessor of the processing unit 52 then implements the steps of the loyalty data processing method, according to the instructions of the computer program 53, so as to generate, as output S, loyalty benefits for the user in question.

[0129] To this end, the transaction device includes, in addition to buffer 51, means for transmitting and receiving data, which may take the form of an interface for connecting to one or more communication networks. These means may also allow for establishing a link with partner servers for managing loyalty programs. The payment terminal may also include cryptographic calculation means, enabling it to verify the authenticity of received data by comparing the result of a cryptographic calculation with an authentication token.

[0130] The embodiments described above in the context of the present invention are combinable. They are given by way of illustrative and non-limiting examples, in order to best illustrate the general principle of the invention. Other embodiments may, of course, be implemented within the scope of the present invention.

Claims

1. A method for managing loyalty identifiers, implemented in a loyalty identifier management server (SIF) and comprising an initialisation phase including a step (11) of generating a unique general loyalty identifier (ID_Gen_U1) for a previously identified user (UI, said general loyalty identifier (ID_Gen_U1) being associated with a plurality of specific loyalty programmes of said user (UI and the following steps: • receiving, from a transaction device associated with a merchant, a request to obtain a specific loyalty identifier for said user for said merchant, said request to obtain comprising said general loyalty identifier of said user; • obtaining at least one piece of identification data for said merchant, said identification data being location information for said transaction device; • searching (13), based on said merchant identification data and said user's general loyalty identifier, for said user's specific loyalty identifier for said merchant: ∘ if the search is successful, transmitting, to said transaction device, a response comprising said user's specific loyalty identifier for said merchant; ∘ if said search is unsuccessful, transmitting a negative response to said transaction device.

2. A method for managing loyalty identifiers according to claim 1, characterised in that said initialisation phase also comprises the following steps, respectively before and after said generation step: • receiving, from a communication terminal of said user, a request to generate a general loyalty identifier associated with said user, said generation request comprising at least one piece of identification data relating to said user; • transmitting, to said user's communication terminal, a response comprising said generated general loyalty identifier.

3. A method for managing loyalty identifiers according to claim 1, characterised in that it further comprises a step of transmitting, to said user's communication terminal, information representing said updated general loyalty identifier.

4. A method for managing loyalty identifiers according to any one of claims 1 to 3, characterised in that it further comprises the following steps: • obtaining authorisation from said user to update said general loyalty identifier; • receiving, from a merchant's transaction device, a request to update said user's general loyalty identifier, said update request comprising said user's general loyalty identifier and at least one specific loyalty identifier of said user for said merchant; • updating (12) said general loyalty identifier by associating said at least one specific loyalty identifier of said user for said merchant with said general loyalty identifier of said user.

5. A method for processing loyalty data, the method being implemented in a merchant's transaction device, comprising the following steps: • obtaining, from a user, a general loyalty identifier of said user, said general loyalty identifier being associated with a plurality of specific loyalty programmes of said user; • sending, to a loyalty identifier management server, a request to obtain a specific loyalty identifier of said user for said merchant, said request comprising at least said user's general loyalty identifier and at least one piece of identification data relating to said merchant, said identification data being location information relating to said transaction device; • receiving, from said loyalty ID management server, a response to said request for obtaining and, if said response includes said user's specific loyalty ID for said merchant: • processing (22) of at least one loyalty data item associated with said user's specific loyalty identifier for said merchant.

6. A method for processing loyalty data according to claim 5, characterised in that it comprises the following steps, if said response is negative: • obtaining a predetermined general authorisation from said user to update said general loyalty identifier; • obtaining (21) a specific loyalty identifier of said user for said retailer; • sending, to said loyalty identifier management server, a request to update said user's loyalty identifier, said update request comprising said user's general loyalty identifier and said user's specific loyalty identifier for said retailer; • processing (22) of at least one loyalty data item associated with said user's specific loyalty identifier for said retailer.

7. A method for processing loyalty data according to any one of claims 5 and 6, characterised in that said steps of obtaining a specific loyalty identifier of said user for said merchant and of processing are implemented via a specific loyalty programme management server associated with said merchant.

8. A method for processing loyalty data according to claim 6, characterised in that said step of obtaining a general loyalty identifier of said user is implemented via means of communication with a communication terminal of said user belonging to the group comprising: • NFC; • Bluetooth; • MST (magnetic stripe emulation).

9. A loyalty identifier management server comprising means for generating a general loyalty identifier (ID_Gen_UI) for a previously identified user (UI, said general loyalty identifier (ID_Gen_UI) being associated with a plurality of specific loyalty programmes of said user (UI, and the following means: • means for receiving, from a transaction device associated with a merchant, a request to obtain a specific loyalty identifier for said user for said merchant, said request to obtain comprising said general loyalty identifier of said user; • means for obtaining at least one piece of identification data relating to said merchant, said identification data being location information relating to said transaction device; • means for searching (13), based on said identification data of said merchant and said general loyalty identifier of said user, for said user's specific loyalty identifier for said merchant: ∘ if the search is successful, transmission to said transaction device of a response comprising said user's specific loyalty identifier for said merchant; ∘ if said search is unsuccessful, transmission to said transaction device of a negative response.

10. A transaction device comprising: • means for obtaining, from a user, a general loyalty identifier of said user, said general loyalty identifier being associated with a plurality of specific loyalty programmes of said user; • means for sending, to a loyalty identifier management server, a request to obtain a specific loyalty identifier of said user for said retailer, said request for obtaining comprising at least said user's general loyalty identifier and at least one piece of identification data for said merchant, said identification data being location information for said transaction device; • means for receiving, from said loyalty identifier management server, a response to said request for obtaining, and if said response includes said user's specific loyalty identifier for said retailer: • means for processing at least one loyalty data item associated with said user's specific loyalty identifier for said merchant.

11. A computer program product downloadable from a communication network and / or stored on a computer-readable medium and executable by a microprocessor, characterised in that it comprises program code instructions for executing a method according to any one of claims 1 to 4, when executed on a computer.

12. A computer program product downloadable from a communication network and stored on a computer-readable medium and / or executable by a microprocessor, characterised in that it comprises program code instructions for executing a method according to any one of claims 5 to 8, when executed on a computer.