WO2020052753A1

WO2020052753A1 - Intermediary system for faciliting communication between virtual smart cards and a smart card interface

Info

Publication number: WO2020052753A1
Application number: PCT/EP2018/074666
Authority: WO
Inventors: Christopher Kevan LOWE; Shunan Fan
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2018-09-12
Filing date: 2018-09-12
Publication date: 2020-03-19

Abstract

Devices capable of implementing each of a plurality of virtual smart cards by executing software code, each virtual smart card hosting one or more applications. The device includes an intermediary system for facilitating communications between the plurality of virtual smart cards and an interface capable of interacting with applications hosted by a smart card so as to enable the interface to interact with the applications hosted by the plurality of virtual smart cards. The intermediary system is configured to emulate a single smart card that hosts the one or more applications hosted by each of the plurality of virtual smart cards.

Description

INTERMEDIARY SYSTEM FOR FACILITING COMMUNICATION BETWEEN VIRTUAL

SMART CARDS AND A SMART CARD INTERFACE

BACKGROUND

As is known to those of skill in the art, a smart card (which may also be referred to as an integrated circuit card (ICC) or a chip card) is a small, often pocket-sized, plastic card that has an embedded integrated circuit. The integrated circuit allows the storage of information on the card itself which can be accessed by another device (e.g. a smart card reader or terminal). Some smart cards comprise a pattern of metal contacts (e.g. as defined in ISO/IEC 7816) which allow another device (e.g. a smart card reader or terminal) to electrically connect to the integrated circuit. Other smart cards are, additionally, or alternatively, contactless. Contactless smart cards can wirelessly communicate with another device (e.g. a smart card reader or terminal) via an induction technology such as, but not limited to, radio-frequency identification (RFID) and near field communication (NFC). Smart cards typically implement one or more security measures, such as, but not limited to, the use of a PIN or password, to allow the secure transmission of personal and/or financial information.

Smart cards are used in a variety of applications including, but not limited to: identification, financial, mobile phones (subscriber identity module (SIM)), public transit, computer security, schools, and healthcare. Some of the most common smart card applications include financial and mobile phone applications. Specifically smart cards are used as identification devices for Global System for Mobile Communications (GSM) digital mobile phones. In these cases, the smart card stores all the necessary information in order to properly identify the user so that the user can use the smart card in multiple mobile phones. Smart cards are also often used to implement credit or direct debit cards. In these cases, the integrated circuit on the card and the card readers/terminals use mutual authentication procedures that help protect users, merchants and banks from fraudulent use.

There has been a recent movement to replace physical smart cards with virtual smart cards that offer equivalent functionality. To implement a virtual smart card software is stored in the memory of a computing device (e.g. a mobile phone), which when executed by the device, implements a virtual smart card which provides the functionality of a physical smart card.

The software to implement a virtual smart card is typically stored in a secure area of the device, such as the Trusted Execution Environment (TEE) of a mobile phone, or even a separate hardware chip, that provides confidentiality and integrity for applications and their associated data. In some cases, a virtual smart card may be implemented as a Virtual Machine (VM).

The European Telecommunications Standards Institute (ETSI) is currently in the process of standardizing the virtual smart card concept as the integrated Secure Smart Platform (iSSP).

The embodiments described below are provided by way of example only and are not limiting of implementations which solve any or all of the disadvantages of known devices that support virtual smart cards.

SUMMARY

This summary is provided to introduce a selection of concepts that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

Described herein are devices, and methods of operating devices, capable of implementing each of a plurality of virtual smart cards by executing software code, each virtual smart card hosting one or more applications. The devices include an intermediary system for facilitating communications between a plurality of virtual smart cards and an interface capable of interacting with applications hosted by a smart card so as to enable the interface to interact with the applications hosted by the plurality of virtual smart cards. The intermediary system is configured to emulate a single smart card that hosts the one or more applications hosted by each of the plurality of virtual smart cards.

A first aspect provides a device capable of implementing each of a plurality of virtual smart cards by executing software code, each virtual smart card hosting one or more applications, the device comprising: an intermediary system in communication with the plurality of virtual smart cards and an interface capable of interacting with applications hosted by a smart card so as to enable the interface to interact with the applications hosted by the plurality of virtual smart cards; wherein the intermediary system is configured to emulate a single smart card that hosts the one or more applications hosted by each of the plurality of virtual smart cards.

The intermediary system may be further configured to: receive a request from the interface for a list of applications hosted by the intermediary system; and in response to receiving the request, generate an aggregate list of applications hosted by the plurality of virtual smart cards and provide all or a portion of the aggregate list of applications to the interface.

The intermediary system may be further configured to maintain a mapping between each application in the aggregate list of applications and the virtual smart card that hosts that application.

The intermediary system may be further configured to: receive information from the interface indicating a selected application from the provided list of applications; and forward the indication to the virtual smart card that hosts the selected application based on the mapping.

The intermediary system may be further configured to record which of the applications was selected by the interface so that any subsequent application information received from the interface can be automatically forwarded to the virtual smart card that hosts the selected application.

Each application may be identified by an application identifier and the intermediary system may be further configured to: in response to determining that two applications hosted by different virtual smart cards are identified by a same application identifier, identify one of the two applications by a different application identifier in the aggregate list of applications so that each application in the aggregate list of applications is identified by a unique application identifier;

The intermediary system may be further configured to record in the mapping both an original application identifier and the different application identifier for the one of the two applications.

The intermediary system may be further configured to: request input from a user of the device as to which of the plurality of virtual smart cards are to be used with the interface; receive input from the user of the device identifying a subset of the plurality of virtual smart cards to be used with the interface; and only provide a list of those applications hosted by the identified subset of virtual smart cards to the interface.

