KR20130108442A - System and method for secure containment of sensitive financial information stored in a mobile communication terminal - Google Patents

Abstract

PURPOSE: A system for a secure repository of importance financial information stored in a mobile communication terminal and a method thereof are provided to protect the information, which is stored in a secure element (SE) of a non-Universal Integrated Circuit Card (UICC) type, with an over-the-air (OTA). CONSTITUTION: An OTA proxy is connected to a trusted service manager (TSM) (10). The OTA proxy receives a security command from the TSM. The security command is either a command to delete the information stored in the SE of the non-UICC type, or a command to lock the access to the information stored in the SE of the non-UICC type. The OTA proxy transmits the mobile terminal information and the SE information to the TSM. The SE information comprises the SE status and the SE type. [Reference numerals] (11) Mobile device; (21) Wallet management application; (23) Non-contact type card application; (31) Mobile wallet application; (AA) Information protection-loss/stolen; (BB) Mobile push server; (CC) Widget; (DD) OTA proxy

Description

SYSTEM AND METHOD FOR SECURE CONTAINMENT OF SENSITIVE FINANCIAL INFORMATION STORED IN A MOBILE COMMUNICATION TERMINAL}

The present invention relates to the security of sensitive data in a mobile terminal.

Recently, with the development of the mobile technology field, as the size and weight of the mobile terminal is greatly reduced, the mobility has increased, and the tendency for the user to always carry the mobile terminal is accelerating. As mobile terminals (e.g. mobile phones and other mobile devices) become more widely used, mobile terminals are used in simple mobile terminals with communication capabilities such as e-mail, computer office application functions, video calls, and more recently mobile payment functions. It has continued to evolve to devices with the same advanced features. Integrating a variety of consumer-friendly utilities into a mobile terminal can provide convenience for the user, but also introduces security issues associated with the mobile terminal.

Security problems associated with increased usability of a mobile terminal may be serious due to improper use due to loss or theft of the mobile terminal as well as other accidents occurring by accident. In order to alleviate this security problem, various techniques have been proposed for remotely locking the mobile terminal in order to disable the function when the mobile terminal is lost or stolen. With this technology, when the mobile terminal is locked in normal operation, its function is deactivated, thereby reducing the improper use and leakage of personal information stored in the mobile terminal.

However, with advances in technology, not only thefters but also their techniques have evolved. Many intelligent thieves can easily break into remotely locked mobile terminals by so-called "jail-breaking" and retrieve critical information. Thus, simply locking the device or application for use is no longer sufficient, and more countermeasures must be made to prevent the use of important data stored on the mobile terminal.

In addition, with the introduction of the mobile Secure Element (SE), additional issues with security have emerged. Because many SEs that store sensitive information can be removed before being locked out, simple lock security on these devices may not be sufficient.

Deleting data can provide reliable security. However, only for SEs that conform to the current industry standard Short Messaging Service-Point to Point (SMS-PP) protocol or Bear Independent Protocol (BIP) (i.e., the standard for SEs of the Universal Integrated Circuit Card (UICC) type), It is only possible to remotely delete SE data. For SEs that do not allow access according to industry standard protocols, such as micro Secure Digital cards or embedded SEs (ie, non-UICC type SEs), SE Remote data deletion may not be feasible.

Finally, even though the stored important data may be deleted, it is not easy to replace the lost data when the lost mobile terminal is recovered or replaced. Therefore, when the mobile terminal storing important information is lost and replaced, both the application and the data must be installed again from the beginning.

An embodiment of the present invention provides a method for protecting information stored in a non-UICC type SE with over-the-air (OTA). In addition, an embodiment of the present invention provides a method for authenticating a mobile terminal with a trusted service manager (TSM) and reconfiguring a mobile wallet application.

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

According to an embodiment of the present invention, a method for receiving an over-the-air proxy initialization request of a mobile terminal, initializing an OTA proxy, receiving a request for protection of information stored in a secure element (SE), and an OTA By using a proxy, a method for protecting information stored in a non-UICC type SE, which includes protecting the information stored in a non-UICC type SE, is provided by an OTA.

