Systems, methods, and computer program products for managing secure elements.

(54) Title: SYSTEMS, METHODS AND PRODUCTS OF COMPUTER PROGRAMS TO MANAGE SECURITY ELEMENTS.

(54) Title: SYSTEMS, METHODS, AND COMPUTER PROGRAM PRODUCTS FOR MANAGING SECURE ELEMENTS.

(57) Summary

Systems, methods and products of computer programs are provided to perform content management functions. At least one memory stores data and a central security domain manages instructions on behalf of one or more security domains of the service provider. Instructions are received, over a network, from a trusted service manager. The instructions are processed in at least one of the one or more security domains of the given service provider, using the data stored in the at least one memory. The data includes one or more generic applications, each of which is instantiated for one or more service providers.

(57) Abstract

Systems, methods, and Computer program products are provided for performing content management operations. At least one memory stores data, and a central security domain manages instructions on behalf of one or more Service provider security domains. The instructions are received, over a network, from a trusted Service manager. The instructions are processed in at least one of the one or more determined Service provider security domains, using the data stored in the at least one memory. The data ineludes one or more generic applications, each of which can be instantiated for one or more Service providers.

<img file="MX337986B_D0001.tif" />

_I KNOW_

SHRfURIADf K1KMIH

Institute

Mexican Property

Industrial

I

PATENT TITLE NO. 337986

Owner (s): GOOGLE INC.

Address: 1600 Amphitheater Parkway, Mountain View, California, 94043, USA

Name: SYSTEMS, METHODS AND PRODUCTS OF COMPUTER PROGRAMS TO MANAGE SECURITY ELEMENTS.

Classification: lnt.CI.8: G06F21 / 00; H04L9 / 32

Inventors): MICHAEL J. GARGIULO; FLORENT HAY

REQUEST

Number: International filing date:

<td>MX / a / 2014/005180</td><td colspan="2">October 16, 2012 PRIORITY _r</td>

<td>Country:</td><td>Date:</td><td>Number:</td>

<td>US</td><td>November 1, 2011</td><td> 61/554,393</td>

<td>US</td><td>September 18, 2012</td><td> 61/702,653</td>

<td colspan="3">Validity: Twenty years</td>

<td>Due date:</td><td>October 16, 2032</td><td></td>

The reference patent is granted based on articles 1 *, 2nd section V, 6th section III, and 59 of the Industrial Property Law.

This patent is valid for twenty years without extension

Pursuant to article 23 of the Law of the ProplédeeLi counted from the date of presentation of the legal rights. ta¹

<img file="MX337986B_D0002.tif" />

and it was subject to the payment of the rate to maintain v tes the Who subscribes if they present Industrial property (Day | »6/01/2004, 16/06/2005, Section a), 4th and 12th fraction title lace with fundamentally provided for by articles 6 tannes lll and 7 ° bis 2 of the Official Λ the Federation (DOF) 06/27/1991, amended to 0 $ Agraf ^^ / 10/1996. 12/26/1997 01/05/2006, 06/05/2009, 06/01/2010, 06/18/2010, 29/29/2010. 27W2012 and 04/09/2012); articles 1 », items I and llls of the Regulation of the Mexican Institute of Industrial Property (DOF 14/12/1999, re 1/07/2004 and 7/09 ^ 07); 'n

3rd ey of the '05 / 1999, action V rimed on and 30th of the Organic Institute of the Mexican Institute of Industrial Property (DOF 12/27/1999, amended on 10/10/2002, 07/29/2004, 08/04/2004 and 09/13/2007); 1, 3 and 5 subsection a) of the Agreement that delegates powers to the Deputy Directors General, Coordinator, Divisional Directors, Holders of the Regional Offices, Divisional Deputy Directors, Departmental Coordinators and other subordinates of the Mexican Institute of Industrial Property. (DOF 12/15/1999, amended on 02/04/2000, 07/29/2004, 08/04/2004 and 09/13/2007).

<img file="MX337986B_D0003.tif" />

Issue Date: March 30, 2016

THE DIVISIONAL DIRECTOR OF PATENTS

<img file="MX337986B_D0004.tif" />

NAHANNY CANAL REYES

<img file="MX337986B_D0005.tif" />

<img file="MX337986B_D0006.tif" />

Arenal No. 550. Floor 1,

Col. Pueblo Santa María Tepepan,

Xochimiico, CP 16029,

Mexico City

Tei. (55) 53 34 97 00 wwvy jmpl pofe. mx

MXZ2016 / 24091

351886

<img file="MX337986B_D0007.tif" />

I

X

MEXICAN INSTITUTE OF INDUSTRIAL PROPERTY to the management of

<img file="MX337986B_D0008.tif" />

COMPUTER PROGRAMS SYSTEMS, METHODS AND PRODUCTS

TO MANAGE SECURITY ELEMENTS Field of the Invention

The present invention relates to security elements and more specifically to computer program systems, methods and products for performing content management operations.

Background of the Invention

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 can be an activity, capacity, functionality, work, or use that is allowed or provided by a service provider such as a payment service, gift, loyalty offer or service, transit service, and the like.

In a mobile environment involving contactless transactions between a mobile device and a service provider, information regarding accounts and applications issued by service providers must be downloaded to mobile devices in order for them to

REF »248130 i

MEXICAN INSTITUTE of the KtomoAn

INDUSTRIAL

<img file="MX337986B_D0009.tif" />

transactions can be made without contact.

A trusted service manager (TSM) is normally an independent entity serving mobile network operators (MNOs) and account issuing service providers by provisioning applications, such as such as contactless applications associated with service providers, for mobile devices. Typical TSMs can remotely distribute and manage contactless applications as they have access to Security Elements (SEs) on a mobile device enabled for near field communication (NFC). in English) .

Critical security applications, such as those involving payments and account credentials, need secure hardware storage and a secure execution environment. On mobile devices, this is usually handled by the security element.

The security feature is a platform on which applications can be installed, customized, and managed. It is made up of hardware, software, interfaces and protocols that allow the secure storage of credentials and the execution of payment applications, authentication, and other services.

A security element can be implemented in

IMPI

Mexican Institute of Industrial Property

<img file="MX337986B_D0010.tif" />

different form factors, such as a universal integrated circuit card (UICC), an integrated security feature, or NFC enablers such as, for example, an external chip or security 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 MNOs. An integrated security element gives service providers the option of integrating the security element into the phone itself. One way in which the security element form factors are implemented is defined in, for example, the Global Platform Card Specification versions 2.1.1 and 2.2 (hereinafter Global Platform document).

A security element can include one or more security domains (SD), each of which includes a collection of data, such as packages, applets, applications, and the like, that rely on a common entity (that is, it is authenticated or managed using a common security key or token).

Security domains may be associated with service providers and may include applets or applications from service providers such as loyalty, coupons and credit cards, and

IMPI

INSTITUTO .MEXICANO

<img file="MX337986B_D0011.tif" />

applets or transit applications.

Traditionally, service provider systems include a TSM to interface with a security element on a mobile device to create a security domain in the security element and install, provision, and manage applets and applications in the security element. Service providers must be able to provide their services to a large number of customers with different mobile devices, equipped with different security features, and be served by a variety of MNOs. As explained above, security elements can be implemented in numerous form factors, and can contain a variety of security domains, applets, and applications, all potentially configured in an extremely large number of ways. As a result, service providers face the daunting task of providing adaptive services and solutions to a large, ever-increasing and changing mix of mobile devices, MNOs, networks, security features, and security domains.

For example, in order for a service provider to securely install a payment applet on a customer security feature on a mobile device, the service provider must first determine a large amount of information in order to send and process a

IMPI

MEXICAN INSTITUTE OF INDUSTRIAL PROPERTY

<img file="MX337986B_D0012.tif" />

request in a security element. For example, service providers using the prior art should obtain security element information (for example, identifiers, type, profile identifier, level and expiration of certification), MNO information (for example, type), security domain information (for example, identifiers, privileges, master key index), and the like. This information can exist from a variety of different sources (eg security domain, security element, mobile device, MNO) and therefore it is a laborious task for a service provider to retrieve and check parity , of all this information, needing extensive processing.

One of the technical challenges in the installation, management and provisioning of applications in security elements is due to the limitations in typical TSMs, that is, they do not function as central intermediaries capable of processing communications between a wide variety of service providers. , MNO, mobile devices, networks, security elements and security domains. There is a need, therefore, for an improved system such as a central TSM, specifically tailored to interface between service providers (including the service provider TSM) and security elements, and to

ΙΜΡΪ

MEXICAN INSTITUTE OF INDUSTRIAL PROPERTY

<img file="MX337986B_D0013.tif" />

manage security elements. ,

From a service provider perspective, what matters is that they can communicate easily and securely (i.e. request customization, service activation, script processing, etc.) with the desired security element of a client, regardless of the client's mobile device, security element, MNO, or mobile network.

From the customer's point of view, what matters is that the service provider's service can be activated on and used with the customer's security element, regardless of the client's mobile device, security element, MNO, or network mobile.

Brief Description of the Invention

The present invention provides computer program systems, methods, and products for performing content management operations.

In one embodiment, a system for performing content management operations includes at least one memory, one or more service provider security domains, a central security domain, and a processor. The at least one memory stores data, and the central security domain manages instructions on behalf of the one or more security domains of the service provider. A processor is coupled to the at least one memory. The instructions are

IMPI

MEXICAN INSTITUTE nc i * MnwpnAD

OF INDUSTRIAL PROPERTY

<img file="MX337986B_D0014.tif" />

they receive, through a network, from a trusted service manager. At least one of the one or more security domains of the service provider in which to process the instructions is determined. The instructions are processed using the data stored in the at least one memory. The data includes one or more generic applications, each of which can be instantiated for one or more service providers.

In another embodiment, a method of performing content management operations includes at least one memory, one or more service provider security domains, and a central security domain. Instructions are received, over a network, from a trusted service manager. At least one of one or more security domains of the service provider in which the instructions are processed are determined. The instructions are processed using data stored in the at least one memory. The data includes one or more generic applications, each of which can be instantiated for one or more service providers. A central security domain manages the instructions on behalf of the one or more security domains of the service provider.

In another embodiment, a non-transient computer-readable medium having instruction sequences stored therein, including instruction sequences

IMPI

SUBSTITUTE MEXIC /, ΝΟ THE INDUSTRIAL PROPERTY

<img file="MX337986B_D0015.tif" />

instructions, which, when ~ japut-an mndinntc. wt computer system make the computer: receive instructions, through a network, from a trusted service manager; determine at least one of one or more security domains of the service provider in which the instructions are processed; processes instructions using data stored in at least one memory. A central security domain can function to manage instructions on behalf of the one or more security domains of the service provider. The data includes one or more generic applications, each of which can be instantiated for one or more service providers.

Other features and advantages of the present invention will become more apparent from the detailed description set forth below when performed in conjunction with the following figures.

Brief Description of the Figures

The features and advantages of the present invention will become more apparent from the detailed description set forth below when discussed in conjunction with the following figures.

Fig. 1 is a diagram of a system for interfacing between a service provider and a security element according to an exemplary embodiment.

Figure 2 is a sequence diagram illustrating a

IMPI. . -I *&gt;. ii * i INfc / Ui t KiAi.

sequence to send a request from a manager

MEXICAN INSTITUTE OF INDUSTRIAL PROPERTY

<img file="MX337986B_D0016.tif" />

trusted services service provider to a security element according to an exemplary modality.

