Patent Description:
With devices such as mobile phones, it is become possible to perform payment using "virtual payment cards", i.e. dematerialized credit/debit cards stored into a "digital wallet" (also called "e-wallet") installed on a memory of the device.

More precisely, a digital wallet comprises:.

Nowadays, digital wallets have gained popularity and are used to store more and more types of virtual cards, and not only payment cards. In particular, digital wallets now support loyalty cards, health cards, ID cards, etc., for use in any interaction (not only transactions) between electronic devices on which the digital wallets are installed and terminals providing services to these electronic devices, such as contactless redeeming of a coupon using a loyalty card before paying in a store, or contactless access control for entering an area, for instance.

However, when there are too many virtual cards in the digital wallet, the users can have trouble finding the correct virtual card to use for a specific interaction with a terminal.

In order to select the correct virtual card, it is known from the prior art (see for instance the document <CIT>) to use "contextual" criterions, such as the location of the interaction, the payment amount when it concerns a transaction, credit limitation associated with a credit card, etc..

To this end, some contextual information has to be downloaded from a server (for instance to check credit limitation associated with a credit card) and is used as an input to context-based rules which are created on a server, then retrieved by the device to be applied therein. Furthermore, some contextual criterions are not supported by standard protocols, so that modifications of protocols have to be performed for exchanging data between the device and the reader, in order to add the contextual information in this data exchange.

This solution requires thus changing the reader hardware and software as well as implementing a dedicated client-server connection in order to download the context-based rules, which is too complex. Furthermore, contextual criterions are sometimes not sufficient to select the right card (for instance the location may not be precise enough).

<CIT> and <CIT> are related pieces of prior art but both do not disclose, at least, the characterizing feature of claims <NUM> and <NUM>.

There is therefore a need for improving the selection of a virtual card in a digital wallet so as to reach an efficient, simple and universal solution.

For these purposes, the present invention provides a method for operating an electronic device storing a plurality of virtual cards in a digital wallet according to claim <NUM>, an electronic device according to claim <NUM>, a computer program product according to claim <NUM>, and a computer-readable medium according to claim <NUM>.

The above and other objects, features and advantages of this invention will be apparent in the following detailed description of an illustrative embodiment thereof, which is to be read in connection with the accompanying drawings wherein:.

The present invention relates to a method for operating an electronic device <NUM> as represented by <FIG>.

As explained, the electronic device comprises a processing unit <NUM>, i.e. a CPU (including one or more processors), and a memory <NUM> (for example a flash memory).

The electronic device <NUM> typically comprises a user interface <NUM> which generally includes a screen (possibly touch sensitive), a loudspeaker, etc. In a preferred embodiment, the electronic device <NUM> is provided with a contactless communication unit <NUM>, for proximity wireless connection, in particular a NFC unit (or any other short range radio communication technology).

The electronic device <NUM> also typically comprises a battery for powering the processing unit <NUM> and other units, another communication unit for connecting (in particular wirelessly) the electronic device <NUM> to a network <NUM> (for example WiFi, Bluetooth, and preferably a mobile network, in particular a GSM/UMTS/LTE network), etc..

This electronic device <NUM> is typically a smartphone, a tablet computer, a laptop, etc. In the following description the example of a smartphone will be used as they are massively used for digital wallets, but the present invention is not limited to this embodiment.

The electronic terminal <NUM> stores, as explained, a plurality of virtual cards in a digital wallet. In practice, the digital wallet is a software executed by the processing unit <NUM>, and data of the virtual cards is stored by the memory <NUM>, generally in encrypted form, for being used by the digital wallet.

The "virtual cards" may be of various types (payment card, loyalty card, health card, ID card, etc.). The virtual card may be a copy of a physical smart card (with the same credentials), or may exist only under virtual form. By "physical smart card", it is meant a card typically made of plastic with an embedded integrated circuit. In the case of a virtual card, the processing unit <NUM> of the electronic device <NUM> mimics this integrated circuit.