An embodiment of the present invention includes receiving mobile terminal information and SE information from a mobile terminal, comparing the received information with stored mobile terminal information and SE information, and transmitting a command based on the comparison result. It provides a mobile terminal authentication method characterized in that.

An embodiment of the present invention, receiving a mobile wallet application reconfiguration request of the user, transmitting the mobile wallet application information stored in association with the user to the mobile terminal, receiving mobile terminal information and SE information and the A method for reconfiguring a mobile wallet application of a mobile terminal, the method comprising transmitting an application stored in association with mobile wallet application information to the mobile terminal.

An embodiment of the present invention provides a mobile terminal for protecting information in a non-UICC type SE including an OTA proxy and a non-UICC type SE that connect to the TSM and receive a security command from the TSM.

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

An embodiment of the present invention can protect information stored in a non-UICC type SE with an OTA. In addition, embodiments of the present invention may authenticate the mobile terminal with TSM and reconfigure the mobile wallet application.

BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are included to assist in understanding the invention, and are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and, together with the description, explain the principles of the invention.
1 is a system configuration diagram of a TSM ecosystem according to an embodiment of the present invention.
FIG. 2 is a system configuration diagram illustrating a method of deleting important credit card information and related mobile wallet information in the SE and the mobile wallet application according to an embodiment of the present invention.
3 is a system configuration diagram illustrating a method for synchronizing a mobile wallet application for authenticating a mobile terminal and a wallet management system for accessing an SE according to an embodiment of the present invention.
4 is a system configuration diagram illustrating a method for reconfiguring financial information credentials and related mobile wallet applications through a push technique according to an embodiment of the present invention.
FIG. 5 is a system configuration diagram illustrating a method for reconfiguring financial information and related mobile wallet applications through a pull technique according to an embodiment of the present invention.

Embodiments of the present invention are described in more detail with respect to the present invention with reference to the accompanying drawings. 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 the 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 mean X only, Y only, Z only, or any combination of two or more items X, Y, and Z (eg, XYZ, XZ, XYY, It should be understood that it can be interpreted as YZ, ZZ). Throughout the drawings and the description, the same reference numerals are understood to represent the same elements, features, and structures unless otherwise indicated. The relative size and description of these elements may be exaggerated for clarity.

1 is a system configuration diagram of a TSM ecosystem (Trusted Service Manager ecosystem) according to an embodiment of the present invention.

As shown in FIG. 1, the system according to the present embodiment employing OTA proxy provisioning and TSM technology includes a TSM 10, a mobile terminal 11, a network 15, A third party messaging platform 16, a financial institution 18, a mobile network operator (MNO) 19, a terminal manufacturer 20, and a card manufacturer 21. In order for the TSM 10 to be fully utilized by the user or its related parties, the service providers 18 to 21 must go through a pre-registration procedure. In this embodiment, the network 15 may be a cellular network including one or more base stations that enable the mobile terminal 11 to communicate with other mobile terminals or third party entities. The network 15 may also include other types of suitable communication networks, such as the Internet, existing wireline telephone lines, and other suitable network technologies.

The terminal manufacturer 20 may include an embedded Secure Element (SE) producer, and the card manufacturer 21 may include a micro SD card (ie, a non-UICC type SE) producer. If the SE manufacturer is different, the OTA key and the other OTA key provided in the existing UICC type SE are provided, so that the terminal manufacturer 20 and the card manufacturer 21 may use their OTA in the aforementioned pre-registration procedure for further processing. The keys may be provided to the TSM 10. Alternatively, the terminal manufacturer 20 and the card manufacturer 21 may provide their own OTA key on request without going through a pre-registration procedure. Details of the pre-registration process are described in co-pending US application 61 / 428,853.