The intermediary system may be further configured to: automatically filter the aggregate list of applications based on one or more of location and user preferences to generate a filtered list of applications; and only provide the filtered list of applications to the interface.

The intermediary system may be configured to generate the aggregate list of applications by: requesting, from each virtual smart card of the plurality of virtual smart cards, a list of applications hosted by that virtual smart card; receiving, from each virtual smart card, a list of the one or more applications hosted by that virtual smart card; and generating the aggregate list of applications hosted by the plurality of virtual smart cards from the lists of one or more applications hosted by the virtual smart cards.

The interface may be configured to interact with applications hosted by smart cards of a certain type and the plurality of virtual smart cards are of the certain type; and the

intermediary system may be configured to identify the plurality of virtual smart cards by requesting a list of virtual smart cards that are of the certain type from a virtual smart card management subsystem that manages virtual smart cards that can be implemented by the device.

The device may comprise a memory; and data defining the software code for implementing each virtual smart card is stored as an image in the memory.

The device may be configured to, in order to implement one of the virtual smart cards:

retrieve from the memory the image for that virtual smart card; prepare that image for execution by forming executable code; and execute the executable code.

The memory images may be stored, and the executable code formed therefrom may be executed, in a dedicated secure subsystem of the device.

The device may store, in a non-transient form data, defining each virtual smart card.

The intermediary system may be configured to communicate with the interface using near field communication.

A second aspect provides a method for operating a device, the method comprising:

executing, by a processing circuit, a plurality of virtual smart cards, wherein each virtual smart card hosts one or more applications; and emulating a single smart card that hosts the one or more applications hosted by each of the plurality of virtual smart cards for establishing communications between the virtual smart cards and an interface capable of interacting with applications on a smart card so as to enable the interface to interact with the applications hosted by the plurality of virtual smart cards.

The execution allows to implement on the device each of the plurality of virtual smart cards.

The additional features described in connection with the device according to the first aspects also define further implementations of the method according to the second aspect. There may be provided computer program code for performing a method as described herein. There may be provided non-transitory computer readable storage medium or computer program product having stored thereon computer readable instructions that, when executed at a computer system, cause the computer system to perform the methods as described herein.

The above features may be combined as appropriate, as would be apparent to a skilled person, and may be combined with any of the aspects of the examples described herein.

BRIEF DESCRIPTION OF THE DRAWINGS

Examples will now be described in detail with reference to the accompanying drawings in which:

FIG. 1 is a block diagram of an example device capable of implementing each of a plurality of virtual smart cards by executing software code that comprises an intermediary system to enable a legacy smart card interface to interact with the virtual smart cards;

FIG. 2 is a timing diagram illustrating an example set of messages exchanged between components of the device of FIG. 1 ; and

FIG. 3 is a flow diagram of an example method for operating a device capable of

implementing each of a plurality of virtual smart cards by executing software.

The accompanying drawings illustrate various examples. The skilled person will appreciate that the illustrated element boundaries (e.g., boxes, groups of boxes, or other shapes) in the drawings represent one example of the boundaries. It may be that in some examples, one element may be designed as multiple elements or that multiple elements may be designed as one element. Common reference numerals are used throughout the figures, where appropriate, to indicate similar features.

DETAILED DESCRIPTION

The following description is presented by way of example to enable a person skilled in the art to make and use the invention. The present invention is not limited to the embodiments described herein and various modifications to the disclosed embodiments will be apparent to those skilled in the art. Embodiments are described by way of example only.

A legacy smart card interface is any interface that is configured to interact with a physical smart card via contacts on the card and/or via a contactless technique such as NFC. Legacy smart card interfaces include, but are not limited to, smart card readers, smart card terminals and card acceptance devices. A card acceptance device typically has a slot into which a smart card is inserted; a card reader is typically connected to a computer which performs the processing functions; and a smart card terminal typically comprises a computer or computing functionality so that it can perform the processing functions itself. Legacy smart card interfaces may also be referred to herein as“smart card interfaces” or simply“interfaces”. As a virtual smart card is virtual it does not typically comprise hardware, such as a pattern of metal contacts, that allows a legacy smart card interface to communicate with the virtual smart card. Accordingly, to allow a virtual smart card to interact with a legacy smart card interface what is needed is a system or mechanism that can facilitate communication between a virtual smart card running on a device and a legacy smart card interface (e.g. a smart card terminal).

Accordingly, described herein are intermediary systems for facilitating communication between virtual smart cards and a legacy smart card interface, such as, but not limited to a legacy smart card reader or terminal. The intermediary systems described herein are designed for devices capable of implementing a plurality of virtual smart cards by executing software code. The intermediary system may be implemented as a software running on a processing circuit or as a combination of hardware and software components that may communicate with a plurality of virtual smart cards, iSSP infrastructure, and with the interface device drivers (such as HCI). The intermediary system has the ability to store the state of enumerations and transactions between the interfaced elements (e.g. the smart card terminal and the virtual smart cards). As described in more detail below, each virtual smart card can host one or more applications which a legacy smart card interface is capable of interacting with. The intermediary systems facilitate communication between the plurality of virtual smart cards and the legacy smart card interface by emulating a single smart card that hosts the applications hosted by each of the virtual smart cards. By emulating a single smart card that hosts the applications hosted by a plurality of virtual smart cards, the intermediary system allows a legacy smart card interface to interact with a plurality of virtual smart cards in an efficient manner and does not require any changes to the legacy smart card interface. Reference is now made to FIG. 1 which illustrates an example device 100 that is capable of implementing a plurality of virtual smart cards of the same type by executing software code. The device 100 may be any computing-based device such as, but not limited to, a mobile telephone, a tablet, and the like that is capable of executing computer executable

instructions. The device 100 comprises data defining software code for implementing a plurality of virtual smart cards 102, 104 of a particular type and an intermediary system 106 to enable a legacy smart card interface 108 to interact with the virtual smart cards 102, 104.

