Patent Grant
10114976
Field of the Invention
The present invention relates to interfacing between service providers and secure elements, and more particularly to systems, methods, and computer program products for interfacing between service provider trusted service managers and secure elements.
Related Art
A service provider (SP) is a company, organization, entity, or the like, that provides services to customers or consumers. Examples of service providers include account-issuing entities such as merchants, card associations, banks, marketing companies, and transit authorities. A service may be an activity, capability, functionality, work, or use that is permitted or provided by a service provider such as a payment service, a gift, offer or loyalty service, transit pass service, and the like.
In a mobile environment that involves contactless transactions between a mobile device and a service provider, information relating to the accounts and applications issued by the service providers must be downloaded onto mobile devices in order to enable them to perform the contactless transactions.
A trusted service manager (TSM) is typically an independent entity serving mobile network operators (MNOs) and account-issuing service providers by provisioning applications, such as contactless applications associated with the service providers, to mobile devices. Typical TSMs can distribute and manage the contactless applications remotely because they have access to secure elements (SEs) in a near field communication (NFC) enabled mobile device.
Security-critical applications, such as those involving payment and account credentials, require secure hardware storage and a secure execution environment. On mobile devices, this is usually handled by the secure element.
The secure element is a platform onto which applications can be installed, personalized and managed. It consists of hardware, software, interfaces, and protocols that enable the secure storage of credentials and execution of applications for payment, authentication, and other services.
A secure element may be implemented in different form factors such as a Universal Integrated Circuit Card (UICC), an embedded secure element, or NFC enablers such as a separate chip or secure device, which can be inserted into a slot on the mobile device. Typically a UICC is in the form of a subscriber identity module (SIM), which is controlled by the MNOs. An embedded secure element gives service providers the option to embed the secure element into the phone itself. One way in which secure element form factors are implemented is defined in, for example, GlobalPlatform Card Specification Versions 2.1.1 and 2.2 (hereinafter “Global Platform”).
A secure element may include one or more security domains (SDs), each of which includes a collection of data, such as packages, applets, applications, and the like, that trust a common entity (i.e., are authenticated or managed using a common security key or token).
Security domains may be associated with service providers and may include service provider applets or applications such as loyalty, couponing, and credit card, and transit applications or applets.
Traditionally, service provider systems include a TSM to interconnect with a secure element on a mobile device to create a security domain on the secure element and install, provision and manage applets and applications on the secure element. Service providers must be able to provide their services to a large number of customers with different mobile devices, equipped with different secure elements, and being serviced by a variety of MNOs. As explained above, secure elements may be implemented in numerous form factors, and may contain a variety of security domains, applets and applications, all potentially configured in an extremely large number of ways. As a result, service providers are faced with the overwhelming task of providing adaptable services and solutions to a large, and often growing and changing, combination of mobile devices, MNOs, networks, secure elements and security domains.
For example, in order for a service provider to securely install a payment applet onto a customer's secure element on a mobile device, the service provider must first determine a large amount of information in order to send to and process a request on a secure element. For example, service providers using the prior art must obtain secure element information (e.g., identifiers, type, profile identifier, certification level and expiration), MNO information (e.g., type), security domain information (e.g., identifier, privileges, master key index), and the like. This information may exist in a variety of different sources (e.g., security domain, secure element, mobile device, MNO) and therefore, it is a laborious task for a service provider to retrieve, and check for parity, all of this information, requiring extensive processing.
One technical challenge in the installation, management, and provisioning of applications on secure elements is due to the limitations in typical TSMs, namely that they do not function as central intermediaries capable of processing communications between a large variety of service providers, MNOs, mobile devices, networks, secure elements and security domains. There is a need, therefore, for an improved system such as a central TSM, particularly tailored for interfacing between service providers (including service provider TSMs) and secure elements.
From the perspective of a service provider, what matters is that they can easily and securely communicate (i.e., request personalization, service activation, processing of scripts, etc.) with an intended customer's secure element, regardless of the customer's mobile device, secure element, MNO, or mobile network.
From the perspective of the customer, what matters is that the service of the service provider can be activated on and used with the customer's secure element, regardless of the customer's mobile device, secure element, MNO, or mobile network.
The present invention provides systems, methods, and computer program products for interfacing between one of a plurality of service provider trusted service managers and one of a plurality of secure elements.
In one embodiment, a system for interfacing between one of a plurality of service provider trusted service managers and one of a plurality of secure elements includes at least one memory and a processor communicatively coupled to the at least one memory. The processor receives, from a service provider trusted service manager over a communications network, a first request including a mobile subscription identifier. The at least one memory is queried for secure element data corresponding to the mobile subscription identifier. The secure element data includes a secure element identifier, and is transmitted to the service provider trusted service manager over the communications network. A second request based on the secure element data is received from the service provider trusted service manager over the communications network, and a third request, based on the second request, is transmitted to a secure element corresponding to the secure element data. The third request is transmitted over a mobile network selected from a plurality of mobile networks based on the secure element data queried from the at least one memory.
In another embodiment, a method for interfacing between one of a plurality of service provider trusted service managers (SP TSM) and one of a plurality of secure elements includes an SP TSM and at least one memory. The SP TSM receives, over a communications network, a first request including a mobile subscription identifier. The at least one memory is queried for secure element data including a secure element identifier corresponding to the mobile subscription identifier. The secure element data is transmitted to the SP TSM over the communications network, and a second request based on the secure element data is received from the SP TSM over the communications network. A third request, based on the second request, is transmitted over a mobile network to a secure element corresponding to the secure element data. The mobile network is selected from a plurality of mobile networks, and determined based on the secure element data queried from the at least one memory.
In another embodiment, a non-transitory computer-readable medium having stored thereon sequences of instructions, the sequences of instructions including instructions, which, when executed by a computer system cause the computer to: receive, from an SP TSM over a communications network, a first request including a mobile subscription identifier; query at least one memory for secure element data including a secure element identifier corresponding to the mobile subscription identifier; transmit the secure element data to the SP TSM over the communications network; receive, from the SP TSM over the communications network, a second request based on the secure element data; and transmit, over a mobile network, a third request, based on the second request, to a secure element corresponding to the secure element data. The mobile network is selected from a plurality of mobile networks, and determined based on the secure element data queried from the at least one memory.
Further features and advantages of the present invention will become more apparent from the detailed description set forth below when taken in conjunction with the following drawings.
The features and advantages of the present invention will become more apparent from the detailed description set forth below when taken in conjunction with the following drawings.
Overview
The example embodiments of the invention presented herein are directed to systems, methods, and computer program products for interfacing between a service provider and a secure element. This is for convenience only, and is not intended to limit the application of the present invention. In fact, after reading the following description, it will be apparent to one skilled in the relevant arts) how to implement the following invention in alternative embodiments, such as interfacing between a large variety and vast number of entities including TSMs, MNOs, secure elements, mobile devices, service providers, and any other systems that are capable of communicating over networks.
Generally, the exemplary embodiments described herein perform interfacing between one or more service provider systems having a mobile subscription identifier (MSI) and one or more secure elements.
A service provider system (i.e., service provider) may communicate with a central TSM in order to access or control a corresponding security domain and/or application on a secure element. In particular, the service provider, by communicating with the central TSM, may pre-personalize a secure element, personalize a service on a security domain in a secure element, or activate a service on the secure element. For example, the service provider may transmit a request to the central TSM to pre-personalize a secure element. In response, the central TSM may pre-personalize the secure element, including creating at least one service provider security domain including corresponding temporary security keys, if required, and/or instantiating an application on the secure element. Instantiation of the application includes creating an instance of an uninstantiated application.
The service provider may also transmit a request to personalize a service to the central TSM. The request may include data and scripts. The scripts may include commands to be executed by an application on a security domain corresponding to the service provider in the secure element. For example, the scripts may include commands to personalize an instantiated application, rotate keys in the corresponding security domain, and/or execute service provider commands in the service provider's security domain and/or instantiated application in the secure element. The central TSM receives the request and securely transmits the scripts and/or data in the request to the secure element. In turn, the secure element receives and executes the scripts and data.
The service provider communicates with the central TSM in order to have commands executed on the secure element. In order to do so, the service provider (i.e., SP TSM) sends a request (e.g., to pre-personalize a secure element) to the central TSM to obtain information about the secure element based on an MSI. The central TSM receives the request and queries its memory, based on the MSI, to obtain the requested information about the secure element. Once the central TSM has retrieved the secure element information corresponding to the MSI, the central TSM transmits the retrieved secure element information and the MSI to the SP TSM.
Once the service provider has identified the target secure element and its information, the service provider (i.e., SP TSM) sends a request to the central TSM, for the central TSM to establish a communication (i.e., a conversation) with the secure element. The request to establish the communication includes the retrieved secure element information and corresponding MSI, as well as information regarding applications or applets, security domains, services and scripts that will be used to process a subsequent request from the service provider. The central TSM receives the request and transmits a response to the SP TSM including a communication identifier and other attributes of the communication.
After the communication has been established, the service provider sends a request (e.g., personalize an application), including the communication identifier, intended to be executed in the secure element. The service provider initially sends the request to the central TSM. The central TSM receives the request, and based on the information in the request, establishes a connection with the secure element and transmits the request (e.g., personalize an application) to the secure element for processing. The central TSM transmits the request to the secure element over a corresponding mobile network. The corresponding mobile network is determined based on MNO information which is retrieved from the memory of the central TSM, which is based on the information in the request made by the service provider (e.g., to personalize an application). The request is processed in the secure element in accordance with the request from the service provider, based on the information in the request and the established communication.
Due to the functionality of the exemplary embodiments described herein, a service provider can efficiently and effortlessly communicate with a central TSM in order to have a variety of requests processed on a secure element with minimal processing and information required. The exemplary embodiments also provide for a central TSM arrangement that significantly reduces the time and cost requirements required for service providers to have requests (e.g., enable services) processed on a secure element.
In addition, a service provider can send a request to a secure element, via a central TSM, merely by using the MSI to communicate with a single source (i.e., the central TSM). That is, the service provider is able to process its requests with a secure element without the need to communicate with multiple intermediary sources (e.g., MNOs, TSMs).
Additionally, service provider requests are standardized such that a single type of request is communicated to the central TSM notwithstanding the type of MNO, mobile device type, secure element, and/or application. By standardizing the service provider requests, advantageously, the errors and complexities associated with the processing of multiple service provider requests are reduced. Further, service providers do not have to transmit or provide an application for installation, or provide MNO, mobile device or secure element interfaces in order to have a request processed on a secure element. Instead, the service provider can send one or more standardized requests with commands to the central TSM. As a result, the processing time and size required to execute a request are minimized.
System
Each of the SP TSMs 103 are communicatively coupled to central TSM 102 via a communications network 105. Communications network 105 may be a virtual private network (VPN), a network using Hypertext Transfer Protocol (HTTP) standards, or the like.
Each of the SP TSMs 103 and the central TSM 102 may also secure these communications by using security protocols such as Secure Socket Layer (SSL), Transport Layer Security (TLS), or the like. Each of the SP TSMs 103 may also communicate with central TSM 102 by using an application programming interface (API) such as a web service API.
In an exemplary embodiment, the central TSM 102 is hardware and/or software that is implemented to serve as an intermediary between the SP TSMs 103 and secure elements 106a-1, 106a-2, . . . , 106a-n (collectively “106a”). Specifically, the central TSM 102 allows each of the SP TSMs 103 to, for example, request pre-personalization of a secure element (e.g., secure elements 106), generate and install new or temporary security domain keysets, personalize a payment service, and/or have a service activated. That is, the central TSM 102 manages the communications between the SP TSMs 103 and the secure elements 106a.
The central TSM 102, therefore, can communicate with a plurality of service providers 107 and SP TSMs 103, and with a plurality of secure elements 106a over a plurality of mobile networks 104-1, 104-2, . . . , 104-n (collectively “104”).
In an example embodiment, the central TSM 102 includes a processor 102a and a memory 102b.
The central TSM 102 may include an enterprise service bus (ESB) (not shown). In an exemplary embodiment, the ESB is an architecture model for implementing the interactions and communications between entities (e.g., secure elements 106a, SP TSMs 103, central TSM 102).
The central TSM 102 is communicatively coupled to the secure elements 106a via corresponding mobile networks 104 used and/or managed by corresponding MNOs. Generally, the mobile networks 104 are used by MNOs to provide wireless communications services. The mobile networks 104 may be mobile phone cellular networks, radio networks, or the like. The central TSM 102 may communicate with the secure elements 106a, via the mobile networks 104, using security protocols such as Global Platform secure channel protocol, SSL, TLS, or the like.
Secure elements (e.g., secure elements 106a) are discussed in further detail below with reference to
During manufacture of a secure element (e.g., secure element 106a-1), the secure element is pre-loaded with content including, for example, an MNO SD, a central SD, a wallet companion applet, a mobile wallet companion applet (WCAp), a proximity payment system environment (PPSE), and a payment package. The MNO SD is a security domain that is managed by an MNO, and includes security keys and applications. The central SD is managed by the central TSM 102. The WCAp may be used by a mobile wallet in order to conduct transactions, and the PPSE is an application that assists in the process of making contactless payment transactions.
The secure elements 106a may include security domains, code, applets, applications, and packages. The packages may include uninstantiated applets and/or applications, and may be loaded on a secure element, for example, over-the-air (OTA). Applets and/or applications on the secure element may be in uninstantiated or instantiated form, and uninstantiated applets and/or applications may be preloaded on a secure element during manufacture of the secure element. Alternatively, applets and/or applications may be loaded, for example, OTA after a secure element has been manufactured (e.g., upon delivering the secure element to a user). Applets and/or applications may be generic or non-generic. Non-generic applets and/or applications may include couponing and loyalty applications, and/or any application that is not generic to multiple service providers. That is, a non-generic application may correspond to a single service provider. Data that may be used and/or associated with a non-generic application (e.g., offers, coupons) may be stored in the secure element or in memory outside of the secure element (e.g., non-volatile memory of a mobile device).
Generic applets and/or applications may include applets and/or applications that, when instantiated, can be used by multiple service providers. For example, a generic application of a payment network (e.g., MasterCard®) may be instantiated for multiple service providers by a central TSM, and therefore may be used by more than one service provider.
Packages including uninstantiated applets and/or applications may be owned or controlled by a single entity controlling a central TSM and/or a central SD. Uninstantiated applets and/or applications may be created under (i.e., directly associated with) a central SD on a secure element, and may be exclusively managed on the secure element by the central TSM using the central SD. In particular, the central SD maintains exclusive access to the WCAp, PPSE, packages, and SP SDs. However, service providers may transmit requests to the central TSM, for example, to rotate (i.e., exchange) security keys. After security keys of an SP SD have been rotated, the corresponding service provider can continue to send requests to the central TSM to execute commands on the corresponding SP SD. After key rotation, the central TSM has limited access to the SP SD. In particular, the central TSM can, for example, stop execution of an application or instantiate applications under the SP SD, but may not access the security keys or personalized content of the SP SD.
Exclusive ownership, control, and/or management of uninstantiated applets or applications allows a single entity to efficiently and cost effectively supervise the applets and/or applications. Further, exclusive ownership, control, and/or management increases security and minimizes the complexities caused by multiple service providers loading and controlling different applets and/or applications on a secure element. For example, a service provider may utilize an instance of an uninstantiated applet and/or application instead of certifying and installing an independent applet and/or application on the secure element.
Additionally, uninstantiated applets and/or applications may be instantiated, and each instance may then be extradited to a corresponding security domain. Instantiation may include personalizing applets and/or applications using data corresponding to the entity for which the instance is being created.
For example, multiple instances of an uninstantiated applet or application may be created for different entities (e.g., service providers) and each instance may be extradited to a different security domain for use by a different entity.
An applet or application on a secure element may function pursuant to requirements established by Global Platform, Europay, MasterCard®, Visa® (EMVCo.), MNOs, and payment networks (e.g., MasterCard®, Visa®, Discover®, American Express®). Applets or applications may be, for example, Expresspay™ payWave™, PayPass™, Zip™, and the like.
For example, the SP TSM 103-1 sends a request to the central TSM 102 via the communications network 105, and the central TSM 102 sends a response back to the SP TSM 103-1 via the communications network 105. The SP TSM 103-1 sends a request, intended for the secure element 106a-1, to the central TSM 102 via the communications network 105. In turn, the central TSM 102 sends that request to the secure element 106a-1 via the respective mobile network 104-1.
In an alternative embodiment, the central TSM 102 can include and utilize an ESB to perform operations.
In an alternative embodiment, a plurality of service providers share one of the SP TSMs 103.
In an additional alternative embodiment, the memory 102b may be a database.
In another alternative embodiment, a plurality of mobile networks communicate with a plurality of SP TSMs.
Process
A. Communicating a Request from a Service Provider TSM to a Secure Element
As shown in
The secure element identifier is a unique number or set of characters which is written to the secure element 201 and may be used to identify the secure element 201. The secure element identifier may also include the type of identifier used to identify the secure element, such as a Card Image Number (CIN), which is a unique number that identifies the secure element and which is written to the secure element during its personalization.
The secure element data are attributes of the secure element 201. The secure element data may include the following information relating to the secure element 201: secure element identifier; name of the MNO associated with the secure element 201; service provider data for the service provider associated with SP TSM 203; master key index including a key for the service provider's security domain in the secure element 201; profile identifier; secure element type; standards versions (e.g., GlobalPlatform, JavaCard); certification level and expiration date.
The MSI is a unique number used to identify a mobile subscription of a mobile device associated with an MNO. The MSI may also include the name of the MNO associated with the mobile subscription as well as the type of identifier used to identify the mobile subscription of the mobile device, such as a mobile device number (MDN), which is generally a phone number associated with a particular line of service.
The central TSM 202 receives the request (Requestx), including the MSI, and queries its memory (Query Memory), at step 252. The memory may be a database including one or more MSIs and one or more corresponding secure element identifiers and secure element data. The memory may also include MNO data corresponding to each of the secure element identifiers. The MNO data may be information used to identify the MNO with which the secure element is associated, and may be used to select an appropriate mobile network to be used for communicating with the secure element. The query is a request to retrieve secure element data, including a secure element identifier corresponding to the MSI, from the memory.
Upon retrieving the secure element data corresponding to the MSI, the central TSM 202 transmits, at step 254, to the SP TSM 203, over the communications network, the retrieved secure element data stored in its database including the secure element identifier (Response). The central TSM 202 also transmits to the SP TSM 207 (Response) the corresponding MSI included in the request. In this way, the SP TSM 203 determines the identity of the secure element 201, to which it will send a request.
The SP TSM 203, using the secure element data received from the central TSM 202, transmits, at step 256, a request (Requesty) to the central TSM 202. The central TSM 202 receives this request (Requesty) including the secure element identifier of the secure element 201, to which the SP TSM 203 has addressed the request.
This request (Requesty) may include one or more requests for the secure element 201 to: manage a communication, process one or more scripts, or activate a service. For example, a request may be used to instruct a secure element to perform, for example, personalization, key rotation, and other processes discussed below with reference to
The central TSM 202 determines a mobile network (e.g.,
In an alternative embodiment, the secure element 201 may transmit to the central TSM 202, over the mobile network, a response after completing or processing the request from the SP TSM 203. The response may include, for example, information indicating whether the processing of a request succeeded or failed.
In an alternative embodiment, the secure element data may not include the secure element identifier. In such a case, the SP TSM 203 may request the secure element identifier (based on the MSI) and the secure element data separately, and the central TSM 202 may provide the secure element identifier and the secure element data in separate responses to the SP TSM 203.
In an alternative embodiment, the SP TSM 203 may initially transmit a request to the central TSM 202 to pre-provision the secure element 201, including creating one or more security domains on the secure element 201, if necessary (i.e., if one or more security domains corresponding to the SP TSM 203 have not been created). Once the one or more security domains have been created, the SP TSM 203 can transmit subsequent requests to the central TSM 202 including, for example, a request to instantiate an uninstantiated application. In turn, the central TSM 202 extradites the instantiated application (i.e., the instance) to a corresponding security domain (e.g., central SD, SP SD).
In an alternative embodiment, the central TSM 202 includes an ESB, and utilizes the ESB to process requests including, for example, to process a script, manage a communication, or activate a service.
B. Communicating Multiple Service Provider TSM Requests to a Secure Element
In
Once the SP TSM 303 receives the secure element identifier, the SP TSM 303 transmits, at step 358, a request (Request SE Data), over the communications network, to the central TSM 302, including a request to obtain secure element data (as discussed in further detail above with reference to
At step 364, the SP TSM 303 subsequently transmits a request (Request to Manage Comm. (Begin)), based on the received secure element identifier and data, to manage a communication to the central TSM 302.
1. Managing a Communication
In general, a request to manage a communication may include a request to begin a communication or a request to end a communication. In an exemplary embodiment, a communication is a notification from a first device (e.g., SP TSM 303, central TSM 302) to a second device (e.g., secure element 301), that the first device intends to perform an over-the-air (OTA) communication or operation with the second device.
As shown in
The communication request (Request to Manage Comm. (Begin)) transmitted at step 364 by the SP TSM 303 to the central TSM 302 may include the following attributes: secure element identifier, MSI, service identifier, service qualifier, target application identifier, format and size of scripts to be executed during the OTA communication, and operation requested (e.g., key rotation, personalization). The “operation requested” attribute is used by the central TSM 302 to track the progress of that operation.
The service identifier may include a service identifier number and version, which are used to identify a general definition of the service. The service qualifier includes a service provider name and payment account reference number (PRN).
The service qualifier is used to identify the particular instance of the service (i.e., the service corresponding to the service identifier) that is to be acted on (e.g., installed, locked, unlocked, deleted) using requests, including commands, during a communication.
The PRN is a unique number for identifying a credential or card (e.g., payment card) associated with a service.
As shown in
As further shown in
As shown in
2. Processing One or More Scripts
In general, a request to process one or more scripts enables the SP TSM 303, using the central TSM 302, to request sending a set of command application protocol data units (APDUs) directed to the secure element 301 and to be executed on the secure element 301. This request may be based on, for example, Global Platform messaging standards, and may be used, for example, to request: application personalization, key rotation, and/or post-personalization. A list of commands which can be sent to the secure element for processing are discussed below with reference to
Each script or command APDU may be used to execute an operation based on or using data that is prestored (i.e., loaded during manufacture) on the secure element. This data may include, for example, code, applets or applications. Using scripts and/or APDUs commands, the SP TSM 303 may request that the central TSM 302 instantiate, for example, an uninstantiated application on the secure element 301, and extradite the instance to a corresponding security domain on the secure element 301.
In an exemplary embodiment, application personalization is the insertion or upload of data onto an application on a security domain in a secure element. That is, a service provider may insert or upload sensitive data, including account and customer data, onto an application on a secure element in the customer's mobile device. More specifically, an SP TSM may transmit a request to personalize an application, including commands and data, to a central TSM. The central TSM may then send a request, based on the request received from the SP TSM, to the secure element to personalize the application on the secure element associated with the customer.
In an exemplary embodiment, key rotation is the concept of setting or inserting a digital key (i.e., an algorithm that undoes the work of an encryption algorithm) provided by a service provider into a security domain in a secure element.
In an exemplary embodiment, post-personalization is the concept of sending requests, including command APDUs to a secure element via a central TSM. In particular, post-personalization requests are sent by a service provider to execute outstanding commands after personalization has been performed.
The request to process one or more scripts may include a communication identifier (as described above) and a list of command APDUs to be sent to and executed in the secure element 301, with reference to a security domain. That is, the SP TSM 303 uses an established communication (and the attributes defined therein) to send a list of commands to the secure element 301 to be executed with regard to a specific and corresponding application or to an uninstantiated application.
Examples of command APDUs include: “Delete Key,” “Get Data,” “Get Status,” “Put Key,” “Select,” “Set Status,” “Store Data,” and “Install”. These command APDUs may be used to retrieve applications and application data, select applications, lock and unlock applications, personalize applications, instantiate uninstantiated applications, extradite instantiated applications to corresponding SP SDs, and update and delete security domain keys. Command APDUs are described in further detail below with reference to
As shown in
As further shown in
In an alternative embodiment, the request to perform key rotation and the request to perform application personalization are transmitted from the SP TSM 303 to the central TSM 302 in a single request.
In another alternative embodiment, multiple operations are performed during a single communication.
3. Activating a Service
As shown in
In general, a request to activate a service is used to activate a service provider's service and make the applications associated with that service selectable on a particular secure element. This request may include the following attributes: secure element identifier, MSI, service identifier, and service qualifier. The service identifier and service qualifier may be used to identify the general and particular instance of the service to be activated on the secure element 301.
The central TSM 302 receives the request to activate a service, and processes the request at step 394 using the information provided in the request. The central TSM 302, at step 396, transmits a response (Response to Request to Activate Service) to the request to the SP TSM 303, including information indicating the execution status of the request (i.e., whether execution failed or succeeded).
In an alternative embodiment, the request to activate a service and requests to perform key rotation and/or application personalization are transmitted from the SP TSM 303 to the central TSM 302 in a single request.
In an alternative embodiment, the central TSM 302 includes an ESB, and utilizes the ESB to process requests including, for example, to process a script, manage a communication, or activate a service.
C. Transmitting a Pre-Personalization Request from an SP TSM to a Secure Element
In
Upon receiving the request, the central TSM 402, at step 454, queries a memory (Query Memory) for the secure element data including the secure element identifier, based on the MSI included in the request (Request SE Data). Once the secure element data has been retrieved, the central TSM 402 transmits, at step 456, a response (Response to Request SE Data) including the secure element data to the SP TSM 403.
As shown in
In an example embodiment, pre-personalization includes creating a security domain, instantiating one or more uninstantiated applications, and extraditing the instance to the security domain. Pre-personalization may also include determining whether security domains and applications already exist on the secure element, performing a technical eligibility check, and loading and instantiating applications.
The central TSM 402 receives the pre-personalization request and, based on this request, transmits, at step 460, a request (Request Security Domain Creation) to the secure element 401 to create a security domain (discussed in further detail below with reference to
The central TSM 402, after transmitting the requests to the secure element 401, transmits, at step 464, a pre-personalization response (Response to Request Pre-personalization) to the SP TSM 403, indicating whether the pre-personalization requested by the SP TSM 403 failed or succeeded.
The secure element 401 may also transmit a response to each request, after each request has been processed.
The central TSM 402 may also determine whether applications are instantiated and/or whether security domains are created on a secure element.
The SP TSM 403 requests to the central TSM 402 are transmitted via an enterprise service bus (ESB).
In an alternative embodiment, the central TSM 402 includes an ESB, and utilizes the ESB to process requests including, for example, to process a script, manage a communication, or activate a service.
D. Embedded Secure Element Configuration
The central SD 504 may perform content management operations on the secure element 501, including instantiating applets (e.g., applets 505-1 and 506-1). That is, applets 505-1 and 506-1 are instances of applications (i.e., uninstantiated applications). In particular, the central SD 504 may securely manage applications (e.g., applets 505-1 and 506-1), create SP SDs, and perform management operations on applets or applications in the secure element.
Each of SP SDs 505 and 506 are associated with applet instances 505-1 and 506-1, respectively, and the SP SDs 505 and 506 assist their respective applets in the establishment of secure channels and in the applet personalization process. Applet instances 505-1 and 506-1 may be created by instantiating uninstantiated applets or applications. Applet instances (e.g., applets 505-1 and 506-1) are created under (i.e., associated with) the central SD 504, and if appropriate, the applet instances are extradited (i.e., delivered) to their respective SP SDs (e.g., applet 505-1 is extradited to its respective SD, SP SD 505). If the instances are not extradited, they may remain under the central SD 504.
As illustrated in
As illustrated in
SP SDs 505 and 506 have Data Authentication Pattern (DAP) verification privilege (discussed in further detail below with reference to Table 1), in order to verify the integrity of binary files managed and handled by the central TSM 502. Data packages that do not require DAP verification are loaded under (i.e., associated with) the central SD 504 (e.g., payment package 508), and data packages that require DAP verification are loaded under their respective SP SDs.
Table 1 illustrates privileges (e.g., Global Platform privileges) assigned to a central SD (e.g., central SD 504) and an SP SD (e.g., SP SDs 505 and 506), according to the secure element configuration 500.
Table 2 illustrates privileges (e.g., Global Platform privileges) commands supported by a central SD (e.g., central SD 504), according to the secure element configuration 500.
Table 3 illustrates the commands (e.g., Global Platform commands) supported by an SP SD (e.g., SP SDs 505 and 506), according to the secure element configuration 500.
In an alternative embodiment, one or both of SP SDs 505 and 506 do not have DAP verification privilege.
In an alternative embodiment, the secure element 501 includes multiple central SDs.
In another alternative embodiment, each SP SD is associated with a corresponding SP TSM.
E. UICC Secure Element Configuration
The secure element 601 is implemented as a UICC, and includes a central SD 604, a secure element issuer SD (ISD) 605, an MNO SD 606, an SP SD 608 and an SP SD 609. The MNO SD 606 is associated with a telecommunications applet 612. The central SD 604 is associated with a package 610, and a wallet companion applet 611. The SP SDs 608 and 609, which are associated with the central SD 604, are associated with applets 608-1 and 609-1, respectively.
The ISD 605 creates the central SD 604 and the MNO SD 606, but does not perform any other content management functions.
The MNO SD 606 has Authorized Management privileges (discussed in further detail below with reference to Table 2), and manages content as instructed by the MNO 607.
The central SD 604 has Authorized Management privileges (discussed in further detail below with reference to Table 2), and manages content as instructed by the central TSM 602. In particular, the central SD 604 may securely manage applications, create SP SDs, and perform management operations on applets or applications in the secure element.
The SP SDs 608 and 609 assist their respective applets in the establishment of secure channels and in the applet personalization process. Applet instances 608-1 and 609-1 may be created by instantiating uninstantiated applets or applications. Applet instances (e.g., applets 608-1 and 609-1) are created under (i.e., associated with) the central SD 604. After instantiation, if appropriate, the applet instances are extradited (i.e., delivered) to their respective SP SDs (e.g., applet 608-1 is extradited to its respective SD, SP SD 608). Alternatively, if an applet instance is not extradited, it may remain under the central SD 604.
SP SDs 608 and 609 have DAP verification privilege, in order to verify the integrity of binary files managed and handled by the central TSM 602. Data packages that do not require DAP verification are loaded under (i.e. associated with) the central SD 604 (e.g., package 610), and the data packages that require DAP verification are loaded under their respective SP SDs.
As illustrated in
As further illustrated in
Table 4 illustrates privileges (e.g., Global Platform privileges) assigned to an ISD (e.g., ISD 605), a central SD (e.g., central SD 604), an MNO SD (e.g., MNO SD 606), and an SP SD (e.g., SP SDs 608 and 609), according to the secure element configuration 600.
Table 5 illustrates the commands (e.g., Global Platform commands) supported by an ISD (e.g., ISD 605), according to the secure element configuration 600.
Table 6 illustrates the commands (e.g., Global Platform commands) supported by a central SD (e.g., central SD 604), according to the secure element configuration 600.
Table 7 illustrates the commands (e.g., Global Platform commands) supported by an MNO SD (e.g., MNO SD 606), according to the secure element configuration 600.
In an alternative embodiment, one or both of SP SDs 608 and 609 do not have DAP verification privilege.
F. Embedded Secure Element Configuration with Third Party Security Domain
The secure element 701 is implemented as an embedded secure element or as an NFC enabler such as a separate chip or secure device, and includes a central SD 704, an ISD 705, a third party SD 706, a Mandated DAP Privilege Holder Security Domain (MDPH SD) 716, a Controlling Authority Security Domain (CA SD) 717, an SP SD 709, an SP SD 710 (with Delegated Management), and an SP SD 711.
The MDPH SD 716 verifies the signatures (i.e., DAP) of the applets and applications loaded or installed on the secure element 701. Table 10 (below) illustrates the commands supported by an MDPH SD.
The CA SD 717 performs key generation for newly created security domains, in order to guarantee confidential loading. Table 9 (below) illustrates the commands supported by a CA SD.
The third party SD 706 has Authorized Management privilege, and manages content as instructed by the third party TSM 708. The third party SD 706 is associated with a package 714. The SP SD 711 is under (i.e., it is associated with) the third party SD 706, and is associated with an application 711-1. Table 6 (above) illustrates the commands supported by a third party SD (e.g., third party SD 706).
The ISD 705 creates security domains, including central SD 704, and third party SD 706, but does not perform any other content management functions. Table 5 (above) illustrates the commands supported by an ISD (e.g., ISD 705) in further detail.
The central SD 704 has Authorized Management privileges (discussed in further detail below with reference to Tables 8.1 and 8.2), and manages the content as instructed by the central TSM 702. In particular, the central SD 704 may securely manage applications, create SP SDs, and perform management operations on applets or applications in the secure element. The central SD 704 is associated with a package 713, the SP SD 709 and the SP SD 710. The SP SDs 709 and 710 are associated with applets 709-1 and 710-1. Table 6 above illustrates the commands supported by a central SD.
The SP SDs 709, 710, and 711 assist their respective applets in the establishment of secure channels and in the applet personalization process. Applet instances 709-1 and 710-1 may be created by instantiating uninstantiated applets or applications. Applet instances (e.g., applets 709-1 and 710-1) are created under (i.e., associated with) the central SD 704. After instantiation, if appropriate, applet instances are extradited (i.e., delivered) to their respective SP SDs. Table 3 (above) illustrates the commands supported by an SP SD, and Table 11 (below) illustrates the commands supported by an SP SD with Delegated Management privileges (e.g., SP SD 710).
SP SDs 709 and 710 have DAP verification privilege, in order to verify the integrity of binary files managed and handled by the central TSM 702. Data packages that do not require DAP verification (e.g., package 713) are loaded under (i.e., associated with) the central SD 704, and the data packages that require DAP verification are loaded under their respective SP SDs. Additionally, the SP SDs with Delegated Management privileges (e.g., 710) may perform authorized content management operations.
As illustrated in
As further illustrated in
Tables 8.1 and 8.2 illustrate the privileges (e.g., Global Platform privileges) assigned to an ISD (e.g., ISD 705), a central SD (e.g., central SD 704), an MDPH SD (e.g., MDPH SD 716), a CA SD (e.g., CA SD 717), a third party SD (e.g., third party SD 706), an SP SD (e.g., SP SD 709), and an SP SD with Delegated Management (e.g., SP SD 710).
Table 9 illustrates the commands (e.g., Global Platform commands) supported by a CA SD (e.g., CA SD 717), according to the secure element configuration 700.
Table 10 illustrates the commands (e.g., Global Platform commands) supported by an MDPH SD (e.g., MDPH SD 716), according to the secure element configuration 700.
Table 11 illustrates the commands (e.g., Global Platform commands) supported by an SP SD with Delegated Management (e.g., SP SD 710), according to the secure element configuration 700.
In an alternative embodiment, the third party TSM 703 has Delegated Management privileges, but content management operations are first be approved by the central TSM 702. The central TSM 702 can verify tokens and generate receipts for each associated SP SD that is not also associated with a third party TSM (e.g., SP SD 709). The third party TSM 703 controls the keys to its associated SP SDs (e.g., SP SD 710) and can load, install, extradite, or delete any associated applications or applets (e.g., applet 710-1) through its associated SP SD.
In an alternative embodiment, one or both of SP SDs 709 and 710 do not have DAP verification privilege.
In an alternative embodiment, one or both of MDPH SD 716 and CA SD 717 are not included in the secure element 701.
In another alternative embodiment, the secure element 701 has zero or more third party SDs.
G. UICC Secure Element Configuration with Third Party Security Domain
The secure element 801 is implemented as a UICC, and includes a central SD 804, an ISD 805, a third party SD 806, an MNO SD 815, an MDPH SD 817, and a CA SD 818. The secure element 801 also includes an SP SD 809, and SP SD (with Delegated Management) 810, and an SP SD 811.
The MNO SD 815 has Authorized Management privileges and can manage content as instructed by the MNO 807.
The MDPH SD 817 verifies the signatures (i.e., DAP) of the applets and applications loaded or installed on the secure element 801. Table 10 (above) illustrates the commands supported by an MDPH SD.
The CA SD 818 performs key generation for newly created security domains, in order to guarantee confidential loading. Table 9 (above) illustrates the commands supported by a CA SD.
The third party SD 806 has Authorized Management privilege, and manages content as instructed by the third party TSM 808. The third party SD 806 is associated with a package 814. The SP SD 811 is under (i.e., it is associated with) the third party SD 806, and is associated with an application 811-1. The third party SD 806 supports the same commands illustrated in Table 6 (above).
The ISD 805 creates security domains, including central SD 804, and third party SD 806, but does not perform any other content management functions. Table 5 (above) illustrates the commands supported by an ISD.
The central SD 804 has Authorized Management privileges (discussed in further detail above with reference to Table 2), and manages the content as instructed by the central TSM 802. In particular, the central SD 804 may securely manage applications, create SP SDs, and perform management operations on applets or applications in the secure element. The central SD 804 is associated with a package 813, the SP SD 809 and the SP SD 810. The SP SDs 809 and 810 are associated with applets 809-1 and 810-1. Table 6 above illustrates the commands supported by a central SD.
As illustrated in
As further illustrated in
As further illustrated in
Tables 12.1 and 12.2 illustrate the privileges (e.g., Global Platform privileges) assigned to an ISD (e.g., ISD 805), a central SD (e.g., central SD 804), an MDPH SD (e.g., MDPH SD 817), a CA SD (e.g., CA SD 818), a third party SD (e.g., third party SD 806), an MNO SD (e.g., MNO SD 815), an SP SD (e.g., SP SD 809), and an SP SD with Delegated Management (e.g., SP SD 810).
In an alternative embodiment, one or both of SP SDs 809 and 810 do not have DAP verification privilege.
In another alternative embodiment, one or both of MDPH SD 817 and CA SD 818 are not included in the secure element 801.
H. Computer Readable Medium Implementation
The present invention (e.g., system 100, sequences 200-400, configurations 500-800, or any part(s) or function(s) thereof) can be implemented using hardware, software, or a combination thereof, and can be implemented in one or more mobile device or other processing systems. To the extent that manipulations performed by the present invention were referred to in terms of human operation, no such capability of a human operator is necessary, or desirable in most cases, in any of the operations described herein which form part of the present invention. Rather, the operations described herein are machine operations. Useful machines for performing the operations of the present invention include mobile phones, smartphones, personal digital assistants (PDAs) or similar devices.
In one embodiment, the invention is directed toward one or more systems capable of carrying out the functionality described herein. An example of a system 900 is shown in
The system 900 includes one or more processors, such as processor 901. The processor 901 is connected to a communication infrastructure 902 (e.g., communication bus, network). Various embodiments are described in terms of this exemplary system. After reading this description, it will become more apparent to a person skilled in the relevant art(s) how to implement the invention using other systems and/or architectures.
The system 900 also includes a main memory 903, which may be a database, or the like.
The system 900 also includes a querying module 904 for querying the main memory 903. Querying a memory (e.g., main memory 903) is discussed in further detail above with reference to
The system 900 also includes a receiving module 905 for receiving data, such as requests, from other entities over a network. Receiving data, such as requests, is discussed in further detail above with reference to
The system 900 also includes a transmission module 906 for transmitting data, such as requests and responses, to other entities over a network. Transmitting data, such as requests and responses, is discussed in further detail above with reference to
Each of modules 904-906 may be implemented using hardware, software or a combination of the two.
The example embodiments described above such as, for example, the systems and procedures depicted in or discussed in connection with
Portions of the example embodiments of the invention may be conveniently implemented by using a conventional general purpose computer, a specialized digital computer and/or a microprocessor programmed according to the teachings of the present disclosure, as is apparent to those skilled in the computer art. Appropriate software coding may readily be prepared by skilled programmers based on the teachings of the present disclosure.
Some embodiments may also be implemented by the preparation of application-specific integrated circuits, field programmable gate arrays, or by interconnecting an appropriate network of conventional component circuits.
Some embodiments include a computer program product. The computer program product may be a non-transitory storage medium or media having instructions stored thereon or therein which can be used to control, or cause, a computer to perform any of the procedures of the example embodiments of the invention. The storage medium may include without limitation a floppy disk, a mini disk, an optical disc, a Blu-ray Disc, a DVD, a CD or CD-ROM, a micro-drive, a magneto-optical disk, a ROM, a RAM, an EPROM, an EEPROM, a DRAM, a VRAM, a flash memory, a flash card, a magnetic card, an optical card, nanosystems, a molecular memory integrated circuit, a RAID, remote data storage/archive/warehousing, and/or any other type of device suitable for storing instructions and/or data.
Stored on any one of the non-transitory computer readable medium or media, some implementations include software for controlling both the hardware of the general and/or special computer or microprocessor, and for enabling the computer or microprocessor to interact with a human user or other mechanism utilizing the results of the example embodiments of the invention. Such software may include without limitation device drivers, operating systems, and user applications. Ultimately, such computer readable media further includes software for performing example aspects of the invention, as described above.
Included in the programming and/or software of the general and/or special purpose computer or microprocessor are software modules for implementing the procedures described above.
While various example embodiments of the invention have been described above, it should be understood that they have been presented by way of example, and not limitation. It is apparent to persons skilled in the relevant art(s) that various changes in form and detail can be made therein. Thus, the disclosure should not be limited by any of the above described example embodiments, but should be defined only in accordance with the following claims and their equivalents.
In addition, it should be understood that the figures are presented for example purposes only. The architecture of the example embodiments presented herein is sufficiently flexible and configurable, such that it may be utilized and navigated in ways other than that shown in the accompanying figures.
Further, the purpose of the Abstract is to enable the U.S. Patent and Trademark Office and the public generally, and especially the scientists, engineers and practitioners in the art who are not familiar with patent or legal terms or phraseology, to determine quickly from a cursory inspection the nature and essence of the technical disclosure of the application. The Abstract is not intended to be limiting as to the scope of the example embodiments presented herein in any way. It is also to be understood that the procedures recited in the claims need not be performed in the order presented.
This application is a continuation of and claims priority to U.S. patent application Ser. No. 14/791,397, filed Jul. 3, 2015 and entitled “Systems, Methods, and Computer Program Products for Interfacing Multiple Service Provider Trusted Service Managers and Secure Elements,” which is a continuation of and claims priority to U.S. patent application Ser. No. 13/653,160, filed Oct. 16, 2012 and entitled “Systems, Methods, and Computer Program Products for Interfacing Multiple Service Provider Trusted Service Managers and Secure Elements,” which claims priority under 35 U.S.C. § 119 to U.S. Provisional Application No. 61/702,653, filed Sep. 18, 2012 and entitled “Systems, Methods, and Computer Program Products for Interfacing Multiple Service Provider Trusted Service Managers and Secure Elements,” and to U.S. Provisional Application No. 61/554,393, filed Nov. 1, 2011 and entitled “Delegated Management of Secure Element Security Domains and Application Personalization, and Certification of Devices and Secure Elements.” The complete disclosure of the above-identified priority applications is hereby fully incorporated herein by reference.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5221838 | Gutman et al. | Jun 1993 | A |
| 5590038 | Pitroda | Dec 1996 | A |
| 5640002 | Ruppert et al. | Jun 1997 | A |
| 5748740 | Curry et al. | May 1998 | A |
| 5805702 | Curry et al. | Sep 1998 | A |
| 5883810 | Franklin et al. | Mar 1999 | A |
| 5884271 | Pitroda | Mar 1999 | A |
| 5901303 | Chew | May 1999 | A |
| 5940510 | Curry et al. | Aug 1999 | A |
| 5949880 | Curry et al. | Sep 1999 | A |
| 6000832 | Franklin et al. | Dec 1999 | A |
| 6005942 | Chan et al. | Dec 1999 | A |
| 6073840 | Marion | Jun 2000 | A |
| 6105013 | Curry et al. | Aug 2000 | A |
| 6116505 | Withrow | Sep 2000 | A |
| 6131811 | Gangi | Oct 2000 | A |
| 6148192 | Ahvenainen | Nov 2000 | A |
| 6233683 | Chan et al. | May 2001 | B1 |
| 6237095 | Curry et al. | May 2001 | B1 |
| 6422464 | Terranova | Jul 2002 | B1 |
| 6587835 | Treyz et al. | Jul 2003 | B1 |
| 6601759 | Fife et al. | Aug 2003 | B2 |
| 6671358 | Seidman et al. | Dec 2003 | B1 |
| 6732081 | Nicholson | May 2004 | B2 |
| 6769607 | Pitroda et al. | Aug 2004 | B1 |
| 6786400 | Bucci | Sep 2004 | B1 |
| 6813609 | Wilson | Nov 2004 | B2 |
| 6837436 | Swartz et al. | Jan 2005 | B2 |
| 6879965 | Fung et al. | Apr 2005 | B2 |
| 6912398 | Domnitz | Jun 2005 | B1 |
| 6925439 | Pitroda | Aug 2005 | B1 |
| 7083094 | Cooper | Aug 2006 | B2 |
| 7110792 | Rosenberg | Sep 2006 | B2 |
| 7127236 | Khan et al. | Oct 2006 | B2 |
| 7155405 | Petrovich | Dec 2006 | B2 |
| 7194422 | St. John Killick | Mar 2007 | B1 |
| 7216109 | Donner | May 2007 | B1 |
| 7249112 | Berardi et al. | Jul 2007 | B2 |
| 7286818 | Rosenberg | Oct 2007 | B2 |
| 7298271 | Sprogis | Nov 2007 | B2 |
| 7308426 | Pitroda | Dec 2007 | B1 |
| 7330714 | Rosenberg | Feb 2008 | B2 |
| 7349885 | Gangi | Mar 2008 | B2 |
| 7363265 | Horgan | Apr 2008 | B2 |
| 7401731 | Pletz | Jul 2008 | B1 |
| 7469151 | Khan et al. | Dec 2008 | B2 |
| 7469381 | Ording | Dec 2008 | B2 |
| 7483858 | Foran et al. | Jan 2009 | B2 |
| 7494055 | Fernandes et al. | Feb 2009 | B2 |
| 7529563 | Pitroda | May 2009 | B1 |
| 7571139 | Giordano et al. | Aug 2009 | B1 |
| 7581678 | Narendra et al. | Sep 2009 | B2 |
| 7613628 | Ariff et al. | Nov 2009 | B2 |
| 7631810 | Liu et al. | Dec 2009 | B2 |
| 7685037 | Reiners et al. | Mar 2010 | B2 |
| 7693752 | Jaramillo | Apr 2010 | B2 |
| 7702578 | Fung et al. | Apr 2010 | B2 |
| 7708198 | Gangi | May 2010 | B2 |
| 7712658 | Gangi | May 2010 | B2 |
| 7775430 | Lin | Aug 2010 | B2 |
| 7802264 | Robertson et al. | Sep 2010 | B2 |
| 7805615 | Narendra et al. | Sep 2010 | B2 |
| 7809652 | Dixon et al. | Oct 2010 | B2 |
| 7818727 | Wilkinson et al. | Oct 2010 | B2 |
| 7828214 | Narendra et al. | Nov 2010 | B2 |
| 7856377 | Cohagan et al. | Dec 2010 | B2 |
| 7864163 | Ording et al. | Jan 2011 | B2 |
| 7865414 | Fung et al. | Jan 2011 | B2 |
| 7890422 | Hirka et al. | Feb 2011 | B1 |
| 7922083 | Harrison et al. | Apr 2011 | B2 |
| 7942337 | Jain | May 2011 | B2 |
| 7954715 | Narendra et al. | Jun 2011 | B2 |
| 7954716 | Narendra et al. | Jun 2011 | B2 |
| 7954717 | Narendra et al. | Jun 2011 | B2 |
| 7961101 | Narendra et al. | Jun 2011 | B2 |
| 7967215 | Kumar et al. | Jun 2011 | B2 |
| 7991158 | Narendra et al. | Aug 2011 | B2 |
| 7996288 | Stolfo | Aug 2011 | B1 |
| 8060449 | Zhu | Nov 2011 | B1 |
| 8069121 | Goodrich et al. | Nov 2011 | B2 |
| 8072331 | Narendra et al. | Dec 2011 | B2 |
| 8083145 | Narendra et al. | Dec 2011 | B2 |
| 8091786 | Narendra et al. | Jan 2012 | B2 |
| 8131645 | Lin et al. | Mar 2012 | B2 |
| 8140418 | Casey et al. | Mar 2012 | B1 |
| 8171525 | Pelly et al. | May 2012 | B1 |
| 8196131 | von Behren et al. | Jun 2012 | B1 |
| 8326758 | Bennett | Dec 2012 | B2 |
| 8392328 | Shah et al. | Mar 2013 | B2 |
| 8396808 | Greenspan | Mar 2013 | B2 |
| 8429046 | Pitroda | Apr 2013 | B2 |
| 8776189 | Jain | Jul 2014 | B2 |
| 8875228 | Gargiulo et al. | Oct 2014 | B2 |
| 9104887 | Gargiulo | Aug 2015 | B2 |
| 9323945 | Gargiulo et al. | Apr 2016 | B2 |
| 9544759 | Gargiulo | Jan 2017 | B2 |
| 20020040936 | Wentker et al. | Apr 2002 | A1 |
| 20020049631 | Williams | Apr 2002 | A1 |
| 20020082921 | Rankin | Jun 2002 | A1 |
| 20020152156 | Tyson-Quah | Oct 2002 | A1 |
| 20020174025 | Hind et al. | Nov 2002 | A1 |
| 20020179703 | Allen | Dec 2002 | A1 |
| 20030009382 | D'Arbeloff et al. | Jan 2003 | A1 |
| 20030061157 | Hirka et al. | Mar 2003 | A1 |
| 20030083042 | Abuhamdeh | May 2003 | A1 |
| 20030115126 | Pitroda | Jun 2003 | A1 |
| 20030126094 | Fisher et al. | Jul 2003 | A1 |
| 20030132298 | Swartz et al. | Jul 2003 | A1 |
| 20030200489 | Hars | Oct 2003 | A1 |
| 20040024703 | Roskind | Feb 2004 | A1 |
| 20040073519 | Fast | Apr 2004 | A1 |
| 20040143550 | Creamer et al. | Jul 2004 | A1 |
| 20040148255 | Beck et al. | Jul 2004 | A1 |
| 20040166839 | Okkonen et al. | Aug 2004 | A1 |
| 20040186768 | Wakim et al. | Sep 2004 | A1 |
| 20050004866 | Bonalle et al. | Jan 2005 | A1 |
| 20050171898 | Bishop et al. | Aug 2005 | A1 |
| 20050186954 | Kenney | Aug 2005 | A1 |
| 20050191968 | Tabayashi et al. | Sep 2005 | A1 |
| 20050199714 | Brandt et al. | Sep 2005 | A1 |
| 20050222961 | Staib et al. | Oct 2005 | A1 |
| 20050234769 | Jain et al. | Oct 2005 | A1 |
| 20050247777 | Pitroda | Nov 2005 | A1 |
| 20050251446 | Jiang et al. | Nov 2005 | A1 |
| 20060149665 | Weksler | Jul 2006 | A1 |
| 20060178937 | Rau et al. | Aug 2006 | A1 |
| 20060287004 | Fuqua | Dec 2006 | A1 |
| 20070014407 | Narendra et al. | Jan 2007 | A1 |
| 20070014408 | Narendra et al. | Jan 2007 | A1 |
| 20070095892 | Lyons et al. | May 2007 | A1 |
| 20070170247 | Friedman | Jul 2007 | A1 |
| 20070198432 | Pitroda et al. | Aug 2007 | A1 |
| 20070265961 | Shah et al. | Nov 2007 | A1 |
| 20070288745 | Kwan et al. | Dec 2007 | A1 |
| 20070288747 | Kwan et al. | Dec 2007 | A1 |
| 20080015988 | Brown et al. | Jan 2008 | A1 |
| 20080306849 | Johnson, Jr. et al. | Dec 2008 | A1 |
| 20080319887 | Pizzi et al. | Dec 2008 | A1 |
| 20090037333 | Flitcroft et al. | Feb 2009 | A1 |
| 20090098854 | Park et al. | Apr 2009 | A1 |
| 20090108064 | Fernandes et al. | Apr 2009 | A1 |
| 20090149192 | Vargas et al. | Jun 2009 | A1 |
| 20090164322 | Khan et al. | Jun 2009 | A1 |
| 20090172678 | Branca, Jr. et al. | Jul 2009 | A1 |
| 20090192935 | Griffin et al. | Jul 2009 | A1 |
| 20090240620 | Kendrick et al. | Sep 2009 | A1 |
| 20090313143 | Darensbourg et al. | Dec 2009 | A1 |
| 20100036770 | Fourez et al. | Feb 2010 | A1 |
| 20100070649 | Ng | Mar 2010 | A1 |
| 20100082481 | Lin et al. | Apr 2010 | A1 |
| 20100094753 | Carlson et al. | Apr 2010 | A1 |
| 20100114739 | Johnston | May 2010 | A1 |
| 20100138518 | Aiglstorfer et al. | Jun 2010 | A1 |
| 20100174595 | Aaltonen et al. | Jul 2010 | A1 |
| 20100188975 | Raleigh | Jul 2010 | A1 |
| 20100198728 | Aabye et al. | Aug 2010 | A1 |
| 20100211445 | Bodington | Aug 2010 | A1 |
| 20100241494 | Kumar et al. | Sep 2010 | A1 |
| 20100257040 | Hunt | Oct 2010 | A1 |
| 20100291896 | Corda | Nov 2010 | A1 |
| 20100291904 | Musfeldt et al. | Nov 2010 | A1 |
| 20100312636 | Coulter et al. | Dec 2010 | A1 |
| 20110006113 | Uchikura | Jan 2011 | A1 |
| 20110029786 | Raffard et al. | Feb 2011 | A1 |
| 20110034160 | Corda et al. | Feb 2011 | A1 |
| 20110055047 | Fox | Mar 2011 | A1 |
| 20110073663 | Narendra et al. | Mar 2011 | A1 |
| 20110087610 | Batada et al. | Apr 2011 | A1 |
| 20110113473 | Corda et al. | May 2011 | A1 |
| 20110127324 | Hirka et al. | Jun 2011 | A1 |
| 20110131133 | Hirka et al. | Jun 2011 | A1 |
| 20110145152 | McCown | Jun 2011 | A1 |
| 20110151836 | Dadu et al. | Jun 2011 | A1 |
| 20110161188 | Roberts | Jun 2011 | A1 |
| 20110171996 | Narendra et al. | Jul 2011 | A1 |
| 20110180598 | Morgan et al. | Jul 2011 | A1 |
| 20110191149 | Blackhurst et al. | Aug 2011 | A1 |
| 20110218849 | Rutigliano et al. | Sep 2011 | A1 |
| 20110223972 | Narendra et al. | Sep 2011 | A1 |
| 20110231238 | Khan et al. | Sep 2011 | A1 |
| 20110238510 | Rowen et al. | Sep 2011 | A1 |
| 20110244796 | Khan et al. | Oct 2011 | A1 |
| 20110269438 | Narendra et al. | Nov 2011 | A1 |
| 20110271044 | Narendra et al. | Nov 2011 | A1 |
| 20110272468 | Narendra et al. | Nov 2011 | A1 |
| 20110272469 | Narendra et al. | Nov 2011 | A1 |
| 20110282780 | French et al. | Nov 2011 | A1 |
| 20110289001 | Bishop et al. | Nov 2011 | A1 |
| 20110320345 | Taveau et al. | Dec 2011 | A1 |
| 20120047237 | Arvidsson | Feb 2012 | A1 |
| 20120064828 | Khan et al. | Mar 2012 | A1 |
| 20120089520 | Mardikar | Apr 2012 | A1 |
| 20120108206 | Haggerty | May 2012 | A1 |
| 20120109681 | Chapman et al. | May 2012 | A1 |
| 20120109764 | Martin et al. | May 2012 | A1 |
| 20120171992 | Cheong et al. | Jul 2012 | A1 |
| 20120197773 | Grigg et al. | Aug 2012 | A1 |
| 20120231736 | Amiel et al. | Sep 2012 | A1 |
| 20120259768 | Mukherjee | Oct 2012 | A1 |
| 20120267432 | Kuttuva | Oct 2012 | A1 |
| 20120300932 | Cambridge | Nov 2012 | A1 |
| 20120304255 | Carnes | Nov 2012 | A1 |
| 20120323664 | Klems | Dec 2012 | A1 |
| 20130024289 | Cueli et al. | Jan 2013 | A1 |
| 20130060618 | Barton et al. | Mar 2013 | A1 |
| 20130080227 | Maskatia et al. | Mar 2013 | A1 |
| 20130111546 | Gargiulo et al. | May 2013 | A1 |
| 20130111599 | Gargiulo | May 2013 | A1 |
| 20140040126 | Andrews et al. | Feb 2014 | A1 |
| 20140082056 | Gargiulo | Mar 2014 | A1 |
| 20140164475 | Gargiulo | Jun 2014 | A1 |
| 20150007345 | Gargiulo et al. | Jan 2015 | A1 |
| 20150310223 | Gargiulo | Oct 2015 | A1 |
| 20170017956 | Gargiulo | Jan 2017 | A1 |
| Number | Date | Country |
|---|---|---|
| 2 381 614 | Mar 2001 | CA |
| 101878492 | Nov 2010 | CN |
| 1 153 375 | Jan 2003 | EP |
| 0 766 852 | Aug 2004 | EP |
| 1 412 890 | Nov 2004 | EP |
| 1 477 943 | Nov 2004 | EP |
| 1 222 503 | Dec 2004 | EP |
| 2 043 060 | Apr 2009 | EP |
| 2 048 591 | Apr 2009 | EP |
| 2 306 684 | Apr 2011 | EP |
| 2004-102784 | Apr 2004 | JP |
| 2007-288494 | Nov 2007 | JP |
| 2010-534879 | Nov 2010 | JP |
| 2011-508466 | Mar 2011 | JP |
| 10-2008-0096722 | Nov 2008 | KR |
| 10-2012-0046376 | May 2012 | KR |
| 2001018629 | May 2001 | WO |
| 2003012717 | Feb 2003 | WO |
| 2009013700 | Jan 2009 | WO |
| 2009060393 | May 2009 | WO |
| 2009144612 | Dec 2009 | WO |
| 2010050652 | May 2010 | WO |
| 2010084081 | Jul 2010 | WO |
| 2010120222 | Oct 2010 | WO |
| 2012042262 | Apr 2012 | WO |
| 2012091349 | Jul 2012 | WO |
| 2013063353 | May 2013 | WO |
| 2013066620 | May 2013 | WO |
| 2013066621 | May 2013 | WO |
| 2014022383 | Feb 2014 | WO |
| 2014047069 | Mar 2014 | WO |
| Entry |
|---|
| “Mexican Office Action received for Mexican Patent Application No. MX/a/2014/005180”, dated Oct. 19, 2015, 3 pages. |
| Aconyte, “Mobile Application Management”, Aconyte Smart Solutions, XP055050399, May 1, 2012, 6 pages. |
| Bai, “International Preliminary Report on Patentability issued in International Application No. PCT/US2013/052708”, dated Feb. 12, 2015, 7 pages. |
| Campbell, “Lewinsky Scandal Ends as Clinton is Disbarred”, Oct. 1, 2001, 2 pages. |
| Campen, “U.S. Office Action issued in copending U.S. Appl. No. 13/545,702, filed Jul. 10, 2012”, dated Jun. 17, 2013, 14 pages. |
| Colbert, “Office Action issued in copending U.S. Appl. No. 13/759,003, filed Feb. 4, 2013”, dated Jun. 6, 2013, 24 pages. |
| De Pol, “Australian Office Action issued in Australian Application No. 2016203535”, dated Mar. 15, 2017, 2 pages. |
| Di Felice, “International Search Report and Written Opinion issued in International Application No. PCT/US2013/060189”, dated Nov. 22, 2013, 9 pages. |
| “Chinese Office Action issued in Chinese Application No. 201280057986.5”, dated Jun. 3, 2016, 4 pages of English Translation and 5 pages of Chinese Office Action. |
| “Chinese Office Action issued in Chinese Application No. 201280059706.4 ”, dated Jun. 24, 2016, 3 pages of English Translation and 5 pages of Chinese Office Action. |
| Finextra Research, “Aconite launches Mobile Application Management”, XP055050391, Oct. 26, 2011, 2 pages. |
| Gee, “U.S. Office Action issued in copending U.S. Appl. No. 14/487,433, filed Sep. 16, 2014”, dated Aug. 17, 2015, 19 pages. |
| Gee, “U.S. Office Action issued in copending U.S. Appl. No. 14/487,433, filed Sep. 16, 2014”, dated May 8, 2015, 14 pages. |
| Gee, “U.S. Office Action issued in copending U.S. Appl. No. 15/073,064, filed Mar. 10, 2015”, dated Apr. 3, 2017, 17 pages. |
| Global Platform Inc., “Global Platform—Card Specification,” Global Platform Inc., version 2.1.1, Mar. 2003, pp. 1-237. |
| Global Platform Inc., “Global Platform's Proposition for NFC Mobile: Secure Element Management and Messaging,” Global Platform Inc., Apr. 2009, pp. 1-36. |
| Global Platform Inc., “Giobal Platform Card Contactless Services Card Specification v2.2—Amendment C”, Global Platform Inc., version 1.0., Feb. 2010, pp. 1-77. |
| Global Platform Inc., “Global Platform—Card Specification”, Global Platform Inc., version 2.2, Mar. 2006, pp. 1-375. |
| Johnson, “U.S. Office Action issued in copending U.S. Appl. No. 13/717,295, filed Dec. 17, 2012”, dated Feb. 28, 2013, 13 pages. |
| Kim, “International Search Report and Written Opinion issued in International Application No. PCT/US2013/052708”, dated Nov. 19, 2013, 10 pages. |
| Kim, “Korean Office Action issued in Korean Application No. 10-2014-7014377”, dated Sep. 24, 2014, 3 pages of English Translation and 3 pages of Korean Office Action. |
| Lau, “Canada Office Action issued in Canada Application No. 2854276”, dated Aug. 26, 2015, 4 pages. |
| Lau, “Canada Office Action issued in Canada Application No. 2854277”, dated Nov. 21, 2014, 5 pages. |
| Lau, “Canada Office Action received for Canada Patent Application No. 2854276”, dated Sep. 20, 2016, 3 pages. |
| Lee, “Korean Office Action issued in Korean Application No. 10-2014-7035460”, dated Mar. 31, 2016, 3 pages of English Translation and 4 pages of Korean Office Action only. |
| Lee, “Korean Office Action issued in Korean Application No. 10-2014-7035460”, dated Jul. 30, 2015, 6 pages of Korean Office Action only. |
| Louie, “U.S. Office Action issued in copending U.S. Appl. No. 13/653,145, filed Oct. 16, 2012, dated Jun. 17, 2013”, 7 pages. |
| Louie, “U.S. Office Action issued in copending U.S. Appl. No. 13/653,145, filed Oct. 16, 2012”, dated May 2, 2014, 9 pages. |
| Louie, “U.S. Office Action issued in copending U.S. Appl. No. 13/653,145, filed Oct. 16, 2012”, dated Oct. 25, 2013, 8 pages. |
| McCosker, “Australian Office Action issued in Australian Application No. 2012332956”, dated Apr. 20, 2015, 3 pages. |
| Moon, “International Preliminary Report on Patentability issued in International Application No. PCT/US2013/060189”, dated Apr. 2, 2015, 14 pages. |
| “Mexican Office Action received for Mexican Patent Application No. MX/a/2014/005180”, dated Jul. 10, 2015, 2 pages of Mexican OA only. |
| Nakazato, “Japanese Office Action issued in Japanese Application No. 2014-538837”, dated Apr. 27, 2015, 12 pages of English Translation and 11 pages of Japanese Office Action. |
| Nakazato, “Japanese Office Action issued in Japanese Application No. 2014-538837”, dated Oct. 5, 2015, 6 pages of English Translation and 6 pages of Japanese Office Action. |
| Nega, “U.S. Office Action issued in copending U.S. Appl. No. 13/653,160, filed Oct. 16, 2012”, dated Oct. 21, 2014, 10 pages. |
| NG, “Australian Office Action issued in Australian Application No. 2015234304”, dated Nov. 17, 2015, 3 pages. |
| Nguyen, “U.S. Office Action issued in copending U.S. Appl. No. 13/784,808, filed Mar. 4, 2013”, dated Jul. 15, 2013, 20 pages. |
| Nora, “International Preliminary Report on Patentability issued in International Application No. PCT/US2014/016922”, dated Dec. 3, 2015, 7 pages. |
| Omogbenigun, “Australian Office Action issued in Australian Application No. 2013318245”, dated Aug. 14, 2015, 3 pages. |
| Omogbenigun, “Australian Office Action issued in Australian Application No. 2013318245”, dated Jul. 8, 2015, 3 pages. |
| Nickitas-Etienne, “International Preliminary Report on Patentability and Written Opinion Received for PCT Patent Application No. PCT/US2012/060442”, dated May 15, 2014, 18 pages. |
| Di Felice, International Search Report and Written Opinion received for PCT Patent Application No. PCT/US2012/060442, dated Jan. 28, 2013, 11 pages |
| Nickitas-Etienne, International Preliminary Report on Patentability and Written Opinion Received for PCT Patent Application No. PCT/US2012/060445, dated May 15, 2014, 14 pages. |
| Di Felice, “International Search Report and Written Opinion received for PCT Patent Application No. PCT/US2012/060445”, dated Jan. 28, 2013, 10 pages. |
| Berlea, International Search Report and Written Opinion of the International Searching Authority for International Patent Application No. PCT/US2013/028697, dated May 23, 2013, 8 pages. |
| Verhoeg, International Search Report and Written Opinion of the International Searching Authority for International Patent Application No. PCT/US2013/033467, dated Jul. 4, 2013, 8 pages. |
| Maenpaa, “International Search Report and Written Opinion of the International Searching Authority for International Patent Application No. PCT/US2013/035406, dated Jul. 19, 2013,”, 8 pages. |
| Quittner, “PayPal Seeks to Cut Out Card Companies with New Plastic”, PayPal inc., Published in Bank Technology News, Oct. 18, 2011, 2 pages. |
| Roberti, “Extended European Search Report issued in European Application No. 14800349.4”, dated Dec. 15, 2016, 9 pages. |
| Shaikh, “U.S. Office Action issued in copending U.S. Appl. No. 13/802,705, filed Mar. 13, 2013”, dated Jul. 18, 2013, 11 pages. |
| Ziegle, “U.S. Office Action issued in copending U.S. Appl. No. 13/658,783, filed Oct. 23, 2012”, dated Jul. 11, 2013, 17 pages. |
| Shingles, “U.S. Office Action issued in copending U.S. Appl. No. 14/029,463, filed Sep. 17, 2013”, dated Dec. 3, 2015, 8 pages. |
| Trotter, “U.S. Office Action issued in copending U.S. Appl. No. 13/731,090, filed Dec. 30, 2012”, dated Nov. 3 2015, 14 pages. |
| Trotter, “U.S. Office Action issued in copending U.S. Appl. No. 13/731,090, filed Dec. 30, 2012”, dated Apr. 3, 2015, 15 pages. |
| Trotter, “U.S. Office Action issued in copending U.S. Appl. No. 13/731,090, filed Dec. 30, 2012”, dated Jun. 2, 2016, 13 pages. |
| Trotter, “U.S. Office Action issued in copending U.S. Appl. No. 13/731,090, filed Dec. 30, 2012”, dated Apr. 5, 2017, 14 pages. |
| Trotter, “U.S. Office Action issued in copending U.S. Appl. No. 13/731,090, filed Dec. 30, 2012”, dated Dec. 13, 2016, 14 pages. |
| Uchide, “Japanese Office Action issued in Japanese Application No. 2015-520725”, dated Feb. 29, 2016, 4 pages of English Translation and 4 pages of Japanese Office Action. |
| Uhthoff Orive, “Office Action received for Mexican Patent Application No. MX/a/2014/015189,” dated Feb. 15, 2016, 2 pages of English Translation and 2 pages of Mexican Office Action. |
| Vergas, “Mexican Office Action issued in Mexican Application No. MX/a/2014/005181”, dated May 20, 2016, 1 page of English Translation and 2 pages of Mexican Office Action. |
| Weidmann, “Extended European Search Report issued in European Application No. 13825094.9”, dated Dec. 9, 2015, 8 pages. |
| Wikipedia, “Disbarment”, From Wikipedia, the free encyclopedia, Dec. 24, 2010, 4 pages. |
| Woldemariam, “U.S. Office Action issued in copending U.S. Appl. No. 14/183,137, filed Feb. 18, 2014”, dated Nov. 4, 2015, 10 pages. |
| Woldemariam, “U.S. Office Action issued in copending U.S. Appl. No. 14/791,397, filed Jul. 3, 2015”, dated Aug. 31, 2016, 12 pages. |
| Yang, “International Search Report and Written Opinion issued in International Application No. PCT/US2014/016922”, dated Jun. 24, 2014, 8 pages. |
| Yliuntinen, “3rd Party TSM Management of SIM Cards”, Sep. 12, 2011, 4 pages. |
| Zhou, “Chinese Office Action issued in Chinese Application No. 201380050257.1”, dated Mar. 1, 2017, 9 pages of English Translation and 8 pages of Chinese Office Action. |
| Ziegle, “U.S. Office Action issued in copending U.S. Appl. No. 13/658,783, filed Oct. 23, 2012”, dated Mar. 5, 2013, 14 pages. |
| Woldemariam, “U.S. Office Action issued in copending U.S. Appl. No. 15/279,975, filed Sep. 29, 2013”, dated Aug. 10, 2017, 15 pages. |
| “Chinese Office Action issued in Chinese Application No. 201480035608.6”, dated Aug. 14, 2017, 6 pages of English Translation and 6 pages of Chinese Office Action. |
| “Chinese Office Action issued in Chinese Application No. 201380050257.1”, dated Oct. 31, 2017, 06 pages of English Translation and 06 pages of Chinese Office Action. |
| Yoon, “Korean Office Action issued in Korean Application No. 10-2017-7021176”, dated Aug. 21, 2017, 4 pages of English Translation and 3 pages of Korean Office Action. |
| Trotter, “U.S. Office Action issued in copending U.S. Appl. No. 13/731,090, filed Feb. 6, 2014”, dated Oct. 17, 2017, 14 pages. |
| “Chinese Office Action issued in Chinese Application No. 201480035608.6”, dated Feb. 11, 2018, 5 pages of Engiish Translation and 4 pages of Chinese Office Action. |
| Lau, “Canada Office Action received for Canada Patent Application No. 2,854,276”, dated Feb. 13, 2018, 4 pages. |
| Woldemariam, “U.S. Office Action issued in copending U.S. Appl. No. 15/279,975, filed Sep. 29, 2016”, dated Jan. 23, 2018, 12 pages. |
| Number | Date | Country | |
|---|---|---|---|
| 20170213051 A1 | Jul 2017 | US |
| Number | Date | Country | |
|---|---|---|---|
| 61702653 | Sep 2012 | US | |
| 61554393 | Nov 2011 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 14791397 | Jul 2015 | US |
| Child | 15481420 | US | |
| Parent | 13653160 | Oct 2012 | US |
| Child | 14791397 | US |