In this embodiment, the OTA proxy is initialized or connected to the TSM 10 while using the mobile wallet application to conserve technical resources. Thus, the OTA proxy is in sleep mode by default until it wakes up to work. Third-party messaging platform 16 (eg, Cloud to Device Messaging (C2DM) can be utilized to wake up the OTA proxy, which wakes up and connects to TSM 10. TSM 10 wakes up). When sending up command and identification information to the third party messaging platform 16 as a message, the third party messaging platform 16 sends the message to the identified mobile terminal 11 and resides therein. The OTA proxy wakes up and connects to TSM 10 for provisioning or other utilities, on the other hand, if necessary, the OTA proxy connects very often or continuously to the wake-up procedure described above. Can be omitted.

If the mobile terminal 11 is equipped with a Near Field Communication (NFC) -enabled chip to provision a contactless card applet using NFC technology, the owner of the mobile terminal 11 is connected to the mobile terminal at the POS-enabled POS store. You can make a purchase by shaking (11). Once a purchase is made with the mobile terminal 11, the payment processor 22 and the aquirer network 23 cooperate to ensure that the payment details at the financial institution 18 are updated. However, this end user application does not involve the TSM ecosystem described above, but is mentioned for complete description of the ecosystem.

A method of deleting important information such as credit card credentials from the SE of the mobile terminal will be described below with reference to FIG. 2. Although only the deletion method is shown in the figure of this embodiment, it is also possible to assume other methods for protecting important information, such as locking access to information stored in the SE.

2 is a system configuration diagram provided for explaining a method of deleting important credit card information in the SE. Although not illustrated in FIGS. 2-5, for the purposes of this embodiment, all communications performed between external parties or SPs 18-21, TSM 10, and mobile terminal 11 are performed. It may be provided via network 15 or other suitable method as shown in FIG. In addition, important information is not limited to credit card information, and reference to credit card information is merely exemplary.