It will be appreciated that FIG. 1 only shows some elements of the device 100 and there may by many other elements (e.g. a display, antenna and/or user input device) that form part of, or are connected to, the device 100 that are not shown in FIG. 1 .

The data defining software code for implementing a virtual smart card 102, 104 defines software code, which when executed by a processor 1 10 of the device 100, replicates the functionality of a physical smart card. In the example of FIG. 1 the virtual smart cards 102, 104 are virtual payment or wallet smart cards that are configured to replicate the functionality of a physical payment or wallet smart card, such as, but not limited to a smart credit card or a smart debit card (e.g. an EMV smart card). As is known to those of skill in the art, EMV stands for Europay®, Mastercard® and Visa® and is a global standard for payment smart cards. However, it will be evident to a person of skill in the art that this is an example only and that the virtual smart cards may replicate the functionality of any type of smart card that is capable of interacting with a legacy smart card interface (i.e. a smart card interface that is configured to interact with a physical smart card via contacts on the physical smart card or via contactless techniques such as, but not limited to, NFC). Furthermore, while the device 100 of FIG. 1 comprises two virtual smart cards that replicate the functionality of a physical smart card that can interact with a legacy smart card interface it will be evident to a person of skill in the art that the techniques and principles described herein may equally be applied to devices that can support more than two such virtual smart cards.

The data defining the software code for implementing each virtual smart card 102, 104 may be stored in memory 1 12 of the device 100. The memory 1 12 may be situated in a secure area, or dedicated secure subsystem of the device 100, such as the Trusted Execution Environment (TEE), or even a separate hardware chip, that provides confidentiality and integrity for applications and their associated data. In some cases, the data defining the software code for implementing a virtual smart card 102, 104 may be stored in a non transient form. In some cases, the data defining software code for implementing a virtual smart card may define a virtual machine (VM) that replicates the functionality of a physical smart card. As is known to those of skill in the art, a VM is software that emulates or imitates dedicated hardware. In these cases, the data defining software code for implementing a virtual smart card defines a VM and may be stored as a VM image. A VM image may comprise or define software code to implement a high-level operating system (HLOS) 1 14, 1 16, infrastructure 1 18, 120 (such as, but not limited to, Java Card / GlobalPlatform) and/or one or more applications 122, 124, 126 that run on top of the high-level operating system 1 14, 1 16 and infrastructure 1 18, 120. In some cases, the VM image may be referred to as a secondary platform bundle (SPB).

Most smart cards can be programmed with software code to implement one or more applications (which if coded using Java Card technology may be referred to as applets) that are capable of communicating with a host application running on an external device, such as, but not limited to a smart card terminal. The ISO 7816 standard specifies that each smart card application is uniquely identified by an application identifier (AID). The AID consists of a five byte resource identifier (RID) which is a unique number issued by the ISO/IEC

registration authority to application providers. This is followed by an optional proprietary application identifier extension (PIX) of up to 1 1 bytes which enable an application provider to differentiate between the different applications it offers. Example AIDs are shown in Table 1 .

Table 1

In some cases, the device 100 may be configured to implement a virtual smart card by retrieving the VM image for that virtual smart card, preparing that image for execution by forming executable code from the image, and executing the executable code on a processor 1 10 of the device 100. In some cases, the VM image may be stored in an encrypted format. In these cases, the device 100 may be configured to decrypt the VM image prior to forming the executable code from the image.

In some cases, the device 100 may also comprise an operating system (OS) 128 for supporting the execution of the software code for implementing the virtual smart cards. For example, the software code implementing the virtual smart cards may be run on top of the OS 128. This OS 128 may be a low-level OS. As is known to those of skill in the art, a low- level OS, compared to a high-level OS operates at a lower level of abstraction with respect to the components of the system.

In some cases, the device 100 may also comprise an image manager (not shown) that is configured to manage the VM images stored in the memory 1 12 of the device 100. In some cases, the image manager may be implemented as a hypervisor (which also may be referred to as a virtual machine monitor (VMM)). As is known to those of skill in the art, a hypervisor is software that creates and runs VMs. The computer on which a hypervisor runs a VM is the host machine and the VM is referred to as the guest machine. The hypervisor presents the guest operating system (e.g. HLOS 1 14, 1 16) with a virtual operating platform.

In some cases, a virtual smart card can be in one of four states: disabled, enabled, active, or removed/deleted. A virtual smart card is said to be enabled if the data defining the software code for implementing that virtual smart card has been properly installed on, and registered with, the device and is available to be used to communicate with a host application. A virtual smart card is said to be disabled if the data defining the software code for implementing that virtual smart card has been properly installed on, and registered with, the device, but it is not available to be used to communicate with a host application. Once a virtual smart card is in the enabled state it can be moved to the active state.

A virtual smart card is said to be in the active state if an instantiation of the virtual smart card has been generated on the device. In other words, a virtual smart card is in the active state if the software code for implementing that virtual smart card is currently running on the device. Accordingly, the set of virtual smart cards that can be activated or implemented by the device are those virtual smart cards that are in the active state or the enabled state. A virtual smart card is said to be in the deleted state if it was installed on the device, but it has since been removed or deleted. A virtual smart card may only stay in the removed or deleted state for a short period of time (e.g. for enough time to notify other components that the virtual smart card has been deleted). In some cases, a virtual smart card can only be moved to the deleted state from the disabled state. In other words, a virtual smart card cannot move directly from the enabled or active state to the deleted state.

In some cases, the device 100 may also comprise other applications (not shown), such as a payment application, which allow the smart card applications to interact with a host application via other communication means, such as, but not limited to a wireless or wired network (e.g. Global System for Mobile Communications (GSM) network).

