US8646059B1

Movatterモバイル変換

Info

Publication number: US8646059B1
Application number: US13/244,777
Authority: US
Inventors: Rob von Behren; Jonathan Wall; Alexej Muehlberg; Hauke Meyn
Original assignee: Google LLC
Current assignee: Google LLC
Priority date: 2010-12-17
Filing date: 2011-09-26
Publication date: 2014-02-04
Anticipated expiration: 2031-09-26
Also published as: US8196131B1; US8807440B1

Abstract

Communication between a software application midlet of a contactless payment device and a control applet resident within a secure element of the contactless payment device includes selecting, on the software application midlet, a card applet to configure from a registered list of card applets, the list comprising application identifiers (AIDs) of card applets resident in the secure element; transmitting, through a secure channel, to the control applet on the secure element, the selected card applet's AID and an instruction for a selected function to be performed on the selected card applet; invoking, by the control applet, process method function calls of a card runtime environment, wherein the process method function calls are defined by the card issuer or the card runtime environment for performing the selected function on the selected card applet; and rendering the process method function calls, thereby performing the selected function on the selected card applet.

Description

RELATED APPLICATIONS

This application claims priority to U.S. Provisional Patent Application No. 61/424,609, filed Dec. 17, 2010 and entitled “Multiple Contactless Payment Application, Control, And Architecture.” The entire contents of the above-identified priority application are hereby fully incorporated herein by reference.

TECHNICAL FIELD

The invention relates generally to systems, methods, and devices for controlling multiple card software applications using a control software application, the control and card software applications resident in a secure element of a contactless smart card.

BACKGROUND

Contactless payment technology incorporates proximity communications between two devices to authenticate and enable payment for goods and services over the air (OTA) or without physical connection. Near Field Communication (NFC) is an example of a proximity communication option that can enable contactless payment technologies and that is supported by the Global System for Mobile Communications (GSM) Association. RFID is an example of a proximity communication method that can be adapted to enable NFC contactless payment technology. NFC communication ranges generally range from about 3 to about 4 inches. Such short communication distances limit, as well as, enable secure communication between close field proximity enabled devices. Proximity enabled contactless payment also can be implemented on Code Division Multiple Access (CDMA) devices with an embedded secure element within an NFC controller or a Re-usable Identification Module (R-UIM) type card.

In GSM phones, a proximity enabled (for example, NFC) controller with an antenna is incorporated into the device with the secure contactless software applications located on a smart chip. The smart chip can be further incorporated into one of several exemplary phone components, including a standard Subscribed Identity Module (SIM) card, a separate Mobile Secure Digital Card (for example, a secure digital (SD) card with non-volatile memory, such as EEPROM), or an embedded chip for the payment module purposes. An NFC-enabled contactless payment device enables financial transactions, ticketing, secure authentication, and coupons among several services that are available to the device owner.

The NFC contactless payment device can function as a credit card to enable purchases at the point-of-sale (POS) or even via merchant websites, where in the later case a GSM phone can be used to secure bank information from an authenticating server called a trusted service manager (TSM). The bank information is used in a form entry for payments on a merchant website. The TSM hosts and controls all credit card information sent to or withdrawn from a trusted NFC enabled contactless payment device.

Card software applications can be identified by Application Identifiers (AIDs) and are typically stored within the secure element of the mobile device. AIDs may be standardized by the ISO 7816 specification and include between 5 and 16 bytes. The first five bytes collectively of the AID is called a Registered Identifier (RID), which typically identifies the card company—for example, MasterCard®, Discover®, or Visa®. The subsequent bytes may include the PIX or Proprietary application Identifier Extension, which can be used to identify such information as the application type, version, manufacturer, and other information. The secure element can exist within a removable smart chip, SD card, or embedded within a fixed chip on the mobile device. The secure element allows a wallet software application resident on the mobile device and accessible by the mobile device user to interact securely with certain functions within the secure element, while protecting a majority of the information stored within it. Further, a secure communication channel uses encryption methods for communication between the secure element and external device and software. The secure element on the smart card includes crypto processors for calculating crypto algorithms, memory controller units to manage the Read Only Memory (ROM), Ready Access Memory (RAM), and EEPROM flash memory within the smart card.

SUMMARY

In certain exemplary embodiments, a computer-implemented method for communication between a software application midlet of a contactless payment device and a control applet resident within a secure element of a smart card, the smart card resident in the contactless payment device comprises selecting, on the software application midlet, at least one of plurality of card applets to configure from a registered list of card applets, wherein the registered list comprises application identifiers (AIDs) of card applets resident in the secure element transmitting, through a secure channel, to the control applet on the secure element, the selected card applet's AID, and a computer-coded instruction for a selected function to be performed on the selected card applet; invoking, by the control applet, process method function calls of a card runtime environment, wherein the process method function calls are defined by the card issuer or the card runtime environment for performing the selected function on the selected card applet; and rendering, by the card runtime environment, the process method function calls, thereby performing the selected function on the selected card applet.

In certain exemplary embodiments, a computer-implemented method for using sharable interface objects (SIOs) to share data between a control applet and a plurality of card applets across at least one secure firewall in a secure element of a contactless smart card comprises creating, in the secure element, a control SIO owned by the control applet and at least a card SIO owned by one of the plurality of card applets, wherein the card applet and the card SIO are located within a card memory context, the card memory context separated by the secure firewall from a control memory context comprising the control applet and the control SIO; enabling, in the secure element, the control applet to request access to the card SIO across the secure firewall; and invoking, in the secure element, by the control applet a data request or a data transmission process method function call in the card applet for returning card SIO data to the control applet or transmitting new SIO data to the card SIO, wherein the invoking step is initiated when the request for access in the enabling step is granted.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts a block diagram illustrating systems for controlling multiple secure element based card software applications using a secure element based control software application according to certain exemplary embodiments.

FIG. 2 depicts a block diagram illustrating a system for controlling multiple secure element based card software applications using a secure element based control software application according to certain exemplary embodiments.

FIG. 3 depicts a block diagram illustrating a system for event notification using a self-contained control software application according to certain exemplary embodiments.

FIG. 4 depicts a flowchart illustrating a method for controlling multiple secure element based card software applications using a secure element based control software application according to certain exemplary embodiments.

FIG. 5 depicts a flowchart illustrating a method for controlling multiple secure element based card software applications using a secure element based control software application according to certain exemplary embodiments.

FIG. 6 depicts a flowchart illustrating a method for using sharable interface objects (SIOs) to share data between a control applet and multiple card applets across at least one secure firewall in a secure element of a contactless smart card.

FIG. 7 depicts a flowchart illustrating a method for managing the lifecycle of a card software application received from a remote trusted service manager (TSM) to a secure element of a contactless smart card.

FIG. 8 depicts a flowchart illustrating a method to personalize a card software application for routing external card reader requests to one of a plurality of alternate card software applications.

