KR101561534B1 - System and method for managing ota provisioning applications through use of profiles and data preparation - Google Patents

Abstract

Receiving an application profile, a load file profile, an SE profile and a mobile terminal profile, establishing a link between the received profiles for assembling the application product, and applying a restriction to the application product, Wherein the method further comprises the step of determining whether the application product is accessible to the user.

Description

FIELD OF THE INVENTION [0001] The present invention relates to an OTA provisioning management system and method using profiles and data preparation.

The present invention relates to a technology for provisioning a virtual card applet to a secure element (SE) of a mobile terminal.

With the recent advances in mobile technology, more and more functions have been added to mobile handsets. Due to the addition of related applications from GPS to mobile office products, mobile terminals have become commonplace for many. Attempts have been made to provide a mobile financial management system that can replace existing real wallets to take advantage of mobile technology for better consumer everyday needs. In particular, this mobile wallet function was intended to realize by directly provisioning the account information of the card issuer to the SE of the mobile terminal. SE is a smart card chip that can store multiple applications that contain account information that is not readily accessible to external vendors. The mobile wallet application has the same configuration as a conventional wallet including payment cards, membership cards, transportation cards, and loyalty cards.

Mobile wallet functionality can be further enhanced by provisioning the user's financial information to a mobile terminal equipped with a Near Field Communication (NFC) enabled chipset. Once the user's financial information is provisioned to the SE of an NFC-enabled mobile terminal, the provisioned NFC-enabled terminals are brought in close proximity to each other without physical contact, thereby transferring information to other NFC-compatible devices, such as point-of- Or perform a payment. This type of technology has traditionally been referred to as a "non-contact" technology, and payment by this technology is called "non-contact" payment. Despite the many advantages that can be exploited using the above techniques, there is no practical solution for provisioning user critical information to NFC-enabled mobile terminals.

One possible solution for provisioning mobile wallet cards is to provision in a security facility controlled by a mobile wallet card issuer. However, this solution requires the user to go directly to the mobile wallet card issuer with his mobile terminal for provisioning. This process must be repeated for every mobile wallet card that the user wants to provision in the security of the different card issuer, making the concept of the mobile wallet impractical.

Meanwhile, many competing SPs will focus on mobile commerce and offer their services to consumers. However, these services should be able to be provided to consumers regardless of the performance of the mobile terminal used by the consumers or the mobile SPs. Due to technical or business compatibility issues, there may be many applications that are not applicable to consumers of certain attributes. Thus, consumers frequently collide with various applications that are not applicable to consumers, making the processor more difficult than necessary.

Embodiments of the present invention provide a method of providing an application to a user. An embodiment of the present invention provides a data preparation method based on a data type.

Additional features of the invention will be set forth in the description which follows, and will become apparent from the following description.

An embodiment of the present invention includes: receiving an application profile, a load file profile, a secure element (SE) profile, and a mobile terminal profile; Establishing a link between received profiles, for assembling an application product; And applying a restriction to the application product, wherein the applied restriction is to determine whether the application product is accessible to the user. ≪ RTI ID = 0.0 > Product).

An embodiment of the present invention includes the steps of receiving data from a service provider (SP), wherein the received data is a DGI (Data Grouping Identifier) format or a raw data format; And processing the data using at least one of a logical data preparation and a physical data preparation. A method of preparing data using a non-transient processor in a Trusted Service Manager (TSM) to provide.

An embodiment of the present invention includes: receiving an application profile, a load file profile, a key profile, an SE profile and a mobile terminal profile; Receiving a key; Establishing a link between the key profile and the key; Establishing a link between received profiles, the link being set for assembling the application product; Applying a restriction to the application product, the restriction being a technical restriction, a restriction on a business rule, or an authentication restriction; Receiving mobile terminal information, the mobile terminal information including at least one of operating system (OS) information, secure element (SE) type information, hardware information, and application information stored in a mobile terminal; And filtering the application product based on the applied restriction and mobile terminal information for display to the user. The method of filtering an application product using a non-transient processor includes the steps of:

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are intended to provide further explanation of the invention as claimed. Other features and aspects will be apparent from the following detailed description, drawings, and claims.