Figure 3 is a sequence diagram illustrating a sequence for sending multiple requests from a trusted service provider service provider to a security element according to an exemplary embodiment.

Figure 4 is a sequence diagram illustrating a sequence for sending a pre-personalization request from a trusted service provider service provider to a security element according to an exemplary embodiment.

Figure 5 is a diagram of a configuration of a security element according to an exemplary embodiment.

Figure 6 is a diagram of a configuration of a security element according to an exemplary embodiment.

Figure 7 is a diagram of a configuration of a security element according to an exemplary embodiment.

Figure 8 is a diagram of a configuration of a security element according to an exemplary embodiment.

Figure 9 is a block diagram of an exemplary system useful for implementing the present invention.

Detailed description of the invention

General view

Exemplary embodiments of the presented invention

<img file="MX337986B_D0017.tif" />

¹⁰ IMPI

YEXICANO INSTITUTE

OF THE PROPERTY - ¹INDUSTRIAL in this document address systems, methods and products of computer programs to manage security elements. 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 an expert in the relevant subject (s) how to implement the following invention in alternative embodiments, such as the interconnection between a wide variety and a large number of entities, including TSMs, MNOs, security features, mobile devices, service providers, and any other system that is capable of communicating over networks.

In general, the exemplary embodiments described herein perform the interconnection between one or more service provider systems that have a mobile subscription identifier (MSI) and one or more security features.

A service provider system (i.e. the service provider) can communicate with a central TSM in order to access or control a corresponding security domain and / or an application in a security element. In particular, the service provider, which communicates with the central TSM, can pre-customize a security element, personalize a service in a security domain into a security element, or activate a

IMPI

MEXICAN INSTITUTE OF INDUSTRIAL PROPERTY

<img file="MX337986B_D0018.tif" />

service in the security element. For example, the service provider may transmit a request to the central TSM to pre-customize a security element. In response, the central TSM can pre-customize the security element, including creating at least one service provider security domain that includes, if necessary, the corresponding temporary security keys, and / or instantiating an application in the security element. Application instantiation includes creating an instance of a non-instantiated application.

The service provider may also transmit a request to customize a service to the central TSM. The request may include data and scripts. The scripts can include commands to be run by an application in a security domain corresponding to the service provider in the security element. For example, scripts can include commands to customize an instantiated application, toggle keys in the corresponding security domain, and / or run service provider commands in the security domain of the service provider and / or the instantiated application. in the security element. The central TSM receives the request and securely transmits the scripts and / or data on the

IMPI

MEXICAN INSTITUTE OF THE fROPIEPAD

INDUSTRIAL

<img file="MX337986B_D0019.tif" />

request to the security element. In turn, the security element receives and executes the scripts and data.

The service provider communicates with the central TSM in order to have the commands executed in the security element. In order to do this, the service provider (i.e. the TSM SP) sends a request (eg to pre-customize a security element) to the central TSM to obtain information about the security element based on an MSI . The central TSM receives the request and consults its memory, based on the MSI, to obtain the requested information about the security element. Once the core TSM has retrieved the security element information for the MSI, the core TSM transmits the retrieved security element information and the MSI to the

TSM SP.

Once the service provider has identified the target security element and its information, the service provider (i.e. the TSM SP) sends a request to the central TSM, so that the central TSM establishes a communication (i.e. a conversation) with the security element. The request to establish communication includes the information of the recovered security element and the corresponding MSI, as well as information regarding applications or applets, security domains, services and

<img file="MX337986B_D0020.tif" />

scripts to be used to process a subsequent request from the service provider. The central TSM receives the request and transmits a response to the TSM SP that includes a communication identifier and other communication attributes.

After communication has been established, the service provider sends a request (for example, customize an application), which includes the communication identifier, intended to run on the security 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 to the security element and transmits the request (eg customize an application) to the security element for processing. The central TSM transmits the request to the security element through a corresponding mobile network. The corresponding mobile network is determined based on the MNO information that is retrieved from the memory of the central TSM, which is based on the information in the request made by the service provider (for example, to customize an application). The request is processed in the security element according to the request of the service provider, based on the information in the request and the established communication.

Due to the functionality of exemplary embodiments

MEXICAN INSTITUTE Dfc LA PrOPíEDA.U

INDUSTRIAL

<img file="MX337986B_D0021.tif" />

described in this document, a service provider can communicate efficiently and effortlessly with a

Central TSM in order to have a variety of requests processed in a security element with minimal processing and necessary information. Exemplary embodiments also contemplate a central layout of a TSM that significantly reduces the time and cost requirements for service providers to have requests (eg, enable services) processed in a security element.

Also, a service provider can send a request to a security element, through a central TSM, simply by using the MSI to communicate with a single source (ie the central TSM). That is, the service provider is able to process your requests with a security element without the need to communicate with multiple sources of intermediation (for example, the

MNO, the TSM).

Furthermore, requests from the service provider are standardized in such a way that a single type of request is communicated to the central TSM regardless of the type of MNO, the type of mobile device, the security element, and / or the application. Standardizing service provider requests advantageously reduces the errors and complexities associated with processing multiple

IMPI

MEXICAN INSTITUTE OF LA FROFIEDA »

INDUSTRIAL

<img file="MX337986B_D0022.tif" />

service provider requests. Furthermore, service providers do not have to transmit or provide an application for their installation, or provide an MNO, a mobile device, or security element interfaces in order to have a request processed in a security element. Instead, the service provider can send one or more standard requests with commands to the central TSM. As a result, the processing time and size required to execute a request are reduced to a minimum.

System

FIG. 1 is a diagram of an exemplary system 100 for interconnection between service providers and security elements over mobile networks. As shown in Figure 1, system 100 includes TSM 103-1, 103-2, .., 103-n (collectively 103) SP. Each of the

TSM 103 SP corresponds to a service provider 107-1,

107-2, .., 107-n (collectively 107). Each TSM SP serves as an intermediary between service providers 107 and other entities including security elements, MNOs, and other types of TSMs (referred to herein as a

Central TSM).

Each of the TSM 103 SP is communicatively coupled to the central TSM 102 through a communications network 105. Communication network 105 may be a

JL IV XX x, s? I

INSTITUTO MEXICANO i 'Λ / DE LA PROPIEDAD

INDUSTRIAL -— · virtual private network (VPN), a network that uses hypertext transfer protocol (HTTP) or similar standards.

Each of the TSM 103 SP and the central TSM 102 can also secure these communications using protocols such as Secure Socket Layer (SSL), Transport Layer Security (TLS). English), or the like. Each of the TSM 103 SP can also communicate with the central TSM 102 using an application programming interface (API), such as a web services API.

In an exemplary embodiment, the core TSM 102 is hardware and / or software that is implemented to serve as an intermediary between TSM 103 SP and elements 106a-1, 106a-2, .., 106a-n (collectively 106a) of security. Specifically, the central TSM 102 allows each of the TSM 103 SP to request, for example, a pre-customization of a security element (for example, security elements 106), generate and install new or temporary sets of keys from the security domain, customize a paid service and / or have an activated service. That is, the central TSM 102 manages the communications between the TSM 103 SP and the security elements 106a.

The central TSM 102, therefore, can communicate with a plurality of service providers 107 and the TSM 103

IMPI

MEXICAN INSTITUTE OF PROPERTY

INDUSTRIAL

<img file="MX337986B_D0023.tif" />

SP, and with a plurality of security elements 106a through a plurality of mobile networks 104-1, 104-2, .., 104-n (collectively 104).

In an exemplary embodiment, the central TSM 102 includes a processor 102a and a memory 02b.

The central TSM 102 may include an enterprise service bus (ESB) (not shown). In an exemplary embodiment, the ESB is an architectural model for implementing interactions and communications between entities (for example, security elements 106a,

TSM 103 SP, the central TSM 102).

The central TSM 102 is communicatively coupled to the security elements 106a through the corresponding mobile networks 104 used and / or managed by the corresponding MNOs. In general, mobile networks 104 are used by MNOs to provide wireless communication services. Mobile networks 104 can be mobile phone networks, radio networks, or the like. The central TSM 102 can communicate with the security elements 106a, through the mobile networks 104, using security protocols such as the Global Platform secure channel protocol, SSL, TLS, or the like.

The elements | Security elements (eg security elements 106a) are discussed in more detail below with reference to Figures 5-8. As shown in

<img file="MX337986B_D0024.tif" />

MEXICAN INSTITUTE CE LA fROHEOAD

INDUSTRIAL

<img file="MX337986B_D0025.tif" />

Figure 1, security elements 106a are associated with corresponding mobile devices 106-1, 106-2, and 106-n (collectively 106), respectively. Security elements 106a may be communicatively coupled to one or more processors and to one or more memories.

During the manufacture of a security element (for example, security element 106a-l), the security element is preloaded with content, including, for example, an SD MNO, a central SD, a companion wallet applet, an applet mobile wallet companion (WCAp), a proximity payment system environment (PPSE), and a payment package. The SD MNO 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 can be used by a mobile wallet to carry out transactions, and the PPSE is an application that helps in the process of modality of contactless payment transactions.

Security elements 106a can include security domains, code, applets, applications, and packages. Packages can include applets and / or non-instantiated applications, and can be uploaded to a security feature, for example, over the air (OTA). Applets and / or applications in the element of

IMPI

MEXICAN INSTITUTE D £ THE PROPERTY

INDUSTRIAL

<img file="MX337986B_D0026.tif" />

Security can be in the form of non-instantiated or instantiated, and applets and / or non-instantiated applications can be preloaded on a security element during the manufacture of the security element. Alternatively, applets and / or applications can be loaded, for example, with the OTA after a security element has been manufactured (for example, after the security element is delivered to a user). Applets and / or applications can be generic or non-generic. Applets and / or non-generic applications may include coupon and loyalty applications, and / or any application that is not generic to multiple service providers. In other words, a non-generic application can correspond to a single service provider. The data that can be used and / or associated with a non-generic application (for example, offers, coupons) can be stored in the security element or in the external memory of the security element (for example, the non-volatile memory of a mobile device ).

Generic applets and / or applications can include applets and / or applications that, when instantiated, can be used by multiple service providers. For example, a generic payment network application (for example, MasterCard®) can be instantiated for multiple service providers through a central TSM, and therefore, can

IMPI

MEXICAN INSTITUTE OF INDUSTRIAL PROPERTY

<img file="MX337986B_D0027.tif" />

be used by more than one service provider.

Packages that include applets and / or non-instantiated applications can be owned or controlled by a single entity that controls a central TSM and / or a central SD. Non-instantiated applets and / or applications can be created according to (i.e. directly as associated with) a central SD in a security element, and can be managed exclusively in the security element by the central TSM using the central SD. In particular, the central SD maintains exclusive access to the WCAp, PPSE, packets, and SD SPs. However, service providers can transmit requests to the central TSM, for example, to toggle (i.e. exchange) security keys. After the security keys of an SD SP have been altered, the corresponding service provider can continue to send requests to the central TSM to execute commands on the corresponding SD SP. After the key is toggled, the central TSM has limited access to the SD SP. In particular, the central TSM can, for example, stop an application from running or instantiate applications according to the SD SP, but cannot access security keys or custom content from the SD SP.

The exclusive ownership, control and / or management of applets or non-instantiated applications allows a single entity to efficiently and profitably monitor applets.

IMPI

MEXICAN INSTITUTE OF INDUSTRIAL PROPERTY