FIG. 9 depicts a flowchart illustrating a method for communication between a software application midlet of a contactless payment device and a control applet resident within a secure element of a smart card.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

Contactless payment devices typically include smart phones; mobile phones; PDAs; mobile computing devices such as netbooks and iPad®s; other electronically enabled key fobs; electronically enabled credit card type cards; and other devices. Some devices can be used for multiple purposes, including financial transactions, coupons, ticketing, secure authentication, and related applications. An NFC enabled chip is implemented, either independently or on existing components, within the contactless payment device, such as the SIM card, U-RIM card, an embedded chip or an external SD card, or any type of smart card.

The secure element can be contained on the contactless payment device, for example, on a smart card capable of hosting secure elements. In certain exemplary embodiments, SIM cards may be capable of hosting a secure element, for example, an NFC SIM Card. The secure element includes components typical of a smart card such as the crypto processors and random generators. A master file in the file structure of the smart card includes additional files that retain authentication keys and application information within the card. The secure element communicates with an NFC controller and the host controller on the contactless payment device. In an exemplary embodiment, the systems and methods described herein can be implemented in Java, using Java Card for the Smart Card applets and J2ME for the midlet applications running on the contactless payment device. The term “card software application” and “card applet” are used interchangeably in this disclosure to refer to a software applications running within the secure element of a smart card. A midlet, for example, a “wallet midlet” or a “Wallet” software application may be a user-interface software application can be developed as a J2ME midlet, where the midlet can be downloaded and installed in the device. Further, the midlet can be made available to a user of the mobile device via a user-interface for making changes with the contents of the midlet functionality.

Card software application providers typically establish Issuer Security Domain (ISD) within the secure element of a smart card, where the ISD utilize keys on the smart card for communication across ISDs or between data objects created by the applets in different ISDs. The ISD may be used to load and delete payment system packages, to instantiate payment applications from external devices, to instantiate a Trusted Service Manager (TSM) Security Domain for download of payment and other card software applications, to lock/unlock card software applications, and to terminate secure element software applications. A proximity payment system environment (PPSE) provides an application directory listing, according to EMVCo (Eurocard-Mastercard-Visa standards) and the specifications of the various card software applications. An updatable directory listing in a file control information (FCI) template is available to a control software application within the secure element. The FCI may be updated with data obtained from the control application and the TSM. The PPSE may be owned by the issuer of the secure element in the mobile device, where the issuer controls the authentication and approval of software applications installed to the secure element. The payment applications may be loaded on the mobile device as a card software application package, where each package, for example, a MasterCard package, typically contains software code for all supported payment applications within MasterCards” offerings, e.g., Mstripe, Mchip, and any other suitable payment application. The payment application creates data objects to control flow of application data. The payment application and the data objects inside the software application package may be protected by a firewall that is described by virtue of the operating system (OS) that functions as the interface among the multiple software application and the control application. In certain examples, the OS is a Java Card operating system (JCOS).

In certain exemplary embodiments, the card software applications and the control software application may be applets within the JCOS structure. The applets, outside of MasterCard's card software applets, each use full-size AIDs for recognition, and may be applets developed in a Java compiler/converter environment. For certain MasterCard payment applications, a “umbrella application,” referred to herein as the generic software application, for all payment type card software applications may be used, where the first 7 bytes in the AID of each card software application is the same. An instance of the MasterCard payment application may be selected for activation and can be masked using the 7 byte AID, which hides the full-size AIDs from the terminal. The masked AID then redirects the terminal request for an application to the activated instance of the payment application underlying the masked 7 byte AID.

In certain exemplary embodiments, a user preference setting is exposed and controlled by the control software application. Direct access to an instance of the card software application occurs only if the full-size AID is listed. An unselected user preference for an instance of a card application to be listed within the PPSE application directory indicates that the selection of a payment application is rejected. When a full-sized AID is selected, the directory software application then routes payment transaction commands according to user selected settings, directly to the selected instance. Instantiation and creation of a card software instance during post-issuance and routing of the card software application object, as well as personalization commands for the card software application are all functions performed by the control software application, with support from the card software applications being installed.

Java Specification Requests (JSR) may be used in J2ME (Java Micro edition) to standardize various communication channels between the various components in the contactless payment device. In certain exemplary embodiments, the JSR177 specification is used to allow communication between a graphical user interface midlet application on the device operating system and an applet in the secure element of the smart card using application protocol data unit (APDU). The JSR257 specifications allows the midlet application on the device to access the radio interface via the ISA 14443 standard, and also can provide a low level interface to the secure element. JSR177 establishes security and trust for application programming interfaces (API), where the API supports communication between the device and the smart card. A card execution environment, for e.g., in the case of a Java Card, a Java Card Runtime Environment (JCRE) and the Java Card API may be stored in the ROM of the smart card. Payment type card software applications and the control software application can be developed as API Java packages and may be loaded into the volatile flash memory section of the smart card. The card execution environment includes an instruction set for compiling software applications as well as application programming interface (API) function calls. The card execution environment may be implemented via a virtual machine that compiles the overlying software applications to the native machine language of the underlying physical hardware. Java bytecode and .NET bytecode are examples of the instruction set, while Java class libraries and .NET class libraries are examples of the API function calls that can be implemented via a card virtual machine, thereby forming a card execution environment.

In certain exemplary embodiments, security of data objects from each application in the smart card prevents rogue applications and coding errors from stealing data. This security is implemented via applet firewalls in the Java Card Platform. Spaces can be allocated to data objects for the card execution environment (e.g., JCRE for Java Cards), and for each applet and applet group. These spaces are called “contexts.” A “JCRE context” is an allocated space for the java card runtime environment in the smart card temporary memory. Group contexts may be allocated to applets within an application, where an applet performs a sub-routine within an application on the smart card. Each context is separated by an in-built firewall that prevents data objects from being shared. While this implementation safeguards the data objects from other applications, it prevents multiple instances of an application type from sharing information. An application for a single card type, with multiple instances (for different financial instruments) can be developed, where the multiple instances are separate applets, and therefore share the same data objects. When one applet calls another applet within the application group, the control for data objects is transferred to the second applet. Routing of the application to an applet allows an instance of the application to be selected.

In certain exemplary embodiments, the data objects created and owned by each card software application can be shared between multiple applications using shareable interface objects (SIOs). This implementation allows the control software application to control selected data objects from other software applications within the smart card, without including security and firewall procedures. This implementation allows the controller application to review the status of other card software application type applets via review of the data objects generated by each applet. Each applet in the secure element of the smart card is identified by a unique AID. In certain exemplary embodiments, the control software application and each of the card software applications are included within independent applets, each with its own fixed AID. When an applet is created, the JCRE is notified and the applet is registered using the assigned AID of the applet. Thereafter, the JCRE encapsulates the AID bytes into an AID object, which is an object defined by the JCRE system. An applet that creates an SIO for the purpose of sharing may be referred to as the server applet, with the AID object being used by other applets, the other applets being referred to as client applets that use the server AID for identification purposes. The SIO is shareable between other applets through the firewall by the server-client relationship established within the JCRE system. However, the applet that requests the shareable object gains control of the object until it has finished its processes; thereafter, the SIO may be available to the other applets, provided the other applets have the required pre-defined permissions.