According to an embodiment of the present invention, an application is provided to a user and data preparation based on a data type becomes possible.

The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and, together with the description, serve to explain the principles of the invention.
1 is a system configuration diagram of a TSM ecosystem supporting an OTA provisioning process through an OTA proxy, according to an embodiment of the present invention.
FIG. 2 is a block diagram illustrating a relationship between a TSM system, its components, and service providers (SPs) according to an embodiment of the present invention.
3 is a high level flowchart illustrating an OTA provisioning process through an OTA proxy according to an embodiment of the present invention.
4 is a flow diagram illustrating pre-registration steps that the SP must perform to utilize the TSM system, in accordance with an embodiment of the present invention.
5 is a flow chart detailing how a profile connection is made to assemble a registered application product, according to an embodiment of the present invention.
Figure 6 is a flow chart detailing how to set limits between profiles, in accordance with an embodiment of the present invention.
FIG. 7 is a flowchart illustrating an exemplary data preparation service provided by the TSM system for provisioning according to an embodiment of the present invention.
8 is a system configuration diagram exemplarily illustrating a provisioned mobile terminal according to an embodiment of the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS Embodiments of the invention will now be described in more detail with reference to the accompanying drawings, in which: Fig. However, the invention may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. For purposes of the present invention, the expression "at least one of" should be understood to mean any combination of the listed elements, including combining many of the listed elements. For example, the expression "at least one of X, Y, and Z" may refer to any combination of X only, Y only, Z only, or any combination of two or more items X, Y, and Z (e.g., XYZ, XZ, XYY, YZ, ZZ). ≪ / RTI > Throughout the drawings and the detailed description, unless indicated to the contrary, the same reference numerals are understood to represent the same elements, features, and structures. The relative size and description of these elements may be exaggerated for clarity.

1 is a system configuration diagram of a TSM ecosystem supporting an OTA provisioning process through an OTA proxy, according to an embodiment of the present invention. A more detailed description of the OTA proxy is given in a system and method for OTA provisioning of critical information to a mobile terminal with non-UICC SE filed on December 30, 2010 and pending herewith.

As shown in Figure 1, a system employing OTA proxy provisioning and TSM technology includes a TSM system 10, a mobile terminal 11, a network 12, a third party messaging platform 13, A POS (Point of Sale) terminal 14, a financial institution 15, an MNO (Mobile Network Operator) 16, a terminal manufacturer 17, and a card maker 18. In this embodiment, the financial institution 15, the MNO 16, the terminal manufacturer 17, and the card maker 18 will be collectively referred to as a SP (Service Provider). The SPs are not limited to the SPs shown in FIG.

In order for the TSM system 10 to be fully utilized by the user, the SPs 15 through 18 must undergo a pre-registration procedure as shown in FIG. In this embodiment, the network 12 may be a cellular network including one or more base stations that enable the mobile terminal 11 to communicate with other mobile terminals or with third party entities of the third party. The network 12 may also include other types of suitable communication networks, such as the Internet, conventional wired telephone lines, and other suitable network technologies.

The terminal manufacturer 17 may include a manufacturer of an embedded Secure Element (SE) and the card manufacturer 18 may include a manufacturer of a Secure Digital SE. The embedded SE and micro SD SE may include non-UICC SE . The terminal manufacturer 17 and the card maker 18 provide the OTA keys for their SEs in the pre-registration procedure to the TSM (10) as the OTA key used in the existing UICC SE is provided, ). In addition, the terminal manufacturer 17 and the card manufacturer 18 may provide their own OTA keys in the case of a request from the mobile terminal 11 without going through a pre-registration process. In this embodiment, the OTA key may be generated by SE manufacturers or acquired through a third party. For simplicity of explanation and representation, the OTA key may simply be referred to as a "key ". However, the term "key" is not limited to an OTA key, but may refer to other keys that may be used to perform a secure transaction involving a transport key, an SE key, and SEs.

