FIELD OF THE INVENTION

The present invention relates to a system for identifying a customer, a method for identifying a customer, and a related computer program and computer program product.

BACKGROUND

With conventional means of identifying a customer, for example based on a loyalty card specific to a particular store or common to a cooperation of multiple different stores, the holder of the loyalty card can in principle be any person. In fact, in practice, the holder of such a loyalty card is often not the same person as the person to whom the loyalty card was originally issued, because loyalty cards are often shared among family members or friends, or are even shortly lent out by a cashier of a shop who wishes to be helpful to the customer. This situation may lead to confusion as to the identity of a customer, when the customer uses such a traditional loyalty card.

Alternatively, the customer may identify himself using a unique identification, e.g. a combination of a name and an address of the customer. However, this approach is cumbersome for the customer, is not resilient in case the customer moves to a different address (or changes his name), is not in line with privacy in case bystanders may be eavesdropping, and may require that the user spell out (parts of) his name to a cashier, which takes effort for both parties and is time-consuming.

In another known approach, the customer may identify himself using a payment of “zero” cost. In this context, “zero” is put between quotation marks, because the real cost is not zero - it only appears to be zero to the customer in first instance. In this approach, which is for example used by various public transport agencies, a customer identifies himself by executing a payment using a payment card that has previously been linked to the customer’s subscription at such public transport agencies. The payment is made for a total of “zero”, i.e. seemingly for a net amount of 0.00 expressed in e.g. euros or any other currency. Therefore, the customer is under the impression that this approach of identifying is free (gratis). This approach will be called the zeropayment approach below.

SUMMARY OF THE INVENTION

However, it is an insight of the inventors that the zero-payment approach of identifying a customer is actually disadvantageous for the agency instituting the zero-payment approach and is also, indirectly, disadvantageous for the customer. One reason for this is that the execution of an actual payment, even if only for a net amount of 0.00, in reality does impose a cost, which may be very small for each separate customer identifying himself but which may become non-negligible for the agency as a whole. Moreover, the agency is then forced, by economics, to indirectly charge this non- negligible cost to (all) its customers, which represent a disadvantage to the customers.

Moreover, another reason for the zero-payment approach being disadvantageous is that it requires certified hardware equipment as well as certified software, because actual payments are involved. This again results in a cost for the instituting agency and thus indirectly also for the customer.

It is therefore an aim of embodiments of the present invention to overcome these problems. In particular, it is an aim of embodiments of the present invention to allow to identify a customer in a cost-efficient and easy yet reasonably secure manner. It is a further aim of at least some embodiments of the present invention to help in combatting identity fraud. Moreover, it is an aim of at least some embodiments of the present invention to reduce the demands placed on the payment systems of a merchant. Furthermore, it is an aim of at least some embodiments of the present invention to be resilient against interruptions of the identification process.

Therefore, the present invention provides a system for identifying a customer, comprising:

- a reader configured for: - establishing an EMV-based or EMV-compatible connection with a payment means of the customer;

- detecting a customer identification code from the payment means; and

- halting the connection; and

- an interface configured for providing the detected customer identification code to an identification client accepting an identification of the customer; wherein the reader is configured for halting the connection if the customer identification code has been detected.

The present invention is at least in part based on the insight of the inventors that using the payment means of the customer may be useful to allow to identify the customer in a cost-efficient and easy yet reasonably secure manner, because the payment means is already in the possession of the customer and is moreover likely to be used subsequently by the customer to pay, and because there is a generally agreed upon consensus that a customer’s payment means is securely linked to the customer’s identity.

Moreover, especially compared to the above-described zero-payment approach, at least some embodiments according to the present invention allow to identify a customer without needing to effect an actual payment. Therefore, there is no need to suffer the costs, even if they are very minor, of effecting payments. Thus, these embodiments reduce costs for any agency operating the system and, indirectly, also reduce costs for customers of those agencies. Moreover, by avoiding the need to effect an actual payment, these embodiments allow identification even without certified hardware and certified software, thus further reducing costs.