The proximity payment service environment (PPSE) is a directory software application that is selected by the terminal reader when the contactless payment device is presented to the reader. Following the above functions that personalize the choice of the payment type card software application, a wallet software application can be used to send management commands, which are used to update the PPSE with the available and active card software applications in the order selected by the user.

System Architecture

FIG. 1 depicts a blockdiagram illustrating systems100 for controlling multiple secure element based card software applications using a secure element based control software application according to certain exemplary embodiments. An external trusted service manager (TSM)108 controlled by a near field communications (NFC)service provider104 hosts and transmits card software applications for installation within thesecure element152 of a contactless smart card inmobile device140. TheNFC service provider104 provides a secure key encrypted software card application for decryption and installation in thesecure element152. The TSM108 includes a trusted service agent, which may be an automated software distribution entity within the TSM. In certain exemplary embodiments, the TSM may be accessible to themobile device140 via theInternet132 directly, without the requirement of amobile services provider136 for the purpose of downloading trusted card software applications to the mobile device. Themobile services provider136 provides card software applications in one of many mobile services protocol, such as 3G and 4G. In certain exemplary embodiments, the TSM108 may exist as a part of themobile services provider136.

In certain exemplary embodiments,external application providers112 provide card software applications to the TSM108 for deployment to themobile device140. In an alternative embodiment, each of theexternal application providers112, may include a TSM for providing trusted card software applications directly to the mobile device via theInternet132 or themobile service provider136. Exemplaryexternal application providers112 includecredit card companies116 for providing credit card type payment card software applications (e.g., Java credit/debit/PayWave/PayPass type applets),ticketing companies120 for providing tickets to events, travel, and other related functions,coupon companies124 for providing coupons that are downloaded and scan-able at a point-of-sale (POS) using the contactless smart card, RFID tags, barcodes,QR 2 dimensional bar codes, and other similar optical coding methods, anauthentication company128 for providing authentication data that may be used to lock/unlock physical appliances or for virtual functions on computer software, and a protectedinformation provider121, such as a bank, merchant, or other financial service provider, for providing confidential or otherwise protected information (for example, account information), which may be used to instantiate a particular card.

When the card software applications have been activated and prioritized, theNFC controller168 is notified of the state of readiness of themobile device140 for an NFC transaction. The NFC controller polls, through theantenna172, a radio signal, or listens for radio signals from areader terminal device176. On establishing a channel between the

devices

172 and176, the reader requests to see the list of available card software applications within thesecure element156. A directory is first displayed, after which, based on the set priority or the type of reader, an application160-164 is chosen and initiated for the transaction.

FIG. 2 depicts a block diagram illustrating asystem100 for controlling multiple secure element based

card software applications

In certain exemplary embodiments, the sharable interface objects (SIOs)236A-X are used to communicated with the software applications and

instances

212,224,240-272 within thesecure element204 of the contactless smart card. The SIOs are owned by the respective software applications and are created at the time of creation of the software applications. To share data across the software applications, the owner of the SIO is designated to be in a server mode control of the SIO, while the recipients function as the clients to the SIO. Data created by the software applications may be stored in the SIO in a recognizable format established by existing standards such as the GP and SECM standards. In certain exemplary embodiments, the AIDs of each of the applications are stored in a list format232 in thecontrol software application224. The control software application includes a list232 of the activate/inactive/non-activatable card software application AIDs in certain format. In certain exemplary embodiments, the list232 typically includes appropriate short and full sized AIDs depending on the type of card software application. Some legacy readers with the requirement to read full sized AID require the corresponding card software application to have their full sized AID listed (e.g.,232).

In certain exemplary embodiments, the active AIDs from thecontrol software application224 typically updates thedirectory software application212. Alternatively, the control software application may server as the directory software application with special privileges to contactless requests from a reader, and different privileges to contact requests from the user internally via the user-interface. Each

card software application

240,252,260, and268 may include instances of their respective applications, such as248 and276. The instances may share the same SIO, where the active instance takes ownership of the SIOs236. The SIO store the application data that defines the issuer of the card software application, the user data within the card issuer application, and possibly a log of transactions tied to the specific card software application and/or its instances. When a

card software application

240,252,260, and268 is enabled, the SIO is active and is accessed by the client modecontrol software application224. The control software application maintains aUPL228 of a list232 of card software applications and their status from each card software application server SIOs236.

In certain exemplary embodiments, areader280 reads thesecure element204 for the first time, thePPSE212 is read by thereader280. The list of availablecard software applications216 are displayed by the AIDs220 to the reader. The reader then chooses or is defaulted to one of the multiple available card software applications. Accordingly, if thereader280 choosess_AID2220B, then the corresponding full AID is retrieved from the control software application. The selected full AID will bef_AID21232F. The correspondingcard software application268 is triggered and the application itself, or itsinstance272, in this case, is activated to the NFC controller for radio transmission of data to the reader.

In certain exemplary embodiments, the user may configure the list in thecontrol software application224, using the wallet application on the user-interface, where the wallet application sends APDU instructions to thecontrol software application224 to perform a function on the selected card software application or its

instances

240,252,260, and268, or theUPL228 on theapplication224.

In certain exemplary embodiments, in the case that the user chooses not to enter a PIN prior to payment, the settings for such processes can be controlled by the user. In case the mobile is powered off and running in virtual card emulation mode where the secure element is powered by the field, the control software application may not access the control functions defined within the device. Implicit access control is provided by the owner of the contactless payment device.

Additionally, in certain exemplary embodiments, only the contact interface performs management commands, and the control software application applet does not have any influence on functionality or security of card software applets. The management commands may be primarily capable of enabling or disabling the selection of the payment application and updating the PPSE file control information (FCI)208 for the application lists216. Thecontrol software application224 is assigned a specific fixed AID and can be called by the external wallet application for selection. Internal to the smart card, the control software application AID may be used by a

card software application

240,252,260, and268, in the server mode (for sharing of data object SIOs as previously discussed), and may have AIDs designated by the operating system of the JCRE (at installation of the card software application) in the absence of an assigned AID. The server mode card or control software application can then verify the AID. The control software application may be the client software application for SIO purposes in event notification functions, for example, instantiation of new contactless payment applications, deletion of instantiation applications, and transaction events, like payments.

The user preference list (UPL)228 stored within thecontrol software application224 as previously discussed may be implemented using registry tags. Information contained within the UPL is illustrated in Table 1 according to certain exemplary embodiments. The items marked “User Defined—UD” are accessible through the secure firewall using the SIOs. The other items are not accessible to the user or other applets, thereby reducing any risk of including data security. In certain exemplary embodiments, the use of a PPSEdirectory software application212 for card software application lists may be merged with the function of theUPL224 of thecontrol software application224, thereby creating a single list which can be accessed by the user-interface via the secure communication channel In this embodiment, changes made by the user to the list on the user-interface can be used to update the UPL on the control software application which is then made available to the reader when the reader terminal requests a list of active applications on the contactless mobile device.