In some cases, the device 100 may also comprise data that defines software code for implementing other smart card or ICC applications. For example, in FIG. 1 the device 100 also comprises data that defines a virtual subscriber identity module (SIM) 130 that replicates the functionality of physical SIM. Specifically, a virtual SIM is associated with, or related to, a subscriber identity (e.g. an International Mobile Subscriber Identity (IMSI) number) and is capable of participating in a data exchange to authenticate that subscriber identity. The virtual SIM may be configured to communicate with a communication subsystem (e.g. a modem) (not shown) that is configured to establish a communication connection with a network (e.g. a GSM network) in accordance with the subscriber identity (e.g. IMSI) relating to the virtual SIM 130. Like the virtual smart cards 102, 104, the virtual SIM 130 may be implemented by a VM and thus the data defining the software code to implement the virtual SIM may comprise a VM image that comprises/defines a high-level operating system 132, infrastructure 134 and one or more applications 136, 138 that run on the high-level operating system 132 and infrastructure 134. The intermediary system 106 facilitates communications between a plurality of virtual smart cards of a particular type and a smart card interface (e.g. smart card terminal) capable of interacting with a physical a smart card (i.e. the applications hosted thereby) of that particular type so as to enable the interface to interact with the plurality of virtual smart cards (i.e. the applications hosted thereby). Specifically, the intermediary system 106 is configured to emulate a single smart card of the particular type that hosts the applications hosted by the plurality of virtual smart cards of that type. For example, if the interface is capable of interacting with a payment or wallet smart card (i.e. applications hosted by a payment or a wallet smart card), and the device 100 is capable of implementing a plurality of virtual payment or wallet smart cards 102, 104 then the intermediary system 106 emulates a single payment or wallet smart card that hosts or supports the applications hosted or supported by each of the plurality of virtual payment or wallet smart cards 102, 104.

The smart card specification standard International Organization for Standardization