<img file="MX337986B_D0028.tif" />

and / or applications. Also, the property— 'ol¹control and / or management increase security and minimize complexities caused by multiple service providers by loading and controlling different applets and / or applications in a security element. For example, a service provider may use an instance of an applet and / or a non-instantiated application instead of certifying and installing an applet and / or a separate application in the security element.

In addition, applets and / or non-instantiated applications can be instantiated, and each instance can then be extradited to a corresponding security domain. The instantiation can include applets and / or custom applications that use the data corresponding to the entity for which the instance was created.

For example, multiple instances of a non-instantiated applet or application can be created for different entities (for example, service providers) and each instance can be extradited to a different security domain for use by a different entity.

An applet or an application in a security element can work in accordance with the requirements established by the Global Platform, Europay, MasterCard®, Visa® (EMVCo.), MNOs and payment networks (for example,

MasterCard®, Visa®, Discover®, American Express®). The

ΙΜΡΙ, ~

INSTIT! ¡Τ * Ί Μί.ΥΙΓΑΜίλ

MEXICAN INSTITUTE OF INDUSTRIAL PROPERTY

MEXICAN INSTITUTE

<img file="MX337986B_D0029.tif" />

applets or applications can be, for example, expresspay ™, payWave ™, PayPass ™, Zip Code ™, and the like.

For example, the TSM 103-1 SP sends a request to the central TSM 102 through the communications network 105, and the central TSM 102 sends a response back to the TSM 103-1 SP through the communications network 105. The TSM 103-1 SP sends a request, destined for the security element 106a-1, to the central TSM 102 through the communication network 105. In turn, the central TSM 102 sends that request to the security element 106a-l through the respective mobile network 104-1.

In an alternative embodiment, the central TSM 102 may include and use an ESB to perform the operations.

In an alternative embodiment, a plurality of service providers share one of the TSM 103 SP.

In a further alternative embodiment, memory 102b may be a database.

In another alternative embodiment, a plurality of mobile networks communicate with a plurality of TSM SPs.

Process

A. Communicate a request from a service provider TSM to a security element

Figure 2 depicts a sequence diagram 200 for sending a request from a TSM 203 SP (for example, in

INDUSTRIAL figure 1, TSM 103-1 SP) to a security _201 element

<img file="MX337986B_D0030.tif" />

(eg, in Figure 1, SE 106a-l), according to an exemplary embodiment. The request may be, for example, a request for security element 201 to process a script, manage a communication, or activate a service. These types of requests are discussed in more detail below with reference to Figures 2 and 3.

As shown in Figure 2, at step 250, the TSM

203 SP transmits a request (Request_x) to the central TSM 202 via a communications network (eg, in FIG. 1, the communications network 105). This request may be a request to retrieve the security element data, which includes a security element identifier, based on a mobile subscription identifier (MSI) included in the request.

The security element identifier is a unique number or a set of characters that are written in security element 201 and can be used to identify security element 201. The security element identifier may also include the type of identifier used to identify the security element, such as a card image number (CIN), which is a unique number that identifies the security element. and it is written to the security element during customization.

IMPI

MEXICAN INSTITUTE OF PROHF.DaD

INDUSTRIAL

<img file="MX337986B_D0031.tif" />

The security element data are attributes of the security element 2 01. The security element data may include the following information in relation to security element 201: an identifier of the security element; an MNO name associated with security element 201; data from the service provider for the service provider associated with the TSM 2 03 SP; a master key index that includes a key for the service provider's security domain in security element 201; a profile identifier; a type of security element; versions of standardizations (eg Global Platform, JavaCard); a certification level and the expiration date.

The MSI is a unique number used to identify a mobile subscription for 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 specific line of service.

The central TSM 202 receives the request (Request_x), which includes the MSI and queries its memory (Query Memory), in step 252. The memory may be a database that includes one or more MSIs and one or more identifiers of

IMPI

MEXICAN INSTITUTE OF PROPERTY

INDUSTRIAL

<img file="MX337986B_D0032.tif" />

corresponding security elements and the security element data. The memory may also include the MNO data corresponding to each of the identifiers of the security element. The MNO data can be information used to identify the MNO with which the security element is associated, and can be used to select an appropriate mobile network to be used to communicate with the security element. The query is a request to retrieve the security element data, which includes a security element identifier corresponding to the MSI, from memory.

After the recovery of the security element data corresponding to the MSI, the central TSM 202 transmits, in step 254, to the TSM 203 SP, through the communications network, the data of the recovered security element stored in its database. data, which includes the identifier of the security element (Response). The central TSM 202 also transmits to the TSM 207 SP (Response) the corresponding MSI included in the request. In this way, the TSM 203 SP determines the identity of the security element 201, to which a request will be sent.

The TSM 203 SP, using the security element data received from the central TSM 202, transmits, in step 256, a request (Requesty) to the central TSM 202. The central TSM 202 receives this request (Request and) which includes the

IMPI

MEXICAN INSTITUTE OF INDUSTRIAL PROPERTY

<img file="MX337986B_D0033.tif" />

identifier of the security element of security element 201, to which the request has been addressed by the TSM 203 SP.

This request (Requesty) can include one or more requests from security element 201 to: manage a communication, process one or more scripts, or activate a service. For example, a request can be used to instruct a security element to perform, for example, personalization, key alternation, and other processes discussed below with reference to Figures 3 and 4.

Central TSM 202 determines a mobile network (eg, in Figure 1, mobile network 104-1) from a plurality of mobile networks based on the MNO data in memory that corresponds to the data of the element of security in the request (Request and). After determining the mobile network, the central TSM 202 transmits, in step 258, a request (Request_z), which is based on the previous request (Requesty), to the security element 201 through the mobile network. In this way, the security element 2 01 can process, in step 260, the request (Request for

Process).

In an alternative embodiment, security element 201 may transmit a response to the central TSM 202 through the mobile network after completing or processing the request from TSM 203 SP. The answer may include, for

IMPI

MEXICAN INSTITUTE OF THE INDUSTRIAL PROPERTY if the processing of

<img file="MX337986B_D0034.tif" />

For example, information indicating a request was successful or failed.

In an alternative embodiment, the security element data may not include the identifier of the security element. In such a case, the TSM 203 SP can request the identifier of the security element (based on the MSI) and the data of the security element separately, and the central TSM 202 can provide the identifier of the security element and the data of the security element. security element in separate responses to TSM 203 SP.

In an alternative embodiment, the TSM 203 SP may initially transmit a request to the central TSM 202 for a predisposition of the security element 201, which includes the creation of one or more security domains in the security element 201, if necessary (it is say, if one or more security domains corresponding to TSM 2 03 SP have not been created). Once the one or more security domains have been created, the TSM 203 SP can transmit the subsequent requests to the central TSM 202, including, for example, a request to instantiate a non-instantiated application. In turn, the central TSM 2 02 extradites the instantiated application (that is, the instance) to a corresponding security domain (for example, the central SD, the

SD SP).

In an alternative embodiment, the central TSM 202 includes

IMPI

MEXICAN INSTITUTE OF PROPERTY

INDUSTRIAL

<img file="MX337986B_D0035.tif" />

an ESB, and uses the ESB to process requests that include, for example, processing a script, managing a communication, or activating a service.

B. Communicate multiple requests from the service provider's TSM to a security element

Figure 3 depicts a sequence diagram 300 for sending multiple requests from a TSM 303 SP (for example, in Figure 1, the TSM 103-1 SP) to a security element 301 (for example, in Figure 1, the SE 106a-1) according to an exemplary embodiment.

In FIG. 3, in step 352, the TSM 303 SP transmits a request (Request SE Identifier), through a communications network (eg, in FIG. 1, the communications network 105), to the central TSM 302 , which includes a request to obtain a security element identifier. The request (Request SE Identifier) ​​includes an MSI, which is associated with security element 301 to which the TSM 303 SP wishes to send a request. Using the MSI, in step 354, the central TSM 302 performs a query (Query Memory) and retrieves the identifier of the security element corresponding to the MSI included in the request. In step 356, the central TSM 302 transmits (Response to

Request Identifier SE) the identifier of the security element recovered from TSM 3 03 SP through the communications network.

IMPI

MEXICAN INSTITUTE OF PROPERTY

INDUSTRIAL

<img file="MX337986B_D0036.tif" />

Once the TSM 3 03 SP receives the identifier of the security element, the TSM 303 SP transmits, in step

358, a request (Request SE Data), through the communication network, to the central TSM 302, which includes a request to obtain the data of the security element (as discussed in more detail above with reference to FIG. 2 ) associated with security element 3 01. This request (Request SE Data) includes the identifier of the security element (received from the central TSM 302) and the corresponding MSI. Using the identifier of the security element and the corresponding MSI, in step 360, the central TSM 302 performs a query (Query Memory) and retrieves the data of the security element corresponding to the identifier of the security element. In step 362, the central TSM 302 transmits (SE Request Data Response) the retrieved security element data to the TSM 3 03 SP through the communications network.

In step 364, the TSM 303 SP subsequently transmits a request (Request to Manage Com. (Start)), based on the identifier and the security element data received, to manage a communication to the central TSM 3 02.

one. Communication Management

In general, a request to manage a communication

<img file="MX337986B_D0037.tif" />

It can include a request to start a communication or a request to end a communication. In an exemplary embodiment, a communication is a notification from a first device (eg, TSM 303 SP, central TSM 302) to a second device (eg, security element 301), where the first device attempts perform communication or operation over the air (OTA) with the second device.

As shown in Figure 3, at step 364, the TSM

303 SP transmits a request (Request Manage Com.

(Start)) to establish communication with the central TSM 3 02, through the communication network, so that the communication parameters and identifiers can be established. By doing this, it notifies the central TSM 302 that the TSM 303 SP will request the execution of an operation on security element 301. This operation can be, for example, the execution of the scripts requested by the TSM 303 SP, or the activation of a service in the security element 301.

The communication request (Request Manage Com.

(Start)) transmitted in step 364 by the TSM 303 SP to the central TSM 302 may include the following attributes: a security element identifier, an MSI, a service qualifier, a destination application identifier, a format and a size of scripts to be run during OTA communication and operation

IMPI

MEXICAN INSTITUTE OF industrial PROfIFDAD

<img file="MX337986B_D0038.tif" />

requested (for example, key alternation, personalization). The requested operation attribute is used by the central TSM 3 02 to track the progress of the operation.

The service identifier may include the number and version of the service identification, which are used to identify a general definition of the service. The service qualifier includes a name of the service provider and the payment account reference number (PRN).

The service qualifier is used to identify the specific instance of the service (i.e. the service corresponding to the service identifier) ​​on which to act (for example, installed, blocked, unlocked, removed) using requests, including commands, during a communication.

The PRN is a unique number to identify a credential or card (for example, a payment card) associated with a service.

As shown in Figure 3, after receiving the request (Request to Manage Com. (Start)), the central TSM 302, in step 366, transmits a response (Response to Request to Manage Com. (Start)) to TSM 303 SP, through the communications network. This response may include the following attributes: an identifier of the

A. X * A

MEXICAN INSTITUTE OF INDUSTRIAL PROPERTY

OTA (i.e. an entity

<img file="MX337986B_D0039.tif" />

of the request), a number and a command to be requested in communication, a bearer in charge of transmission, maximum size of sequences, an operation, a script format and the allowed length of the communication.

As further shown in Figure 3, in steps 374 and 388, after one or more scripts are processed (discussed in more detail below), the TSM