Yet another advantage of at least some embodiments according to the present invention is if it is desired to identify the customer before - as opposed to after - the customer pays for the transaction, in order to take into account the user’s identity and e.g. any benefits, vouchers, etc. still outstanding for the user into the transaction conditions. Known approaches wherein the customer is identified only after paying for the transaction suffer from the problem that the transaction can therefore not be personalised and cannot take into account the identity of the customer. T ranslated into a technical problem, this corresponds with the problem of identifying the customer prior to the customer paying for the transaction. Compared with known approaches, wherein the customer has to identify himself using another identification means, such as customer loyalty card, a QR card, etc., prior to paying with his payment means, the customer is required to carry multiple means. In contrast, at least some embodiments according to the present invention solve these problems, because they allow to identify the customer before the payment using only the payment means. Therefore, the user’s identity can be taken into account into the transaction conditions.

Note that in the context of the present disclosure the expression “a financial institution issuing a payment means” may mean that the financial institution issued the payment means, i.e. issued the entire means, but may also instead have a more specific meaning, namely that the financial institution issued a software certificate embodied on the payment means, even if the payment means was produced by another party, e.g. a smartphone producer. Because the financial institution issued the relevant element embodied by the payment means even in this latter situation, the expression “a financial institution issuing payment means” will be clear to the skilled person.

Note that the abbreviation EMV originally stood for "Europay, Mastercard, and Visa", the three companies which created the standard. Currently, there are the standards ISO/IEC 7816 for contact cards, and ISO/IEC 14443 for contactless cards. It is at present common to refer to these ISO/IEC standards as “the EMV standards” and to procedures or product conforming to these ISO/IEC standards as “EMV-based” or “EMV-compatible” procedures or products, even though the historical link to the three original companies has now been rendered less relevant.

It is considered advantageous if the payment means conforms with at least one of ISO/IEC 7816 (for contact cards) and ISO/IEC 14443 (for contactless cards), in order to benefit from a soft guarantee of the financial institution issuing the payment means (or a software certificate on the payment means, in the case of a smart device) that the holder of the payment means can be assumed to be the owner of the payment means. This is under the viable assumption that, in practice, such payment means are not or only rarely shared among different people, especially among friends or strangers, because such payment means are typically used in conjunction with a PIN code, which is typically not shared with other people.

Therefore, because the payment means already offer a soft guarantee from a financial institution issuing the payment means (or a software certificate on the payment means, e.g. in the case of a smart device) that the holder of the payment means can be assumed to be the owner of the payment means, embodiments of the present invention allow to identify a customer in a reasonably secure manner. In this way, they may also help in combatting identity fraud.

Moreover, because a customer typically intends to use their payment means for effecting a payment in the store anyway, having to present the payment means is likely considered easy and does not appear as a hindrance to the customer.

Furthermore, because a customer already owns a payment means (because a customer by definition buys and thus has to pay for goods and/or services), there is no need for the store to provide costly loyalty cards and dedicated hardware and/or software for reading such loyalty cards, nor is there any need for the store owner to provide a customer information system which may be subject to stringent security and privacy demands and which may therefore be costly to install and maintain. In this way, the solution is cost-efficient for the store.

Moreover, by halting the connection if the customer identification code has been detected, at least some embodiments of the present invention allow to reduce the demands placed on the payment systems of a merchant. This is because such embodiments do not require that the connection (and thus the demands placed on the payment systems of the merchant) is maintained any longer than is deemed necessary for the purposes of identifying the customer.

This has the additional benefit of making such embodiments more resilient against interruptions of the identification process, because the only communication step that is required between the reader and the payment means is the step of detecting the customer identification code. If, after this step, the communication process were to be interrupted, e.g. if the reader were to experience a malfunction in the connection or if payment means were to be removed abruptly, this is unlikely to hinder the method of such embodiments.