When performing the present method, the electronic device <NUM> is connected to a terminal <NUM> in view of an interaction. Terminal <NUM> is typically a merchant terminal dedicated to a specific kind of interaction with similar electronic device and/or physical smart cards suitable for this interaction. In particular, the interaction is typically transaction/payment but it could be any other action between the electronic device <NUM> and the terminal <NUM> implying a card, for instance authentication.

The interaction is to be performed using a virtual card of said plurality of virtual cards stored in the digital wallet, and more precisely a virtual card suitable for said interaction. By suitable, it is meant a card using which the interaction can be actually carried out.

For instance, it is obvious that a payment card is required if the interaction is a payment, and even a particular payment card, for instance a Visa payment card if the merchant terminal only accepts Visa and not MasterCard, a specific payment card for taking the public transportation, etc. Similarly, if the interaction is the use of a number of loyalty points in a given shop, the suitable card is only the loyalty card of this shop. Another example, if the interaction is the verification that the user is covered by a social security scheme, then the suitable card is a health insurance card.

The interaction may thus be of any possible type of interaction between the electronic device <NUM> and a terminal <NUM>, using a virtual card stored into the digital wallet of the device <NUM>. The terminal <NUM> itself may be of various types (for instance a merchant terminal for providing payment services using the electronic device) and may be connected in various ways with the electronic device <NUM>.

In a preferred embodiment (represented by <FIG>), the terminal <NUM> is a contactless reader, so that the connection could be through the contactless communication unit <NUM>. In such embodiment, the terminal <NUM> is typically an EFTPOS (Electronic funds transfer at point of sale), i.e. a payment terminal for payment cards generally located at a shop checkout.

Recent EFTPOS are provided by NFC technology ("tap sensors") for contactless payment using a payment card with a RFID chip. For the record, contactless cards include typical "proximity cards" complying with Standard ISO/IEC <NUM>, and "vicinity cards" which can be read from a greater distance (<NUM>) as compared with proximity cards (<NUM>), complying to Standard ISO/IEC <NUM>. The electronic device <NUM> with NFC capability is able to perform an interaction using a virtual card in the exact same way as using a contactless physical card: just passing the device/the physical contactless card close to the reader.

It is to be noted that other connections are possible, for instance using a cable between the device <NUM> and the terminal <NUM>.

Reference is now made to <FIG>, which illustrates an embodiment of the method according to the invention.

The present method can be implemented by an operating software of the electronic device, as a digital wallet is generally a basic functionality of a device such as a smartphone. Alternatively, the present method can be implemented by a dedicated software application.

In a first step (a), identification data related to the terminal <NUM>, connected to the electronic device <NUM> in view of an interaction, is received from this terminal <NUM>.

By "identification data", it is meant information which may be emitted by a terminal <NUM> for initiating exchanges with the electronic device <NUM>, in order to perform the interaction.

Such identification data is for instance defined by the standard ISO/IEC <NUM>-<NUM>. The standard ISO/IEC <NUM> is an international standard related to electronic identification cards with contacts (physical cards), and its part <NUM> "Organization, security and commands for interchange" is independent of the physical interface technology, and applies equally to contact cards, and contactless cards, including virtual cards as they simulate physical contactless cards. This part <NUM> specifies contents of command-response pairs exchanged at the interface.

Advantageously, said identification data related to the terminal <NUM> comprises service category identifier (SCID), identifying a category of service provided by the terminal <NUM> and/or an application identifier (AID) addressing an application to be used for performing the interaction, preferably both. Both of them are defined in the Standard ISO/IEC <NUM>-<NUM>. It is to be noted that the identification data can also be processed from said SCID and/or AID (and not solely comprises it), as discussed below.

The category of service identifies the type of the interaction performable by the terminal <NUM>, such as payment, loyalty, user identification, etc. The AID identifies a more specific type of service within the category, such as the network used for a payment (e.g. Visa, MasterCard, etc.). It addresses an application normally implemented in the integrated circuit of a suitable physical smart card, i.e. when sending the AID the terminal <NUM> declares which targeted application of a card it can deal with.