TABLE 1

Application related data: 61

AID: 4F	(ES)	A000000003101001	A000000004001010	A0000000043060	—
Application Short File	(ID)	1	2	3
ID: 94
Priority: 81	(UD)	2	1	3
Lifecycle: 9F70	(ES)	SELECTABLE	SELECTABLE	SELECTABLE
		ACTIVE	NOT_ACTIVE	ACTIVE
Update Counter: 80	(ID)	2	6	1
Discretionary Data: A6
MC indicator: AA	(ID)	false	true	true
Payment system: AB	(ID)	VISA	MCCREDIT	MCDEBIT
Issuer: AC	(ES)	BOA	CITI	WF
‘AlwaysOn’: AD	(UD)	true	false	fase

Event Logging list: A7

Global Event Sequence Counter: A9 (ES)

16

Event: AF

Short File ID: 94 (ID)	Sequence Counter: A8 (ID)	Event ID: AE (ES)

2	12	1
1	13	3
1	14	6
3	15	2

Codes:
Externally supplied—ES
Internally derived—ID
User defined—UD

In certain exemplary embodiments, external commands formatted to the control software applet may be represented by Global Platform (GP) 2.2 standard. The GP 2.2 standard defines Java Card API standards for applets within the secure element. This will allow an easier transition for the next Java Card Open Platform (JCOP) platform for supporting updates and amendments. As shown in Table 1 above, the event logging list can be used to trace the payment events, installation of bank instances, and deletion thereof. The Global Platform type control software application can include a standard format based on the Secure Element Contactless Management or SECM in the Europay, MasterCard, and Visa—the EMV standard, or contactless registry service (CRS), which is GP standard terminology. Further, the card software applet in certain exemplary embodiments is defined to work with both, the GP standard and a SECM standard, where each standard supports a type of on-card software application management. The control software application can implement an APDU instruction set to perform the following exemplary functions per the request of a wallet application: get non-secure information on registered contactless card and external software applications (via the AID of the card software application) and their respective contactless registry information (GP standard reference for the UPL); activate/deactivate contactless card software applications; and respond with a list of conflicting application AIDs, where the APDU also establishes the order of applications in the UPL registry of the control software application by receiving a list of application AIDs. Additionally, some exemplary modules have AIDs that are reserved by the GP standard for the purpose of installing the control software application, including an executable load file AID, an executable module AID, and an application AID. The control software application may typically process the APDU commands, therefore providing the user with expected management capabilities via the user-interface.

The exemplary parameters in the UPL in Table 1 may be accessed through a GET STATUS and SET STATUS command issued by the control software application. The application AID tag “4F” may be a tag within the contactless registry UPL. Partial AID matching is supported when this tag is used as a search criterion in the GET STATUS command. If a length for the AID is not specified in the GET STATUS command, then a complete contactless registry UPL may be returned. In an exemplary embodiment, the GP control software application can be resident outside the security domain because the definition of the GET STATUS and SET STATUS commands require access to only the non-secure status information and not the actual secure data. Application short file ID defines the local namespace of the contactless registry UPL. This item is used by the event logging list to map an application identifier to the software application that produced the event. Priority indicator defines the order in which the payment applications are represented in the PPSE. An entry of “0” means that the respective contactless card software application is not accessible over the contactless interface, for example, the card software application may be disabled by the user or locked by the issuer.

In certain exemplary embodiments, the Application Lifecycle State tag “9F70” provides the application lifecycle state on the first byte as defined in GP2.2 standards. The Contactless Activation State may be encoded on the second byte as defined in GP2.2 standards. The software application discretionary data may be accessible to the wallet application through the control software application, for proprietary usage. In certain exemplary embodiments, if the card software application belongs to MasterCard, a MasterCard indicator may be set in the corresponding cell of Table 1. The tag for the control software application can execute logic on the short-size AID limitation on legacy readers. Value coding may be on one of the tag byte as follows: “A5” indicates not in MasterCard payment system, i.e., false, while “5A” indicates a MasterCard payment system instance, i.e., true.

In certain exemplary embodiments, the system indicator tag codes in Table 1 are provided in ASCII used by the payment system, for example, “VISA.” The issuing bank tags can be coded in ACII, for example, “CITI.” The mechanism to determine the issuer can be done by either using information provided by the trusted service agent (TSA), which is a trusted service manager (TSM) owned off-card software application on the payment device (or wallet application), or information coded in the payment application's PIX. In certain exemplary embodiments, the “Always On” feature from the payment card software application describes a state where a contactless card software application that is activated on a payment device is accessible to a contactless terminal as long as the mobile device is capable of communicating over the antenna interface, even when the payment device is not “switched on”. A card software application in the “Always On” state can be equated to a regular contactless card in that the only action required from the mobile device user to initiate a contactless transaction is the act of presenting the contactless payment device to the contactless terminal. Conversely, a contactless payment card software application that is not in an “Always On” state would need the consumer to take a conscious action on their payment device to make the application accessible prior to the act of presenting the mobile payment device to the contactless terminal. As an example, setting byte data to “A5” in Table 1 indicates not an “always on” or false state, while “5A” indicates “Always On” or true state.

The Event logging list in Table 1 includes recorded transaction events. The on-card software application resident in the secure element initiates an event, for example, a PayPass event, where the last transaction command could signal a payment attempt. In order to support the GP standard, the CRS version of the control software application will reference the contactless registry UPL using the short file application ID and record the global sequence counter value at the time of event. An event ID (identifier) signals what type of event occurred. Events may be triggered by the payment type card software applications that are activated on the mobile payment device. The following events are exemplary events that may be registered in this list, where the byte code is coded in the event ID, for example, application INSTALL—tag, 01, application DELETE—tag 02, application SELECT: 03, application BLOCKED: 04, application UNBLOCKED: 05, PIN VERIFIED: 06, PIN FAILED: 07, and Payment transaction: 08.

Event sequence counter, short file ID, or Event ID are chronologically numbered in the event logging list. The value of the global event sequence counter is recorded, together with the short file ID. Then, events can be identified in order. Event ID specifies what type of event occurred. The Global Event Sequence Counter is a short number, recording the number of all events that occurred. An unsigned overflow is allowed to occur (at a range of 65000 to 0). The trusted service agent (TSA) are software applications within a trusted server manager (TSM) that manage deployment of card software applications to the secure element of contactless smart cards. The trusted service agent (TSA) also manages updates to the deployed card software applications in a remote contactless payment device's secure element based on requests from the user of the contactless payment device or an issuer of the TSM card software application. The UPL in the control software application is self-contained using notification mechanisms through the SIOs.