303 SP transmits a request (Request Manage Com.

(End)) to end the communication (that is, the communication corresponding to the communication identifier) ​​to the central TSM 302, through the communication network. This request can include the identifier of the communication previously received by the TSM 303 SP, as well as the status of the operation (for example, if it has failed or succeeded). By doing this, the TSM 303 SP indicates that the communication corresponding to the communication identifier is no longer intended to be used, and the communication can no longer be used. In steps 376 and 390, the central TSM 302 sends a response (Response to Request

Manage Com. (End)), indicating the status of the operation (for example, if it has failed or has been successful), to the TSM 303 SP, through the communications network.

As shown in Figure 3, while communication is open (i.e. a communication has

<img file="MX337986B_D0040.tif" />

started and not finished), the TSM 3 03 SP sends a request to the central TSM 302 to process one or more scripts.

. Processing of one or more scripts

In general, a request to process one or more scripts allows the TSM 303 SP, using the central TSM 302, to request the sending of a set of Command Application Protocol Data Units (APDUs) directed to Security Element 301. and to run on security element 301. This request can be based on, for example, the Global Platform messaging standards, and can be used, for example, to request: application customization, key toggle and / or post-customization. The following is a list of commands that can be sent to the security element for processing with reference to Figures 5-8.

Each script or command APDU can be used to execute an operation based on or using data that is pre-stored (that is, loaded during manufacturing) in the security element. This data may include, for example, code, applets, or applications. Using scripts and / or command APDUs, TSM 3 03 SP can request that the central TSM 302 instantiate, for example, an application not instantiated in security element 301, and extradite the instance to a corresponding security domain in the

IMPI

MEXICAN INSTITUTE OF INDUSTRIAL PROPERTY security element 301.

In an exemplary mode, application customization is the insertion or uploading of data into an application in a security domain in a security element. That is, a service provider can insert or upload sensitive data, including the customer's account and data, in an application in a security feature on the customer's mobile device. More specifically, a TSM SP can transmit a request to customize an application, including commands and data, to a central TSM. The core TSM can then send a request, based on the request received from the TSM SP, to the security element to customize the application to the security element associated with the client.

In an exemplary mode, key toggling 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 in a security domain in an element of security.

In an exemplary embodiment, post-customization is the concept of sending requests, which include command APDUs to a security element through a central TSM. In particular, post-customization requests are sent through a service provider to execute pending commands after the customization has been performed.

<img file="MX337986B_D0041.tif" />

MEXICAN INSTITUTE

OF PROPERTY V

INDUSTRIAL 'te “*

The request to process one or more scripts can include a communication identifier (as described above) and a list of command APDUs to be sent to and executed in security element 301, with reference to a security domain. That is, the TSM 3 03 SP uses an established communication (and the attributes defined in it) to send a list of commands to the security element 301 to be executed with respect to a specific and corresponding application or a non-instantiated application.

Examples of command APDUs include: Delete Key, Get Data, Get Status, Put Key, Select, Set Status, Store Data (store data), and Install. These command APDUs can be used to retrieve applications and application data, select applications, lock and unlock applications, customize applications, non-instantiated applications, extradite instantiated to the corresponding SD SP, and update and delete the security domain keys. Command APDUs are described in more detail below with reference to Figures 5-8.

As shown in Figure 3, at step 368, the TSM will instantiate applications

303 SP issues a request (Response to Process Script (for key toggle)) to process a script

IMPI

Mexican Institute of Industrial Property

<img file="MX337986B_D0042.tif" />

to the central TSM 302, through the communications network. In particular, this request includes a communication identifier, which is the established communication that will be used to transmit the request. This request also includes commands (for example, command APDUs) to perform key toggling in the security domain in security element 301. In response, at step 372, the

Central TSM 302 transmits a response (Response to Request Script Processing (for key toggle)) to TSM 303 SP which includes a list of response APDUs and a list of command APDUs that have failed execution.

As further shown in Figure 3, after the request to perform the key toggle are processed in step 370, the TSM 303 SP requests that terminate the previously initiated communication by sending a request (Request to Manage Com. (End)) , in step 374, to the central TSM 302. In step 376, the central TSM transmits a response (Response to Request to Manage Com. (End)) to the

TSM 303 SP. In turn, the TSM 303 SP requests to initiate (i.e. Start), at step 378, a subsequent communication by transmitting a request (Request to Manage Com. (Start)) and obtains a corresponding communication identifier, at step 380, in a response (Response to Request to Manage Com (Start)) from the central TSM 302. Using the communication identifier and the

IMPI

MEXICAN INSTITUTE OF INDUSTRIAL PROPERTY

<img file="MX337986B_D0043.tif" />

Communication obtained in step 380, the TSM 303 SP transmits, in step 382, ​​an additional request (Response to Process Script (Customize Application)) to process a script to the central TSM 302, through the communications network. In particular, this request includes a communication identifier, which is the open communication that will be used to transmit the request, and a list of commands (i.e. command APDUs) to perform application customization in the domain of security in security element 3 01. At step 3 84, this request (Customize Application) is processed. In response, at step 386, the core TSM 302 transmits a response (Request to Process Script (Customize Application) Response) to the TSM 303 SP which includes a list of the response APDUs and a list of the failed command APDUs. the execution. At step 388, TSM 303 SP transmits a request (Request Manage Com.

(End)) to the central TSM 302 to end the communication. In step 390, the central TSM 3 02 transmits a response (Response to Request to Manage Com. (End)).

In an alternative mode, the request to perform the key alternation and the request to perform the application customization are transmitted from the TSM

303 SP to the central TSM 302 in a single request.

In another alternative modality, multiple

ΙΜΡΪ

MEXICAN INSTITUTE OF PROPERTY. , _. . , industrial operations during a single communication.

3. Activation of a service

As shown in Figure 3, at step 392, the TSM

303 SP transmits a request (Request Activate the

Service) to the central TSM 302 to activate a service (for example, a paid service), through the communication network.

In general, a request to activate a service is used to activate a service from a service provider and make the applications associated with that service selectable in a specific security element. This request can include the following attributes: a security element identifier, an MSI, a service identifier, and a service qualifier. The service identifier and the service qualifier can be used to identify the general and specific instance of the service to be activated in security element 301.

The central TSM 302 receives the request to activate a service, and processes the request in step 394 using the information provided in the request. The central TSM 302, in step 396, transmits a response (Response to Request to Activate the Service) to the request of the TSM 303 SP, which includes information indicating the execution status of the request (i.e., if the execution has failed or has been successful).

<img file="MX337986B_D0044.tif" />

IMPI

MEXICAN INSTITUTE OF PROPERTY

INDUSTRIAL

<img file="MX337986B_D0045.tif" />

In an alternative embodiment, the request to activate a service, and the requests to perform key alternation and / or application customization are transmitted from the TSM 303 SP to the central TSM 302 in a single request.

In an alternative embodiment, the central TSM 302 includes an ESB, and uses the ESB to process requests that include, for example, processing a script, managing a communication, or activating a service.

C. Transmit a pre-personalization request from a TSM SP to a security element

FIG. 4 depicts an exemplary sequence diagram 400 for sending a pre-personalization request from a TSM 403 SP (eg, in FIG. 1, the TSM) SP) to a security element 401 (eg, in FIG. 1, SE 106a-l).

In Fig. 4, at step 452, the TSM 403 SP transmits a request (Request SE Data), through a communications network (for example, in Fig. 1, the communications network 105) to the central TSM 4 02 , to obtain the security element data that includes a security element identifier. The application includes an MSI.

Upon receiving the request, the central TSM 402, in step 454, queries a memory (Query Memory) for the security element data including the identifier

IMPI

MEXICAN INSTITUTE OF PROPERTY

INDUSTRIAL

<img file="MX337986B_D0046.tif" />

of the security element, based on the _MST included in I^torequest (Request SE Data). Once the security element data has been retrieved, the central TSM 4 02 transmits, in step 456, a response (SE Request Data Response) that includes the security element data to the TSM 403 SP.

As shown in Figure 4, in step 458, the TSM 403 SP transmits a pre-personalization request (Request Pre-Personalization) to the central TSM 402, via the communications network. This request can include attributes to identify the service (and its corresponding applications) for which pre-customization is requested, as well as the commands to execute the pre-customization request. In particular, the request does not include the applications of the service that must be installed in the security element.

In an exemplary mode, pre-customization includes creating a security domain, instantiating one or more non-instantiated applications, and extraditing the instance to the security domain. Pre-customization can also include determining whether security domains and applications already exist in the security element, performing a technical suitability check, and loading and installing applications.

The central TSM 402 receives the request for pre41

I ΚΙ ΡI

MEXICAN INSTITUTE jl

FROM THE INDUSTRIAL PROPERTY dHTjjE 'customization and, based on this request, transmits, at step 460, a request (Request Security Domain Creation) to security element 401 to create a security domain (discussed in more detail below) with reference to Figures 5 to 8). After the security domain has been created in security element 401, the central TSM 402 transmits, in step 462, a request (Request Application Installation) to security element 401 to install one or more applications associated with the service of the service provider.

The central TSM 402, after transmitting the requests to the security element 401, transmits, in step 464, a pre-personalization response (Pre-Personalization Request Response) to the TSM 403 SP, indicating whether the pre-personalization requested by the TSM 403 SP has failed or succeeded.

Security element 401 may also transmit a response to each request, after each request has been processed.

The central TSM 4 02 can also determine if the applications have been installed and / or if the security domains have been created in a security element.

They are transmitted from the TSM 403 SP to the central TSM 402 via an enterprise service bus (ESB).

In an alternative embodiment, the central TSM 402 includes a

MEXICAN INSTITUTE

OF THE PROPERTY

INDUSTRIAL

<img file="MX337986B_D0047.tif" />

ESB, and uses the ESB to process requests that include, for example, processing a script, managing a communication, or activating a service.

D. Configuration of the integrated security element

Figure 5 depicts a configuration of a security element 500 according to an exemplary embodiment. As depicted in FIG. 5, the security element configuration 500 includes a security element 501, a central TSM 502, and a TSM 503 SP. Security element 501 includes a central security domain (SD) 504, an SD 505 SP and SD 506 SP. Security element 501 is implemented as an integrated security element, or as an NFC enabler, such as an external chip or secure device.

The central SD 504 can perform content management operations on security element 501, including instantiation of applets (for example, applets 505-1 and 5061). That is, the 505-1 and 506-1 applets are application instances (that is, the non-instantiated applications). In particular, the central SD 504 can securely manage applications (for example, applets 505-1 and 506-1), create SD SPs, and perform management operations on applets or applications on the security element.

Each of the SD 505 and 506 SP are associated with the applet instances 505-1 and 506-1, respectively, and the SD

505 and 506 SP help their respective applets in the

INSTITUTO MEXICANO rP &amp; Mvr + Zjf Jl de la Property

INDUSTRIAL establishment of safe channels and in the process of · ¹ .......— · «II I i · II ·· ιι'Βίκ ^ ΜΜΜΜ ^ ηΜΒΚηΒΒ · Applet customization. Instances 505-1 and 506-1 of applets can be created by instantiating applets or non-instantiated applications. Applet instances (for example, applets 505-1 and 506-1) are created conforming (i.e. associated with) to the central SD 504, and if appropriate, the applet instances are extradited (i.e. delivered ) to their respective SD SP (for example, applet 505-1 is extradited to their respective SD, SD 505 SP). If the instances are not extradited, they can remain in accordance with Central SD 504.