An AID according to ISO/IEC <NUM>-<NUM>, initially foreseen for physical cards including several applications (for instance a physical bank card with debit, credit and e-purse applications), consists of a registered application provider identifier (RID) of five bytes, which is issued by the ISO/IEC <NUM>-<NUM> registration authority, followed by a proprietary application identifier extension (PIX), which enables the application provider to differentiate among the different applications offered.

It will be assumed in the following description that a terminal <NUM> has a single identification data defining the service it provides access to. Even if some versatile terminals <NUM> might be capable of providing different services, such terminals <NUM> could be considered as a combination of several different "theoretical" terminals <NUM> with each its own identification data, i.e. the different identification data related to each theoretical terminal <NUM> is sent at step (a).

The present method astutely reuses the standard application selection process intended for physical cards so as to allow automatic virtual card selection in the digital wallet.

More precisely, at least one virtual card suitable for said interaction is selected (step b), among the plurality of virtual cards stored in the digital wallet, as a function of at least the identification data related to the terminal <NUM>.

Preferably, if there are at least two virtual cards which are selected as suitable for said interaction, a further selection is requested (step b2) by the user of a virtual card for performing the interaction, among the virtual cards selected as suitable. In other words, a second manual selection follows the first automatic selection in such a case. Such second selection could be done for example through a pop-up displayed on the user interface <NUM>, and may involve only a few pre-selected card (and not the whole plurality of cards stored in the digital wallet), so this selection is not bothering for the user.

In other words, the identification data allows to discriminate between virtual cards, and to provide an automatic selection of a single virtual card or at least a pre-selection of virtual cards (as there might be several virtual cards suitable for the interaction). And in a preferred embodiment, this is done by using only a standard protocol without any modification, as such selection is only based on parameters which are transmitted by the terminal <NUM> (i.e. the identification data).

To illustrate this aspect, let's consider an embodiment where the ISO/IEC <NUM>-<NUM> standard is supported by the terminal <NUM> and this ISO/IEC <NUM>-<NUM> standard defines that the 3rd and 4th bytes are used by the protocol to insert the AID in a message sent from terminal <NUM> to the electronic device <NUM> once connected.

Let's assume that certain values for this AID are already allocated to identify specific type of applications, for instance AID with value "0x0003" identifying a first payment application (e.g. VISA), while AID with value "0x0004" identifying a second payment application (e.g. Master Card). If there is no identification yet for an loyalty program applications, these 3rd and 4th bytes can be reused for that purpose, for instance by defining that an AID with the value "0x0005" identifies a first loyalty program application (e.g. Orange loyalty program) while an AID with the value "0x0006" identifies a second loyalty program application (e.g. Carrefour loyalty program).

Thanks to the reuse of the format of standard protocol, new applications for services to be provided through the terminal <NUM> can be easily added and used, without having to completely update the standard and its implementation.

The identification data could be either directly the category of the service of the interaction and/or the AID, or a processed data obtained from the category of service and/or the AID. Indeed, category of service and AID may be extended based on any needs, for example to identify an enterprise.

In other words, the identification data could be a "tag" determined based on the category and the AID, for example "payment at Carrefour" or "loyalty at Orange". It is very advantageous because all the merchant terminals <NUM> of a single enterprise generally share the same AID and category, so that the same virtual card will automatically be selected in every shop of this enterprise. Nevertheless, the present invention is not limited to any kind of identification data related to the merchant terminal <NUM>.

Finally, the interaction between the electronic device <NUM> and the terminal <NUM> can be performed in a further step (c) using one of the selected virtual cards, preferably the one selected by the user if there is a further manual selection among the ones selected as suitable.

In the embodiment illustrated in <FIG>, at least one virtual card is stored in the digital wallet is associated with reference identification data. There might be a database of the reference identification data, in particular stored on the memory <NUM>.

By "reference identification data", it is meant identification data which could be received during a suitable use of the card. For example, if the virtual card is a loyalty card, the identification data emitted by a terminal <NUM> intending to add loyalty points could be reference identification data for this card, but to the contrary the identification data emitted by a terminal <NUM> intending to perform a payment could not be reference identification data for this card (assuming that this card has no payment functionality).