In certain exemplary embodiments, the control software application SIO uses Shared Notify Service Interface, which is a shareable (tagging) interface for notification of SIO data. The following methods are accessible by card software applications in the format of “notify(AID aid, short event)”: application INSTALL: 01; application DELETE: 02; application SELECT: 03; application BLOCKED: 04; application UNBLOCKED: 05; PIN VERIFIED: 06; PIN FAILED: 07; and Payment Transaction: 08.

In certain exemplary embodiments, the control software application may implement the Shared Notify Service Interface by itself. When a notify message is triggered, the control software application runs instruction based logic to update the UPL.FIG. 3 depicts a block diagram illustrating a system for event notification using a self-contained control software application according to certain exemplary embodiments. A trustedservice agent304 sends a one of a number of available requests312, along with the AID and a card software application for installation, deletion, or another function, each to be performed within thesecure element308 of a contactless smart card. In certain exemplary embodiments, the installapplication312B request is received via theJCRE316. TheJCRE316 includes API classes andmethods320 and324 to perform the functions requested by theTSA304. For an exemplary install function, an installinstruction348A is sent to the card software application represented by the short AID of the full AID reference used in the TSA request (312B). In certain exemplary embodiments, the card software application forcard type C360B is chosen to receive the API function call from theJCRE316 because the full AID the received request includes the short AID of the selectedcard type C360B. This indicates that the received software application may actually be an institutional instance of an existing card software application. Thecard software application360B initiates the installation of the instance of the card software application as received within the secure element.

In certain exemplary embodiments, upon installation, the card software application notifies thecontrol software application328 of the newly installed instance of the card software application. The card software application may simply trigger amethod call352B with the card software Java applet using the full AID of the instance, along with an event ID to indicate the function352 performed on the instance (e.g., install, delete, etc.). Thecontrol software application328 adds336H the AID of the payment card software application or a card software application instance to theUPL332. In certain exemplary embodiments, the card software application applets360 access the control software application SIOs344 from a constructor class instance of thecard software application328, thereby triggering the instantiation event for notification ofdeletion352A,installation352B,transaction352X, and other related functions352.

In certain exemplary embodiments, to ensure the constructor instance is not throwing an exception during instantiation (for example, if an algorithm including a function requested by the TSA is not supported or the contactless smart card memory is not sufficient), event notification352 can be done after JCRE registration of the instance (register method)320. In certain exemplary embodiments, for MasterCard owned card software application instances e.g.,instance364, the event for notification352 can be triggered by a generic software application upon creation of the instance, where the generic software application masks the full AID to support short and long AID implementations from the terminal reader's that reads only the full or only a short sized AID. For the DELETE function348, thesecure element308 operating system OS receives aJCRE316 function348 which marks the card software application instance or the whole card software application package for deletion. If open references are not found, the deleted applet is removed fromregistry328 and the memory is freed by the OS. TheJCRE316 provides an AppletEvent method “uninstall,” which is called, if implemented, before a card software applet360 is deleted. The “uninstall” method allows the instance to execute maintenance before removal. As an example, references can be set to null, or in this case, notification352 is sent to thecontrol software application328 that theinstance364 has been deleted. The control software application then removes the deleted payment card software application entry (AID)336G from theUPL332. As such, this removal allows synchronization of theUPL332 against theactual JCRE registry324D supporting the notification event mechanism.

System Process

In certain exemplary embodiments, external commands available for the CRS (GP control software application) include a SELECT command. The SELECT command initiates the CRS to return file control information (FCI) signaling the version number and global event sequence counter. Here, the data may include the CRS AID, which can be the AID for the control software application. The response to the command is tag “6F”: FCI template, tag “84”: CRS AID, tag “A5”: FCI Proprietary Template, tag “9F08”: version number (2 bytes), Value “01” “00,” tag “A9”: Global Event Sequence Counter (big endian). To obtain a CRS registry entry, the GET STATUS command is used. This command retrieves the CRS registered contactless applications, the Lifecycle status, and other information according to the given match/search criteria. Data on non-contactless payment applications may not be available through this command (for example, the CRS control software application itself cannot be mined). Authentication is not required to process this command. Data secured is of the format tag “4F,” full-size AID, partial AID, where “4F” “00” means complete registry. An alternative response could be “registry entry”: “none” if not found; if found, the data is encapsulated in the application related data tag “61” for the certain exemplary conditions including, one applet in case of full-size matching AID, one or more applets in case of partial AID match, and a complete registry if no AID specified.

The SET STATUS command may be used to modify the “Availability State” of the CRS registered contactless software card application(s), and the priority assigned to the active application list in the PPSE or the FCI. In addition, the SET STATUS command can be used to globally switch on/off the contactless interface. The SET STATUS command may be limited in terms of modification options offered to non-contactless application data. Further, authentication may not be required to process this command. The data targeted by the SET STATUS command for one or more application AIDs includes information corresponding to contactless interface activation/deactivation status, application lifecycle state, and application discretionary data. The response to the command may either be an “OK,” data/signal when the user preference is rendered, a “warning” data/signal when conflict resolution is successful where user preference is executed partially, and/or an “error” data/signal when conflict resolution fails, where the previous user preference is still active. This process is illustrated inFIG. 5.

In certain exemplary embodiments, for the GP specification of a payment environment, an internal method call in the PPSE towards the control software application applet typically modifies the FCI. By way of an example, a function, “setFci(byte[ ] aidList):void”, may be defined that lists parameter AID including tag length value (TLV) of the coded AIDs, where the coding may be defined according to the EMVCo contactless specification. A clearFci( ): void function may be defined for clearing the FCI content in the PPSE. However, for EMV compliant terminals, the PPSE may not show any payment applications on the secure element for this method, and a direct read is performed to an active card software application as illustrated inFIG. 3.

Further,FIG. 3 also illustrates a standard payment transaction and related event notification using a payment type card software application, where the payment is processed as defined by EMV standards to support existingreaders376 according to certain exemplary embodiments. Payment type card software applications allow a selection and a transaction over a contactless radio interface. In certain exemplary embodiments, using the terminal376 selects either the PPSE or an activatedcard software application360X and receives the FCI from the PPSE listing the available card types by the AID. In certain exemplary embodiments, theterminal reader376 may make a default request for a particular card software application. For MasterCard payment applications, in view of the previously described legacy ready issues, the reader terminal matches short-sized AIDs of the MasterCard payment application. The terminal then selects the matching short-sized AID of the MasterCard payment application. Upon receipt of a SELECT command, the MasterCard applet checks if an active bank instance exists, and if yes, then the payment card software application sets routing information for commands to the active bank instance. The SELECT command is forwarded to the active bank instance. If the response is modified, the application exchanges FCI with the short-sized AID of the MasterCard payment application. This response is communicated back to the terminal. If an active bank instance does not exist, the same error status is returned to the terminal as for non-existent AIDs on the card. Thereafter, all proceeding commands and responses are routed to the selected bank instance.

