Enabling users to select between secure service providers using a key escrow service

Information

  • Patent Grant
  • 9450927
  • Patent Number
    9,450,927
  • Date Filed
    Monday, March 18, 2013
    11 years ago
  • Date Issued
    Tuesday, September 20, 2016
    7 years ago
Abstract
Systems and methods are described herein for enabling users to select from available secure service providers (each having a Trusted Service Manager (“TSM”)) for provisioning applications and services on a secure element installed on a device of the user. The device includes a service provider selector (“SPS”) module that provides a user interface for selecting the secure service provider. In one embodiment, the SPS communicates with a key escrow service that maintains cryptographic keys for the secure element and distributes the keys to the user selected secure service provider. The key escrow service also revokes the keys from deselected secure service providers. In another embodiment, the SPS communicates with a central TSM that provisions applications and service on behalf of the user selected secure service provider. The central TSM serves as a proxy between the secure service providers and the secure element.
Description
TECHNICAL FIELD

The present disclosure relates to systems and methods for enabling mobile device users to select from available Trusted Service Managers (“TSMs”) for completing secure transactions, communications, and other tasks.


BACKGROUND

The current Near Field Communication (“NFC”) eco-system relies on a piece of hardware commonly referred to as a “secure element” installed on communication devices to provide a secure operation environment for financial transactions, transit ticketing, identification and authentication, physical security access, and other functions. A secure element generally includes its own operating environment with a tamper-proof microprocessor, memory, and operating system. A Trusted Service Manager (TSM), among other things, installs, provisions, and personalizes the secure element. The secure element has one or more keys that are typically installed at manufacture time. A corresponding key is shared by the TSM so that the TSM can establish a cryptographically secure channel to the secure element for installation, provisioning, and personalization of the secure element while the device having the secure element is in the possession of an end user. In this way, the secure element can remain secure even if the host CPU in the device has been compromised.


The problem with current NFC systems is that there is a tight coupling between the secure element and the TSM. For current deployments, only one TSM has access to the keys of a particular secure element. Therefore, the end user can choose to provision secure element features that are supplied by the one TSM only. This TSM is typically chosen by the manufacturer of the device. For example, a smart phone manufacturer may select the TSM for smart phones under guidance from a Mobile Network Operator (“MNO”), such as SPRINT or VERIZON, that purchases the smart phone rather than the end user. Thus, the TSM features available to the end user may not be in the end user's interest. As an example, the MNO may have a business relationship with one payment provider, such as MASTERCARD or BANK of AMERICA, only. That TSM may allow the secure element to be provisioned with payment instructions from the one payment provider only. Thus, the end user would not be able to access services from other payment providers, such as VISA.


SUMMARY

In certain exemplary embodiments, a method for providing secure services to a network device having a secure element includes a computer maintaining at least one cryptographic key for the secure element. The at least one cryptographic key is operable to provide secure access to the secure element via a secure communication channel. The computer receives from the network device a selection of a secure service provider. The computer transmits the at least one cryptographic key to the selected secure service provider in response to receiving the selection.


These and other aspects, objects, features, and advantages of the exemplary embodiments will become apparent to those having ordinary skill in the art upon consideration of the following detailed description of illustrated exemplary embodiments, which include the best mode of carrying out the invention as presently perceived.





BRIEF DESCRIPTION OF THE DRAWINGS


FIG. 1 depicts a Near Field Communication (“NFC”) system, in accordance with certain exemplary embodiments.



FIG. 2 is a block flow diagram depicting a method for changing secure service providers in the NFC system of FIG. 1, in accordance with certain exemplary embodiments.



FIG. 3 depicts another NFC system, in accordance with certain exemplary embodiments.



FIG. 4 is a block flow diagram depicting a method for changing secure service providers in the NFC system of FIG. 3, in accordance with certain exemplary embodiments.





DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

Overview


The methods and systems described herein enable an end user of a communication device, such as a mobile phone, to select a secure service provider to use with a secure element stored on the communication device. In one embodiment, a system includes a key escrow service that manages cryptographic keys for one or more users and one or more secure service providers. Typically, the secure element and one or more cryptographic keys for the secure element are installed on each user communication device at the time that the communication devices are manufactured. These keys or corresponding keys are provided to the key escrow service. Each user device also includes a service provider selector (“SPS”) module or software application that enables the users to select from available secure service providers. The SPS transmits, via a secure channel, information identifying the selected service provider to the key escrow service in response to a user selection. The key escrow service provides the key for the user's secure element to a Trusted Service Manager (“TSM”) of the selected secure service provider. The key escrow service also revokes the key for the user's secure element from the TSM of the user's previous secure service provider. In addition, the SPS can prevent unauthorized secure service providers, such as the previous secure service provider, from accessing the secure element.


In another embodiment, a central TSM performs business logic and application provisioning on behalf of other secure service providers. Rather than distributing the cryptographic keys to selected secure service providers, the central TSM acts as a proxy between the selected secure service provider and the secure element installed on the communication device.


The exemplary systems and methods described herein overcome the deficiencies of conventional NFC systems that allow users to access services of one secure service provider only. Rather than being limited to the functionality and services provided by the one secure service provider, the user can select from multiple secure service providers. For example, if a secure service provider does not provide services that the user desires, such as making payments via a particular brand of credit card, the user can select a secure service provider that does provide these services.


One or more aspects of the exemplary embodiments may include a computer program that embodies the functions described and illustrated herein, wherein the computer program is implemented in a computer system that comprises 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 exemplary embodiments in computer programming, and the exemplary embodiments 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 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 exemplary embodiments. Moreover, any reference to an act being performed by a computer should not be construed as being performed by a single computer as the act may be performed by more than one computer. The functionality of the exemplary embodiments will be explained in more detail in the following description, read in conjunction with the figures illustrating the program flow.


Turning now to the drawings, in which like numerals indicate like (but not necessarily identical) elements throughout the figures, exemplary embodiments are described in detail.


System Architecture



FIG. 1 depicts a Near Field Communication (“NFC”) system 100, in accordance with certain exemplary embodiments. As depicted in FIG. 1, the system 100 includes one or more end user network devices 110, one or more application providers 180, a key escrow service 150, a mobile network operator (“MNO”) 130, and multiple secure service providers 160. Each of the application providers 180, key escrow service 150, and secure service providers 160 include a network device configured to communicate via the Internet 140. For example, each of the application providers 180, key escrow service 150, and secure service providers 160 may include a server, desktop computer, laptop computer, tablet computer, smartphone, handheld computer, personal digital assistant (“PDA”), or any other wired or wireless, processor-driven device. In one embodiment, the key escrow service 150 includes (or is communicably coupled to) a first network communication module for receiving requests to change (or select) from available secure service providers 160 and a second network communication module for transmitting cryptographic keys 120 to secure service providers 160. The first and second network communication modules may be the same or different network communication modules.