(ISOyinternational Electrotechnical Commission (IEC) 7816 specifies that a smart card interface and a smart card communicate using Application Protocol Data Units (APDUs). An APDU is a packet of data that conforms to a specific format and contains either a command message or a response message. A command APDU begins with a four-byte header and is optionally followed by a body. The header contains fields that specify an operation to be performed by a smart card. The body can include any data that accompanies the request and the maximum number of data bytes expected in response to the command. A response APDU optionally begins with a body that contains any data returned in the response and ends with a two-byte trailer that specifies the processing state of the smart card. Typically, the interface generates commands, the smart card processes the commands, and sends back a response to each command. Therefore a specific response corresponds to a specific command, referred to a command-response pair. Accordingly, the intermediary system 106 may be configured to receive command APDUs from the interface, forward the command APDUs to the appropriate virtual smart card, receive response APDUs from the virtual smart cards, and forward the response APDUs to the interface.

In some cases, prior to sending commands to a particular smart card application, a smart card interface 108 may be configured to obtain a list of applications (e.g. a list of AIDs) supported or hosted by the smart card and select one or none of the supported applications to communicate with. For example, an interface 108 that is configured to communicate with an EMV smart card is configured to obtain a list of payment applications supported or hosted by an EMV payment smart card and select one or none of the supported payment applications to be used in processing a transaction based on, for example, whether the interface 108 supports a corresponding or compatible application (e.g. whether the smart card supports a Visa® application and the interface is able to process Visa® transactions).

An EMV interface may be configured to determine whether the interface and the smart card comprise corresponding, or compatible applications by comparing the AIDs of the

applications supported or hosted by the smart card and the AIDs of the applications supported or hosted by the interface to determine if they match, or partially match.

According to the EMV standard, a contact EMV interface may be configured to obtain the list of payment applications supported by an EMV payment smart card by accessing the smart card’s PSE (Payment System Environment). The PSE is an optional mechanism for a contact smart card to store a directory structure that holds records containing one or more applications that are available on the smart card. The PSE is accessed by the interface by issuing a SELECT command for the PSE (Ί PAY.SYS. DDF01’). Similarly, a contactless EMV interface may be configured to obtain the list of payment applications supported by an EMV payment smart card by accessing the smart card’s PPSE (proximity payment system environment). The PPSE on a contactless card contains the list of all card applications supported by the contactless card. The interface obtains the PPSE by issuing a SELECT command for the PPSE (‘2PAY.SYS. DDFOT). It will be evident to a person of skill in the art that this is an example only and that other types of smart cards and smart card applications may use different means to obtain a list of applications hosted or supported by a smart card.

In these cases, to emulate a single virtual smart card the intermediary system 106 may be configured to, in response to receiving a request for a list of applications supported by a smart card (e.g. a‘SELECT 1 PAY1 .SYS. DDFOT APDU or a‘SELECT 2PAY1 .SYS. DDFOT ADPU) of a particular type from an interface 108, generate an aggregate list of applications hosted or supported by the plurality of virtual smart cards 102, 104 of that type, and provide all or a portion of the aggregate list of applications to the interface 108. In some cases, the intermediary system 106 may be configured to generate the aggregate list of applications by: requesting, from each virtual smart card 102, 104 of the relevant type a list of applications supported or hosted by that virtual smart card 102, 104; receiving, for each virtual smart card 102, 104, a list of the one or more applications hosted by that virtual smart card 102, 104; and generating an aggregate list of applications hosted by the virtual smart cards 102, 104 of the relevant type from the lists of one or more applications hosted by each virtual smart card 102, 104. In some cases, the intermediary system 106 may be configured to request a list of applications supported or hosted by a particular virtual smart card by forwarding the request (e.g. a‘SELECT 1 PAY1 .SYS.DDF01’ or‘SELECT 2PAY1 .SYS.DDFOT message) received from the interface 108 to the relevant virtual smart cards 102, 104.

In some cases, one or more of the virtual smart cards 102, 104 may be configured to restrict access to the list of available applications to interfaces with proper access rights. In these cases, prior to issuing a request for a list of applications supported by a smart card (e.g. a ‘SELECT 1 PAY1.SYS.DDF01’ APDU or a‘SELECT 2PAY1 .SYS.DDFOT ADPU) the interface 108 may be configured to engage in an authentication process with the smart card. For example, the interface 108 may be configured to initiate the authentication process by transmitting a‘GET CHALLENGE’ command ADPU to the smart card. If the smart card supports and/or requires authentication, then in response to the GET CHALLENGE command the smart card responds with a CHALLENGE response ADPU which comprises challenge data generated by the card (e.g. an 8 byte random number). The interface 108 then uses a secret key to encrypt the challenge data and sends the encrypted data to the smart card via an EXTERNAL AUTHENTICATE command ADPU. If the interface 108 used the correct secret key (e.g. the same key that is stored on the smart card) then when the card decrypts the encrypted data, the smart card will obtain the same challenge data. The smart card 108 then grants the interface access to the smart card. In some cases, the intermediary system 106 may be configured to, in response to receiving a request to initiate authentication (e.g. a‘GET CHALLENGE’ ADPU) forward the request to one of the virtual smart cards 102, 104 to allow that virtual smart card 102, 104 to handle the authentication of the interface 108. In other cases, the intermediary system 106 may be configured to, in response to receiving a request to initiate authentication (e.g. a‘GET CHALLENGE’ ADPU), spoof a response, return a previously obtained list of applications supported by the virtual smart cards, and then disconnect and reconnect once the application for the particular interaction has been successfully determined as set out below.

As described above, smart card applications are typically identified by an AID. Accordingly, the list of applications supported by a particular virtual smart card, and/or the aggregate list of applications supported by the virtual smart cards of the relevant type may comprise a list of AIDs.

In some cases, the intermediary system 106 may be configured to provide the complete aggregate list of applications to the interface 108 in response to the request for a list of supported or hosted applications. In other cases, the intermediary system 106 may be configured to request input from the user of the device 100 as to which of the plurality of virtual smart cards 102, 104 are to be used with the interface 108; receive input from the user of the device 100 as which of the plurality of virtual smart cards 102, 104 of the relevant type are to be used with the interface 108; and only provide a list of those applications hosted by the identified virtual smart card(s) to the interface. For example, where the device 100 comprises a display (not shown) the intermediary system 106 may be configured to display on the display a request for the user to provide input as to which virtual smart card is to be used with the interface (e.g. Would you like to use your Visa® card or your Mastercard®? Press 1 for Visa®; Press 2 for Mastercard®). The user may be able to manually indicate their preference via a manual input device such as, but not limited to, a keyboard or a touchscreen, or verbally via a microphone or the like.

In yet other cases, the intermediary system 106 may be configured to automatically filter the aggregate list of applications based on one or more criteria and only provide the filtered list of applications to the interface in response to receiving the request for the list of applications from the interface 108. The criteria that are used to filter the aggregate list of applications may include, but are not limited to, the current location of the device 100, time of day, proximity to another device, information obtained from one or more external systems and/or user preferences. It will be evident to a person of skill in the art that these are example criteria only and that additional and/or different criteria may be used to filter the aggregate list of applications.

For example, the device 100 may be equipped with means, such as, but not limited to, a global positioning system (GPS) receiver or global navigation satellite system (GNSS) receiver, that can identify the current location of the device 100. In these cases, the intermediary system 106 may be configured to automatically filter the aggregate list of applications based on the current location of the device 100 prior to sending the list of applications to the interface 108. For example, where the device 100 comprises a first virtual smart card issued by an application service provider in country A and a second virtual smart card of the same type issued by an application service provider in country B and the location information indicates that the device 100 is currently in country A then the intermediary system 106 may be configured to automatically filter the list of aggregate applications so that it only contains the applications supported or hosted by the virtual smart card that was issued by the service provider in country A.

In another example, the user may be able to specify, for example, which virtual smart card(s) of each type of virtual smart card is/are the preferred virtual smart card(s). The user may also, for example, be able to specify that one virtual smart card of a particular type is to be used before 5pm and another virtual smart card of the particular type is to be used after 5pm. It will be evident to a person of skill in the art that these are examples only and that the user may be able to specify other user preferences. In these cases, the intermediary system 106 may be configured to automatically filter the aggregate list of applications based on the specified user preferences prior to sending the list to the interface 108. For example, where the user has specified one or more preferred virtual smart cards of a certain type, when the interface 108 is configured to communicate with cards of that type the intermediary system 106 may be configured to automatically filter out the non-preferred virtual smart cards of that type.

Once all or a portion of the aggregate list of applications has been provided to the interface 108, the interface 108 selects one or none of the applications from the list to communicate or interact with. For example, as described above, an EMV interface may be configured to determine whether the interface 108 and the smart card support compatible or corresponding applications (e.g. whether the smart card support a Visa® application and the interface is able to process Visa® transactions). An EMV interface may be configured to determine whether the interface and the smart card comprise corresponding, or compatible applications by comparing the AIDs of the applications supported or hosted by the smart card and the AIDs of the applications supported or hosted by the interface to determine if they match, or partially match.

If the interface 108 selects an application to communicate with, the interface 108 sends information (e.g. a message) to the intermediary system 106 identifying which application it has selected. The message is typically, but may not necessarily be, a‘SELECT AID’ APDU where the AID is the AID of the selected application. When a smart card receives such a message it causes the smart card to activate the application with the identified AID.

To ensure that the intermediary system 106 can cause the appropriate application to be activated in response to a select message the intermediary system 106 may be configured to maintain a mapping between each application in the aggregate list of applications and the virtual smart card 102, 104 that hosts that application. For example, the intermediary system 106 may maintain a table, such as Table 2 shown below, in which the AIDs of the

applications supported or hosted by the virtual smart cards 102, 104 are mapped to the virtual smart card 102, 104 that hosts the application. Where the intermediary system 106 is configured to maintain such a mapping the intermediary system 106 may be configured to, in response to receiving information identifying a selected application from the provided list of applications, identify the virtual smart card that hosts the selected application based on the mapping, and cause the identified virtual smart card to activate the selected application. In some cases, the intermediary system 106 may be configured to cause the identified virtual smart card to activate the selected application by forwarding, or otherwise, sending a ‘SELECT AID’ ADPU to the identified virtual smart card where the specified AID is the AID of the selected application.

Table 2

In some cases, after the interface 108 has selected an application to communicate with, any further communications from the interface 108 to the application may not identify the selected application. For example, where the interface 108 communicates with the application of the virtual smart card using APDUs any command APDUs that follow the SELECT APDU may not specify the AID to which they relate. This is because typically there is only one active application per smart card - the selected application - so once an application has been activated via a SELECT command, any subsequent commands that are sent to the smart card are processed by the selected application. However, in the example device 100 of FIG.

1 , one of a plurality of virtual smart cards can be running the active application. This means that when the intermediary system 106 receives a communication from the interface 108 following an application selection it may not be immediately evident which virtual smart card should receive the communication. Accordingly, in some cases, the intermediary system 106 may be configured to record which of the applications was selected by the interface 108 so that communications from the interface that follow an application selection communication (e.g. a SELECT command) can be automatically forwarded or transmitted to the appropriate virtual smart card (i.e. the virtual smart card that hosts the selected application). In some cases, a record of the selected application may be stored as part of, or in association with, the mapping of AIDs to virtual smart cards, as shown in Table 3. Table 3

Typically a physical smart card will not have two or more applications with the same AID.

This is because a physical smart card typically comprises one or more applications that are supported by a particular application provider and the application provider will be able to distinguish their different applications by different AIDs (e.g. using different PIX values). For example, a bank card from company X may comprise a first application AID 1 and a second application AID 2 which are supported by company X. However, since, in the device 100 of FIG. 1 , there may be multiple virtual smart cards that support or host applications that relate to the same application provider (e.g. company X) it is possible that there may be two or more virtual smart cards that support or host applications with the same application identifier (AID). For example, there may be a first virtual smart card that supports an application AID 1 and a second virtual smart card that supports the same application AID 1. This may result in the aggregate list of applications comprising two or more AIDs that are the same (i.e. two or more duplicate AIDs). If such a list of applications is sent to the interface 108 and the interface 108 selects one of the duplicate AIDs, the intermediary system 106 may not know which of the virtual smart cards that supports or hosts the identified application to

select/activate.

In some cases, the intermediary system 106 may be configured so that if the selected application (i.e. selected AID) is a duplicate (i.e. two or more virtual smart cards are capable of hosting an application with that AID) the intermediary system 106 selects one of the duplicate applications as the selected application based on one or more criteria (such as, but not limited to, user preferences). In other cases, the intermediary system 106 may be configured to filter the aggregate list of applications (in a similar manner to that described above) prior to sending the aggregated list to the interface so that the list sent to the interface only comprises applications with unique AIDs and recording which of the applications were sent to the interface.

In yet other cases, the intermediary system 106 may be configured to, in response to determining that two applications in the aggregate list of applications have the same AID; give one of the two applications a new AID so that each application in the aggregate list of applications is identified by a unique AID; and record the mapping between the original AID and the new AID. For example, as shown in Table 4, where there are two virtual smart cards that host an application with a particular AID (e.g. AID 1 ) the intermediary system 106 may be configured to give the second application a new unique AID (e.g. AID 12). The new unique AID may be generated by, for example, modifying the PIX portion of the AID. A mapping between the original AID (AID 1 ) and the final AID (AID 12) may be maintained so that if the interface 108 selects the application with AID 12 the intermediary system 106 can translate or convert that selection command, prior to sending the selection command to the relevant virtual smart card, so that the application with AID 1 is activated. In some cases, it may not be feasible to amend the AID of one of the applications. For example, some EMV terminals are configured to select the application to use for the current transaction by comparing the AIDs of the applications supported by the terminal to the applications supported or hosted by the smart card to see if they are identical and only if they are identical is one selected. In these cases, one of the duplicate applications may be selected in another manner, such as based on user input or one or more criteria as described above.

Table 4

In some cases, the device 100 may also comprise a router 140 that is configured to connect the virtual smart cards to other components of the device 100. The router 140 may maintain a list of virtual smart cards and their state (e.g. disabled, enabled, active, or removed/deleted). In these cases, the intermediary system 106 may be configured to, prior to communicating with a smart card interface 108 of a particular type, request a list of virtual smart cards of the particular type. In response to the request, the router 140 may provide the intermediary system 106 with a list of active virtual smart cards of the particular type on the device 100.

Reference is now made to FIG. 2 which illustrates an example timing diagram 200 which illustrates example messages that may be exchanged between the components of the device 100 of FIG. 1. In this example, the intermediary system 106 requests (at 202) a list of the virtual smart cards of a particular type (e.g. virtual wallet smart cards) from the router 140. The router 140 (at 204) then returns a list of the active virtual smart cards of the particular type on the device 100. In this example, the device 100 comprises two virtual wallet smarts cards - a first virtual wallet smart card 1 (VWSM1 ) and a second virtual wallet smart card (VWSM2) - and so the router 140 returns a list comprising these two virtual wallet smart cards.

At (206) the intermediary system 106 receives a request from a smart card interface 108 for a list of applications supported or hosted by the particular type of smart card (e.g. payment or wallet smart card). The request may be, for example, in the form of a SELECT FILENAME APDU wherein FILENAME is the name of a file or application to be accessed (e.g.‘SELECT 1 PAY1.SYS.DDF0T or‘SELECT 2PAY1 .SYS.DDF0T). In response to receiving the application list request from the smart card interface 108, the intermediary system 106 requests a list of applications supported or hosted from each of the plurality of virtual smart cards of the particular type (e.g. the intermediary system 106 sends an application list request to each of the first and second virtual wallet smart cards) (at 208, 212). The request sent to each virtual smart card of the relevant type may be in the form of a SELECT

FILENAME ADU (e.g.‘SELECT 1 PAY1.SYS.DDF0T or‘SELECT 2PAY1 .SYS.DDF0T). In response to receiving the request for a list of supported or hosted applications each virtual smart card of the relevant type responds with a list of applications supported or hosted by that virtual smart card (210, 214).

Once the intermediary system 106 receives a list of supported or hosted applications from each of the virtual smart cards of the particular type (e.g. from each virtual payment or wallet smart card) the intermediary system 106 generates (at 216) an aggregate list of supported or hosted applications. The intermediary system 106 then sends (at 222) at least a portion of the aggregate list of applications to the smart card interface 108. In some cases, the intermediary system 106 may be configured to send the complete list of aggregate applications to the smart card interface 108. In other cases, the intermediary system 106 may be configured to request input from the user (at 218) on which of the virtual smart cards of the relevant type should be used with the interface. The user may select one, or more than one virtual smart card to use with the smart card interface 218. In these cases, the intermediary system 106 may be configured to only send a list of applications in the aggregate list of applications that are hosted or supported by the user selected virtual smart card(s). In yet other cases, the intermediary system 106 may be configured to automatically filter the aggregate list of applications prior to sending the list of applications based on one or more criteria such as, but not limited to, the current location of the device 100, time of day, proximity to another device, information obtained from one or more external systems, and user preferences. Where only a portion of the aggregate list of applications is provided to the interface 108 then the intermediary system 106 may be configured to record which applications in the aggregate list of applications was provided to the interface 108.

Upon receiving a list of applications (which may comprise all or a portion of the aggregate list of applications) from the intermediary system 106 the interface 108 is configured to select one or none of the listed applications to communicate or interact with. The interface 108 may be configured to select an application in any suitable manner. For example, as described above, an EMV interface may be configured to select one or none of a set of supported payment applications to be used in processing a transaction based on, for example, whether the smart card interface 108 supports a corresponding or compatible application (e.g.

whether the smart card support a Visa® application and the interface is able to process Visa® transactions). An EMV interface may be configured to determine whether the interface and the smart card comprise corresponding, or compatible applications by comparing the AIDs received from the intermediary system 106 and the AIDs of the applications supported or hosted by the interface 108 to see if they match or if they partially match.

If the smart card interface 208 selects one of the applications from the list to communicate or interact with, the smart card interface 208 sends information to the intermediary system 106 that indicates the selected application (at 226). In some cases the information that is sent from the smart card interface 108 and the intermediary system 106 may be in the form of a‘SELECT AID’ ADPU in which the AID is the AID of the selected application. In response to receiving the information indicating the selected application, the intermediary system 106 may be configured to record the selected application and the virtual smart card hosting that selected application (at 228). The intermediary system 106 is then configured to send information to the virtual smart card that hosts or supports the selected application which causes the virtual smart card to activate the selected application. In some cases, the information that is sent from the intermediary system 106 to the relevant virtual smart card 104 to activate the selected application is a‘SELECT AID’ ADPU in which the AID is the AID of the selected application. Although not shown in FIG. 2, in some cases, in response to receiving the information indicating the selected application the virtual smart card may respond with some information. In these case, the intermediary system 106 may be configured to forward any information received from the virtual smart card to the smart card interface 108.

Subsequent to sending information indicating the selected application, the smart card interface 108 may send further communications to the intermediary system 106 to interact with the selected application (at 232). In some cases the subsequent communications may be in the form of a command ADPU. In response to receiving a subsequent communication (e.g. command) from the smart card interface 108 the intermediary system 106 may be configured to recall which virtual smart card is hosting the selected application (at 234) and automatically send the communication (e.g. command) to that virtual smart card (at 236).

For example, in FIG. 2 the second virtual wallet (VWSC2) is hosting the selected application so the intermediary system 106 is configured to provide or forward any subsequent communication (e.g. command) received from the smart card interface 108 to the second virtual wallet smart card (VWSC2). The relevant virtual smart card (e.g. the second virtual wallet smart card (VWSC2) in FIG. 2) processes the communication (e.g. command) and returns a response to the intermediary system 106 (at 238). The intermediary system 106 then forwards the response from the relevant virtual smart card to the smart card interface 108. This process of sending commands and receiving responses may continue until, for example, the interface terminates the session or selects or activates another application.

Reference is now made to FIG. 3 which illustrates an example method 300 of operating a device (e.g. device 100 of FIG. 1 ) that is capable of implementing multiple virtual smart cards by executing software. The method 300 begins at bock 302 where the device 100 implements on the device 100 each of a plurality of virtual smart cards 102, 104 of a particular type (e.g. a plurality of virtual wallet smart cards) by executing software. Each virtual smart card supports or hosts one or more applications. The method 300 then proceeds to block 304 At block 304, the device, facilitates, using an intermediary system 106 of the device 100, communication between the plurality of virtual smart cards and a smart card interface capable of interacting with applications on a physical smart card of the particular type so as to enable the smart card interface 108 to interact with the applications hosted by the plurality of devices by emulating a single smart card that hosts the one or more applications hosted by each of the plurality of virtual smart cards. Emulating a single smart card that hosts the one or more applications hosted by each of the plurality of virtual smart cards may comprise receiving communications (e.g. ADPU packets) from the interface and forwarding those communications (e.g. ADPU packets) to the appropriate virtual smart card and vice versa.

In some cases, emulating a single smart card that hosts the one or more applications hosted by each of the plurality of virtual smart cards may further comprise, in response to receiving a request from the smart card interface for a list of supported or hosted applications, generating an aggregate list of applications supported by all of the virtual smart cards of the relevant type and providing at least a portion of the aggregate list of applications to the interface in response. In some cases, the aggregate list of applications may be generated by requesting a list of hosted or supported applications from each of the virtual smart cards of the relevant type and generating an aggregate list therefrom. In some cases, the complete aggregate list is sent to the interface in response to the request for the list of applications. In other cases, the aggregate list of applications may be filtered prior to sending the list to the interface. For example, the list may be filtered based on input from the user and/or other criteria such as, but not limited to, the current location of the device 100, time of day, proximity to another device, information obtained from one or more external systems, and predetermined user preferences.

The method 300 of FIG. 3 may be implemented by the device 100 of FIG. 1.

The applicant hereby discloses in isolation each individual feature described herein and any combination of two or more such features, to the extent that such features or combinations are capable of being carried out based on the present specification as a whole in the light of the common general knowledge of a person skilled in the art, irrespective of whether such features or combinations of features solve any problems disclosed herein. In view of the foregoing description it will be evident to a person skilled in the art that various modifications may be made within the scope of the invention.

Claims

1 . A device capable of implementing each of a plurality of virtual smart cards by

executing software code, each virtual smart card hosting one or more applications, the device comprising: an intermediary system in communication with the plurality of virtual smart cards and an interface capable of interacting with applications hosted by a smart card; wherein the intermediary system is configured to emulate a single smart card that hosts the one or more applications hosted by each of the plurality of virtual smart cards so as to enable the interface to interact with the applications hosted by the plurality of virtual smart cards.

2. The device of claim 1 , wherein the intermediary system is further configured to: receive a request from the interface for a list of applications hosted by the

intermediary system; and in response to receiving the request, generate an aggregate list of applications hosted by the plurality of virtual smart cards and provide all or a portion of the aggregate list of applications to the interface.

3. The device of claim 2, wherein the intermediary system is further configured to

maintain a mapping between each application in the aggregate list of applications and the virtual smart card that hosts that application.

4. The device of claim 3, wherein the intermediary system is further configured to: receive information from the interface indicating a selected application from the provided list of applications; and forward the indication to the virtual smart card that hosts the selected application based on the mapping.

5. The device of claim 4, wherein the intermediary system is further configured to record which of the applications was selected by the interface so that any subsequent application information received from the interface can be automatically forwarded to the virtual smart card that hosts the selected application.

6. The device of any of claims 2 to 5, wherein each application is identified by an

application identifier and the intermediary system is further configured to: in response to determining that two applications hosted by different virtual smart cards are identified by a same application identifier, identify one of the two

applications by a different application identifier in the aggregate list of applications so that each application in the aggregate list of applications is identified by a unique application identifier.

7. The device of claim 6, wherein the intermediary system is further configured to record in the mapping both an original application identifier and the different application identifier for the one of the two applications.

8. The device of any of claims 2 to 7, wherein the intermediary system is further

configured to: request input from a user of the device as to which of the plurality of virtual smart cards are to be used with the interface; receive input from the user of the device identifying a subset of the plurality of virtual smart cards to be used with the interface; and only provide a list of those applications hosted by the identified subset of virtual smart cards to the interface.

9. The device of any of claims 2 to 7, wherein the intermediary system is further

configured to: automatically filter the aggregate list of applications based on one or more of location and user preferences to generate a filtered list of applications; and only provide the filtered list of applications to the interface.

10. The device of any of claims 2 to 9, wherein the intermediary system is configured to generate the aggregate list of applications by: requesting, from each virtual smart card of the plurality of virtual smart cards, a list of applications hosted by that virtual smart card;

receiving, from each virtual smart card, a list of the one or more applications hosted by that virtual smart card; and

generating the aggregate list of applications hosted by the plurality of virtual smart cards from the lists of one or more applications hosted by the virtual smart cards.

1 1. The device of any preceding claim, wherein: the interface is configured to interact with applications hosted by smart cards of a certain type and the plurality of virtual smart cards are of the certain type; and the intermediary system is configured to identify the plurality of virtual smart cards by requesting a list of virtual smart cards that are of the certain type from a virtual smart card management subsystem that manages virtual smart cards that can be implemented by the device.

12. The device of any preceding claim, wherein: the device comprises a memory; and data defining the software code for implementing each virtual smart card is stored as an image in the memory.

13. The device of claim 1 1 , wherein the device is configured to, in order to implement one of the virtual smart cards: retrieve from the memory the image for that virtual smart card; prepare that image for execution by forming executable code; and execute the executable code.

14. The device of claim 12, wherein the memory images are stored, and the executable code formed therefrom is executed, in a dedicated secure subsystem of the device.

15. The device of any preceding claim, wherein the device stores in a non-transient form data defining each virtual smart card.

16. The device of any preceding claim, wherein the intermediary system is configured to communicate with the interface using near-field communication.

17. A method for operating a device comprising: executing, by a processing circuit, a plurality of virtual smart cards, each virtual smart card hosting one or more applications; and emulating a single smart card that hosts the one or more applications hosted by each of the plurality of virtual smart cards for establishing communications between the virtual smart cards and an interface capable of interacting with applications on a smart card so as to enable the interface to interact with the applications hosted by the plurality of virtual smart cards.

18. A computer program product having stored thereon computer readable instructions that, when executed at a computer system, cause the computer system to perform the method of claim 17.