For non-MasterCard payment applications, the terminal will match full-size AIDs, and will select a full-size AID of the payment application. Upon receipt of a SELECT command, the payment card software application checks if selection is enabled, and, if yes, initiates processing functions as previously discussed. If the selection is disabled, the same error status is communicated to the terminal as is returned for non-existent AIDs on the smart card. For access purposes, in an exemplary embodiment, only the wallet application can access the control software application externally. An access control is not needed for any other application, and indirect access control is limited and exercised by the use of a contact interface, ownership of the contactless payment device, or security features on the device, such as hiding API access to the secure element. Additional security can include adding PIN verification, among other methods. The control software application does not exhibit the UPL or any other information internally. The control software application uses UPL for the decision process, for example, what payments applications should be updated with active/inactive (activated/deactivated) information and what content should PPSE exhibit to the terminal. To perform this function, the application follows the SIO method by acting as the client and accessing information via the SIO PPSE and payment applications.

Compared to the PPSE in a card form factor, the PPSE in a mobile contactless payment device may not be static. The user preference for a specific payment instrument may be applied by activating and deactivating certain payment apps and also, by exhibiting directory of available card software applications to the terminal. Such a directory may be contained in the FCI of the device PPSE. The PPSE functionality may conform to the definitions of the EMV specifications in order to support legacy readers. For mobile contactless payment devices, the PPSE can be updatable. In certain exemplary embodiments, the update process is handled internally through the control software application. The EMV approach makes the update process configurable directly using the user-interface, i.e., the wallet application, on the mobile device. The EMV contactless mobile specification commands “PUT TEMPLATE” and “GET TEMPLATE” can be mapped to SIO methods for the control software application. The FCI in the PPSE can be a list similar to the UPL list; however, some differences may be related to the strict structure as defined by EMV, where full-size AIDs of MasterCard payment applications' bank instances may not be listed. Instead, only the first 7 bytes are listed. In this manner, a subset of the UPL is listed (in case the UPL includes strict EMV structure with extensions such as “AlwaysOn.”). This listing is illustrated inFIG. 2, where thedirectory software application212 includes a list of short and full sized AIDs220. When theapplication212 is presented to thereader device280, the reader device may select an application according to the pre-set reader designations or the availability of the activecard software applications240.

In certain exemplary embodiments, thePPSE FCI212 is accessed for reading through the contactless interface, and is not access controlled to support legacy type readers with EMV specifications. Here, all the data in the PPSE may not be distributed to merchants' reader by default, but is available to the user for selection via the user-interface. The user may choose to use the access functionality for specific payments on short distance contactless communication with a specific merchant terminal. The wallet application user-interface may implement configuration options for the data included in the PPSE, where the data can be further distributed, for example, using loyalty programs or pinpointed advertising.

Application Lifecycle Management of on-card application lifecycles are defined in GlobalPlatform (GP) specifications, specifically for contactless in GP 2.2. In certain exemplary embodiments, the existing card lifecycles may be coded on the first byte, while the second byte defines a contactless activation state. The additional three contactless activation states are “ACTIVATED,” “DEACTIVATED,” and “NON_ACTIVABLE.” The contactless activation state byte may be encoded independently of the application lifecycle state byte. The value of the contactless activation state byte can be retrieved independently using the GET STATUS command from the CRS control software application. A card software application currently in the “ACTIVATED” state is able to communicate through the contactless interface. Conversely, an application currently in the “DEACTIVATED” state may not able to communicate through the contactless interface. An application in the “NON_ACTIVATABLE” state is implicitly DEACTIVATED due to some internal reason known by the application or its provider (for example, a possible attempt of fraudulent use), and cannot be ACTIVATED by the control software application. Any attempt to activate an application that is currently in the NON_ACTIVATABLE state typically fails.

In certain exemplary embodiments, transitions between the three contactless activation states abide by certain rules maintained by the control software application. In an exemplary rule, an application may always able to transition itself into the “DEACTIVATED” state automatically. In another exemplary rule, an application cannot transition itself into the “ACTIVATED” state without user permission and in yet another rule, an application may transition itself into the “NON_ACTIVATABLE” state at any time, thereby indicating to the OPEN that it is both deactivated, and not in a suitable internal state to become ACTIVATED on the contactless interface. Further, an application may be able to transition itself from the NON_ACTIVATABLE state to the DEACTIVATED state, thereby indicating to the OPEN that it is in a suitable state to become ACTIVATED again. In addition, certain rules may also be applied to the lifecycle process for communication with the contactless interface. In one exemplary rule, an application may not communicate through the contactless interface if it is not in a selectable state (in particular, when the application is in the LOCKED state). Further, when an Application is unlocked, the contactless activation state remains in the same state as it was prior to being in the LOCKED state, which means that the wallet application should be cautious while setting the contactless activation state to DEACTIVATED.

In certain exemplary embodiments, personalization of certain card software applications may not be compliant to EMV and other payment system standard specifications. This may be a result of the application objects that are created, and may not be directly available for use via a full-size AID compared to a payment card software application on a card (form factor). MasterCard in legacy reader devices may not support short-sized or partial AIDs. A personalization flow modification and personalized commands can be considered in this case. In certain exemplary embodiments, support for legacy readers can be implemented on a personalized PPSE. The card software applications that access the issuer secure domain (ISD) of the contactless smart card can be accessed for customized GP API creation using the issuer secure domain (ISD) keys. The personalization method, in certain exemplary embodiments, is performed by injecting personalization keys encrypted with an ISD data encryption key (DEK) to the ISD to access existing card software applications. A payment card software application may be selected and authenticated using the personalization keys for customization purposes.

In certain exemplary embodiments, all card software applications other than the MasterCard type card software applications may be allocated a memory size limitation. The persistent memory typically stores code and data, while transient memory can provide such data as the number of instances of card software applications available to the user. For example, only two MChip instances may be installed within the smart card. Further, it may be possible to free memory for a removed payment application, but it may not be possible to free memory in the secure element for a deselected application. When only one card software application and its instance exists, then the AID length can be set to a default at 7 bytes, while more than one instance changes the AID length requirement to 8 bytes.

FIG. 4 depicts a flowchart illustrating amethod400 for controlling multiple secure element based card software applications using a secure element based control software application according to certain exemplary embodiments. The method includes receiving a card software application AID and a software code for an instruction to be performed on the selected card application applet as represented inblock405. Inblock410, the received software code instruction is executed within the secure element to perform certain functions on the card software application represented by the received AID.

In certain exemplary embodiments, the received software coded instruction may be a short software coded remote method invocation (RMI) to an existing API within the secure element to perform a function on the selected card software application. In another exemplary embodiment, the software coded instruction may be the function itself that is rendered within the virtual machine in the secure element of the smart card. Further, if the software coded instruction is received from the wallet application, then the instruction is in the APDU format, and may be issued to a process method of the card software applet representing the selected AID. The instructions may include at least, “install,” “delete,” “activate,” “deactivate,” and “prioritize.” The prioritize instruction contains information on where to place the selected card software application from among the list of registered active card software applications.