As illustrated in Figure 5, the central TSM 502 manages the central SD 504. That is, the central TSM 502 acts as a security element manager by controlling the keys of the central SD 504 (and its associated applications), and therefore can use any of its associated privileges (discussed in greater detail below with reference to table 1). Through the central SD 504, the central TSM 502 can load, install, extradite, block or delete any applet or application in the security element 501. Also, the central TSM 502 can create and manage SD SPs, and can lock security element 501.

As illustrated in Figure 5, TSM 503 SP is associated with and manages SD 506 SP and applet 506-1. That is, the TSM 503 SP maintains the SD 506 SP and 506-1 applet keys, and can use any of the privileges associated with the SD

MEXICAN INSTITUTE

OF THE PROPERTY

INDUSTRIAL

<img file="MX337986B_D0048.tif" />

506 SP (discussed in greater detail below with reference to Table 1).

SD 505 and 506 SP have a Data Authentication Pattern Verification (DAP) privilege (discussed in more detail below with reference to Table 1), in order to verify the integrity of the binary files managed and managed by the central TSM 502. Data packets that do not need a DAP check are loaded conforming (i.e. associated with) to the central SD 504 (for example, pay packet 508), and data packets that need a DAP check are loaded according to their Respective SD SP.

Table 1 illustrates the privileges (for example, Global Platform privileges) assigned to a central SD (for example, the central SD 504) and an SD SP (for example, the SD 505 and 506 SP), according to security element configuration 500.

Table 1

<td>Privileges</td><td>SD Central</td><td>SD SP</td>

<td>Security Domain</td><td>Yes</td><td>Yes</td>

<td>DAP verification</td><td></td><td>Optional</td>

<td>Delegated management</td><td></td><td></td>

<td>Card lock</td><td>Yes</td><td></td>

<td>Finish Card</td><td>Yes</td><td></td>

<td>Selected by default</td><td></td><td></td>

<td>CVM management</td><td>Yes</td><td></td>

<td>DAP verification sent</td><td></td><td></td>

<img file="MX337986B_D0049.tif" />

Table 2 illustrates the privilege commands (eg, Global Platform privileges) supported by a central SD (eg, central SD 504), according to security element setting 500.

<img file="MX337986B_D0050.tif" />

Table 2

<td>Command</td><td>Supports</td>

<td>DELETE</td><td>Required with 4F tag (ELF or AID application); Optional with DO (Key Identifier) ​​and D2 (Number of key version); N / A with labels B6 and 9E (relative to SCP 10).</td>

<td>GET DATA</td><td>Required, with the following labels: - 42 (Identification number of the issuing provider) - 45 (Card image number) - 66 (Card details) - E0 (Key information template) - Cl (sequence counter of the number of default key version)</td>

<td>GET STATUS</td><td>Necessary.</td>

<td>INSTALL [for upload]</td><td>Necessary, without specific parameters.</td>

<td>INSTALL [for install]</td><td>Required, labeled C9 (Parameters application specific).</td>

<td>INSTALL to do selectable]</td><td>Necessary, without specific parameters.</td>

<td>INSTALL [for personalization]</td><td>Optional.</td>

<td>INSTALL [for update registry]</td><td>N / A.</td>

<img file="MX337986B_D0051.tif" />

IMPI

IKJT! TUTü MEXICANO I ?; INDUSTRIAL PROPERTY

<td>Command</td><td>Support- ¹ '</td>

<td>INSTALL [for extradition]</td><td>Necessary.</td>

<td>LOAD</td><td>Required, with labels C4 (Load file data block) and E2 (DAP block).</td>

<td>MANAGE CHANNEL</td><td>Optional.</td>

<td>PUT KEY</td><td>Required for central SD keys.</td>

<td>SET STATUS</td><td>Necessary.</td>

Table 3 illustrates the commands (for example, Global Platform commands) supported by an SD SP (for example, SD 505 and 506 SP), according to configuration 500 of the security element.

Table 3

<td>Command</td><td>Supports</td>

<td>DELETE</td><td>N / A</td>

<td>GET DATA</td><td>Required, with the following labels: - 42 (Identification number of the SD provider) - 45 (SD image number) - 66 (SD management data) - E0 (Key information template) - Cl (sequence counter of the number of default key version)</td>

<td>GET STATUS</td><td>Necessary.</td>

<td>INSTALL [for upload]</td><td>N / A.</td>

<td>INSTALL [to install]</td><td>N / A.</td>

<td>INSTALL [to do selectable]</td><td>N / A.</td>

<img file="MX337986B_D0052.tif" />

X 1V1 JL X

MEXICAN INSTITUTE OF INDUSTRIAL PROPERTY

<td>Command</td><td>Supports</td>

<td>INSTALL [for customization]</td><td>Optional.</td>

<td>INSTALL [for update the record]</td><td>N / A.</td>

<td>INSTALL [for extradition]</td><td>N / A.</td>

<td>LOAD</td><td>N / A.</td>

<td>MANAGE CHANNEL</td><td>Optional.</td>

<td>PUT KEY</td><td>Required for SD SP keys.</td>

<td>SET STATUS</td><td>Required for SD SP (and its applications)</td>

<td>STORE DATA</td><td>Required, with the following labels: - 42 (Identification number of the transmitter) - 45 (SD image number) - 66 (SD management data)</td>

In an alternative mode, one or both of the SD 505 and 506 SP do not have the DAP verification privilege.

In an alternative embodiment, security element 501 includes multiple central SDs.

In another alternative embodiment, each SD SP is associated with a corresponding TSM SP.

E. Configuration of the UICC security element

Figure 6 depicts a configuration 600 of the security element according to an exemplary embodiment. As depicted in Figure 6, the security element configuration 600 includes a security element 601, a TSM 602

<img file="MX337986B_D0053.tif" />

IMPI

MEXICAN INSTITUTE

OF THE PHOELETAD

INDUSTRIAL central, a TSM 603 SP and an MNO 607. -, —. — .....

Security element 601 is implemented as a UICC, and includes a central SD 604, a security element sender SD 605 (ISD), an SD 606 MNO, an SD 608 SP, and an SD 609 SP. The SD 606 MNO is associated with a telecom applet 612. The central SD 604 is associated with a 610 package and a supplemental 611 wallet applet. SD 608 and 609 SP, which are associated with the central SD 604, are associated with applets 608-1 and 609-1, respectively.

ISD 605 creates the core SD 604 and SD 606 MNO, but does not perform any other content management functions.

The SD 606 MNO has authorized management privileges (discussed in greater detail below with reference to Table 2), and manages content in accordance with MNO 607.

The central SD 604 has authorized management privileges (discussed in more detail below with reference to Table 2), and manages the content as indicated by the central TSM 602. In particular, the central SD 604 can securely manage applications, create SD SPs, and perform management operations on applets or applications on the security element.

The SD 608 and 609 SP assist their respective applets in establishing secure channels and in the applet customization process. Instances of applet 608-1 and

IMPI

<img file="MX337986B_D0054.tif" />

MEXICAN INSTITUTE OF INDUSTRIAL PROPERTY

<img file="MX337986B_D0055.tif" />

instantiated. Applet instances (for example, applets 608-1 and 609-1) are created according to (i.e. associated with) the central SD 604. After instantiation, if appropriate, the applet instances are extradited (i.e. delivered) to their respective SD SPs (for example, applet 608-1 is extradited to their respective SDs, SD 608 SP). Alternatively, if an applet instance is not extradited, it can remain compliant with Central SD 604.

The SD 608 and 609 SP have the DAP verification privilege, in order to verify the integrity of the binary files managed and managed by the central TSM 602. Data packets that do not need a DAP check are loaded conforming (i.e. associated with) to the central SD 604 (for example, packet 610), and data packets that need a DAP check are loaded according to their SD SP respective.

As illustrated in Figure 6, the central TSM 602 manages the central SD 604. That is, the central TSM 602 acts as a manager of the security element controlling the keys of the central SD 604 (and its associated applications), and therefore can use any of its associated privileges (discussed in greater detail below with reference to table 4). Through the central SD 604, the TSM

602 central can load, install, extradite, block or delete any applet or application associated with the

MSXICAN INSTITUTE

OF THE PROPERTY

INDUSTRIAL

<img file="MX337986B_D0056.tif" />

security element 601. In addition, the central TSM 602 can create and manage SD SPs.

As further illustrated in Figure 6, the MNO 607 associates with and manages an SD 606 MNO and the telecom applet 612. Therefore, the MNO 607 can use any of the privileges of the SD 606 MNO. Through SD 606 MNO, MNO 607 can load, install, extradite, block or delete any applet or application associated with security element 601. Additionally, MNO packages and applet instances are loaded and / or created conforming (i.e. associated with) to SD 606 MNO.

Table 4 illustrates the privileges (for example, Global Platform privileges) assigned to an ISD (for example, ISD 605), a central SD (for example, central SD 604), an SD MNO (for example, the SD 606 MNO), and an SD SP (for example, the SD 608 and 609 SP), according to the configuration 600 of the security element.

Table 4

<td>Privileges</td><td>ISD</td><td>SD Central</td><td>SD MNO</td><td>SD SP</td>

<td>Security Domain</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td>

<td>DAP Verification</td><td></td><td></td><td></td><td>Optional</td>

<td>Delegated management</td><td></td><td></td><td></td><td></td>

<td>Card lock</td><td>Yes</td><td></td><td></td><td></td>

<td>Finish card</td><td>Yes</td><td></td><td></td><td></td>

<td>Restart card</td><td></td><td></td><td></td><td></td>

<td>CVM management</td><td>Yes</td><td></td><td></td><td></td>

<td>DAP verification sent</td><td></td><td></td><td></td><td></td>

IMPI

MEXICAN INSTITUTE OF PROPERTY

<td>Privileges</td><td>ISD</td><td>SD Central</td><td>SD MNO</td><td>SD SP</td>

<td>Trust path</td><td>Yes</td><td>Yes</td><td>«I-</td><td>¹ gi </td>

<td>Authorized management</td><td>Yes</td><td>Yes</td><td>Yes</td><td></td>

<td>Token Verification</td><td></td><td></td><td></td><td></td>

<td>Global elimination</td><td>Yes</td><td></td><td></td><td></td>

<td>Global lock</td><td>Yes</td><td></td><td></td><td></td>

<td>Global record</td><td>Yes</td><td></td><td></td><td></td>

<td>Final application</td><td></td><td></td><td></td><td></td>

<td>Global service</td><td></td><td></td><td></td><td></td>

<td>Receive Generation</td><td></td><td></td><td></td><td></td>

<img file="MX337986B_D0057.tif" />

Table 5 illustrates the commands (for example, Global Platform commands) supported by an ISD (for example, ISD 605), according to configuration 600 of the security element.

Table 5

<td>Command</td><td>Supports</td>

<td>DELETE</td><td>Required with 4F tag (ELF or AID app); and with DO labels (Key identifier) ​​and D2 (Number of key version); N / A with labels B6 and 9E (relative to SCP 10)</td>

<td>GET DATA</td><td>Required, with the following labels: - 2FOO (List of applications) - 42 (Issuer identification number) - 45 (Card image number) - 66 (Card details) - E0 (Key information template) - Cl (sequence counter of the number of default key version)</td>

<td>GET STATUS</td><td>Necessary.</td>

<img file="MX337986B_D0058.tif" />