The end user network devices 110 may be mobile phones, smart phones, PDAs netbook computers, laptop computers, tablet computers, or any other wired or wireless, processor-driven device. As shown in FIG. 1, the end user network devices 110 access the Internet 140 via the MNO 130. Exemplary MNOs include VERIZON, SPRINT, and AT&T. The MNOs provide Internet access to the end user network devices 110 via a mobile network (not shown), such as a 3G or 4G mobile communication network. Of course, the end user network devices 110 can access the Internet 140 via other mechanisms, such as Wi-Fi in connection with an Internet provider.


The end user network devices 110 each include a secure element 111 having one or more cryptographic keys 120, an NFC controller 112, an NFC antenna 113, an host CPU 114, and an SPS 115. The NFC controller 112 and the NFC antenna 113 enable the end user network device 110 to communicate with other NFC-enabled devices (not shown). For example, the end user network devices 110 can communicate with NFC-enabled merchant point of sale (“POS”) devices, ticketing devices, security devices, and other end user network devices 110.


The host CPU 114 executes applications stored on the end user network device 110. For example, the host CPU 114 may execute applications that interact with the NFC controller 112, such as NFC payment applications that enable the user operating the end user network device 110 to complete purchases via an NFC-enabled POS or a transit or event ticketing application that enables the user to enter a transit facility or event via an NFC-enabled ticketing POS. Other applications, including identification, authentication, security, and coupon clipping and redemption applications, also may be stored on the end user network device 110 for execution by the host CPU 114 in connection with the NFC controller 112 and the NFC antenna 113.


Each of the applications may be provided by a respective application provider 180. For example, a credit card company may provide a credit card payment application; a transit or other ticketing company may provide a ticket purchasing and redemption application; a manufacturer, retailer, or other entity that sells products or services may provide a coupon application; and an authentication company may provide a user authentication application.


NFC applications are typically stored in the secure element 111 of the end user network device 110 for security purposes. The secure element 111 provides a secure operating environment for the NFC (or other) applications. The secure element 111 typically includes its own operating environment with tamper-proof microprocessor, operating system, and memory for storing information, such as payment credentials. The secure element 111 may exist within a fixed chip of the end user network device 110, a Subscriber Identification Module (“SIM”) card, a Universal Integrated Circuit Card (“UICC”), a removable smart chip, or in a memory card, such as a microSD card. The secure element 111 also may include a memory controller for managing Read Only Memory (“ROM”), Ready Access Memory (“RAM”), and EEPROM flash memory of the card or chip in which the secure element 111 is installed.


In general, the secure service providers 160 serve as intermediaries that assist application providers 180 and other service providers in securely distributing and managing applications and services, such as NFC contactless applications services. A TSM 170 of the secure service provider 160 typically hosts the applications and installs and provisions the applications onto the secure element 111. As shown in FIG. 1, each TSM 170 can receive, store, and utilize the keys 120 for users' secure elements 111. By having the keys 120, the TSM 170 can access the secure elements 111 via a secure encrypted communication channel to install, provision, and customize applications within the secure elements 111. Exemplary secure services providers 160 include GEMALTO and FIRST DATA.


In certain exemplary embodiments, the secure service providers 160 bypass the host CPU 114 and the NFC controller 112 when communicating with the secure element 111. For example, in certain UICC/SIM secure elements, the secure service providers 160 communicate with the secure element 111 via a radio CPU (not shown) installed on the end user network device 110. Thus, the involvement of the NFC controller 112 and the host CPU 114 may be optional during the provisioning of applications on the secure element 111 in certain exemplary embodiments. In certain exemplary embodiments, the host CPU 114 and the radio CPU interact with one another to coordinate access controls to the secure element 111.


The key escrow service 150 maintains the keys 120 for the secure elements 111. The key escrow service 150 also distributes the keys to the TSMs 170, for example in response to a user selection. For instance, if a user elects to switch from a first secure service provider 160A to a second secure service provider 160B, the key escrow service 150 revokes the keys 120 from the first TSM 170A and provides the keys 120 to the second TSM 170B. The second TSM 170 can then access the secure element 111 of the user's network device 110.


The SPS 115 is implemented in software and/or hardware and enables the user of the end user network device 110 to select or change secure service providers 160 via the key escrow service 150. The SPS 115 provides a user interface that allows the user to make a selection of a secure service provider 160. In response to a user selection, the SPS 115 transmits information regarding the selected secure service provider 160 to the key escrow service 150. The key escrow service 150 also can confirm the selection via one or more off-path mechanisms. The SPS 115, key escrow service 150, and other components of the exemplary system 100 are described in more detail hereinafter with reference to the method depicted in FIG. 2.



FIG. 3 depicts another NFC system 300, in accordance with certain alternative exemplary embodiments. The exemplary system 300 includes many of the same components as the system 100, including one or more end user network devices 110, one or more application providers 180, an MNO 130, and multiple secure service providers 160. However, rather than a key escrow service 150, the system 300 includes a central managed TSM 350. The managed TSM 350 includes a network device configured to communicate with the Internet 140, such as a server, desktop computer, laptop computer, tablet computer, smartphone, handheld computer, PDA, or other wired or wireless, processor-driven device. Similar to the key escrow service 150, the managed TSM 350 maintains the keys 120 for the secure elements 111 and enables the users operating the end user network devices 110 to select from multiple secure service providers 160. Rather than distributing the keys 120 to the selected TSMs 170, the managed TSM 350 can interact with the secure elements 111 on behalf of the selected secure service provider 160. That is, the managed TSM 350 can install, provision, and interact with applications installed on the secure elements 111. Or, the managed TSM 350 can establish (and terminate) a secure communication channel between the selected TSM 170 and the secure element 111 such that the selected TSM 170 can interact with the secure element 111. This secure communication channel may be encrypted with a different key that is not associated with the secure element 111, and may be specific to each secure service provider 160. The managed TSM 350 also can perform business logic on behalf of the secure service providers 160. The managed TSM 350 and other components of FIG. 3 are described in more detail hereinafter with reference to the method depicted in FIG. 4.


System Process



FIG. 2 is a block flow diagram depicting a method 200 for changing secure service providers in the NFC system 100 of FIG. 1. The method 200 is described with reference to the components illustrated in FIG. 1.


In block 205, one or more secure cryptographic keys 120 are provided for a secure element 111. In certain exemplary embodiments, the secure element 111 and its keys 120 are installed on an end user network device 110 at manufacture time. In certain exemplary embodiments, the secure element 111 and its keys 120 are installed on a removable card or chip, such as a SIM card or microSD card, that is later installed on the end user network device 110.


In block 210, the keys 120 for the secure element 111 or corresponding keys are provided to the key escrow service 150. These keys 120 enable the key escrow service 150 (or another entity that receives the keys 120) to create a secure communication channel with, and gain access to, the secure element 111. Optionally, the keys 120 also are provided to a TSM 170 of a secure service provider 160. Conventionally, the secure service provider 160 and the TSM 170 for the secure element 111 are selected by the manufacturer of the end user network device 110, typically under guidance from the MNO 130 that purchases the end user network device 110. In this case, the keys 120 may be provided to that TSM 170. Alternatively, the keys 120 are provided to the key escrow service 150 only. In this case, the user operating the end user network device 110 (or another entity, such as the MNO 130) can make an initial selection of secure service providers 160 using the SPS 115.