Block

415 triggers an update to the registeredlist332 of card software applications stored with a software coded tag responsive to the instruction performed. The tags are stored in theevent logging list340 as depicted inFIG. 3. The updated list of the card software application is synchronized, via an update, block420, with the PPSE list, or in the alternative, the PPSE list is directly altered to reflect the changes requested by the software coded instruction. In certain exemplary embodiments, the software coded instructions are rendered via the control software application to the list of registered applications within the PPSE applet, thereby eliminating the redundancy of a UPL and a PPSE based FCI list.

FIG. 5 depicts a flowchart illustrating a method for controlling multiple secure element based card software applications using a secure element based control software application, block500, according to certain exemplary embodiments. A user request on the user-interface of the control software application inblock500 modifies the PPSE in block504 and the UPL inblock512. The PPSE in block504 may be indirectly updated using a synchronization of the updates made to the UPL inblock512, after updating the UPL. The terminal reader represented byblock508 polls for radio wave based devices in the vicinity of the reader. When the reader device appears, the reader inblock508 requests the root or default directory, thePPSE block520 in this case, for analyzing the transaction options available to the reader.

In certain exemplary embodiments, the FCI directory list is returned to the user in short sized (7 byte) AIDs depicted inblock524. The terminal process inblock528 analyzes the data received and selects a 7 byte AID among the FCI list. The selected 7 byte AID is sent, referenced inblock532, to the card software applications list (UPL) in the control software application. Inblock540, the selected short AID is compared to the UPL list to retrieve the full size AID related to it. The SIO of the selected full size AID is accessed via a client mode function for the control software application and the full size AID with SIO data is returned to the control software application, perblock544. The full size AID is exchanged for the related 7 byte AID, and the data, along with the 7 byte AID, is transmitted to the terminal for processing, block556. The 7 byte AID and its related full sized AID are then used for the next set of card software related function transactions with the UPL providing the exchange of short and full size AID at each transaction process shown in blocks560-572.

FIG. 6 depicts a flowchart illustrating a method600 for using sharable interface objects (SIOs) to share data between a control applet and multiple card applets across at least one secure firewall in a secure element of a contactless smart card, according to certain exemplary embodiments. The contactless smart card includes a number of software applications, each designed to perform certain pre-defined tasks. By way of an example, a directory software application (e.g., the PPSE) may be accessible to an external card reader to present the reader with options of the active card software applications available for transactions from the contactless smart card. The card software applications communicate with an external card reader to provide credit/debit account information, coupon information, membership information, loyalty information, and other related applications via APDU commands as described above. A control software application communicates with the card software applications and also may communicate with an external software application outside the secure element, e.g., a user-interface software application rendered on a contactless payment device that is in electronic, optical, or radio contact with the contactless smart card. In one example, a contactless payment device may be a mobile phone, while the contactless smart card may be incorporated within a SIM card, U-RIM card, an embedded chip or an external SD card, or any type of smart card, as discussed above.

When applications and their instances reside within the same context, the SIOs related to the application and their instances may be shared by each of the other instances within the context without special access requests. Accordingly, a card software application, which in a Java Card implementation is a card applet, may obtain data from SIO fields of other instances of the card applet by requesting the data directly from the parent applet that owns the SIO. However, when for application packages that are installed in one application memory context, their SIOs are limited for access by firewalls of the application memory context. In an exemplary embodiment, block610 depicts the step in method600, for enabling applets to request for access to SIOs across a firewall, where the requisition is implemented viablock615, using process method function calls of the runtime environment. Accordingly, a software application or its instance that resides in a different application memory context has to perform a client role by initiating an access request via the runtime environment process method function calls to a server card applet including the intended SIO data to be accessed across the firewall. After access is granted, block620 depicts a method step, where the client software application may invoke process method function calls in the server applet to access the data in the server applet's SIO.

Inblock625, an exemplary embodiment of tracking information related to one of a number of SIOs is depicted. The control applet and the directory applet stores a registered list of card applets available within the smart card device. The directory applet may only register the active card applets from data provided by the control applet on the status of each of the card applets. The data provided by the control applet is stored in pre-defined fields of the control applet SIO as illustrated inFIG. 2 at236B. Only the active instances or application packages (illustrated as220 inFIG. 2) from the control application SIO are listed in the directory application SIO, and may be presented to an external card reader. Accordingly, when an SIO owned by a card applet is accessed by the control applet or the directory applet for performing an action on the card applet, such action is recorded by updating data tags related to the card applet viablock625. Actions performed on the card applet include, a delete action, a select event, a block event, an unblock event, a personal identification number (PIN) verified event, a PIN failed event, and a payment transaction event. The data tag is illustrated inFIG. 3 at336G-H, where thedata228 is retrieved from the SIO of the control applet.

FIG. 7 depicts a flowchart illustrating a method for managing the lifecycle of a card software application received from a remote trusted service manager (TSM) to a secure element of a contactless smart card, according to certain exemplary embodiments. Card software applications may be downloaded to the secure element of a smart card from remote servers via a wireless connection offered by a mobile service provider or a direct to server connection using Wi-Fi. In a Java Card implementation, the card software applications are card applets, which may be installed within the secure element for use with an external card reader. The card software application includes information related to the type of transaction function the application will perform. By way of an example, the card software application may be used to access a credit card account, a debit card account, a loyalty card account, a web-based coupon account, a membership account, a gift card account, or an access card account. The account information is stored within the card and is verified by an external card reader using secure contactless communication with the card software application on the card.

Block

The TSM also provides instructions to the contactless smart card based on requests received by a user of the contactless smart card. By way of an example, if the user wants to activate/deactivate a card software application registered within the control software application, the user issues a request to the control software application. However, the user may not be able to directly send data or instructions for functions to the control software application, as the controls software application is resident within the secure element. Accordingly, the user needs to secure authentication for instructions prior to the control software application receiving and rendering the instruction. The TSM provides authentication for instructions received by the smart card from the user of the smart card device. When the smart card is embedded within a contactless payment device, the user may provide an instruction via a user-interface software application that renders on the contactless payment device.

In a Java Card implementation, a user-interface MIDlet is deployed on the contactless payment device, where the MIDlet passes user input to the runtime environment (or JCRE) of the smart card, and the runtime environment authenticates the instructions via process method function calls to the TSM. The authenticated computer coded instruction is sent to the runtime environment for rendering. Alternatively, the TSM may issue pre-defined instructions for such exemplary external functions, as blocking/unblocking a card software application because of such issues as a theft, over-uses, or account overdraft. Such pre-defined instructions do not need external requests to the control software application, but may deploy directly to the control software application for rendering.Block710 depicts a step ofmethod700 wherein the TSM sends one of number of available instructions to be performed on the card software application. The instruction from the TSM may be in the form of a software code to invoke a process method function call of the card runtime environment.Block720 uses process methods in the card runtime environment to update the card application status tag in the control software application with a computer code related to the instruction performed.