Thus, a virtual card selected as suitable for said interaction at step (b) is a card associated with reference identification data matching the identification data related to the terminal <NUM>.

In other words, step (b) is performed by comparing the received identification data with the reference identification data associated with the stored virtual cards.

In a first embodiment, all the cards of the plurality of virtual cards which are associated with the received identification data itself are selected, in other words one selects all the virtual cards which are associated with reference identification data identical to the received identification data, and only these virtual cards.

In another embodiment, one selects all the cards of the plurality of virtual cards which are associated with a reference identification data identical to the received identification data or which, though not exactly identical to the received identification data, corresponds to this received identification data (for instance, if the received identification data is made of a <NUM>-digit sequence and the reference identification data is a <NUM>-digit sequence identical to the first <NUM> numbers of the received identification data).

In the above-mentioned embodiment where the comparison step (b) is performed to select only the virtual cards associated with reference identification data which are identical to the received identification data, a more precise selection of virtual cards is enabled, increasing the chances that the appropriate virtual card is directly selected without having to request a manual confirmation from the user.

In the above-mentioned embodiment where the comparison step (b) is performed to select virtual cards associated with reference identification data which are not necessarily identical but correspond to the received identification data, a broader selection of virtual cards may be achieved. Such a broader selection is typically advantageous when using a single service where several terminals have their own different identification data with a common part identifying the service.

For instance when using a virtual card for subway transportation, a specific subway entrance may have several terminals, each associated with a respective gate to be opened when a user is authorized by the terminal. Each of these several terminals may have different identification data with a common part identifying the subway entrance. With the above-mentioned embodiment requiring reference identification data to be identical to the received identification data, every time a user uses a new terminal of the same subway entrance, a new association between the transportation card and the received identification data of this new terminal must be stored. With the above-mentioned embodiment requiring reference identification data to correspond to the received identification data (without having to be identical), once one of the terminals of the subway entrance has been used and its identification data stored in the electronic device, the transportation card can be directly selected to be used with the other terminals of the same subway entrance, without having to store identification data for each of these other terminals.

To rephrase, if a virtual card is associated with the received identification data, it is suitable for the corresponding interaction, but if a virtual card is not associated with the received identification data, it does not mean that this virtual card is not suitable for the interaction: it only means that one may not know yet that it is suitable for the interaction.

Consequently, the reference identification data can be progressively constituted by "learning" from the interactions operated by the user of the electronic device <NUM>.

To this end, in an advantageous embodiment, if no virtual card stored in the digital wallet is associated with reference identification data matching the received identification data related to the terminal <NUM>, a further selection is requested (step b2), from a user of the electronic device <NUM>, of a virtual card for performing the interaction, among said plurality of virtual cards stored in the digital wallet.

The process then further comprises associating (step d) with the virtual card selected by the user the identification data related to the terminal <NUM> as reference identification data, and storing this association, typically in the electronic device <NUM>.

In other words, if no suitable virtual card is found, a manual selection (among all the virtual cards) is still required (such selection could be done again for example through a pop-up displayed on the user interface <NUM>), and the virtual card selected by the user is recorded as being suitable for this interaction (the identification data related to the terminal <NUM> is associated to this card as reference identification data), so that next time the same identification data is encountered, automatic selection of this virtual card occurs.

In such an embodiment, it is possible to start with no reference identification data associated with any virtual card, i.e. an empty database which is completed each time the user performs an interaction with his electronic device <NUM>.

In addition, the user may be provided with the possibility of correcting a selection, if (s)he prefers to use another virtual card instead of the one selected. To this end, there might be a command for overriding the selection, and reverting to the manual selection previously described. In particular, when one or more virtual card is firstly selected as suitable, the user could have the choice to either choose one of the initially selected cards (or confirming if a single one is selected as suitable) for performing the interaction, or to choose "none of these".

Again, the identification data related to the terminal <NUM> is preferably associated to the manually selected virtual card as reference identification data, for further uses.