In block 215, the user selects a secure service provider 160 and thus, a TSM 170, using the SPS 115. For example, the user may access the SPS 115 using the end user network device 110. The SPS 115 may present a user interface that lists available secure service providers 160 and optionally the services supported by the secure service providers 160. For example, the SPS 115 may display financial institutions for which contactless transactions are supported by each secure service provider 160. In another example, the SPS 115 may display applications provisioned and supported by each available secure service provider 160. In yet another example, the SPS 115 may provide a search function that enables users to search secure service providers 160 based on their features and services. When the user finds an appropriate secure service provider 160, the user can select that secure service provider 160 using the SPS 115.


In block 220, the SPS 115 transmits a request to use the selected service provider 160 to the key escrow service 150 in response to the user selection. The request typically includes information identifying the selected secure service provider 160. In response to receiving the request, the key escrow service 150 processes the request.


In block 225, the key escrow service 150 performs an off-path confirmation procedure to confirm that the user initiated the request to use the selected secure service provider 160. This block 225 is optional and provides an additional level of security for the SPS 115/key escrow service 150 system for example to prevent another person from accessing this feature in the event that the end user network device 110 is lost or stolen.


In one embodiment, the off-path confirmation procedure includes the key escrow service 150 communicating to the user that the request was made via a different communication channel than through the end user network device 110. For example, the key escrow service 150 may transmit an SMS text message to a mobile phone of the user that indicates that the request was made. Or, key escrow service 150 may make a telephone call to the user with a message that the request was made. The text message or voice message may instruct the user to call a certain telephone number if the user did not make the request. The key escrow service 150 also may require that the user confirm the request. For example, the text message may instruct the user to respond to the text message, access a web site of the key escrow service 150, or call the key escrow service 150 to confirm the request. Also, a code may be provided in the message to the user and the user may be required to enter the code via phone or via the web site to confirm the request.


In block 230, if another TSM 170 possessed the keys 120 for the secure element 115, the key escrow service 150 revokes the keys 120 from that previous TSM 170. In one embodiment, the key escrow service 150 sends a message, for example an SMS text message, to the previous TSM 170 requesting that the TSM discard the keys 120. The secure service providers 160 may be obligated under contract to discard the keys 120 in response to such a request.


In another embodiment, the key escrow service 150 revokes the keys 120 from the previous TSM 170 by instructing the secure element 111 to block the previous TSM 170. The secure element 111 can include program code that identifies TSMs 170 attempting to access the secure element 111 and a list of allowed and/or blocked TSMs 170. When a TSM 170 attempts to access the secure element 111, the secure element 111 can compare information identifying that TSM 170 to the list(s) to determine whether to grant access. The key escrow service 150 also can send a request to the previous TSM 170 requesting that the previous TSM discard the keys 120. Of course, the blocked TSM 170 can be unblocked in the event that the user reselects the secure service provider 160 for that TSM 160. For example, the key escrow service 150 may send a message to the secure element 111 requesting that the secure element 110 unblock the TSM 170.


In yet another embodiment, the key escrow service 150 revokes the keys 120 from the previous TSM 170 via the use of a master key and TSM specific keys. A TSM specific key may be provided to the secure element 111 for each available TSM or for a selected TSM 170. The TSM specific keys also are distributed to the respective TSMs 170. The TSM specific keys may be preloaded onto the secure element 111 at manufacture time, installed at a later date by the key escrow service 150, or installed by the key escrow service 150 in response to the user selecting a TSM 170. The secure element 111 can control which of the TSM specific keys are active and which TSM specific keys are inactive. For example, if a user requests to switch from secure service provider 160A to secure service provider 160B, the SPS 115 communicates this request (and information identifying the selected TSM 170B) to a key management applet or module (not shown) of the secure element 111. The key management applet activates the TSM specific key for the TSM 170B and deactivates the TSM specific key for the TSM 170A in response to the request. At this point, the secure element 111 allows access to the TSM 170B while blocking access from the TSM 170A.


In block 235, information stored on the secure element 111 related to the previous TSM 170 and/or previous secure service provider 160 is removed from the secure element 111. For example, payment card credentials associated with the previous TSM 170 may be stored on the secure element 111 while that TSM 170 is being used in conjunction with the secure element 111. These credentials are removed from the secure element 111 prior to enabling another TSM 170 access to the secure element 111. In addition, any applications installed on the secure element 111 for the previous TSM 170 are uninstalled. In certain exemplary embodiments, the key escrow service 150 sends a command to an applet or module of the secure element 111, such as a card manager applet, to remove the information related to the previous TSM 170.


In block 240, the key escrow service 150 transmits the keys 120 to the TSM 170 of the selected secure service provider 160. This transmission is typically made via a secure communication channel. For example, the key escrow service 150 may send the keys 120 to the selected TSM 170 via an encrypted communication channel. In block 245, the selected TSM 170 receives the keys 120.


In certain exemplary embodiments, the key escrow service 150 delays transmitting the keys 120 to the TSM 170 of the selected secure service provider 160 until receiving confirmation that the information and applications related to the previous TSM 170 are removed from the secure element 111. In some embodiments, the key escrow service 150 may not transmit the keys 120 to the TSM 170 of the selected secure service provider 160 without receiving off-path confirmation from the user that the user requested to use the selected secure service provider 160.


In block 250, the TSM 170 of the selected secure service provider 160 attempts to create a secure communication channel with the secure element 111 using the received keys 120. In one embodiment, the TSM 170 sends an encrypted message to the secure element 111 requesting access to the secure element 111. The TSM 170 encrypts the message by performing a cryptographic algorithm on the message using the received keys 120.


In block 255, the secure element 111 determines whether to grant access to the TSM 170. In one embodiment, the processor of the secure element 111 performs a cryptographic algorithm on the received message using the keys 120 stored on the secure element 111 to determine whether to grant access to the TSM 170.


In certain exemplary embodiments, the SPS 115 makes an initial determination as to whether to grant access to a TSM 170 prior to the secure element 111 validating the TSM 170. For example, when the end user network device 110 receives a request for access to the secure element 111, the SPS 115 may evaluate the request to determine whether the TSM 170 that issued the request is the TSM 170 that the user selected prior to the request being passed to the secure element 111. If the SPS 115 determines that the TSM 170 that issued the request is the selected TSM 170, then the secure element 111 may validate the request in accordance with the acts of block 255.


If the secure element 111 grants access to the TSM 170, the method 200 follows the “Yes” branch to block 265. Otherwise, if the secure element 111 determines that the TSM 170 should be blocked, the method 200 follows the “No” branch to block 260.


In block 260, the secure elements 111 blocks the TSM 170 from accessing the secure element 111. The secure element 111 also may send a message to the TSM 170 to notify the TSM 170 that the TSM 170 was not granted access.