Preferably, the reader is configured for inhibiting further communication via the connection after the customer identification code has been detected.

In this way, it can be guaranteed that no time or resources are wasted.

Preferably, the reader is configured for the inhibiting of further communication via the connection after the customer identification code has been detected, except for communication required for halting the connection.

In this way, it can be guaranteed that the connection is halted correctly, while minimising the amount of time or resources wasted.

Preferably, the connection conforms with at least one of ISO/IEC 7816 and ISO/IEC 14443, and the reader is configured for, when establishing the connection, verifying that the payment means supports the connection.

In this way, it is possible to benefit from the guarantees provided by the cited ISO standards regarding authenticity and identification.

Preferably, the customer identification code is a primary account number, PAN (EMV Tag 5A).

Preferably, the reader is configured for halting the connection as soon as the reader has detected the customer identification code.

In this way, the above-described benefit of reducing the demands placed on the payments systems of the merchant and the above-described benefit of improving resilience against interruptions is achieved more strongly, because the connection is halted without idling. Preferably, the reader is configured for halting the connection upon completing the following steps:

- decoding any SFI records on the payment means;

- decoding an Application Label comprising an ApplicationlD, also known as EMV tag 50, from the payment means;

- decoding any optional processing options from the payment means;

- decoding an Application File Locator, also known as EMV tag 94, from the payment means.

Preferably, the reader is configured for halting the connection subject exclusively to a condition that the reader has detected the customer identification code.

In this way, the above-described benefit of reducing the demands placed on the payments systems of the merchant and the above-described benefit of improving resilience against interruptions is achieved more strongly, because the connection is halted if the reader has detected the customer identification code and without regard to any other conditions.

Preferably, the reader is configured for ignoring or discarding any other information on the payment means when detecting the customer identification code from the payment means. Alternatively, the reader is configured for detecting any one or more of the following information together with detecting the customer identification code: a payment means expiry condition (EMV Tag 5F 24); a state of issuance of the payment means (EMV Tag 5F 28); a preferred currency of the payment means (EMV Tag 9F 42); a type of the payment means (EMV Tag 50); and a preferred user language of the payment means (EMV Tag 5F 2D).

Preferably, the reader is configured for halting the connection prior to the interface providing the detected customer identification code to the identification client.

In this way, the above-described benefit of reducing the demands placed on the payments systems of the merchant and the above-described benefit of improving resilience against interruptions is achieved more strongly, because the connection is halted prior to expending time and effort to establish a connection through the interface for providing the detected customer identification code.

Furthermore, the present invention also provides a method for identifying a customer, comprising:

- establishing an EMV-based or EMV-compatible connection with a payment means of the customer;

- detecting a customer identification code from the payment means via the connection;

- halting the connection;

- providing the detected customer identification code to an identification client accepting an identification of the customer; wherein the connection is halted if the customer identification code has been detected.

Note that the method may be initiated when the customer presents his payment means to the reader, in which case the identification client is implicitly accepting or accepting the customer identification code, but alternatively the method may be initiated based on an explicit request of the identification client or another entity.

The skilled person will understand that analogous considerations and advantages apply for the method as for the above-described system, mutatis mutandis.

Preferably, the method comprises inhibiting further communication via the connection after the customer identification code has been detected.

Preferably, the inhibiting of further communication via the connection after the customer identification code has been detected exceptionally allows communication required for halting the connection.

Preferably, the connection conforms with at least one of ISO/IEC 7816 and ISO/IEC 14443, and the method comprises, when establishing the connection, verifying that the payment means supports the connection. Preferably, the customer identification code is a primary account number, PAN (EMV Tag 5A).

Preferably, the connection is halted as soon as the customer identification code has been detected.

Preferably, the connection is halted upon completing the following steps:

- decoding any SFI records on the payment means;

- decoding an Application Label, comprising an ApplicationlD, also known as EMV tag 50, from the payment means;