<img file="MX337986B_D0059.tif" />

<td>Command</td><td>Supports</td>

<td>INSTALL [for load]</td><td>Required, labeled EF / C6, EF / C7, EF / C8, EF / D6 (Memory Management).</td>

<td>INSTALL [for install]</td><td>Optional with the same parameters as the INSTALL [to install &amp; do selectable].</td>

<td>INSTALL [to do selectable]</td><td>Optional.</td>

<td>INSTALL [for install &amp; do selectable]</td><td>Required, labeled C9 (Parameters application specific) and labels EF / C6, EF / C7, EF / C8, EF / D7 EF / D8 (Management of memory).</td>

<td>INSTALL [for personalization]</td><td>Necessary.</td>

<td>INSTALL [for update registry]</td><td>Necessary, without specific parameters.</td>

<td>INSTALL [for extradition]</td><td>Necessary, without specific parameters.</td>

<td>LOAD</td><td>Required, with C4 tags (Load block of file data) and E2 (DAP block).</td>

<td>MANAGE CHANNEL</td><td>Required for UICC Optional for the integrated SE.</td>

<td>PUT KEY</td><td>Required for ISD keys.</td>

<td>SET STATUS</td><td>Necessary. Only SD allowed to block or finish card</td>

<td>STORE DATA</td><td>Required, with the following labels: - 42 (Issuer identification number) - 45 (Card image number) - 4F (AID ISD) - 66 (Card details)</td>

Table 6 illustrates the commands (for example, Global Platform commands) supported by a central SD (for example, central SD 604), according to the

IMPI

MEXICAN INSTITUTE OF INDUSTRIAL PROPERTY

<img file="MX337986B_D0060.tif" />

security element configuration 600.

Table 6

<td>Command</td><td>Supports</td>

<td>DELETE</td><td>Required with 4F tag (ELF or AID application); and with DO labels (Identifier key) and D2 (Key version number); N / A with labels B6 and 9E (relative to SCP 10)</td>

<td>GET DATA</td><td>Required, with the following labels: - 2F00 (Application List) - 42 (Provider identification number transmitter) - 45 (SD image number) - 66 (SD management data) - E0 (Key information template) - Cl (sequence counter of the number of default key version) - C2 (Receipt confirmation counter (only if delegated management is supported))</td>

<td>GET STATUS</td><td>Necessary.</td>

<td>INSTALL [for load]</td><td>Required, labeled EF / C6, EF / C7, EF / C8, EF / D6 (Memory Management).</td>

<td>INSTALL [for install]</td><td>Necessary, with the same parameters as the INSTALL [to install &amp; make selectable].</td>

<td>INSTALL [to do selectable]</td><td>Necessary.</td>

IMPI

MEXICAN INSTITUTE OF INDUSTRIAL PROPERTY

<img file="MX337986B_D0061.tif" />

<td>Command</td><td>Supports</td>

<td>INSTALL [for install &amp; do selectable]</td><td>Required, labeled C9 (Application Specific Parameters) and labels EF / C6, EF / C7, EF / C8, EF / D7 EF / D8 (Management of memory). EF / 82 and EF / 83 labels are supported in case the memory granted is supported accumulated.</td>

<td>INSTALL [for personalization]</td><td>Necessary.</td>

<td>INSTALL [for update registry]</td><td>Necessary, without specific parameters. EF / 82 and EF / 83 tags are supported in case supported memory is supported accumulated.</td>

<td>INSTALL [for extradition]</td><td>Necessary, without specific parameters.</td>

<td>LOAD</td><td>Required, with C4 tags (Load block of file data) and E2 (DAP block).</td>

<td>MANAGE CHANNEL</td><td>Required (for UICC, optionally for SE integrated).</td>

<td>PUT KEY</td><td>Required for SD keys.</td>

<td>SET STATUS</td><td>Necessary, but it is not allowed to modify the card / ISD status.</td>

<td>STORE DATA</td><td>Required with the following tags: - 42 (SD Issuer Identification Number) - 45 (SD image number) - 66 (SD management data)</td>

Table 7 illustrates the commands (for example, Global Platform commands) supported by an SD MNO (for example, SD 606 MNO), according to configuration 600 of the security element.

IMPI

MEXICAN INSTITUTE OF INDUSTRIAL UTILITY

<img file="MX337986B_D0062.tif" />

Table 7

<td>Command</td><td>Supports</td>

<td>DELETE</td><td>Required with the 4F tag (ELF or AID application), · and with DO (Key Identifier) ​​and D2 (Key version number) tags; N / A with labels B6 and 9E (relative to SCP 10)</td>

<td>GET DATA</td><td>Required, with the following labels: - 2F00 (Application List) - 42 (Service provider identification number) - 45 (SD image number) - 66 (SD management data) - E0 (Key information template) - Cl (sequence counter of the number of default key version) - FF21 (Card Resource Information extended (from TS 102.226))</td>

<td>GET STATUS</td><td>Necessary.</td>

<td>INSTALL [for upload]</td><td>Required, labeled EF / C6, EF / C7, EF / C8, EF / D6 (Memory Management).</td>

<td>INSTALL [for install]</td><td>Required, with the same parameters as INSTALL [to install &amp; make selectable].</td>

<td>INSTALL [to do selectable]</td><td>Necessary.</td>

<td>INSTALL [for install &amp; do selectable]</td><td>Required, labeled C9 (Application Specific Parameters), labels EF / C6, EF / C7, EF / C8, EF / D7 EF / D8 (Memory Management), and labels CA, EA (Game Application UICC specific tools and parameters).</td>

<td>INSTALL [for customization]</td><td>Necessary.</td>

<img file="MX337986B_D0063.tif" />

MEXICAN INSTITUTE

OF PROPERTY f% · * INDUSTRIAL

<td>Command</td><td>Supports</td>

<td>INSTALL [for update registry]</td><td>Necessary, without specific parameters.</td>

<td>INSTALL [for extradition]</td><td>Necessary, without specific parameters.</td>

<td>LOAD</td><td>Required, with labels C4 (Load file data block) and E2 (DAP block).</td>

<td>MANAGE CHANNEL</td><td>Required (for UICC, optionally for integrated SE).</td>

<td>PUT KEY</td><td>Required for SD keys.</td>

<td>SET STATUS</td><td>Necessary, but it is not allowed to change the status of the card / ISD.</td>

<td>STORE DATA</td><td>Required with the following tags: - 42 (Provider identification number SD) - 45 (SD image number) - 66 (SD management data)</td>

In an alternate mode, one or both of SD 608 and 609 SP do not have the DAP verification privilege.

F. Configuration of the security element integrated with the third-party security domain

Figure 7 depicts a configuration 700 of the security element according to an exemplary embodiment. As depicted in Figure 7, security element configuration 700 includes a security element 701, a central TSM 702, an MNO 707, a third-party TSM 708 (with authorized management), and a third-party TSM 703 (with delegated management).

MEXICAN INSTITUTE DS LA TROPltDAD

INDUSTRIAL

<img file="MX337986B_D0064.tif" />

Security element 701 is implemented as an integrated security element or as an NFC enabler such as an external chip or secure device, and includes a core SD 704, an ISD 705, a third-party SD 706, a domain 716 Security Maintained DAP Privilege Maintainer (MDPH SD) 716, a Control Authority Security 717 (CA SD) domain, an SD 709 SP, an SD 710 SP (with delegated management), and an SD 711 SP.

SD 716 MDPH verifies the signatures (that is, the DAP) of the applets and the applications loaded or installed in security element 701. Table 10 (below) illustrates the commands supported by an SD MDPH.

The SD 717 CA performs key generation for newly created security domains in order to ensure confidential upload. Table 9 (below) illustrates the commands supported by an SD CA.

The third party SD 706 has an authorized management privilege, and manages the content in accordance with the provisions of the third party TSM 708. The third party SD 706 is associated with a 714 packet. The SD 711 SP conforms to (ie is associated with) the third party SD 706, and is associated with a 711-1 application. Table 6 (above) illustrates the commands supported by a third-party SD (for example, third-party SD 706).

IMPI

MEXICAN INSTITUTE Dt LA PHOPIEDao

INDUSTRIAL

<img file="MX337986B_D0065.tif" />

ISD 705 creates security domains, which include the 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 (for example, ISD 705) in more detail.

The central SD 704 has authorized management privileges (discussed in greater detail below with reference to Tables 8.1 and 8.2), and manages the content as indicated by the central TSM 702. In particular, the central SD 704 can securely manage applications, create SD SPs and perform management operations on applets or applications on the security element. The central SD 704 is associated with a 713 package, the SD 709 SP and the SD 710 SP. SD 709 and 710 SP are associated with applets 709-1 and 710-1. Table 6 above illustrates the commands supported by a central SD.

SD 709, 710 and 711 SP assist their respective applets in establishing secure channels and in the applet customization process. 709-1 and 710-1 applet instances can be created by instantiating applets or non-instantiated applications. Applet instances (for example, applets 709-1 and 710-1) are created according to (i.e. associated with) the central SD 704. After instantiation, if appropriate, the applet instances are extradited (i.e. delivered) to their respective SD SPs. Table 3 (above)

<img file="MX337986B_D0066.tif" />

illustrates the commands supported by an SD SP. y-1-a — i - ihl -i ... 4 l · · (below) illustrates the commands supported by an SD SP with delegated management privileges (eg SD 710

SP).

The SD 709 and 710 SP have a DAP verification privilege, in order to verify the integrity of the binary files managed and managed by the central TSM 702. Data packets that do not need DAP verification (for example, packet 713) are loaded conforming (i.e. associated with) to central SD 7 04, and data packets that need DAP verification are loaded according to their SD Respective SP. In addition, SD SPs with delegated management privileges (eg 710) can perform authorized content management operations.

As illustrated in Figure 7, the central TSM 702 manages the central SD 704. That is, the central TSM 702 acts as a security element manager by controlling the keys of the central SD 704 (and its associated applications), and therefore can use any of its associated privileges (discussed in more detail below with reference to Tables 8.1 and 8.2). Through the central SD 704, the central TSM 702 can load, install, extradite, block or remove any applet or application associated with security element 701. In addition, the central TSM can create and manage SD SPs, and can lock and

<img file="MX337986B_D0067.tif" />

MEXICAN INSTITUTE OF INDUSTRIAL PROPERTY unlock security element 701 through the ISD

705.

As further illustrated in Figure 7, the third party TSM 708 controls the keys of the third party SD 706 (and its associated applications), and therefore can use any of its associated privileges (discussed in greater detail below). with reference to Tables 8.1 and 8.2). Through a third party SD 706, the third party TSM 708 can load, install, extradite, block or delete any applet or associated application. Third-party TSM 708 can also create and manage SD SPs that are associated with their respective third-party SD (i.e., third-party SD 706). Third-party TSM 708 can block or delete any of its applets or associated applications in security element 701 through its third-party SD 706. Packets that are associated with the third-party TSM (for example, packet 714) are uploaded (that is, associated with) to the third-party SD 706. The applets or applications that are associated with the third-party TSM 708 (for example, the 711-1 application) are instantiated and the instances are created conforming (i.e. associated with) to the third-party SD 706. After instantiation, if appropriate, applets or applications are extradited (i.e. delivered) to your SD SP

MEXICAN INSTITUTE Jt

OF THE PROBLEM V

Respective INDUSTRIAL (eg application 711-1 is extradited to its respective SD, SD 711 SP).