In block 265 the TSM 170 provisions services at the secure element 111. The TSM 170 may transmit to the secure element 111 one or more applications and credentials for use with those applications. The applications may be selected by the user. For example, the user may request an application from an application provider 180. In response, the application provider 180 requests the TSM 170 to install the application onto the secure element 111 of the user. The application provider 180 also may provide information regarding the user or account information of the user to the TSM 170 for storing at the secure element 111. For example, a credit card company may provide a payment application and information regarding a payment account of the user to the TSM 170 for installing/storing on the secure element 111. In certain exemplary embodiments, the user may request the application from the key escrow service 150 or the secure service provider 160.


In block 270, the user accesses services provided by the selected secure service provider 160 in connection with one or more application providers 180. For example, if the application provider 180 is a credit card company, the user may complete purchases using the end user network device 110 at an NFC-enabled POS. The NFC controller 112 may interact securely with the secure element 111 to obtain payment credentials from the secure element 111 and provide those credentials to the NFC-enabled POS via the NFC antenna 113.


After block 270, the method 200 ends. Of course, the user can continue to access services provided by the selected secure service provider 160 or switch to another secure service provider 160.



FIG. 4 is a block flow diagram depicting a method 400 for changing secure service providers in the NFC system 300 of FIG. 3, in accordance with certain exemplary embodiments. The method 400 is described with reference to the components illustrated in FIG. 3.


In block 405, one or more secure cryptographic keys 120 are provided for a secure element 111. In certain exemplary embodiments, the secure element 111 and its keys 120 are installed on an end user network device 110 at manufacture time. In certain exemplary embodiments, the secure element 111 and its keys 120 are installed on a removable card or chip, such as a SIM card or microSD card, that is later installed on the end user network device 110.


In block 410, the keys 120 for the secure element 111 or corresponding keys are provided to the managed TSM 350. These keys 120 enable the managed TSM 350 (or another entity that receives the keys 120) to create a secure communication channel with and gain access to the secure element 111.


In block 415, the user selects a secure service provider 160 using the SPS 115. This block 415 can be the same as or similar to block 215 illustrated in FIG. 2 and described above. In block 420, the SPS 115 transmits a request to use the selected service provider 160 to the managed TSM 350 in response to the user selection. The request typically includes information identifying the selected secure service provider 160. In response to receiving the request, the managed TSM 350 processes the request.


In block 425, the managed TSM 350 performs an off-path confirmation procedure to confirm that the user initiated the request to use the selected secure service provider 160. This block is optional and is substantially similar to block 225 of FIG. 2 described above. However, the managed TSM 350 performs the off-path confirmation in block 425 rather than the key escrow service 150.


In block 430, information stored on the secure element 111 related to the previous TSM 170 and/or previous secure service provider 160 is removed from the secure element 111. For example, payment card credentials associated with the previous TSM 170 may be stored on the secure element 111 while that TSM 170 is being used in conjunction with the secure element 111. These credentials are removed from the secure element 111 prior to enabling another TSM 170 access to the secure element 111. In addition, any applications installed on the secure element 111 for the previous TSM 170 are uninstalled. In certain exemplary embodiments, the managed TSM 350 sends a command to an applet or module of the secure element 111, such as a card manager applet, to remove the information related to the previous TSM 170.


In block 435, the managed TSM 350 creates a secure communication channel with the secure service provider 160 that the user selected. This secure communication channel may be encrypted, for example using one or more cryptographic keys different than the keys 120. Other encryption techniques may be used as would be appreciated by one of ordinary skill in the art having the benefit of the present disclosure.


In block 440, the managed TSM 350 notifies the selected secure service provider 160 that the user has requested to access the services of that secure service provider 160. The managed TSM 350 also may request one or more applications from the secure service provider 160 on behalf of the user. Or, the user may request the one or more applications from the application provider 180 and the application provider 180, in turn, transmits a request to the secure service provider 160 to provide the one or more applications to the user's secure element 111. In block 445, the selected secure service provider 160 transmits the requested application(s) and any other appropriate information to the managed TSM 350. For example, this other appropriate information may include a credential for accessing the secure service, such as payment card credentials.


In block 450, the managed TSM 350 creates a secure communication channel with the secure element 111 using the one or more keys 120. In block 455, the managed TSM 350 provisions services at the secure element 111. The managed TSM 350 may transmit to the secure element 111 one or more applications and credentials for use with those applications. The managed TSM 350 also may provide information regarding the user or an account of the user to the secure element 111. For example, a credit card company may provide a payment application and information regarding a payment account of the user to the managed TSM 350 for installing/storing on the secure element 111.


In block 460, which is optional, the managed TSM 350 executes business logic for the selected secure service provider 160 and serves as a proxy or intermediary between the selected secure service provider 160. Examples of business logic performed by the managed TSM 350 includes validating whether a user has a payment card with a partnered financial institution, validating credit card credentials provided by a user so that the credit card can be provisioned to the secure element 111, validating whether the selected secure service provider 160 provides a requested service for the given end user network device 150 on the MNO 130 that the end user network device 150 communicates with, and receiving a provisioning request from the user and translating the provisioning instructions for the secure element 111.


In block 465, the user accesses services provided by the selected secure service provider 160 in connection with one or more application providers 180. For example, if the application provider 180 is a credit card company, the user may redeem transit tickets using the end user network device 110 at an NFC-enabled POS. The NFC controller 112 may interact securely with the secure element 111 to obtain transit ticket credentials from the secure element 111 and provide those credentials to the NFC-enabled POS via the NFC antenna 113.


After block 465, the method 400 ends. Of course, the user can continue to access services provided by the selected secure service provider 160 or switch to another secure service provider 160.


General


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


The invention can be used with computer hardware and software that performs the methods and processing functions described above. As will be appreciated by those having ordinary skill in the 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 of the invention have been described above in detail, the description is merely for purposes of illustration. Various modifications of, and equivalent blocks corresponding to, the disclosed aspects of the exemplary embodiments, in addition to those described above, can be made by those having ordinary skill in the art 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.