- decoding any optional processing options from the payment means;

- decoding an Application File Locator, also known as EMV tag 94, from the payment means.

Preferably, the connection is halted subject exclusively to a condition that the reader has detected the customer identification code.

Preferably, the method comprises ignoring or discarding any other information on the payment means when detecting the customer identification code from the payment means; or comprises detecting any one or more of the following information together with detecting the customer identification code: a payment means expiry condition (EMV Tag 5F 24); a state of issuance of the payment means (EMV Tag 5F 28); a preferred currency of the payment means (EMV Tag 9F 42); a type of the payment means (EMV Tag 50); and a preferred user language of the payment means (EMV Tag 5F 2D).

Preferably, the connection is halted prior to the interface providing the detected customer identification code to the identification client.

Furthermore, the present invention also provides a computer program comprising instructions configured for, when executed by at least one processor, performing the method of any one of the embodiments described above. Furthermore, the present invention also provides a computer program product comprising computer-readable means storing the computer program described above.

The skilled person will understand that analogous considerations and advantages apply for the computer program and the computer program product as for the abovedescribed system, mutatis mutandis.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be more fully understood with the help of the examples described below and the appended drawings, in which:

Figure 1 schematically illustrates an embodiment of the system according to the present invention;

Figure 2 schematically illustrates an embodiment of the system according to the present invention;

Figure 3 schematically illustrates another embodiment of the system according to the present invention;

Figure 4 illustrates a flowchart of an embodiment of the method according to the present invention; and

Figure 5 illustrates a flowchart of another embodiment of the method according to the present invention.

DETAILED DESCRIPTION

Figure 1 schematically illustrates an embodiment of the system according to the present invention. The figure shows system 10, comprising reader 11 and interface 12. The reader 11 is configured for establishing an EMV-based or EMV-compatible connection with a payment means of the customer (not shown in this figure). The reader 11 is further configured for detecting (which in itself may comprise reading out and optionally processing) a customer identification code from the payment means via the connection. The reader 11 is further configured for halting the connection. The interface 12 is configured for providing the detected customer identification code to an identification client (not shown in this figure) accepting an identification of the customer. The reader 11 is configured for halting the connection if the customer identification code has been detected.

Examples of customer identification codes may include the primary account number (PAN, EMV Tag 5A), which is at present the preferred option, the cardholder name (EMV Tag 5F 20), the international bank account number (IBAN, EMV Tag 5F 53), the unique serial number “baked into” the smartcard embodying the payment means, or any other suitably unique identification code. Note that complete uniqueness is not necessarily required for some applications, which may accept or which may otherwise compensate for colliding identification codes. Furthermore, it is preferred to select as customer identification code a code that is guaranteed to be present on all EMV- compatible payment means - contrast this for instance with the IBAN, EMV Tag 5F 53, which is not guaranteed to be present on all EMV-compatible payment means.

Figure 2 schematically illustrates an embodiment of the system according to the present invention. The embodiment of Figure 2 corresponds with the embodiment of Figure 1 and therefore shares several reference signs with it. Figure 2 further shows payment means 21 and identification (ID) client 22. Figure 2 shows the connection established by the reader 11 with the payment means 21 in order to detect from the payment means the customer identification code. Figure 2 further shows the connection between the interface 12 and the ID client 22, used for providing the detected customer identification code to the ID client 22.

Examples of suitable payments means may include: classic credit cards with a magnetic stripe, credit cards with an embedded integrated circuit having contact points, modern contactless credit cards having a contactless electromagnetic communication element, such as an antenna, for example adapted for Near Field Communication, Bluetooth and/or other types of wireless electromagnetic communication. Examples of the latter include Mastercard Contactless, Visa PayWave, and American Express ExpressPay. Additionally, examples of EMV-based payments means comprise smart devices, such as smartphones, smartwatches, or other wearables, configured for supporting wireless payment. Figure 3 schematically illustrates another embodiment of the system according to the present invention. The embodiment of Figure 3 may for example be a further developed embodiment of the embodiments of Figure 1 or Figure 2 and therefore shares several reference signs with them. Figure 3 further shows processor 31 and memory 32. In certain embodiments such as this further developed embodiment, it may be practical to store instructions for operation on the memory 32, to be run by the processor 31 , in order to have the system 10 operate as intended. This is schematically illustrated by connecting the processor 31 and the memory 32 to a bus that is also connected to the reader 11 and the interface 12.