As shown in Fig. 2, in step 201, the SP of the financial institution 18, etc., in the stolen / lost mobile terminal 11 has its main information (e.g., credit card number, expiration date, security code, To delete a personal identification number (PIN), a request is generated that includes identification information, such as a Mobile Subscriber Integrated Services Digital Network (MSISDN). In this embodiment, such a request may be initiated by the owner of the mobile terminal 11 or by the SP. This request may be specific to credit card information of a particular SP, and may be a request for deletion of all of the sensitive information stored in the SE or a request for deletion of some of the important information stored in the SE. The request may generally be limited to the credit card information of the requesting SP, but if there is an agreement between the financial institutions, it can be implemented by requesting deletion of the credit card information of the other SPs agreed upon.

Similarly, in step 201, the request sent by the SP may be a request to lock the entire credit card information held by the SE or a request to lock by the security domain of the SE where the credit card information is stored separately. The request to lock or delete a particular security domain or SE may be specified by the SPs or by satisfying other business rules / requirements. In addition, although not shown, a request for information protection stored in the SE may be initiated by the owner of the mobile terminal 11 directly contacting the TSM 10. Further, in step 201 the request may be initiated by the SP voluntarily by the SP or in response to a request of the owner of the mobile terminal 11.

Upon receiving the request from the SP, in step 202 the TSM 10 updates the mobile terminal's account to " delete " in its database. In addition, the TSM 10 performs an internal query for checking whether a mobile wallet application 31 such as the SK C & C mobile wallet application 31 is installed in the mobile terminal 11 in question. In the present embodiment, if it is determined that the SK C & C mobile wallet application 31 is installed in the lost / stolen mobile terminal 11, the TSM 10 is a related contactless applet, a wallet management applet resident in the SE (Wallet Management Applet: Modify the request to delete the credit card information of the WMA) 21 and the widgets residing in the SK C & C mobile wallet application 31.

In addition, the TSM 10 determines the type of SE installed in the lost / stolen mobile terminal 11. Micro SD cards and embedded SEs (ie non-UICC type SE) do not support the existing Subscriber Identity Module Application Toolkit (SAT) / Universal Subscriber Identity Module Application Toolkit (USAT) / Card Application Toolkit (CAT) frameworks. The delete command configured by the TSM 10 may have to go through an OTA proxy to delete information stored in a non-UICC type SE such as a micro SD card or an embedded SE. On the other hand, OTA proxies can also support SEs supported by existing SAT / USAT / CAT frameworks such as 'UICC, Services Identity Module (SIM) or Universal Subscriber Identity Module (USIM)' (hereafter collectively referred to as UICC). have. A detailed description of the OTA proxy is described in co-pending US patent application 61 / 428,851.

When the TSM 10 completes the modification of the user account state, a push request is made to the mobile push server, which is a kind of C2DM (Cloud to Device Messaging) platform, in step 203.

In step 204, the mobile push server pushes a message to wake up the OTA proxy residing on the lost / stolen mobile terminal 11.

In step 205, the OTA proxy retrieves the mobile terminal 11 information and related SE information (such as MSISDN and CIN (Card Image Number)) and transmits the search result to the TSM 10. In the present embodiment, the SE information may further include a card reference number (CRN), a card production life cycle (CPLC), and a card serial number (CSN).

In addition, although not shown, upon receiving the mobile terminal information and the SE information, the TSM 10 checks the state of the SE. Since information processing stored in the SE is based on the state of the SE, the analysis of the SE state and its processes is performed before accessing the information stored in the SE. More specifically, depending on the state of the SE, several preparatory steps may be executed for SE security in processing commands received through the OTA proxy. In this embodiment, the SE attached to the mobile terminal 11 has one of three states (OS native, initialized and secured). If the SE is confirmed to be "secured", no further preparation steps are executed. The “secured” state of the SE may be an “intended operating card life cycle state” in post issuance. On the other hand, if the SE is determined 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 status is determined to be "OS native," a pre-personalization procedure is performed, which provides the SE with an initial issuer master key and a final issuer master key. It includes. The "OS native" state of the SE means that the SE is not initialized by the manufacturer's initialization method.

After determining the state of the SE, SE type analysis is performed to determine the type of protocol that must be run on the OTA proxy to provision the identified SE. If the SE is a UICC type or embedded type, the SE can be accessed to modify the information stored in the SE. Alternatively, if the SE is of micro SD type, a specific protocol may be executed for additional processes to access or modify the information stored in the SE. A person skilled in the art knows what type of protocol is used to access the micro SD type, so the description thereof is omitted.

In step 206, the TSM 10 processes the information provided with the " delete " command, converts it into an Application Protocol Data Unit (APDU) command, and sends the converted APDU command to the OTA proxy.

In step 207, the OTA proxy forwards the received APDU command to the SE with the credit card information. Credit card information is present in the wallet management applet 21 as well as the contactless card applet 23. Details of how the wallet management applet 21 is generated are described in co-pending US application 61 / 428,846.

If the " delete " command is successfully processed, the result is sent to the OTA proxy in step 208.

In step 209, the OTA proxy passes the result to the TSM 10. Then, in step 210, the TSM 10 informs the SP of the result of the request.

The "delete" function shown in FIG. 2 may be provided when the mobile terminal 11 is powered on and in a network reception state.

3 shows a system configuration diagram provided for synchronization of the mobile wallet application 31 residing in the mobile terminal 11.

In step 301, various external companies or SPs may request to change the configuration of the user's mobile wallet application 31 using a TSM / WMS (Wallet Management System). The master configuration of the mobile wallet application 31 is stored. In an embodiment of the present invention, external firms or SPs include financial institution 18, MNO 19, handset manufacturer 20 and card maker 21 (hereinafter collectively referred to as "PS" or "SPs"). It is not limited to these. Since the mobile wallet application 31 may not always run, the TSM / WMS may function as a central repository where various external companies can request a change, regardless of the user's login status to the mobile wallet application 31. For example, the external company or SPs may request a provision of a contactless card to be added to the user's mobile wallet application 31 at a time desired by the user regardless of the user's state.

Similarly, the TSM 10 may recognize that the expiration date of the contactless card applet stored in the SE is approaching based on its internal record, and may guide / induce the user to update the contactless card applet information. In an embodiment of the invention, the user of the mobile terminal 11 may be guided / induced by the mobile wallet application 31 or other suitable method such as email, text and voice mail. The user may be guided / derived from the TSM 10 in other ways besides providing such text, email, voicemail, or other suitable means of providing notification. In response to the guidance / induction, the user of the mobile terminal 11 may re-provision the contactless card applet via the TSM 10 system or by contacting the SP associated with the contactless card applet that is about to expire.

Then, when the user logs in to the mobile wallet application 31 of the mobile terminal 11, in step 302, the OTA proxy residing in the mobile wallet application 31 is the information of the mobile terminal 11 and the SE information (eg For example, it retrieves MSISDN, International Mobile Equipment Identity (IMEI) / Mobile Equipment Identifier (MEID), Integrated Circuit Card Identification (CIN / ICCID), and sends them to the TSM 10 for analysis.

Receiving the provided information, the TSM 10 performs internal verification of the information provided by the OTA proxy using the stored information in step 303.

If the provided terminal information or SE information is in conflict with the registered information, the TSM 10 logs to the event log and locks or deletes the important information until further verification or resolution is provided in step 304. 31). The sensitive information includes account information related to financial institution 18 that may be stored in the SE, such as credit card number, expiration date, personal identification number (PIN), and other related information. In addition, the sensitive information may include user security information or other personal information stored in the SE.

In this embodiment, the thief can steal a mobile SE, such as a micro SD, from the mobile terminal 11 and use it in another mobile terminal until the user knows that the SE has disappeared from his mobile terminal 11. By cross-referencing the registered mobile terminal ID and the registered SE, the TSM 10 recognizes whether the registered SE is mounted on another mobile terminal 11 which is not registered. It should also be noted that the TSM 10 may perform device mismatch recognition in a different manner than described in step 304. The TSM 10 may process these events according to business rules provided by the relevant company, such as guiding / inducing the user with a password, security key or other verification method.

Additional or other methods may be provided by the SPs that handle these events according to the consumer or their business rules.

When there is a request to provision another contactless card applet 23 or when the OTA proxy requests a connection with the TSM 10 or equivalent system, a synchronization check may be performed.

4 is a configuration diagram of a push system for reconfiguring a mobile wallet application 31 according to an embodiment of the present invention. Even if a user finds or replaces a mobile terminal, he or she may not have all of his or her previous financial credentials, so that the user can store all previously stored content in the mobile wallet application 31 and the mobile wallet application 31. You must contact either the SP or the TSM 10 to reconfigure. In an embodiment of the invention, the mobile wallet application 31 may include widgets residing within the mobile wallet application 31, a contactless card applet 23 stored in the SE, a wallet management applet 21, and an OTA proxy. . However, the mobile wallet application 31 may not include all of the mentioned elements but may also include many more elements.

In step 401, the user of the mobile terminal 11 contacts the SP and notifies that the new mobile terminal 11 has been obtained. The SP may perform self-authentication to confirm that the user is a legitimate user of the mobile terminal 11. Similarly, the user may directly notify the MNO 19 or the TSM 10.

Upon authenticating the user, the SP requests the TSM 10 to re-provision the user's new mobile terminal 11 with the SP's contactless application and related credentials at step 402.

In step 403, the TSM 10 checks to see if the user has another SP account provisioned before losing his or her mobile phone. If you have another SP account you have, you can request provisioning information from those SPs.

When the SP receives the provisioning information request, internal authentication and validation are performed, and the necessary information is sent to the TSM 10 at step 404.

In step 405, another internal check is executed to confirm what mobile wallet application 31 the user had previously on his mobile terminal 11. The mobile wallet application 31 may include various types such as the SK C & C mobile wallet application 31 or another mobile wallet application provided by another manufacturer.

If the mobile wallet application 31 is found to have been previously installed, then at step 406 the system retrieves the same version and associated user preference settings as the mobile wallet application 31 and delivers it to the user. Before moving to step 407, the user settings and mobile wallet application 31 may be sent to the user's mobile terminal 11 via the mobile push server. In the present embodiment, it is assumed that the mobile wallet application 31 includes the corresponding OTA proxy, which may be installed by the mobile terminal 11 upon application reception or as a separate procedure.

In step 407, the TSM 10 sends a push message to wake up the OTA proxy to a mobile push server, which is a kind of C2DM system. In this embodiment, the mobile wallet application 31 may be sent before, together or after the OTA proxy.

The mobile push server then forwards the received wake up command to the OTA proxy at step 408.

In step 409, the OTA proxy retrieves the SE information with the mobile terminal 11, such as MSISDN and CIN, and transmits the SE information to the TSM 10.

Upon receiving the information sent by the OTA proxy, in step 410 the TSM 10 processes the received information with the provisioning command and converts them into APDU commands for sending to the OTA proxy. In this embodiment, the provisioning command may include specific information, such as installation or removal of specific information or applications, and account information of the contactless card applet provided by the financial institution 18. In addition, when account information is received for a contactless card applet or other sensitive information, this information may be redundantly provisioned in the wallet management applet 21. In addition, the TSM 10 obtains a version of the associated widget for the mobile wallet application 31 of the mobile terminal 11 directly to the wallet application 31.

Next, in step 411, the OTA proxy delivers the credit card information, the APDU command received to the SE to which the contactless applet will be provisioned. If the user is a previous user of the mobile wallet application 31, an APDU command is passed to provision account information for the contactless applet installed in the wallet management applet 21 located in the SE. In addition, the widget application is installed in the mobile wallet application 31 to provide a graphic display of the installed account.

If the provisioning command is successfully processed, the result is passed to the OTA proxy at step 412.

Next, in step 413, the OTA proxy forwards the result to the TSM 10, and the TSM 10 updates the system according to the result of performing the request.

In step 414, an SP provisioning request performance result notification is sent to the corresponding SP (s).

As with FIG. 4, the user's mobile wallet application 31 can be restored via a pull mechanism, which is initiated by the owner of the mobile terminal 11 as shown in FIG. 5.

If the owner of the mobile terminal 11 attempts to reinstall the mobile wallet application 31 on the mobile terminal 11, a request is made from the new or replaced portable terminal 11 in step 501. This request is sent to the TSM 10 along with the mobile identification information.

The TSM 10 receives the request with the relevant identification information, and an authentication process is performed to verify the user at step 502. The requesting user can be authenticated through passwords, security issues, social security numbers, or other appropriate verification methods. If you are authenticated as a legitimate user, a check is made on your existing account. If the mobile wallet application 31 is found to have been previously installed, the system retrieves the same version of the mobile wallet application 31 and associated user settings and sends it to the user at step 503 for download. The mobile wallet application 31 along with the configured user settings may be transmitted to the user's mobile terminal 11 via the mobile push server.

In this embodiment, if it is determined that the requesting user does not have the mobile wallet application 31 previously, a new account is created in the TSM 10, and the mobile wallet application 31 is a mobile terminal through the mobile push server. Is sent to (11). In the present embodiment, it is assumed that the mobile wallet application 31 includes the corresponding OTA proxy, which may be installed by the mobile terminal 11 upon application reception or in a separate procedure.

Next, in step 504, the TSM 10 checks the requesting user account with the associated SP account information. If more than one SP account is associated with a user account, each SP is notified and requests provisioning information to be sent to the requesting user. Step 503 and step 504 are composed of separate steps. Steps 503 and 504 may be integrated or implemented in reverse order. For example, in this embodiment, the mobile wallet application 31 and the SP related widget may be separately provided. However, by collecting all the necessary widgets and the mobile wallet application 31 from the SP, the TSM 10 may deliver both the widgets and the mobile wallet application 31 to the user. If the TSM 10 is allowed to store account information, the TSM 10 may provide the mobile wallet application 31 and widgets without further requests to the SPs.

When the SPs receive the request for provisioning information, internal authentication and validation is performed, and the necessary information is sent to the TSM 10 in step 505.

In step 506, the TSM 10 sends a push message to wake up the OTA proxy to a mobile push server, a kind of C2DM system. Although the mobile wallet application 31 has been described as being sent prior to the OTA proxy, it should be noted that the OTA proxy may be sent simultaneously with or prior to the mobile wallet application 31.

The mobile push server then forwards the received wake up command to the OTA proxy at step 507.

In step 508, the OTA proxy collects the mobile terminal 11 information, such as MSISDN and CIN, together with the provisioning command and sends it to the TSM 10. In this embodiment, the provisioning command may include specific information or a specific command to install or delete an application and account information for a contactless card applet that may be provided by the financial institution 18. Other important information, such as the key of the SE, may be provided by other SPs or the TSM 10. Important information may be provided by the SP before the TSM 10 is used as an intermediary and stored in real time or stored in the TSM 10.

Upon receiving the information sent by the OTA proxy, in step 509 the TSM 10 processes the information along with the provisioning command, converts it into an APDU command and sends it to the OTA proxy. When a provisioning command including account information of a contactless card applet is received, this information may be redundantly provisioned in the wallet management applet 21. In addition, the version of the widget associated with the wallet application 31 may be obtained by the TSM 10 and provisioned directly to the mobile wallet application 31.

Next, in step 510, the OTA proxy forwards the received APDU command to the SE to which the credit card information, contactless applet will be provisioned. If the user is a previous user of the mobile wallet application 31, an APDU command is sent to provision account information for the contactless applet installed in the wallet management applet 21 located in the SE. In addition, the widget application may be installed in the mobile wallet application 31 to provide a graphic display of the installed account.

If the provisioning command is processed successfully, the result is sent to the OTA proxy in step 511.

Thereafter, if the OTA proxy forwards the result to the TSM 10 in step 512, the TSM 10 updates the system with the result of performing the request.

In step 513, an SP provisioning request performance result notification is sent to the corresponding SP (s).

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

10: Trusted Service Manager
11: mobile terminal
31: Mobile Wallet Application
21: Wallet Management Applet
23: Contactless Card Applet
18 ~ 21: SP (Service Provider)

Claims (33)

In the information protection method stored in the secure element (SE) of the non-UICC (non-Universal Integrated Circuit Card) type of the mobile terminal,
Receiving an over-the-air proxy (OTA) initialization request of the mobile terminal;
Initializing the OTA proxy;
Receiving a request for protection of information stored in the SE; And
Protecting the information stored in the SE by using the OTA proxy;
And the SE is a non-UICC type SE.
The method of claim 1,
Requesting installation of the OTA proxy;
Receiving installation information of the OTA proxy;
And installing the OTA proxy in the mobile terminal.
The method of claim 2,
Information installation method of the OTA proxy, characterized in that receiving from the Trusted Service Manager (TSM).
The method of claim 3, wherein
The OTA proxy initialization step,
Waking the OTA proxy; And
Transmitting mobile terminal information and SE information to the TSM;
The SE information includes an SE state and an SE type.
The method of claim 1,
The request for protection of the information includes an information protocol data unit (APDU) command.
6. The method of claim 5,
The information protection step,
Executing the APDU command to protect the requested information;
The non-UICC type SE is
Information that includes a micro Secure Digital card, an embedded SE, or an SE that does not support the Short Messaging Service Point to Point (SMS-PP) protocol or the Bear Independent Protocol (BIP). Protection method.
The method of claim 1,
The information protection step,
And deleting the information stored in the SE of the non-UICC type.
The method of claim 1,
The information protection step,
Locking (locking) access to information stored in the SE of the non-UICC type.
The method of claim 1,
And the OTA proxy initialization request is received from a push server.
The method of claim 1,
Preparing the SE for information protection before protecting the requested information;
The SE preparation step,
Retrieving SE information including mobile terminal information and SE status and SE type;
Receiving a key according to the SE state; And
Accessing the SE using a key.
The method of claim 10,
The mobile terminal information,
And at least one of an International Mobile Equipment Identity (IMEI), a Mobile Equipment Identifier (MEID), and a Mobile Subscriber Integrated Services Digital Network Number (MSISDN).
The method of claim 10,
And the key comprises at least one of an initial issuer master key and a final issuer master key.
13. The method of claim 12,
The information protection step,
And if it is determined that the SE state is an operating system (OS) native, providing at least one of the initial issuer master key and the last issuer master key to the SE.
13. The method of claim 12,
The protection step,
If it is determined that the SE status is initialized, providing the final issuer master key to the SE.
The method of claim 10,
Using the key to access the SE,
And processing a protocol that enables provisioning of an SE of which the SE type is a micro SD (Secure Digital) type.
In the mobile terminal authentication method,
Receiving mobile terminal information and secure element (SE) information from the mobile terminal;
Comparing the received information with stored mobile terminal information and SE information; And
And transmitting a command based on the comparison result.
17. The method of claim 16,
The mobile terminal information,
A mobile terminal authentication method comprising at least one of an International Mobile Equipment Identity (IMEI), a Mobile Equipment Identifier (MEID), and a Mobile Subscriber Integrated Services Digital Network Number (MSISDN).
17. The method of claim 16,
The SE information,
A mobile terminal authentication method comprising at least one of a card image number (CIN), a card reference number (CRN), a card production life cycle (CPLC), and a card serial number (CSN).
17. The method of claim 16,
The command transmission step,
And if the received information is different from the stored information, transmitting a command to delete the information stored in the SE of the mobile terminal.
20. The method of claim 19,
The SE,
A mobile terminal authentication method, characterized in that the SE of the non-Universal Integrated Circuit Card (UICC) type.
17. The method of claim 16,
The command transmission step,
If the received information is different from the stored information, transmitting a command to lock (lock) access to information stored in the SE of the mobile terminal.
22. The method of claim 21,
The SE is a non-UICC (non-Universal Integrated Circuit Card) type SE, characterized in that the mobile terminal authentication.
In the method for reconfiguring a mobile wallet application of a mobile terminal,
Receiving a mobile wallet application reconfiguration request from a user;
Transmitting mobile wallet application information stored in association with the user to the mobile terminal;
Receiving mobile terminal information and secure element (SE) information; And
And transmitting an application stored in association with the mobile wallet application information to the mobile terminal.
24. The method of claim 23,
The application transmission step,
And transmitting an over-the-air proxy (OTA) proxy application related to the user.
24. The method of claim 23,
The application transmission step,
And transmitting an OTA proxy application related to the mobile wallet application information.
24. The method of claim 23,
Receiving the user's mobile wallet application reconfiguration request,
Receiving identification information associated with the user; comprising a mobile wallet application reconfiguration method.
24. The method of claim 23,
Application information stored in connection with the mobile wallet application,
And at least one of a contactless card applet, a wallet management applet, and a widget application for the user interface.
In the mobile terminal for protecting the information stored in the secure element (SE) of the non-Universal Integrated Circuit Card (non-UICC) type with OTA,
An OTA proxy connecting to a Trusted Service Manager (TSM) to receive security commands from the TSM; And
A mobile terminal comprising a non-UICC type SE.
29. The method of claim 28,
The security command,
And a command for deleting information stored in the non-UICC type SE or a command for locking access to information stored in the non-UICC type SE.
29. The method of claim 28,
The OTA proxy transmits mobile terminal information and SE information to the TSM.
The SE information includes a SE state and a SE type.
31. The method of claim 30,
The OTA proxy is,
Receive a key from the TSM to access the SE based on the SE information sent to the TSM,
The key comprises at least one of an initial issuer master key and a final issuer master key.
31. The method of claim 30,
The OTA proxy is a mobile terminal, characterized in that for receiving a protocol for preparing the SE SE is a micro SD (Secure Digital) type provisioned.
29. The method of claim 28,
The non-UICC type SE is
Contactless card applet; And
A wallet management applet for the contactless card applet;
The wallet management applet comprises at least one of a contactless card applet, an expiration date and an account number associated with a security code.

Images