Claims
  • 1. A computer-implemented method to provide secure services to computing devices comprising secure elements, comprising: maintaining, by a key escrow service computing device, at least one cryptographic key for a secure element of a network computing device, the at least one cryptographic key operable to enable one of a plurality of trusted service managers (“TSMs”) to provide read and write access the secure element via a secure communication channel;receiving, by the key escrow service computing device, a selection of one of the plurality of TSMs,wherein if the secure element comprises information related to a previous TSM that is different from the selected TSM, the key escrow service computing device revokes the at least one cryptographic key from the previous TSM in response to receiving the request to select the TSM; andtransmitting, by the key escrow service computing device, the at least one cryptographic key to the selected TSM in response to receiving the selection of the one of the plurality of TSMs to enable the selected TSM to access the secure element using the at least one cryptographic key.
  • 2. The computer-implemented method of claim 1, wherein the revoking the at least one cryptographic key comprises transmitting a message to the previous TSM requesting that the previous TSM discard the at least one cryptographic key.
  • 3. The computer-implemented method of claim 1, wherein the revoking the at least one cryptographic key comprises sending a message to the secure element requesting the secure element to block the previous TSM from accessing the secure element, and wherein the secure element is operable to block the previous TSM from accessing the secure element in response to receiving the message.
  • 4. The computer-implemented method of claim 1, wherein the secure element is further operable to identify TSMs attempting to access the secure element and to prevent access to blocked TSMs.
  • 5. The computer-implemented method of claim 1, wherein the secure element comprises at least one cryptographic key for each of the plurality of TSMs, and wherein the revoking the at least one cryptographic key comprises transmitting a message to the secure element requesting the secure element to deactivate the at least one cryptographic key for the previous TSM.
  • 6. The computer-implemented method of claim 1, wherein if the secure element comprises information related to a previous TSM that is different from the selected TSM, the method further comprising removing information related to the previous TSM from the secure element in response to receiving the request to select the TSM.
  • 7. The computer-implemented method of claim 1, further comprising sending a message to the secure element requesting the secure element to remove information related to a previous TSM from the secure element in response to the request to select the TSM.
  • 8. The computer-implemented method of claim 1, wherein the request comprises a selection of the selection TSM, and wherein the method further comprises performing an off-path confirmation of the selection of the selected TSM prior to transmitting the at least one cryptographic key to the selected TSM.
  • 9. The computer-implemented method of claim 1, wherein the network device comprises a near field communication (“NFC”) module and wherein a secure service comprises a secure contactless service via the NFC module.
  • 10. The computer-implemented method of claim 1, the request to select the TSM is received from the network device.
  • 11. A computer program product, comprising: a non-transitory computer-readable medium having computer-readable program code embodied therein that when executed by a computer cause the computer to provide secure services to computing devices, comprising:computer-readable program code to maintain at least one cryptographic key for a secure memory of a computing device, the at least one cryptographic key operable to enable one of a plurality of secure service providers to access the secure memory via a secure communication channel;computer-readable program code to receive a selection of one of the plurality of secure service providers,wherein if the secure memory comprises information related to a previous secure service provider that is different from the selected secure service provider, the at least one cryptographic key from the previous secure service provider is revoked in response to receiving the request to select the secure service provider; andcomputer-readable program code to transmit the at least one cryptographic key to the selected secure service provider in response to receiving the selection of one of the plurality of secure service providers to enable the selected secure service provider to access the secure memory using the at least one cryptographic key.
  • 12. The computer program product of claim 11, wherein revoking the at least one cryptographic key comprises computer-readable program code to transmit a message to the secure memory requesting the secure memory to block the previous secure service provider from accessing the secure memory, and wherein the secure memory is operable to block the previous secure service provider from accessing the secure memory in response to receiving the message.
  • 13. The computer program product of claim 12, wherein the secure memory is further operable to identify secure service providers attempting to access the secure memory and to prevent access to blocked secure service providers.
  • 14. The computer program product of claim 11, wherein the secure memory comprises at least one cryptographic key for each of the plurality of secure service providers, and wherein revoking the at least one cryptographic key comprises computer-readable program code to transmit a message to the secure memory requesting the secure memory to deactivate the at least one cryptographic key for the previous secure service provider.
  • 15. The computer program product of claim 11, wherein the secure memory is a secure element.
  • 16. The computer program product of claim 11, wherein the revoking the at least one cryptographic key comprises computer-readable program code to transmit a message to the previous secure service provider requesting that the previous secure service provider discard the at least one cryptographic key.
  • 17. The computer program product of claim 11, further comprising computer-readable program code to remove information related to the previous secure service provider from the secure memory in response to receiving the request to select the secure service provider.
  • 18. The computer program product of claim 11, further comprising computer-readable program code to transmit a message to the secure memory requesting the secure memory to remove information related to the previous secure service provider from the secure memory in response to the request to select the secure service provider.
  • 19. The computer program product of claim 11, wherein the request comprises a selection of the selected secure service provider, and wherein the computer program product further comprises computer-readable program code to perform an off-path confirmation of the selection of the selected secure service provider prior to transmitting the at least one cryptographic key to the selected secure service provider.
  • 20. The computer program product of claim 11, wherein the network device comprises a near field communication (“NFC”) module, and wherein a secure service comprises a secure contactless service via the NFC module.
  • 21. A system to provide secure services to computing devices comprising secure memories, comprising: a key escrow service computing device that maintains at least one cryptographic key for a secure memory, the at least one cryptographic key operable to enable one of a plurality of trusted service managers (“TSMs”) to securely access the secure memory via a secure communication channel;a first network communication module that receives a selection of one of the plurality of TSMs,wherein if the secure memory comprises information related to a previous TSM that is different from the selected TSM, the key escrow service computing device revokes the at least one cryptographic key from the previous TSM in response to receiving the request to select the TSM; anda second network communication module that transmits the at least one cryptographic key to the selected TSM in response to receiving the selection of one of the plurality of TSMs to enable the selected TSM to securely access the secure memory using the at least one cryptographic key,wherein the key escrow service computing device is communicably coupled to the first network communication module and to the second network communication module.
  • 22. The system of claim 21, wherein the key escrow service computing device revokes the at least one cryptographic key by sending, via the second network communication module, a message to the secure memory requesting the secure memory to block the previous TSM from accessing the secure memory, and wherein the secure memory is operable to block the previous TSM from accessing the secure memory in response to receiving the message.
  • 23. The system of claim 22, wherein the secure memory is further operable to identify TSMs attempting to access the secure memory and to prevent access to blocked TSMs.
  • 24. The system of claim 21, wherein the secure memory comprises at least one cryptographic key for each of a plurality of TSMs, and wherein the escrow service computing device revokes the at least one cryptographic key by transmitting, via the second network communication module, a message to the secure memory requesting the secure element to deactivate the at least one cryptographic key for the previous TSM.
  • 25. The system of claim 21, wherein the key escrow service computing device sends, via the second network communication module, a message to the secure memory requesting the secure memory to remove information related to the previous TSM from the memory in response to the request to select the TSM.
  • 26. The system of claim 21, wherein the secure memory is a secure element.
  • 27. The system of claim 21, wherein the request to select the TSM is received from the network device.
  • 28. The system of claim 21, wherein the key escrow service computing device revokes the at least one cryptographic key by transmitting a message to the previous TSM requesting that the previous TSM discard the at least one cryptographic key.
  • 29. The system of claim 21, wherein the key escrow service computing device sends a message to the secure memory requesting the secure memory to remove information related to the previous TSM from the secure memory in response to the request to select the TSM.
  • 30. The system of claim 21, wherein the request comprises a selection of the selected TSM, and wherein the key escrow service computing device performs an off-path confirmation of the selection of the selected TSM prior to transmitting the at least one cryptographic key to the selected TSM.
  • 31. The system of claim 21, wherein the network device comprises a near field communication (“NFC”) module, and wherein a secure service comprises a secure contactless service via the NFC module.
RELATED APPLICATIONS

This application is a continuation of and claims priority to U.S. patent application Ser. No. 13/589,067, filed Aug. 17, 2012 and entitled “Enabling Users to Select Between Secure Service Providers Using a Key Escrow Service,” which is a continuation of and claims priority to U.S. patent application Ser. No. 13/244,876, filed Sep. 26, 2011 and entitled “Enabling Users to Select Between Secure Service Providers Using a Key Escrow Service,” which claims priority to U.S. Provisional Patent Application No. 61/535,329, filed Sep. 15, 2011 and entitled “Enabling Users To Select Between Secure Service Providers Using A Central Trusted Service Manager.” The complete disclosure of each of the above-identified priority applications is hereby fully incorporated herein by reference.