It is to be noted that the reference identification data associated to the firstly selected virtual card is preferably not modified in such a case. Indeed, the first selection is generally not wrong, as there might be several cards suitable for a given terminal <NUM>, for instance payment cards issued by different banks.

For ensuring the absence of wrong associations, the modification of the reference identification data associated with a virtual card (for instance a new association to be performed following a manual selection by the user) is performed only after that the interaction is performed using the manually selected virtual card. It allows to verify that this manually selected virtual card is actually suitable for the interaction, so that every learnt reference identification data is necessarily correct: if the user manually selects a wrong virtual card (for instance a loyalty card for a payment), the interaction fails and no further reference identification data is added to the wrongly selected virtual card (as it proves not to be suitable for the interaction). When such a verification is performed, a new selection of a virtual card shall then only mean that the user wishes to use an alternate virtual card, both the firstly and the newly selected virtual cards being suitable for the interaction.

Anyways, the user should be provided with an interface for modifying at will the reference identification data associated to all the virtual cards, enabling the deletion of some reference identification data, if for any reason wrong reference identification data has been associated to a virtual card.

In a second embodiment, the received identification data is processed so to determine the at least one suitable virtual card using rules, for instance imported from a remote server. When compared to the first embodiment, this second one does not need a "learning" phase, but requires on the other hand using a remote server.

To illustrate this second embodiment, a company may obtain from a standardization organization that an identifier for its loyalty virtual card (or loyalty program) be added in the standard protocol, for instance as an AID with the value "0x0005". In such a case, the e-wallet application installed on the electronic device <NUM> can download the new paring rule of this loyalty virtual card with the AID value "0x0005" from the server of the standardization organization. This way, whenever a message containing the AID with value "0x0005" is received when electronic device <NUM> connects with terminal <NUM>, the loyalty virtual card for this company will be selected automatically, without the need of user's selection.

The present invention further proposes an electronic device <NUM> comprising a memory <NUM> and a processing unit <NUM>, adapted for carrying out the method for operating as previously described. This device <NUM> may also comprise a user interface <NUM>, or a contactless communication unit <NUM>. This processing unit <NUM> is configured to implement the steps of:.

The processing unit <NUM> is further configured to perform the interaction with the terminal <NUM> using one of the selected virtual cards, and to store the received identification data related to the terminal <NUM> as reference identification data associated with the virtual card selected for performing the interaction, wherein the storing of the received identification data related to the terminal as reference identification data associated with the virtual card selected for performing the interaction is performed only if the interaction with the terminal <NUM> is correctly performed.

Claim 1:
A method for operating an electronic device (<NUM>) storing a plurality of virtual cards in a digital wallet, wherein at least one virtual card stored in the digital wallet is associated with reference identification data, characterized in that it comprises the following steps, performed by a processing unit (<NUM>) of the device (<NUM>):
receiving (a), from a terminal (<NUM>) connected to the electronic device (<NUM>), identification data related to the terminal (<NUM>);
selecting (b) each virtual card suitable for an interaction between the electronic device (<NUM>) and the terminal (<NUM>), among the plurality of virtual cards stored in the digital wallet, as a function of at least said identification data related to the terminal (<NUM>), the selecting step (b) comprising comparing (b1) the received identification data with said reference identification data, a virtual card being selected as suitable for said interaction if the reference identification data it is associated with matches the received identification data related to the terminal (<NUM>),
wherein, if no virtual card stored in the digital wallet is associated with reference identification data matching said identification data related to the terminal (<NUM>), the selecting step (b) further comprises requesting (b3) the selection by a user, among said plurality of virtual cards stored in the digital wallet, of a virtual card for performing the interaction,
performing (c) the interaction between the electronic device (<NUM>) and the terminal (<NUM>) using one of the selected virtual cards; and storing (d) the received identification data related to the terminal (<NUM>) as reference identification data associated with the virtual card selected for performing the interaction,
characterized in that
the step of storing (d) the received identification data related to the terminal (<NUM>) as reference identification data associated with the virtual card selected for performing the interaction is performed only if the interaction is correctly performed at the step of performing (c) the interaction.