In this embodiment, if the contactless card applet is provisioned in the mobile terminal 11 and the contactless card applet is interlocked with the NFC technology mounted on the mobile terminal 11, the owner of the mobile terminal 11 may be an NFC-enabled POS terminal 14 to shake / approach the mobile terminal 11 to purchase. When purchases are made with the mobile terminal 11, an aquirer network and a payment processor collaborate to ensure that the payment history at the financial institution 15 is updated. However, this end-user application is not accompanied by the TSM 10 echo system described above, and is mentioned for a complete description of the echo system according to an embodiment of the present invention.

In addition, the TSM 10 may include several components for more efficient processing. FIG. 2 is a block diagram illustrating a relationship between a TSM system, its components, and service providers (SPs) according to an embodiment of the present invention.

The TSM system 10 includes a CAMS (Card & Application Management System) 21, a KMS (Key Management System) 22, a PIP (Post Issuance Processor) 23), CBPS (Customer Care, Billing, Participant System: Customer Management, Payment, Affiliate System) 24, WMS (Wallet Management System Wallet Management System) 25, OM & A ) 26, an external system interface (ESI) 27, and a data base (DB) (not shown) for storing and managing various information provided to the TSM 10. The DB repository may reside in a particular component as an independent component within the TSM 10, or may be separate from the TSM 10 as an external component.