It is in general preferred that the interface 12 is configured for providing the customer identification code to the ID client 22 using a suitable method of encryption, e.g. TLS encryption, to further improve security, in particular in view of a potential man-in-the- middle attack. It will be apparent to the skilled person that there may exist multiple ways of implementing such a suitable method of encryption of the customer identification code, and it is left to the skilled person to determine the most suitable method for any practical implementation.

It will be understood that processor 31 may be of any suitable type of processor, e.g. a CPU, or another piece of dedicated hardware. Processor 31 may optionally be housed remotely from reader 11. Analogous considerations apply for memory 32, which may be of any suitable type of memory and which may optionally be housed remotely from reader 11 and/or remotely from processor 31.

Figure 4 illustrates a flowchart of an embodiment 100 of the method according to the present invention. The method may be performed by e.g. system 10 of the Figures 1- 3, and the method comprises the following steps:

Optional step 101 is receiving a request from an ID client, e.g. ID client 22 of the Figures 1-3. Note that this step is optional, and that the method may commence simply by establishing a connection in step 102.

Step 102 is establishing a connection with a payment means of the customer. Optional step 103 is verifying that the payment means supports the connection, in particular whether or not the connection conforms with at least one of ISO/IEC 7816 and ISO/IEC 14443.

Step 104 is detecting a customer identification code (CIO) from the payment means via the connection.

Step 105 is checking that the customer identification code has been detected and, if so, advancing to step 106.

Step 106 is halting the connection.

Optional step 107 is inhibiting further communication via the connection after the customer identification code has been detected.

Step 108 is providing the detected customer identification code to an identification client accepting an identification of the customer.

Optionally, it is not necessary to wait to provide 108 the customer identification code to the identification client until after halting 106 the connection and the optional step 107, but the customer identification code may be provided 108 to the identification client immediately after it has been detected, preferably in parallel 109 with halting 106 the connection, in order to save time and resources.

Figure 5 illustrates a flowchart of another embodiment 200 of the method according to the present invention. The method comprises the following steps:

Step 201 : Offer the payment means to a reader, e.g. reader 11 of Figures 1-3. An ATR response is received, and the response can optionally be checked to verify if it actually is a EMV-based or EMV-compatible payment means. These steps establish the connection.

Step 202: Request: Read datafile “1 PAY.SYS.DDF01” if contact-based or datafile “2PAY.SYS.DDF02” if contactless.

Response: Decode received tags and store them.

Optional step 203 is not necessary if the payment means is contactless: Request: Read SFI records.

Response: If valid responses are received, decode and store received Tag values. Note that a tag is an entity consisting of a key which is a hexadecimal integer and a data section which has a variable length of data.

Step 204: Select ApplicationlD

Request: Select ApplicationlD, which can be extracted from previously found Tags.

Response: Receive tags, decode and store them.

Step 205: Get processing options, by reading PDOL register.

Request: Processingoptions.

Response: Receive tags, decode and store them.

Step 206: Read records according to ApplicationFileLocater

Request: Read the relevant registers.

Response: Receive tags, decode and store then.

Step 207: Process what has been received, to find the tags that contain the data of interest and decode the content in the desired format.

Step 208: Halt the connection to disable communication with the payment means.

It will be understood that the above-described embodiments are to be construed only as examples of the present invention, whose scope is determined by the independent claims. The skilled person will understand that further modifications may be made to these embodiments without departing from that scope.