FIG. 8 depicts a flowchart illustrating amethod800 to utilize a card software application to route external card reader requests to one of a plurality of alternate card software applications, according to certain exemplary embodiments.Block805 depicts the selection of a card software application, where process method function calls using the appropriate AID of one of a number of registered card software applications is selected. Inblock810, an authentication process is performed to enable an external device, for example, the contactless payment device or an external device, to edit the selected card software application. In one example, the authentication is implemented by using issuer security domain (ISD) keys, which are accessible via process method function calls defined by the issuer of the smart card for the card runtime environment. The ISD keys may be defined by the card issuer to protect application memory contexts within the secure element. The ISD key may offer a firewall type protection for applications in the secure element.

Block

815 depicts the editing step of the exemplary embodiment ofmethod800. Once an external device gains access to the card software application, certain data fields may be edited. In certain exemplary embodiments, the file control information (FCI), a priority status tag, and application discretionary data may be edited. Applets, in the form of the control software application or the card software application typically return a success status when an external card reader selects an application. However, when the selected card software application's FCI data is activated, then the selected card software application returns the FCI data retrieved from an SIO that includes the FCI data as an object field. The FCI data is returned in a tag length value (TLV) format as disclosed above. The FCI data may be edited to include additional AID bytes, where the external card reader selects a short (or 7 byte) AID, and the selected card software application automatically routes the selection to an instance of the card software application, the instance including a full sized AID.

Further, the edited FCI can be edited to include routing information to route an external card reader request received at the card software application to an alternate AID of an alternate card software application. The editing and routing in the card software application enables the smart card to route external card reader requests to any underlying active instance of the card software application. Accordingly, multiple instances of a card software application may reside on the smart card, with one of the instances designated as an active instance. Further, in the case of a legacy reader that may read a short sized AID with 7 bytes of AID data, the reader may be routed to the complete AID using the edited AID as an intermediate routing application.

Block

820 depicts the installation process that follows the editing, where the edited card software application is installed for “make selectable,” which causes the runtime environment to instantiate a related card sharable interface object (SIO), the card SIO including the alternate AID defined for retrieval by the FCI as described above.

As mentioned previously, themethod800 is useful with secure element payment applications for legacy readers. Certain legacy readers recognize only applets having a short-form AID. However, the long-form AID applets can allow more functionality and specifically can allow use of multiple software applications within a mobile device. A legacy card reader requests invocation of a software applet based on the short-form AID known to the legacy card reader. A router applet operating on the mobile device receives the request for the short-form AID applet, determines the long-form AID applet corresponding to the short-form AID applet, and routes the request to the long-form AID applet, thereby invoking the long-form AID applet. In this manner, legacy readers that have stored therein only the short-form AID applet can invoke the functionality of the long-form AID applet on the smart card. Additionally, newer readers implementing the long-form AID applet can request directly the long-form AID applet.

FIG. 9 depicts a flowchart illustrating amethod900 for communication between a software application midlet of a contactless payment device and a control applet resident within a secure element of a smart card, according to certain exemplary embodiments. In a Java Card implementation, a midlet is a user accessible software application, while the applet is typically an embedded software application with the secure element, inaccessible to external software applications and users. Accordingly, a software application midlet residing outside the secure element may need TSM authentication prior to performing various functions on the card software applications within the secure element. A secure channel for communication may be implemented for enabling the midlet to communicate with the applet, thereby enabling certain functions to be performed without TSM intervention. The secure element typically provides cryptographic and firewall blocks against external access to an applet within the secure element. ISD keys defined by the card issuer or the card runtime environment can be made available to the midlet to access the secure channel.

Many primary functions, such as de-activate and activate for a card applet within the secure element require TSM permissions prior to implementation. Using ISD keys, via process method function calls of the card issuer or the card runtime environment, allows some primary functions to be performed on a card applet using input from a user on an insecure midlet.Block905 depicts a selection step to identify at least one card applet to configure from a midlet residing outside the secure element. The selection step uses the AID of the intended applet to identify the applet. In an exemplary embodiment, the midlet recognizes the name of the card applet from the user input and extracts an AID related to the name, where the AID is used for the remainder of the steps.Block910 includes application programmable interface (API) function calls for transmitting the AID of the selected card applet, and for encrypting and transmitting a computer coded instruction for a function to be performed on the card applet. The stored keys in the secure element can be used to verify and decrypt the receiving computer-coded instruction.Block915 depicts an invoking step, where the control applet initiates process method function calls defined by the card issuer or the card runtime environment. The invoked process method function calls perform the selected function defined in the computer-coded instruction selected by a user on the midlet. The card runtime environment renders, viablock920, the process method function call, thereby performing the selected function on the selected card applet.

One or more aspects of the invention may include a computer program that embodies the functions described and illustrated herein, wherein the computer program is implemented in a computer system that includes instructions stored in a machine-readable medium and a processor that executes the instructions. However, it should be apparent that there could be many different ways of implementing the invention in computer programming, and the invention should not be construed as limited to any one set of computer program instructions. Further, a skilled programmer would be able to write such a computer program to implement an embodiment of the disclosed invention based on the appended flow charts and associated description in the application text. Therefore, disclosure of a particular set of program code instructions is not considered necessary for an adequate understanding of how to make and use the invention. The inventive functionality of the invention will be explained in more detail in the following description of exemplary embodiments, read in conjunction with the figures illustrating the program flow.

The exemplary methods and acts described in the embodiments presented previously are illustrative, and, in alternative embodiments, certain acts can be performed in a different order, in parallel with one another, omitted entirely, and/or combined between different exemplary embodiments, and/or certain additional acts can be performed, without departing from the scope and spirit of the invention. Accordingly, such alternative embodiments are included in the inventions described herein.

The exemplary embodiments can be used with computer hardware and software that perform the methods and processing functions described above. As will be appreciated by those having ordinary skill in that art, the systems, methods, and procedures described herein can be embodied in a programmable computer, computer executable software, or digital circuitry. The software can be stored on computer readable media. For example, computer readable media can include a floppy disk, RAM, ROM, hard disk, removable media, flash memory, memory stick, optical media, magneto-optical media, CD-ROM, etc. Digital circuitry can include integrated circuits, gate arrays, building block logic, field programmable gate arrays (“FPGA”), etc.

Although specific embodiments have been described above in detail, the description is merely for purposes of illustration. It should be appreciated, therefore, that many aspects described above are not intended as required or essential elements unless explicitly stated otherwise. Various modifications of, and equivalent acts corresponding to, the disclosed aspects of the exemplary embodiments, in addition to those described above, can be made by a person of ordinary skill in the art, having the benefit of the present disclosure, without departing from the spirit and scope of the invention defined in the following claims, the scope of which is to be accorded the broadest interpretation so as to encompass such modifications and equivalent structures.