Tables 8.1 and 8.2 illustrate the privileges (for example, Global platform privileges) assigned to an ISD (for example, ISD 705), a central SD (for example, central SD 704), an SD MDPH (for example, the SD 716 MDPH), an SD CA (for example, the SD 717 CA), a third-party SD (for example, the third-party SD 706), an SD SP (for example, the SD 709 SP) , and an SD SP with delegated management (for example, the SD 710 SP).

Table 8.1

<td>Privileges</td><td>ISD</td><td>SD Central</td><td>SD MDPH</td><td>SD CA</td>

<td>Security Domain</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td>

<td>DAP Verification</td><td></td><td></td><td></td><td></td>

<td>Delegated management</td><td></td><td></td><td></td><td></td>

<td>Card lock</td><td>Yes</td><td></td><td></td><td></td>

<td>Finish card</td><td>Yes</td><td></td><td></td><td></td>

<td>Restart card</td><td></td><td></td><td></td><td></td>

<td>CVM management</td><td>Yes</td><td></td><td></td><td></td>

<td>DAP Verification errand</td><td></td><td></td><td>Yes</td><td></td>

<td>Trust path</td><td>Yes</td><td>Yes</td><td></td><td></td>

<td>Authorized management</td><td>Yes</td><td>Yes</td><td></td><td></td>

<td>Token Verification</td><td></td><td>Yes</td><td></td><td></td>

<td>Global elimination</td><td>Yes</td><td></td><td></td><td></td>

<td>Global lock</td><td>Yes</td><td></td><td></td><td></td>

<td>Global record</td><td>Yes</td><td></td><td></td><td></td>

<td>Final application</td><td></td><td></td><td></td><td></td>

<td>Global service</td><td></td><td></td><td></td><td>Yes</td>

<img file="MX337986B_D0068.tif" />

ΙΜΡΪ

MEXICAN INSTITUTE OF THE INDUSTRIAL PLIOl'IEUAD

<td>Privileges</td><td>ISD</td><td>SD Central</td><td>SD MDPH—</td><td>- 5D CA—</td>

<td>Generation of reception</td><td></td><td>Yes</td><td></td><td></td>

Table 8.2

<td>Privileges</td><td>SD third parts</td><td>SD SP</td><td>SD SP (with management delegate)</td>

<td>Security Domain</td><td>Yes</td><td>Yes</td><td>Yes</td>

<td>DAP Verification</td><td></td><td>Optional</td><td>Optional</td>

<td>Delegated management</td><td></td><td></td><td>Yes</td>

<td>Card lock</td><td></td><td></td><td></td>

<td>Finish card</td><td></td><td></td><td></td>

<td>Restart card</td><td></td><td></td><td></td>

<td>CVM management</td><td></td><td></td><td></td>

<td>DAP Verification errand</td><td></td><td></td><td></td>

<td>Trust path</td><td>Yes</td><td>Yes</td><td>Yes</td>

<td>Authorized management</td><td>Yes</td><td></td><td></td>

<td>Token Verification</td><td></td><td></td><td></td>

<td>Global elimination</td><td></td><td></td><td></td>

<td>Global lock</td><td></td><td></td><td></td>

<td>Global record</td><td></td><td></td><td></td>

<td>Final application</td><td></td><td></td><td></td>

<td>Global service</td><td></td><td></td><td></td>

<td>Receive Generation</td><td></td><td></td><td></td>

Table 9 illustrates the commands (for example, Global Platform commands) supported by an SD CA (for example, SD 717 CA), according to security element configuration 700.

IMPI

MEXICAN INSTITUTE

OF THE PROPERTY

INDUSTRIAL

Table 9

<img file="MX337986B_D0069.tif" />

<td>Command</td><td>Supports</td>

<td>DELETE</td><td>N / A.</td>

<td>GET DATA</td><td>Required with the following tags: - 42 (Identification number of the SD provider) - 45 (SD image number) - 66 (SD management data) - EO (Key Information Template) - Cl (sequence counter of the number of default key version)</td>

<td>GET STATUS</td><td>Necessary.</td>

<td>INSTALL [for upload]</td><td>N / A.</td>

<td>INSTALL [for install]</td><td>N / A.</td>

<td>INSTALL [to do selectable]</td><td>N / A.</td>

<td>INSTALL [for personalization]</td><td>N / A.</td>

<td>INSTALL [for update registry]</td><td>N / A.</td>

<td>INSTALL [for extradition]</td><td>N / A.</td>

<td>LOAD</td><td>N / A.</td>

<td>MANAGE CHANNEL</td><td>N / A.</td>

<td>PUT KEY</td><td>Required for SD CA keys.</td>

<td>SET STATUS</td><td>Required for the SD CA itself.</td>

<img file="MX337986B_D0070.tif" />

IMPI

MEXICAN INSTITUTE OF INDUSTRIAL PROPERTY

<td>Command</td><td>Supports</td>

<td>STORE DATA</td><td>Required with the following tags: - 42 (Identification number of the SD provider) - 45 (SD image number) - 66 (SD management data)</td>

Table 10 illustrates the commands (for example, Global Platform commands) supported by an SD MDPH (for example, SD 716 MDPH), according to security element setting 700.

Table 10

<td>Command</td><td>Supports</td>

<td>DELETE</td><td>N / A.</td>

<td>GET DATA</td><td>Required with the following tags: - 42 (Identification number of the SD provider) - 45 (SD image number) - 66 (SD management data) - E0 (Information template of key) - Cl (sequence counter of the key version number per default)</td>

<td>GET STATUS</td><td>Necessary.</td>

<td>INSTALL [for upload]</td><td>N / A.</td>

<td>INSTALL [to install]</td><td>N / A.</td>

<td>INSTALL [to do selectable]</td><td>N / A.</td>

<img file="MX337986B_D0071.tif" />

IMPI.

V INSTITUTO MEXICANO DE LA PRÓriEDAD

<td>Command</td><td>Supports</td>

<td>INSTALL [for personalization]</td><td>N / A. ”-----------------</td>

<td>INSTALL [to update the registry]</td><td>N / A.</td>

<td>INSTALL [for extradition]</td><td>N / A.</td>

<td>LOAD</td><td>N / A.</td>

<td>MANAGE CHANNEL</td><td>N / A.</td>

<td>PUT KEY</td><td>Required for SD MDPH keys.</td>

<td>SET STATUS</td><td>Required for SD MDPH itself.</td>

<td>STORE DATA</td><td>Required with the following tags: - 42 (Identification number of the provider) - 45 (SD image number) - 66 (SD management data)</td>

Table 11 shows the commands (for example, Global Platform commands) supported by a delegated managed SD SP (for example, SD 710 SP), according to security element configuration 700.

Table 11

<td>Command</td><td>Supports</td>

<td>DELETE</td><td>Required with the 4F tag (ELF or AID application), · and with DO tags (Identifier key) and D2 (Key version number); N / A with labels B6 and 9E (relative to SCP 10)</td>

MEXICAN INSTITUTE

OF THE PROPERTY

INDUSTRIAL

<td>Command</td><td>Supports</td>

<td>GET DATA</td><td>Required, with the following labels: - 2F00 (Application List) - 42 (Identification number of the supplier of service) - 45 (SD image number) - 66 (SD management data) - E0 (Key information template) - Cl (sequence counter of the number of default key version) - C2 (Receipt confirmation counter (for delegated management))</td>

<td>GET STATUS</td><td>Necessary.</td>

<td>INSTALL [for load]</td><td>Required, labeled EF / C6, EF / C7, EF / C8, EF / D6 (Memory Management), and with upload Token.</td>

<td>INSTALL [for install]</td><td>Required, see INSTALL [to install &amp; do selectable].</td>

<td>INSTALL [for do selectable]</td><td>Required, see INSTALL [to install &amp; do selectable].</td>

<td>INSTALL [for install &amp; do selectable]</td><td>Required, labeled C9 (Application Specific Parameters) and labels EF / C6, EF / C7, EF / C8, EF / D7 EF / D8 (Management of memory) and with Install &amp; Make Tokens selectable).</td>

<td>INSTALL [for personalization]</td><td>Necessary.</td>

<td>INSTALL [for update registry]</td><td>Necessary, without specific parameters, and with Registration update token.</td>

<td>INSTALL [for extradition]</td><td>Necessary, without specific parameters, and with Extradition token.</td>

<img file="MX337986B_D0072.tif" />

IMPI

MEXICAN INSTITUTE OF INDUSTRIAL PROPERTY

<td>Command</td><td>Supports ......., ————-</td>

<td>LOAD</td><td>Required, with labels C4 (Load file data block) and E2 (DAP block).</td>

<td>MANAGE CHANNEL</td><td>Required (for UICC, optionally for integrated SE).</td>

<td>PUT KEY</td><td>Required for SD SP keys.</td>

<td>SET STATUS</td><td>Required, only for SD SP and its applications.</td>

<td>STORE DATA</td><td>Required with the following tags: - 42 (Identification number of the supplier of service) - 45 (SD image number) - 66 (SD management data) Also supported for customization of applications after INSTALL [for customization]</td>

In an alternative modality, the third-party TSM 703 has delegated management privileges, but first the content management operations must be approved by the central TSM 702. The central TSM 702 can verify the tokens and generate receipts for each associated SD SP that is not associated with a third-party TSM (for example, the SD 709 SP). The third-party TSM 703 controls the keys of its associated SD SPs (for example, the SD 710 SP) and can load, install, extradite, or delete any associated application or applet (for example, the 710-1 applet) through from its associated SD SP.

In an alternative modality, one or both of SD 709 and

<img file="MX337986B_D0073.tif" />

Mexican Institute of Industrial Property

710 SPs do not have a DAP verification privilege.

In an alternative embodiment, one or both of the SD 716 MDPH and SD 717 CA are not included in security element 701.

In another alternative embodiment, security element 701 has zero or more third-party SDs.

G. Configuration of the UICC security element with a third-party security domain

Figure 8 depicts a configuration 800 of the security element according to an exemplary embodiment. As depicted in Figure 8, security element configuration 800 includes a security element 801, a central TSM 802, an MNO 807, a third party TSM 808 (with authorized management), and a third party TSM 803 ( with delegated management).

Security Element 801 is implemented as a UICC, and includes a core SD 804, ISD 805, third party SD 806, SD 815 MNO, SD 817 MDPH, and SD 818

AC. Security Element 801 also includes an SD 809 SP and SD 810 SP (with delegated management), and an SD 811 SP.

SD 815 MNO has authorized management privileges and can manage content in accordance with MNO 807.

SD 817 MDPH verifies the signatures (that is, the DAP) of the applets and the applications loaded or installed in the

<img file="MX337986B_D0074.tif" />

IMPI

INSTITUTO MEXICANO de la PRdriEnAn

INDUSTRIAL security element 801. Table 10 (above) illustrates the commands supported by an SD MDPH.

The SD 818 CA performs key generation for newly created security domains, in order to ensure confidential upload. Table 9 (above) illustrates the commands supported by an SD CA.

The third party SD 806 has an authorized management privilege, and manages the content in accordance with the provisions of the third party TSM 808. The third party SD 806 is associated with an 814 packet. The SD 811 SP is compliant with (ie associated with) the third party SD 806, and is associated with an 811-1 application. The third party SD 806 supports the same commands illustrated in Table 6 (above).