US Referenced Citations (167)
Number Name Date Kind
4851653 Limisaque et al. Jul 1989 A
5221838 Gutman et al. Jun 1993 A
5321242 Heath, Jr. Jun 1994 A
5692049 Johnson et al. Nov 1997 A
5787173 Seheidt et al. Jul 1998 A
5872849 Sudia Feb 1999 A
5991399 Graunke et al. Nov 1999 A
6005942 Chan et al. Dec 1999 A
6041123 Colvin, Sr. Mar 2000 A
6092201 Turnbul et al. Jul 2000 A
6101477 Hohle et al. Aug 2000 A
6141752 Dancs et al. Oct 2000 A
6151657 Sun et al. Nov 2000 A
6230267 Richards et al. May 2001 B1
6233683 Chan et al. May 2001 B1
6402028 Graham, Jr. et al. Jun 2002 B1
6434238 Chaum et al. Aug 2002 B1
6484174 Wall et al. Nov 2002 B1
6601761 Katis Aug 2003 B1
6609113 O'Leary et al. Aug 2003 B1
6633984 Susser et al. Oct 2003 B2
6647260 Dusse et al. Nov 2003 B2
6732278 Baird et al. May 2004 B2
6792536 Teppler Sep 2004 B1
6823520 Susser et al. Nov 2004 B1
6907608 Susser et al. Jun 2005 B1
6922835 Susser et al. Jul 2005 B1
6963270 Gallagher, III et al. Nov 2005 B1
7093122 Susser et al. Aug 2006 B1
7140549 De Jong Nov 2006 B2
7152782 Shenker et al. Dec 2006 B2
7159180 Ward Jan 2007 B2
7165727 de Jong Jan 2007 B2
7191288 de Jong Mar 2007 B2
7206769 Laurent et al. Apr 2007 B2
7232073 De Jong Jun 2007 B1
7243853 Levy et al. Jul 2007 B1
7275685 Gray et al. Oct 2007 B2
7346170 Asano et al. Mar 2008 B2
7349885 Gangi Mar 2008 B2
7353396 Micali et al. Apr 2008 B2
7360691 Takayama Apr 2008 B2
7374099 De Jong May 2008 B2
7382762 Chmora et al. Jun 2008 B2
7392378 Elliott Jun 2008 B1
7395535 Susser et al. Jul 2008 B2
7469151 Khan et al. Dec 2008 B2
7478389 Susser et al. Jan 2009 B2
7502946 Perkins et al. Mar 2009 B2
7567674 Nishimoto et al. Jul 2009 B2
7607175 Susser et al. Oct 2009 B2
7631346 Hinton et al. Dec 2009 B2
7631810 Liu et al. Dec 2009 B2
7708198 Gangi May 2010 B2
7712658 Gangi May 2010 B2
7739731 Violleau et al. Jun 2010 B2
7757086 Walmsley Jul 2010 B2
7860486 Frank et al. Dec 2010 B2
7967215 Kumar et al. Jun 2011 B2
8060449 Zhu Nov 2011 B1
8120460 Zhu Feb 2012 B1
8126806 DiMartino et al. Feb 2012 B1
8150767 Wankmueller Apr 2012 B2
8171137 Parks et al. May 2012 B1
8171525 Pelly et al. May 2012 B1
8196131 von Behren et al. Jun 2012 B1
8255687 Pelly et al. Aug 2012 B1
8297520 Wakerly et al. Oct 2012 B1
8313036 Wakerly et al. Nov 2012 B1
8335921 von Behren et al. Dec 2012 B2
8335932 von Behren et al. Dec 2012 B2
8352749 von Behren Jan 2013 B2
8379863 Pelly et al. Feb 2013 B1
8385553 Jooste et al. Feb 2013 B1
8412933 Pelly et al. Apr 2013 B1
8737621 Pelly et al. May 2014 B2
20010011250 Paltenghe et al. Aug 2001 A1
20010021927 Laurent et al. Sep 2001 A1
20010027441 Wankmueller Oct 2001 A1
20010039657 Fopeano et al. Nov 2001 A1
20020004783 Paltenghe et al. Jan 2002 A1
20020042776 Woo et al. Apr 2002 A1
20020068554 Dusse Jun 2002 A1
20020194138 Dominguez et al. Dec 2002 A1
20030023954 Wilkinson et al. Jan 2003 A1
20030074579 Della-Libera et al. Apr 2003 A1
20030140176 Susser et al. Jul 2003 A1
20040029569 Khan et al. Feb 2004 A1
20040030601 Pond et al. Feb 2004 A1
20040091116 Staddon May 2004 A1
20040123152 Le Saint Jun 2004 A1
20040128259 Blakeley et al. Jul 2004 A1
20040140351 Flugge et al. Jul 2004 A1
20040250066 Di Luofflo et al. Dec 2004 A1
20050001711 Doughty et al. Jan 2005 A1
20050071418 Kjellberg et al. Mar 2005 A1
20050091659 Susser et al. Apr 2005 A1
20050102679 Susser et al. May 2005 A1
20050149926 Saltz Jul 2005 A1
20050184163 de Jong Aug 2005 A1
20050184164 de Jong Aug 2005 A1
20050184165 De Jong Aug 2005 A1
20050188360 De Jong Aug 2005 A1
20050193218 Susser et al. Sep 2005 A1
20050222961 Staib et al. Oct 2005 A1
20060036570 Schaefer et al. Feb 2006 A1
20060041507 Novack et al. Feb 2006 A1
20060126831 Cerruti et al. Jun 2006 A1
20060165060 Dua Jul 2006 A1
20060200865 Leake Sep 2006 A1
20060219774 Benco et al. Oct 2006 A1
20070067325 Weitzner et al. Mar 2007 A1
20070090195 Kawamura et al. Apr 2007 A1
20070135164 Lee Jun 2007 A1
20070169043 Violleau et al. Jul 2007 A1
20070179906 Frankel et al. Aug 2007 A1
20070226786 Berger et al. Sep 2007 A1
20080056501 McGough et al. Mar 2008 A1
20080073426 Koh et al. Mar 2008 A1
20080130902 Foo Kune et al. Jun 2008 A1
20080162834 Brokenshire et al. Jul 2008 A1
20080167988 Sun et al. Jul 2008 A1
20080208681 Hammad et al. Aug 2008 A1
20080208762 Arthur et al. Aug 2008 A1
20080270253 Huang Oct 2008 A1
20090158028 Jung et al. Jun 2009 A1
20090239512 Hammad et al. Sep 2009 A1
20090261172 Kumar et al. Oct 2009 A1
20090307139 Mardikar et al. Dec 2009 A1
20090307142 Mardikar Dec 2009 A1
20090312011 Huomo et al. Dec 2009 A1
20100012732 Pinzinger et al. Jan 2010 A1
20100042824 Lee et al. Feb 2010 A1
20100050271 Saarisalo Feb 2010 A1
20100058463 Bertin Mar 2010 A1
20100063893 Townsend Mar 2010 A1
20100088237 Wankmueller Apr 2010 A1
20100088518 Dottax Apr 2010 A1
20100106967 Johansson et al. Apr 2010 A1
20100114731 Kingston et al. May 2010 A1
20100131413 Kranzley et al. May 2010 A1
20100138518 Aiglesorfer et al. Jun 2010 A1
20100203870 Hubinak et al. Aug 2010 A1
20100205432 Corda et al. Aug 2010 A1
20100207742 Buhot et al. Aug 2010 A1
20100211507 Aabye et al. Aug 2010 A1
20100250956 Reed et al. Sep 2010 A1
20100291896 Corda Nov 2010 A1
20100291904 Musfeldt et al. Nov 2010 A1
20100306076 Taveau et al. Dec 2010 A1
20100306107 Nahari Dec 2010 A1
20100306531 Nahari Dec 2010 A1
20100323681 Corda et al. Dec 2010 A1
20100330958 Corda et al. Dec 2010 A1
20110016275 Lemonnier et al. Jan 2011 A1
20110029671 Deprun et al. Feb 2011 A1
20110053504 Corda Mar 2011 A1
20110072425 Lemonnier et al. Mar 2011 A1
20110078081 Pirzadeh et al. Mar 2011 A1
20110087610 Batada et al. Apr 2011 A1
20110099605 Cha et al. Apr 2011 A1
20110113473 Corda et al. May 2011 A1
20110131421 Jogand-Coulomb et al. Jun 2011 A1
20110263225 Escott Oct 2011 A1
20110306318 Rodgers et al. Dec 2011 A1
20120009873 Corda et al. Jan 2012 A1
20120129452 Koh et al. May 2012 A1
Foreign Referenced Citations (24)
Number Date Country
102204299 Sep 2011 CN
19925389 Dec 2000 DE
1004992 May 2000 EP
1318488 Jun 2003 EP
2043060 Apr 2009 EP
2365469 Sep 2011 EP
2448171 May 2012 EP
2457221 Aug 2009 GB
2003-032237 Jan 2003 JP
2011-525028 Dec 2010 JP
5519086 Jun 2014 JP
100600508 Jul 2005 KR
10-2006-0035421 Apr 2006 KR
10-2009-0051823 May 2009 KR
WO 9843212 Oct 1998 WO
WO 9852158 Nov 1998 WO
WO 0045347 Aug 2000 WO
WO 0122374 Mar 2001 WO
WO 2004054125 Jun 2004 WO
WO 2009040715 Sep 2008 WO
WO 2009043859 Apr 2009 WO
WO 2009090591 Jul 2009 WO
WO 2010120222 Oct 2010 WO
WO 2010150817 Dec 2010 WO
Non-Patent Literature Citations (75)
Entry
Babin, G., Canadian Office Action issued in Application No. 2,811,215, pp. 1-2, Oct. 7, 2013.
Lau, A., Canadian Office Action issued in Application No. 2,825,457, pp. 1-3, Oct. 25, 2013.
Chinese Office Action issued in Application No. 201380000186.4, pp. 1-9, Dec. 2, 2014.
Mobile Near Field Communication (Mobile NFC) Stepping Stones version 1.0.0, Sim Alliance Interoperability Working Group; Retrieved http://www.simalliance.org on, pp. 1-82, Jun. 15, 2011.
Global Platform Card Specification version 2.2.1—Public Release, pp. 1-303, Jan. 1, 2011.
Park, J., Korean Office Action issued in Korean application No. 10-2013-7022952, pp. 1-6, Oct. 27, 2014.
Sanchez, R., EP Office Action issued in EP Application No. 13744414.7, pp. 1-7, Feb. 16, 2015.
Schossmaier, K., EP Office Action issued in EP Application No. 12769000.6, pp. 1-5, Jan. 5, 2015.
Zhou, Y., Chinese Office Action issued in Chinese Application No. 201380000817.2, pp. 1-17, Oct. 21, 2014.
U.S. Appl. No. 14/636,902 to Wall et al. filed Mar. 3, 2015.
Chinese Office Action issued in Application No. 201380000186.4, pp. 1-22, Jun. 4, 2014.
3rd Generation Partnership Project Partnership Project 3GPP TR 33.812 V9.2.0, 3rd Generation Partnership Project, pp. 1-87, Jun. 1, 2010.
Global Platform Proposition for NFC Mobile: Secure Element Mangement & Messaging, pp. 1-36, Apr. 2009.
Chinese Office Action issued in Application No. 201280003150.7, pp. 1-26, Feb. 21, 2014.
ANSI/X9 X9.24-1: 2004 Retail Financial Services Symmetric Key Management Part 1: Using Symmetric Techniques, pp. 1-71, Feb. 4, 2004.
An, W., Office Action issued in copending U.S. Appl. No. 13/868,041, filed Apr. 22, 2013, pp. 1-15, Jun. 16, 2014.
Kaneki, Y., Japanese Office Action issued in Application No. 2013-534076, pp. 1-4, Aug. 27, 2013.
Menezes et al., Key Establishment Protocols, Handbook of Applied Cryptography, pp. 489-541, Jan. 1, 1997.
Nakazato, H., Japanese Office Action issued in Application No. 2014-076015, pp. 1-13, May 7, 2014.
Park, J., Korean Office Action issued in Application No. 10-2013-70067529, pp. 1-4, Nov. 26, 2013.
Park, J., Korean Office Action issued in Application No. 10-20137010284, pp. 1-6, Nov. 26, 2013.
Sanchez, R., EPO Extended Search Report issued in Application No. 13714841.7, pp. 1-10, Mar. 7, 2014.
Sanchez, R., EPO Extended Search Report issued in Application No. 13744414.7, pp. 1-10, Mar. 7, 2014.
Savin, D., Canadian Office Action issued in Application No. 2,813,167, pp. 1-2, Aug. 21, 2013.
Yamamoto, M., Japanese Office Action issued in Application No. 2014-509525, pp. 1-4, Apr. 7, 2014.
U.S. Appl. No. 13/752,355 to Pelly et al. filed Jan. 28, 2013.
U.S. Appl. No. 13/868,041 to Wall et al. filed Apr. 22, 2013.
U.S. Appl. No. 13/776,660 to Jooste et al. filed Feb. 25, 2013.
U.S. Appl. No. 60/338,419, Merckling et al., filed Dec. 4, 2001.
AN1787—MIFARE Application Directory (MAD), NXP Semiconductors—MIFARE Application Directory, pp. 1-23, Jul. 7, 2010.
Data Sheet: MIFARE—Standard Card IC—MF1 IC S50 Functional Specification, Philips Semiconductors—Product Specification—Revision 4.0, pp. 1-18, Jul. 1, 1998.
Santa Clara Puts Payments in “Palm” of Your Hand: Palms and Cellphones Initiate Payments to Campus Card System, CR80 News.com, vol./Iss: 2 (5), pp. 1-3, May 1, 2003.
Mobile Payments at the Physical Point-of-Sale: Assessing U.S. Market Drivers and Industry Direction, Smart Card Alliance Report—Publication No. PT-05001, pp. 1-52, Apr. 1, 2005.
Global Platform Card—Global Platform Card—Contactless Services, Card Specification v2.2—Amendment C, Global Platform Public Release—Document Reference: GPC SPE 025, pp. 1-77, Feb. 1, 2010.
The Role of the TSM, Gemalto—The Review, Jan. 1, 2008.
Smart-card Devices and Applications, pp. 1-13, Jan. 1, 2001.
Boly et al., ESCORICS 94 (Third European Symposium on Research in Computer Security) LNCS 875, pp. 217-230, Nov. 7, 1994.
Chen, Zhiqun, How to Write a JAVA Card Applet: A Developer's Guide, JavaWorld, pp. 1-9, Jul. 1, 1999.
Corum, Chris, Card Offices Increase their Focus on Off-Campus Merchant Programs, CR80News.com, vol./Iss: 2 (5), pp. 1-5, May 1, 2003.
Daswani et al., SWAPEROO: A Simple Wallet Architecture for Payments, Exchanges, Refunds, and Other Operations, USENIX—3rd USENIX Workshop on Electronic Commerce, pp. 1-20, Aug. 31, 1998.
Dotzer, Florian, Aspects of Multi-Application Smart Card Management Systems, Thesis at Technical University of Munich, Chair of Data Processing, pp. 1-124, Oct. 15, 2002.
Hehn, Eva, International Search Report and Written Opinion for International Patent Application No. PCT/US2012/032560, pp. 1-10, Jul. 26, 2012.
Hernandez-Suesta, Raul, E-Wallet with Decentralized Credentialed Keepers, Masters Thesis—Norges Teknisk—Naturvitenskapelige Universitet, pp. 1-74, Jun. 30, 2003.
Hernandez et al., E-Wallet Software Architecture with Decentralized Credentials, Masters Thesis—Norwegian University of Science and Technology, pp. 1-12, Jan. 1, 2003.
Huang et al., Future Personal “E-Payment”: IRFM, IEEE Wireless Communications, pp. 1-7, Feb. 1, 2006.
Kim, S. G., International Search Report and Written Opinion for International Application No. PCT/US2013/035521, pp. 1-9, Jul. 25, 2013.
Lee, D.Y., International Search Report and Written Opinion issued in International Application No. PCT/US2013/027700, pp. 1-10, Jun. 17, 2013.
Mjolsnes et al., On-Line E-Wallet System with Decentralized Credential Keepers, Mobile Networks and Applications vol. 8, pp. 1-13, Feb. 1, 2003.
Retrieved from http://www.europeanpaymentscouncil., EPC-GSMA Trusted Service Manager—Service Management Requirements and Specifications, retrieved from http://www.europeanpaymentscouncil., pp. 1-60, Jan. 1, 2010.
Schossmaier, K., EPO Search Report issued in Appl. No. 12769000.6, pp. 1-3, Jul. 31, 2013.
Song, H., Office Action issued in co-pending U.S. Appl. No. 13/443,671, filed Apr. 10, 2012, pp. 1-8, Aug. 6, 2012.
Song, H., Office Action issued in co-pending U.S. Appl. No. 13/523,637, filed Jun. 14, 2012, pp. 1-6, Jul. 30, 2012.
Song, H., Office Action issued in copending U.S. Appl. No. 13/776,660, filed Feb. 25, 2013, pp. 1-6, May 9, 2013.
Song, H., Office Action issued in copending U.S. Appl. No. 13/752,355, filed Jan. 28, 2013, pp. 1-9, Aug. 27, 2013.
Song, Hosuk—USPTO Examiner, US Office Action issued in copending U.S. Appl. No. 13/244,889, filed Sep. 26, 2011, USPTO Office Action, pp. 1-8, Dec. 5, 2011.
Sun Microsystems, Inc., Runtime Environment Specification—Java Card Platform, Version 3.0, Classic Edition, pp. 1-158, Mar. 1, 2008.
Yin Sara, Google Wallet Is Just Another Pilot, Says World's Largest SIM Card Maker, PCMag.com, pp. 1, May 27, 2011.
Yin Sara, Google Wallet Aims to Take Mobile Payments Mainstream, PCMag.com, pp. 1-2, May 26, 2011.
Yixin et al., Design of Objects Sharing Mechanisms with Security Domain in Java, 2009 International Conference on Electronic Computer Technology, pp. 1-5, Feb. 20, 2009.
Yliuntinen, 3rd Party TSM Management of SIM Cards, Cryptomathic, pp. 1-5, Sep. 1, 2011.
Young, L. S., International Search Report and Written Opinion issued in International Application No. PCT/US2012/050479, pp. 1-10, Feb. 1, 2013.
Yun et al., Design and Implementation of Wireless Payment System using GVM and MobileC, Proceedings of the International Conference on Mobile Computing and Ubiquitous Networking, pp. 1-10, Apr. 13, 2005.
Zecher, C., Office Action issued in copending U.S. Appl. No. 13/547,029, filed Jul. 11, 2012, pp. 1-13, Sep. 20, 2012.
Korean Office Action issued in Application No. 10-2014-7002137, pp. 1-7, Jun. 13, 2014.
Aoki, S., Japanese Office Action issued in Application No. 2013-207763, pp. 1-7, Aug. 28, 2014.
Kaneki, Y., Japanese Office Action issued in Application No. 2013-262240, pp. 1-2, Mar. 28, 2014.
Kim, J., Korean Office Action issued in Application No. 10-2013-7022952, pp. 1-15, Jul. 7, 2014.
Schossmaier, K., European Office Action issued in European Application No. 12769000.6, pp. 1-5, Aug. 14, 2013.
Harms, C., European Office Action issued in European Application No. 12717143.7, pp. 1-6, Jun. 22, 2015.
Park, J., Korean Office Action issued in Korean Application No. 10-2014-7024699, pp. 1-7, Oct. 2, 2015.
Park, J., Korean Office Action issued in Korean application No. 10-2013-7022952, pp. 1-8, Feb. 26, 2015.
Zhou, Y., Chinese Office Action issued in Chinese Application No. 201280001114.7, pp. 1-12, Sep. 25, 2015.
Zhou, Y., Chinese Office Action issued in Chinese Application No. 201380000817.2, pp. 1-13, Jun. 26, 2015.
Harms, C., European Office Action issued in European Application No. 12717143.7, pp. 1-6, Dec. 15, 2015.
Schossmaier, K., Extended EPO Search Report issued in European Application No. 15003446.0, pp. 1-8, Mar. 9, 2016.
Related Publications (1)
Number Date Country
20130212384 A1 Aug 2013 US
Provisional Applications (1)
Number Date Country
61535329 Sep 2011 US
Continuations (2)
Number Date Country
Parent 13589067 Aug 2012 US
Child 13846849 US
Parent 13244876 Sep 2011 US
Child 13589067 US