The CAMS 21 manages the Life Cycle (LC) of the SE, the security domain, and the applet. The LC (Life Cycle) represents various states of an SE or an applet installed in the mobile terminal 11. In this embodiment, the LC of the SE may include an OS (Operating System) native (OS native), initialized (initialized), and secured (secured). The LC of an applet can include a lock and an unlock. The CAMS 21 also manages the SE type, SE profile, SE ID, application profile and card profile. One or more SEs are individually identified by the CAMS 21 as their own SE IDs (Card Reference Number (CRN), Card Image Number (CIN), Card Production Life Cycle (CPLC) Respectively.

The KMS 22 performs key management to enable a secure transaction. Key management operations include, but are not limited to, secure log in, access control, audit, key profile management, key management, key profile exchange, & recovery and delegated management.

The PIP 23 provisions information to the mobile terminal 11, which includes the provision of data to be provisioned and the provisioning of the provisioning message provided by the APDU (Application Protocol Data Units) and the actual execution of the pre-service data preparation.

The CBPS 24 is responsible for customer management. The CBPS 24 maintains and monitors data relating to customer account status and SP service subscriptions. If a particular event occurs (e.g., a mobile terminal stolen) or there is a request from the SP, the CBPS 24 may modify the status of the SPs associated with the customer.

The WMS 25 manages the mobile wallet application and the associated mobile card widget stored therein. The WMS 25 may provide a mobile ID associated with both the wallet application stored in the user's mobile terminal 11 as well as each of the widgets stored in the mobile wallet application. In addition, the WMS 25 stores user settings (e.g., language, font, base card, etc.) generated by the wallet owner. The system may have a master configuration to provide synchronization benefits to the mobile wallet application. This component may be provided within the TSM 10 or in a separate system.

The O & M 26 provides an interface for external administrators to access the TSM 10 directly. If the SP or an external vendor directly enters data or wishes to modify certain items, the designated contact person can access the TSM 10 via OM & A 26 to make the necessary modifications.

The ESI 27 provides an interface through which one or more SPs send and receive data. Since the SPs have specific or specialized protocols that they utilize, the ESI 27 translates commands and requests sent and received by the TSM 10.

The TSM 10 described above is implemented as a third party entity in a position to integrate information from the financial institution 15, the MNO 16, the terminal manufacturer 17 and the card manufacturer 18 It is possible. Since the TSM 10 has information gathered from various vendors, it is sufficient for the mobile terminal 11 to interact only with the TSM 10, not the various separated objects. In summary, the TSM 10 functions as an integration point of one or more SPs or external vendors that the mobile terminal 11 must deal with, thereby providing mobile services with smooth and more efficient operations.

All of the components described above may reside within the TSM system or may be separated at the TSM 10 according to business or system design specifications. In this embodiment, the TSM 10 may be an individual server present on the network or a vendor of various servers.

3 is a high level flowchart illustrating an OTA provisioning process through an OTA proxy according to an embodiment of the present invention. When the requesting mobile terminal 11 installs the OTA proxy application accompanied by the mobile wallet application, the provisioning procedure is performed according to the procedure described below.

Prior to provisioning the mobile card application, one or more SPs are pre-registered with the TSM 10, as shown in step 301. A detailed illustration and description of this procedure is provided in FIG.

When the SP profiles are registered, the user may select the payment card of the registered SP to be provisioned to the mobile terminal 11 at step 302.

If there is a request to provision the selected mobile payment card, at step 303 the financial institution 15 requests the TSM 10 to issue it. The service subscription request may include identification information, such as a Mobile Subscriber Integrated Services Digital Network Number (MSISDN), along with encrypted account related information to provision.

In response to the request, at step 304, the TSM 10 begins provisioning the provisioning data. Upon receiving the provisioning information, an internal data link is performed to log the service request by the financial institution 15. In addition, a portion of the account data transmitted by the financial institution 15 may be retained in the TSM 10 to identify the user and the card account. For security reasons, the entire account number does not need to be retained. However, for business reasons, the entire account number may be retained. A detailed illustration and description of how links are provided between two or more profiles is provided in FIG.

If the request is logged in the TSM 10, then in step 305 the TSM 10 sends a wake-up request command to the mobile push server (e.g., Cloud to Device Messaging (C2DM) platform) with identification information In step 306, the mobile push server forwards the command to wake up the OTA proxy residing on the user's mobile terminal 11. [

In a preferred embodiment of the present invention, the OTA proxy assumes a sleep state before awakening. When woken up or initialized, the OTA proxy connects to the TSM 10. After awake, the OTA proxy can connect to the TSM 10 automatically or when a user command is entered. Once connected, the OTA proxy collects the SE information and mobile terminal information and sends the collected information to the TSM 10 for verification. However, the OTA proxy may collect information prior to connection or may provide information to the TSM 10 in a separate procedure. When the provided information is received, at least one of MSISDN, International Mobile Equipment Identity (MEEI) / Mobile Equipment Identifier (MEID), and Card ID Number (ICIN) / Integrated Circuit Card Identification (ICCID) The TSM 10 performs an internal check to ensure that it matches the stored user information. Since this internal inspection is performed each time the OTA proxy connects to the TSM 10, it can be seen that an additional security procedure is provided for identifying the mobile terminal 11 and the SE associated with the user account.

When the OTA proxy connects to the TSM 10 and the internal inspection by the TSM 10 is completed, the TSM 10, in step 307, Lt; RTI ID = 0.0 > provisioning < / RTI >

More specifically, at step 307, the TSM 10 identifies the SE state and the SE type to determine the appropriate process for provisioning to be performed. Since the processing of the SE is based on its state, an analysis of the SE state and the corresponding process is performed before accessing the information stored in the SE. More specifically, depending on the state of the SE, several preparatory steps are performed to secure the SE to process the commands received via the OTA proxy. In this embodiment, the SE provided in the mobile terminal 11 may have one of three states (OS native, initialized and secured).

If the SE is found to be in the "secured" state, no further preparatory steps are performed. The "secured" state of the SE may be an "intended operating card life cycle state" in a post issuance. On the other hand, if the SE is found to be in the "initialized" state, the TSM 10 provides a final issuer master key for SE security. The "initialized" state of the SE may be an " administrative card production state ". Finally, if the SE state is identified as "OS native ", a pre-personalization procedure is performed, which provides the SE with an initial issuer master key and a final issuer master key . The "OS native" state of the SE refers to the state in which the SE is not initialized by the manufacturer's initialization method.

After determining the state of the SE, an SE type analysis is performed to determine the type of protocol to be executed in the OTA proxy to provision to the identified SE. If the SE is a UICC type or an embedded type, the SE may be accessed to modify the information stored in the SE. Alternatively, if the SE is of the micro SD type, a particular protocol may be executed for further processing to access or modify the information stored in the SE. Those skilled in the art will know what type of protocol is used to access the micro SD type, and a description thereof will be omitted.

Once the optimal provisioning mode is determined, in step 308 the TSM 10 prepares the provisioning data in the APDU format and sends it to the OTA proxy. The OTA proxy that receives the APDU command from the TSM 10 forwards the provisioning data to the SE in step 309.

The OTA proxy can access the non-UICC SE through the various keys loaded in the TSM 10 and the application programming interface (API) of the SE, and the API of the SE is exchangeable offline. These attributes are combined to provide an OTA proxy protocol for access to the SE to be provisioned.

4 is a flow diagram illustrating pre-registration steps that the SP must perform to utilize the TSM system, in accordance with an embodiment of the present invention. In this embodiment, the SPs register their information in the TSM 10 to be available in the TSM 10 first. The SP is an object whose service is desired to be provisioned to the mobile terminal 11.

In step 401, the information of the SP is registered in the TSM 10. [ This process can be performed in various ways. For example, the SP can send basic registration information in an encrypted e-mail with a Pretty-Good-Privacy (PGP) public key. Registrations can be done through people, phones, automated systems, or other means of exchanging information. The TSM manager inputs basic information of the SP to the TSM 10 and stores the SP's unique SP ID, transport key ID, SP type (financial institution 15, MNO 16, The manufacturer 17, and the card manufacturer 18). A TSM administrator can be a person, an automation system, or a separate entity. The TSM 10 then creates an SP account and generates a secure token for associating with the SP ID. When this is done, the TSM 10 encrypts the SP account information and sends it to the SP in encrypted e-mail.

In step 402, a transfer key is exchanged between the TSM 10 and the SP. The transport key enables secure transmission of important data between various vendors. Such security may be provided through encryption, data encryption conversion via Message Authentication Code (MAC), or other appropriate security measures. The SP sends a request to receive the transmission key set to the TSM (10). In response, the TSM 10 identifies the duplicate keys assigned to the requested SP, and if such a key is not assigned, it generates a transport key set within the Hardware Security Module (HSM). In this embodiment, the transport key set may comprise three keys, which are composed of an encryption key (ENC), a data encryption key (DEK) and a message authentication code (MAC) have. The TSM will export the generated keys in an encrypted form using the PGP key provided by the SP in step 301. When the transport key set is exchanged between vendors, the associated profiles (LoadFile profile 403, application profile 404, key profile 405, SE profile 406, and mobile terminal profile 407 )] Is provided to the TSM 10 for registration. These processes can be performed simultaneously or independently. Further, the profiles are not limited to the above-mentioned profiles. In the present embodiment, a large number of registered profiles may be provided to provide customized more specific application products to the user, and in order to provide more general purpose application products to various users, a small number of registered profiles Can be provided.

The load file profile 403 defines an application code file that contains one or more applications or defines load files that make up application code. The application profile 404 defines the smart card application as metadata, which is later utilized to create an application instance. The key profile 405 defines basic profile information and key information as metadata, which is utilized to generate a key instance. The ISD master key is also registered in the system, including an Initial Supplier Key (ISK), an Initial Issuer Master Key (KMC), and a Final Issuer Master Key (CMK). Key profile 405 includes metadata for one or more keys, including ISK, KMC, and CMK. The SE profile 406 defines the attributes of the smart card. More specifically, the SE profile includes, but is not limited to, manufacturer, version, name, model, and contact / contact attribute (e.g., transmission rate) information. And finally, the mobile terminal profile 407 defines the attributes of the mobile terminal 11, including whether it supports NFC functionality, supported SE types and OTA channels.

Once more than one profile is provided to the TSM 10, the TSM 10 establishes one or more links between the provided profiles to provide one or more application products that the user requests. The profiles may be sent directly to the TSM 10 over the network 12 in a typical way of providing data or in any other suitable way that information can be transmitted. At step 408, two or more of these profiles may be linked. The procedure in which these profiles are linked to each other will be described in more detail with reference to FIG.

Once the links between the profiles have been established, the constraints between the profiles are set in step 409. One or more application products may be limited according to the business rules collected by the TSM 10 based on the agreement between the SPs. For example, for business reasons, some MNO 16 (e.g., Sprint ^R ) may refuse to collaborate with a financial institution 15 (e.g., Citibank ^R ). There may also be some technical limitations that make it impossible to provide specific application products to the user's mobile terminal 11, such as an incompatible mobile OS. According to these constraints, a list of filtered application products can be provided for the consumer's request. A detailed description of how to set limits between profiles will be described in detail below with reference to FIG.

5 is a flowchart detailing how profile connections are made to assemble a registered application product, according to an embodiment of the present invention.

As mentioned in FIG. 4, in steps 403-407, various profiles are registered in the TSM 10 by SPs. However, if the key profile 405 is registered, further steps may be performed. If the keys are not provided with the key profile 405, then in step 501 the keys are registered by the SP. If the keys are provided with a key profile 405, the keys are extracted by the TSM manager or TSM 10. Also, once both the key and key profiles are registered, a link is created between the key and the key profile in step 502 to provide a key instance for use by the TSM 10.

At step 503, when one or more profiles are registered with the TSM 10, the TSM 10 or the TSM administrator compiles the registered profiles based on one or more possible combinations and initiates application product registration for issuance do. The application product may include the following attributes: product name, logo, group, SE type, application ID (AID) and instance AID of the secure domain. For example, a product instance can consist of a Citi ^R type bank, a Visa ^R issue, an Android ^R operating system, a Sprint ^R mobile service, and other related properties. This application product registration step can be repeated until the corresponding application products are registered. This step may be performed using suitable software or applications well known to those skilled in the art, or using specialized software or applications designed for this purpose. This step may also be performed by another person, an automated system, or other suitable system.

Once the application products are configured by concatenating the various profiles, the application products are analyzed in step 504 to verify that it is appropriate to carry the dependent application products. For example, a contactless FDC-supported credit card applet as an application product may require a Payment Procedure Secure Elements (PPSE) application to accompany each applet at the mobile terminal 11. As such, providing appropriate subordinate applications ensures that application products are used smoothly, ensuring that users have appropriate control mechanisms in the context of using provisioned application products.

Figure 6 is a flow chart detailing how to set limits between profiles, in accordance with an embodiment of the present invention.

In step 601, the TSM 10 analyzes one or more registered application profiles 404, a registered SE profile 406, and a registered mobile terminal profile 407.

Based on the provided profiles, in step 602 one or more profiles are checked for technical incompatibility problems with other profiles. If the provided profiles are compatible, no restrictions apply to the application product. However, in the event of a technically incompatible problem, restrictions apply to ensure that no application products are provided to the user that may not be technically compatible.

If there is no technical incompatibility problem, at step 603, it is verified that the restrictions on the stored business rules apply for each application product. For example, if MNO 16 (e.g., Sprint ^R ) refuses to collaborate with financial institution 18 (e.g., Citibank ^R ), restrictions on business rules may apply to the application product .

If there are no restrictions on the applicable business rules, then in step 604 the TSM 10 verifies the authentication requirements imposed by credit card issuers, such as VISA ^R or Master Card ^R , for the application product. If an application product is not authenticated by a specific issuer, then the certification limitation applies to that application product. If there is no authentication incompatibility problem, no restrictions are added to the registered profiles.

Although steps 602 through 604 are described as proceeding in a specific order, this order is for illustrative purposes only and is not limited in the order presented. In this embodiment, steps 602 to 604 may be performed all at once, or may be performed in some combination of steps. Further, steps 602 through 604 may be processed in reverse order or in a different order. Also, in one particular step, the compatibility / conformance check may not affect providing another compatibility / conformance check. All or part of the compatibility / conformance check can be performed by the TSM 10. For example, the TSM 10 can only verify business compatibility or business and technical compatibility. Finally, these compatibility / conformance checks are not limited to the categories provided, and more compatibility / conformity categories may be added to the TSM 10.

7 is a flow diagram illustrating an exemplary data provisioning service provided by the TSM system for provisioning, in accordance with an embodiment of the present invention.

In step 701, the SP sends provisioning data, such as credit card account information, to the TSM 10. In step 702, an analysis is performed by the TSM 10 to ascertain the data preparation level of the provisioning data. Since SPs have different capabilities in preparing the data to be provided, some data may require more data preparation than other data. For example, small financial institutions may lack the technical capability to provide prepared data or may not have the bargaining power necessary to order data preparation services from a third party. For example, the data provided by each of the SPs may be in three different formats: APDU format, Data Grouping Identifier (DGI) format, and raw data format.

If it is determined that the SP is providing data in the APDU format, the TSM 10 need not perform any further processing before provisioning the data provided by the SP, as shown in step 705.

If it is determined that only the logical data preparation has been performed by the SP, the TSM 10 classifies the data into the DGI format and, in step 704, converts physical data preparation. Physical data preparation may be performed using one or more suitable methods as is possible. The provided data then waits for provisioning at step 705.

If the SP does not prepare the data at all and it is determined that only low data is provided, the TSM 10 first performs logical data preparation, as shown in step 703. Logical data preparation may be performed using one or more suitable methods as appropriate. When logical data preparation is complete, another level of preparation of physical data preparation is required at step 704, before waiting for provisioning at step 705. [ Logical data preparation and physical data preparation are well known, so further description of them is omitted herein.

By providing data preparation services independent of the data provisioning level provided by the SP, the TSM 10 allows the TSM 10 to be used for provisioning even for small SPs that do not have the necessary commercial or technical capabilities.

8 is a system configuration diagram exemplarily illustrating a provisioned mobile terminal according to an embodiment of the present invention.

The mobile terminal 11 includes a mobile wallet application 81, an OTA proxy 82, a device stack 83 and an SE 84 when the mobile terminal 11 is provisioned according to an embodiment of the present invention.

The mobile wallet application 81 provides a graphical, mobile wallet interface to the user that may be used to provide a mobile wallet interface such as a widget associated with other elements (e.g. coupons, transportation passes, phone billing bills, etc.) And includes various components.

OTA proxy 82 supports provisioning of important information, such as financial applications and associated account information, to SE 84 of mobile terminal 11. The OTA proxy 82 is a mobile client that supports post-issuance of related services to the SE of the mobile terminal to the OTA. Since the micro SD and embedded SE (i.e. non-UICC SE) of the SE types can not support the existing SAT / SUSAT / CAT framework, the SP transmits data to the mobile terminal 11 equipped with the non-UICC SE OTA proxies via OTA are used. However, if desired, the OTA proxy may provide other methods beyond the existing methods for provisioning to the SE that may support the existing SAT / SUSAT / CAT framework (e.g., UICC / SIM / USIM).

SE 84 includes a WMA (Wallet Management Applet) 801, a Payment Procedure Secure Elements (PPSE) 802 and a payment applet (s) 803. When the payment applet 803 is provisioned to the SE of the mobile terminal 11, the payment applet 803 is placed in the security domain of the SE to prevent unauthorized access to sensitive account information stored in the payment applet. The payment applet 803 includes an application ID, an application label or a logo, and account information that the user can not access. In addition, when the payment applet 803 is provisioned to the SE 84, the PPSE 802 for managing the payment applet 803 during a payment transaction is also provisioned. During the payment procedure at the POS terminal 14, for the retailer and manufacturer to select a particular payment applet, the PPSE 802 manages the application label of the payment applet and the associated application ID required for selection . However, since the mobile terminal 11 can not directly access the payment applet 803, a copy of the account information stored in the payment applet 803 in the original provisioning procedure of the payment applet 803 is also separately provisioned to the WMA 801 . However, in response to a business request, the WMA 801 may be provisioned independently of the provisioning of the payment applet 803. The WMA 801 is provided with a duplicate record of the payment applet 803 so that the user of the mobile terminal 11 can access the account information stored in the SE 84. [

It will be apparent to those skilled in the art that various modifications and variations can be made in the present invention without departing from the spirit or scope of the invention. Accordingly, it is intended that the present invention cover modifications and variations of this invention provided they come within the scope of the appended claims and their equivalents.

10: TSM
11: Mobile devices
21: Card & Application Management System (CAMS)
22: Key Management System (KMS)
23: PIP (Post Issuance Processor)
24: Customer Care, Billing, Participant System (CBPS)
25: Wallet Management System (WMS)
81: Mobile Wallet Application
82: OTA proxy
84: Secure Element (SE)
801: WMA (Wallet Management Applet)
802: Payment Procedure Secure Elements (PPSE)
803: Payment Applet

Claims (18)

A method for providing an application using a non-transitory processor,
Receiving at least one of an application profile, a load file profile, a Secure Element (SE) profile, and a mobile terminal profile;
Establishing a link between received profiles, for assembling an application; And
Applying a restriction to the application, wherein the applied restriction is to determine whether the application is accessible to the user.
The method according to claim 1,
The application profile comprises:
Wherein the smart card application is defined as metadata for creating an application instance.
The method according to claim 1,
The load-
Wherein one or more load files constituting the application code are defined.
The method according to claim 1,
The mobile terminal profile comprising:
Wherein the attributes of the mobile terminal including NFC (Near Field Communication) function, supportable SE type, and OTA channel support are defined.
The method according to claim 1,
Receiving a key profile;
Receiving a key; And
And setting a link between the key profile and the key.
The method according to claim 1,
The application comprises:
A product name, a logo, a product group, an SE type, an application ID (AID) of a security domain, and an instance AID.
6. The method of claim 5,
Wherein the key profile comprises:
Wherein the key information is defined as metadata in order to generate a key instance.
The method according to claim 1,
Wherein applying the restriction to the application comprises:
Applying a technical restriction,
The above-
Wherein the method is applied when it is determined that there is a technical incompatibility problem between at least one of the mobile terminal, the OS and the SE type of the mobile terminal.
The method according to claim 1,
Wherein applying the restriction to the application comprises:
Applying a restriction on business rules,
Business limitations,
And the application is applied when it is determined that there is a business incompatibility problem among one or more SPs.
10. The method of claim 9,
In the SP,
A financial institution, a mobile network operator (MNO), a terminal manufacturer, and a card manufacturer.
The method according to claim 1,
Wherein applying the restriction to the application comprises:
Applying an authentication restriction,
The authentication restriction may include:
Wherein the application is applied when it is determined that the application is not authenticated by the financial institution.
12. The method of claim 11,
Wherein the financial institution is a credit card issuer or a debit card issuer.
The method according to claim 1,
For assembling the application, establishing a link between received profiles comprises:
And setting a link to the application and a dependent application.
delete delete delete delete A method for filtering an application using a non-transitory processor, the method comprising:
Receiving at least one of an application profile, a load file profile, a key profile, an SE profile, and a mobile terminal profile;
Receiving a key;
Establishing a link between the key profile and the key;
Establishing a link between received profiles, said link being set for assembling said application;
Applying a restriction to the application, the restriction being a technical restriction, a restriction on a business rule, or an authentication restriction;
Receiving mobile terminal information, the mobile terminal information including at least one of operating system (OS) information, secure element (SE) type information, hardware information, and application information stored in a mobile terminal; And
And filtering the application based on application restrictions and mobile terminal information for display to the user.

Images