ISD 805 creates security domains, which include a central SD 804 and a 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 delegated management privileges (discussed in more detail below with reference to Table 2), and manages content as indicated by the central TSM 802. In particular, the central SD 804 can securely manage applications, create SD SPs and perform management operations on applets or applications on the security element. The central SD 804

<img file="MX337986B_D0075.tif" />

ÍMPI is associated with an 813 package, the SD 809 SP and the SD 810 SP. SD 809 and 810 SP are associated with applets 809-1 and 810-1. Table 6 above illustrates the commands supported by a central SD.

As illustrated in Figure 8, the central TSM 802 manages the central SD 804. That is, the central TSM 802 acts as a security element manager by controlling the keys of the central SD 804 (and its associated applications), and therefore can use any of its associated privileges (discussed in more detail below with reference to Tables 12.1 and 12.2). Through the central SD 804, the central TSM 802 can load, install, extradite, block or delete any applet or associated application in security element 801. In addition, the central TSM 802 can create and manage SD SPs.

As further illustrated in Figure 8, the MNO 807 associates with and manages an SD 815 MNO and the Telecom applet 816. Therefore, the MNO 807 can use any of the privileges of SD 815 MNO. Through SD

815 MNO, the MNO 807 can load, install, extradite, block or delete any applet or associated application in security element 801. Additionally, MNO packages and instances of the application or applet are loaded and / or created conforming (i.e. associated with) to SD 815 MNO. The MNO 807 can block or delete any associated application

IMPI

MEXICAN INSTITUTE

<img file="MX337986B_D0076.tif" />

to the MNO in security element 801 through SD 815

MNO.

As further illustrated in Figure 8, the third-party TSM 808 controls the keys to the third-party SD 806 (and its associated applications), and therefore can use any of its associated privileges (discussed in greater detail below with reference to tables 12.1 and 12.2). Through a third party SD 806, the

Third-party TSM 808 may load, install, extradite, block or delete any applet or associated application. The third party TSM 808 can also create and manage SD SPs that are associated with their respective third party SD. Packets that are associated with the third-party TSM (for example, packet 814) are uploaded (that is, associated with) to the third-party SD 806. The applets or applications that are associated with the

Third-party TSM 808 (for example, application 811-1) are instantiated and instances are created conforming (i.e. associated with) to third-party SD 806. After instantiation, if appropriate, applets or applications are extradited (i.e. delivered) to their respective SD

SP (for example, application 811-1 is extradited to SD 811

SP).

Tables 12.1 and 12.2 illustrate the privileges (for example, Global Platform privileges) assigned to

IMPI eg&gt; 5.

MEXICAN INSTITUTE.-XJ

OF THE PROPERTY

INDUSTRIAL - an ISD (for example, ISD 805), a central SD (for example, central SD 804), an SD MDPH (for example, SD 817 MDPH), an SD CA (for example, SD 818 CA), a third-party SD (for example, the third-party SD 806), an SD MNO (for example, the SD 815 MNO), an SD SP (for example, the SD 809 SP), and an SD SP with delegate management (eg SD 810 SP).

Table 12.1

<td>Privileges</td><td>ISD</td><td>SD Central</td><td>SD MDPH</td><td>SD CA</td><td>SD MNO</td>

<td>Security Domain</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td><td>Yes</td>

<td>DAP Verification</td><td></td><td></td><td></td><td></td><td></td>

<td>Delegated management</td><td></td><td></td><td></td><td></td><td></td>

<td>Card lock</td><td>Yes</td><td></td><td></td><td></td><td></td>

<td>Finish card</td><td>Yes</td><td></td><td></td><td></td><td></td>

<td>Restart card</td><td></td><td></td><td></td><td></td><td></td>

<td>CVM management</td><td>Yes</td><td></td><td></td><td></td><td></td>

<td>DAP Verification errand</td><td></td><td></td><td>Yes</td><td></td><td></td>

<td>Trust path</td><td>Yes</td><td>Yes</td><td></td><td></td><td>Yes</td>

<td>Authorized management</td><td>Yes</td><td>Yes</td><td></td><td></td><td>Yes</td>

<td>Verification of Token</td><td></td><td>Yes</td><td></td><td></td><td></td>

<td>Global elimination</td><td>Yes</td><td></td><td></td><td></td><td></td>

<td>Global lock</td><td>Yes</td><td></td><td></td><td></td><td></td>

<td>Global record</td><td>Yes</td><td></td><td></td><td></td><td></td>

<td>Final application</td><td></td><td></td><td></td><td></td><td></td>

<td>Global service</td><td></td><td></td><td></td><td>Yes</td><td></td>

<td>Generation of reception</td><td></td><td>Yes</td><td></td><td></td><td></td>

Table 12.2

0¾¾ MEXJCANO INSTITUTE V ^ ** ®!?, ** j 'M DE LA · ΚΟΠ? Γ&gt; / νί&gt; VeaerAjáSA IN? M'.TUAl. '' ia

INSTITUTO MEXICANO PE LA INII'ÍTLíaL

<td>Privileges</td><td>SD third parts</td><td>SD SP</td><td>SD SP (with delegated management)</td>

<td>Security Domain</td><td>Yes</td><td>Yes</td><td>Yes</td>

<td>DAP Verification</td><td></td><td>Optional</td><td>Optional</td>

<td>Delegated management</td><td></td><td></td><td>Yes</td>

<td>Card lock</td><td></td><td></td><td></td>

<td>Finish card</td><td></td><td></td><td></td>

<td>Restart card</td><td></td><td></td><td></td>

<td>CVM management</td><td></td><td></td><td></td>

<td>DAP Verification errand</td><td></td><td></td><td></td>

<td>Trust path</td><td>Yes</td><td>Yes</td><td>Yes</td>

<td>Authorized management</td><td>Yes</td><td></td><td></td>

<td>Verification of Token</td><td></td><td></td><td></td>

<td>Global elimination</td><td></td><td></td><td></td>

<td>Global lock</td><td></td><td></td><td></td>

<td>Global record</td><td></td><td></td><td></td>

<td>Final application</td><td></td><td></td><td></td>

<td>Global service</td><td></td><td></td><td></td>

<td>Generation of reception</td><td></td><td></td><td></td>

In an alternative mode, one or both of the SD 809 and 810 SP do not have DAP verification privileges.

In another alternative modality, one or both of SD 817

MDPH and SD 818 CA are not included in security element 801.

Implementation of the computer readable medium

The present invention (for example, system 100,

<img file="MX337986B_D0077.tif" />

IΖνϊPI

MEXICAN INSTITUTE OF INDUSTRIAL PROPERTY 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 devices or other processing systems. Insofar as the manipulations performed by the present invention have been referenced in terms of human operation, such ability of a human operator is not necessary, or desirable in most cases, in any of the operations described herein. that are 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, smart phones, personal digital assistants (PDAs), or similar devices.

In one embodiment, the invention is directed toward one or more systems capable of performing the functionality described herein. An example of a 900 system is shown in Figure 9.

System 900 includes one or more processors, such as processor 901. Processor 901 is connected to a communications infrastructure 902 (eg, a communication bus, a network). Various embodiments are described in terms of this exemplary system. After reading this

<img file="MX337986B_D0078.tif" />

ΙΜΡΙ '~

INSTITUTO MEXICANO description, it will become more evident to an expert in the relevant subject (s) how to implement the invention using other systems and / or architectures.

System 900 also includes main memory 903, which may be a database, or the like.

System 900 also includes a query module 904 for querying main memory 903. Querying a memory (eg, main memory 903) has been discussed in more detail above with reference to Figures 24.

System 900 also includes a receive module 905 for receiving data, such as requests, from other entities over a network. Receipt of data, such as requests, has been discussed in more detail above with reference to Figures 2-4.

System 900 also includes a transmission module 906 for transmitting data, such as applications and responses, to other entities over a network. Data transmission, such as requests and responses, has been discussed in more detail above with reference to Figures 2-4.

Each of the 904-906 modules can be implemented using hardware, software, or a combination of the two.

The exemplary embodiments described above, such as, for example, the systems and procedures depicted in or discussed in connection with Figures 1 to

8, or any part or function of the ^_ themselves can

<img file="MX337986B_D0079.tif" />

be implemented using hardware, software, or a combination of the two. Implementation can be on one or more computers or other processing systems. While the manipulations performed by these exemplary embodiments may have been referenced in terms commonly associated with mental operations performed by a human operator, no human operator is required to perform any of the operations described herein. In other words, the operations can be fully implemented with machine operations. Machines useful for performing the operation of the exemplary embodiments presented herein include general-purpose digital computers or similar devices.

The parts of the exemplary embodiments of the invention can be conveniently implemented using a conventional general-purpose computer, a specialized digital computer, and / or a microprocessor programmed in accordance with the teachings of the present disclosure, as is apparent to those of ordinary skill in the art. Appropriate software encoding can be easily prepared by skilled programmers based on the teachings of the present disclosure.

<img file="MX337986B_D0080.tif" />

MEXICAN INSTITUTE

OF THE PROPERTY

INDUSTRIAL

Some embodiments may also be implemented by preparing application specific integrated circuits, programmable gate arrays, or by interconnecting a suitable network of conventional component circuits.

Some embodiments include a computer program product. The computer program product may be a non-transient storage medium or a medium that has instructions stored therein or in these that can be used to control, or cause a computer to perform any of the procedures of exemplary embodiments of the invention. The storage medium may include, without limitation, a floppy disk, a mini disc, an optical disc, a Blu-ray disc, a DVD, a CD or a CD-ROM, a micro-device, a magneto-optical disc, a ROM, RAM, EPROM, EEPROM, DRAM, VRAM, flash memory, flash card, magnetic card, optical card, nanosystems, molecular memory integrated circuit, RAID, storage / file / remote data warehousing, and / or any other type of device suitable for storing instructions and / or data.

Stored on any one of the media or non-transient computer-readable media, some implementations include software to control both the computer hardware or the general microprocessor and / or

IMPI

MEXICAN INSTITUTE OF INDUSTRIAL PROPERTY

<img file="MX337986B_D0081.tif" />

special, such as to allow the computer or microprocessor to interact with a human user or other mechanism using the results of exemplary embodiments of the invention. This software may include, without limitation, device drivers, operating systems, and user applications. Finally, such computer-readable media additionally includes software to perform exemplary aspects of the invention, as described above.

Included in programming and / or computer software or the general and / or special purpose microprocessor, software modules to implement the procedures described above.

While various exemplary 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 evident to persons skilled in the relevant subject (s) that various changes in form and detail may be made therein. Therefore, the description should not be limited by any of the exemplary embodiments described above, but should be defined only in accordance with the following claims and their equivalents.

Furthermore, it should be understood that the figures are presented for example purposes only. The architecture of the

<img file="MX337986B_D0082.tif" />

⁷⁹ IMPI

MEXICAN INSTITUTE

OF THE PROPERTY

INDUSTRIAL r

Exemplary embodiments presented herein are flexible and configurable enough that they can be used and addressed in ways other than those shown in the accompanying figures.

In addition, the purpose of the summary is to enable the United States Patent and Trademark Office and the general public, and especially scientists, engineers, and subject matter experts who are unfamiliar with legal or patent terms or phraseology. , quickly determine from a cursory inspection the nature and essence of the technical description of the request. The summary is not intended to be limiting in any way as to the scope of the exemplary embodiments presented herein. It should also be understood that the procedures recited in the claims need not be performed in the order presented.

It is noted that in relation to this date, the best method known by the applicant to put the aforementioned invention into practice is the one that is clear from the present description of the invention.