CN110024425B

CN110024425B - Apparatus and method for installing and managing ESIM configuration files

Info

Publication number: CN110024425B
Application number: CN201780074498.8A
Authority: CN
Inventors: 李慧远; 姜秀姃; 朴钟汉; 尹江镇; 李德基
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 2016-12-01
Filing date: 2017-11-30
Publication date: 2022-12-06
Anticipated expiration: 2037-11-30
Also published as: CN110024425A; JP7043497B2; EP3530016A1; EP3530016A4; KR102237840B1; KR20180062923A; JP2020501437A

Abstract

An apparatus and method for securely providing a configuration file to a terminal in a communication system are provided. The apparatus and method include a communication technology that combines a fifth generation (5G) communication system for supporting a data rate higher than a fourth generation (4G) system with a technology internet of things (IoT) technology, and a system thereof. The present disclosure may be applied to intelligent services based on 5G communication technology and internet of things related technology, such as smart homes, smart buildings, smart cities, smart cars or networked cars, healthcare, digital education, retail, security, and security related services.

Description

Apparatus and method for installing and managing ESIM configuration files

Technical Field

The present disclosure relates to an apparatus and method for communication connection by downloading and installing a communication service from a communication system to a terminal. More particularly, the present disclosure relates to an apparatus and method for online downloading, installing and managing configuration files in a communication system.

Background

In an effort to meet the increasing demand for wireless data services since the Fourth Generation (4G) communication system deployment, improved Fifth Generation (5G) or pre-5G communication systems have been developed. Accordingly, the 5G or pre-5G communication system is also referred to as a "super 4G network" or a "Post (Post) Long Term Evolution (LTE) system". The 5G communication system is considered to be implemented in a higher frequency (millimeter wave) band (e.g., 60Ghz band) in order to achieve a higher data rate. In order to reduce propagation loss of radio waves and increase transmission distance, beamforming, massive Multiple-Input Multiple-Output (MIMO), full-Dimensional MIMO (FD-MIMO), array antenna, analog beamforming, and Massive antenna techniques are discussed in the 5G communication system. In addition, in the 5G communication system, development of system Network improvement is being performed based on advanced small cell, cloud Radio Access Network (RAN), ultra-dense Network, device-to-Device (D2D) communication, wireless backhaul, mobile Network, cooperative communication, coordinated Multi-point (CoMP), receiver interference cancellation, and the like. In the 5G system, hybrid Frequency Shift Keying (FSK) and Quadrature Amplitude Modulation (QAM) Modulation (FQAM) and Sliding Window Superposition Coding (SWSC) as Advanced Coding Modulation (ACM) have been developed, as well as filterbank Multi-Carrier (FBMC), non-Orthogonal Multiple Access (NOMA), and Sparse Code Multiple Access (SCMA) as Advanced Access technologies.

The Internet is a human-centric connected network in which people generate and consume information, and is now developing into the Internet of things (IoT), in which distributed entities, such as things, exchange and process information without human intervention. Internet of things (IoE) has emerged, which combines Internet of things technology with big data processing technology through connection with cloud servers. As technical elements, there have recently been studied IoT implementations, sensor networks, machine-to-Machine (M2M) Communication, machine Type Communication (MTC), and the like, such as "sensing technologies", "wired/wireless Communication and network infrastructures", "service interface technologies", and "security technologies", which have been required. Such an Iot environment can provide an intelligent internet technology service that creates new value for human life by collecting and analyzing data generated between connected things. Through the fusion and integration of existing Information Technology (IT) with various industrial applications, ioT may be applied to smart homes, smart buildings, smart cities, smart cars or networked cars, smart grids, healthcare, smart homes, and advanced medical services.

In line with this, various attempts have been made to apply the 5G communication system to the IoT network. For example, techniques such as sensor networks, MTC, and M2M communication may be implemented through beamforming, MIMO, and array antennas. The application of cloud RAN as the big data processing technology described above can also be considered as an example of the convergence between 5G technology and IoT technology.

Disclosure of Invention

Technical problem

A Universal Integrated Circuit Card (UICC) is a smart Card for insertion into a mobile communication terminal or the like, and is called a UICC Card. The UICC may include an access control module for accessing a network of a mobile communications service provider. Examples of such access control modules may be Universal Subscriber Identity Module (USIM), subscriber Identity Module (SIM), and Internet Protocol (IP) Multimedia Service Identity Module (ISIM). A UICC including a USIM may be generally referred to as a USIM card. In the same way, a UICC comprising a SIM module may be generally referred to as a SIM card. In the following description of the present disclosure, a SIM card will be generally used for UICC cards including UICC cards, USIM cards, and UICCs including ISIMs. That is, although the SIM card is mentioned, its technical characteristics can be applied to the USIM card, the ISIM card, or the universal UICC card in the same manner.

The SIM card stores personal information of a mobile communication subscriber and enables the user to use secure mobile communication by performing user authentication and service security key generation during access to a mobile communication network.

In putting forward the present disclosure, generally, a SIM card is manufactured as a dedicated card for a specific Mobile communication service provider at the request of the corresponding service provider during the manufacture of the card, and authentication information, such as a USIM application and an International Mobile Subscriber Identity (IMSI), a K value, and an OPc value, for accessing a network of the corresponding service provider is previously embedded in the card before shipment. Accordingly, the manufactured SIM card is delivered to a corresponding mobile communication service provider and then provided to a subscriber. Thereafter, if desired, management of applications in the UICC, such as installation, correction, and deletion, may be performed using techniques such as over-the-air (OTA). The subscriber can use the network and application services of the corresponding mobile communication service provider by inserting the UICC card into the subscriber's mobile communication terminal. In the case of a replacement terminal, the UICC card may be removed from an existing terminal and then may be inserted into a new terminal, so authentication information, a mobile communication phone number, a personal phone book, etc. stored in the UICC card may be used as if they were in the new terminal.

However, it is inconvenient to use the SIM card in the case where a mobile communication terminal user intends to receive a service provided from another mobile communication service provider because the user should physically acquire the SIM card for the service. For example, in the case of traveling to another country, the end user should purchase a local SIM card in order to receive local mobile communication services. Although the roaming service may solve the inconvenience problem to some extent, the user may not receive the service due to expensive fees or no agreement between communication service providers.

On the other hand, in the case where the SIM module is remotely downloaded and installed in the UICC card, the inconvenience problem as described above can be significantly solved. That is, the user can download the SIM module of the mobile communication service intended for use into the UICC card at a desired time. A plurality of SIM modules may be downloaded and installed in the UICC card, and one of the downloaded SIM modules may be selected for use. The UICC card may or may not be fixed to the terminal. In particular, a UICC fixed to a terminal is called an embedded UICC (eUICC), which represents a UICC card generally fixed to the terminal and can remotely download and select a SIM module. In the present disclosure, a UICC card capable of remotely downloading and selecting a SIM module is generally referred to as an eUICC. That is, a UICC card fixed or not fixed to a terminal among UICC cards capable of remotely downloading and selecting a SIM module is generally called an eUICC. In addition, the downloaded SIM module information is commonly referred to as eUICC profile.

The above information is presented merely as background information to aid in understanding the present disclosure. No determination is made and no assertion is made as to whether any of the above is applicable to the prior art with respect to this disclosure.

Means for solving the problems

Aspects of the present disclosure are directed to solving at least the above problems and/or disadvantages and to providing at least the advantages described below. Accordingly, an aspect of the present disclosure is to provide an apparatus and method for a terminal to perform a communication connection by selecting a communication service in a communication system.

Another aspect of the present disclosure is to provide an apparatus and method for a terminal to download, install and manage a configuration file for a communication connection online in a communication system.

It is still another aspect of the present disclosure to provide an apparatus and method for securely providing a configuration file to a terminal in a communication system.

Specifically, the present disclosure proposes the following method for solving the above-described aspects.

-method for a terminal to transmit a message for requesting profile download or remote profile management to a profile management server subscription manager data preparation plus (SM-DP +).

-a method for the profile management server SM-DP + to selectively send in reply to the terminal the profile download or the remote profile management, and to send in reply the reference information to be used when the terminal generates a message to be transmitted to the next phase for requesting the profile download or the remote profile management.

-a message exchange procedure between the terminal and the profile management server SM-DP +.

According to an aspect of the present disclosure, a terminal in a wireless communication system is provided. The terminal includes: an input unit (user interface) configured to display and receive an input from a user of a type of an event (profile download or remote profile management) performed by the terminal; a sending unit capable of sending one or more of the following to the profile management server SM-DP +: an embedded universal integrated circuit card (eUICC) identifier (EID) in the terminal, eventRequestType indicating a type of an event to be performed by the terminal, RPMConfig indicating whether the terminal allows remote profile management, an Integrated Circuit Card ID (ICCID) of a profile that is a subject on which the terminal is to perform remote profile management, and an opertorid of a service provider that currently provides a communication service to the terminal; a receiving unit capable of receiving one or more events to be executed by the terminal and one or more types and numbers of one or more events to be executed next by the terminal from the profile management server SM-DP + in response thereto; an input unit (user interface) configured to display information on one or more events to be performed by the terminal to a user and receive an input of the user who agrees to perform the corresponding event; a processor configured to determine whether to continue or stop execution of one or more received events based on input consent; a processor configured to execute the event if it is determined to continue executing the event (i.e., if the user's approval is input); a processor and a transmitting unit configured to transmit a result of the execution event to a profile management server SM-DP +; and a processor and a transmitting unit configured to transmit a message for requesting a next event to the profile management server SM-DP + according to the type and number of one or more events to be executed next by the terminal.

According to another aspect of the present disclosure, a profile management server SM-DP + in a wireless communication system is provided. The profile management server SM-DP + comprises: an event memory configured to store an event (profile download or remote profile management) to be executed by an eUICC of the terminal; a processor and determination unit configured to control and determine priorities of events stored in the event memory; a receiving unit configured to receive one or more of the following from a terminal: an EID in the terminal, eventRequestType indicating a type of an event to be performed by the terminal, RPMConfig indicating whether the terminal allows remote profile management, ICCID being a profile for which the terminal is to perform remote profile management, and OperatorID of a service provider currently providing a communication service to the terminal; a receiving unit capable of receiving eUICC authentication information including a signature; a determining unit configured to select one or more events to be executed by the terminal by comparing the received message of the terminal with priorities of the events stored in an event memory of the profile management server SM-DP +; a determination unit configured to grasp a type and a number of one or more events to be executed next by the terminal among the events stored in the event memory; a transmitting unit capable of transmitting a type and a number of one or more events to be executed by the terminal next time; a receiving unit capable of receiving a result of executing the event from the terminal; and a receiving unit capable of receiving a message for requesting a next event from the terminal.

According to another aspect of the present disclosure, a method of a terminal in a wireless communication system is provided. The method comprises the following steps: transmitting a Universal Integrated Circuit Card (UICC) -related message to a server to request an event for a terminal, wherein the UICC-related message includes information on an operation type of the event; receiving a response message including data corresponding to the operation type from the server, and performing an operation based on the data.

According to another aspect of the present disclosure, a terminal in a wireless communication system is provided. The terminal includes a transceiver and a processor coupled to the transceiver, the processor configured to control: transmitting a UICC-related message to a server to request an event for a terminal, wherein the UICC-related message includes information on an operation type of the event; receiving a response message including data corresponding to the operation type from the server, and performing an operation based on the data.

According to another aspect of the present disclosure, a method of a server in a wireless communication system is provided. The method comprises the following steps: receiving a UICC-related message from a terminal to request an event of the terminal, wherein the UICC-related message includes information on an operation type of the event; and transmitting a response message including data corresponding to the operation type to the terminal.

According to another aspect of the present disclosure, a server in a wireless communication system is provided. The server includes a transceiver and a processor coupled to the transceiver, the processor configured to control: receiving a UICC-related message from a terminal to request an event of the terminal, wherein the UICC-related message includes information on an operation type of the event; and transmitting a response message including data corresponding to the operation type to the terminal.

Technical aspects performed by the present disclosure are not limited to those described above, but other non-mentioned aspects will be clearly understood from the following description by those of ordinary skill in the art to which the present disclosure pertains.

The invention has the advantages of

According to another aspect of the present disclosure, in the communication system, the terminal may notify the profile management server SM-DP + of an input of a current user, and selectively receive an event to be currently performed among profile download or remote profile management from the profile management server SM-DP +, and may direct an event to be performed next to the terminal. Thus, in case one or more events (profile download or remote profile management) in the profile management server SM-DP + are in a standby state, the terminal can automatically request, receive, and then execute the next event.

Other aspects, advantages, and salient features of the disclosure will become apparent to those skilled in the art from the following detailed description, which, taken in conjunction with the annexed drawings, discloses various embodiments of the disclosure.

Drawings

The above and other aspects, features and advantages of certain embodiments of the present disclosure will become more apparent from the following description taken in conjunction with the accompanying drawings, in which:

fig. 1 is a diagram illustrating a method of a terminal connecting to a mobile communication network using a Universal Integrated Circuit Card (UICC) embedded with a fixed profile according to an embodiment of the present disclosure;

fig. 2 is a diagram illustrating a message exchange process between a terminal and a profile server in the case of installing one or more profiles through the profile server according to an embodiment of the present disclosure;

fig. 3 is a diagram illustrating a message exchange process between a terminal and a profile server in the case of installing one or more profiles through the profile server and performing one or more remote profile managements according to an embodiment of the present disclosure;

fig. 4 is a diagram illustrating a method of specifying a type of an event corresponding to a command input by a user when a terminal requests the event from a profile server according to an embodiment of the present disclosure;

FIG. 5 is a diagram illustrating a method of a profile server managing an event store according to an embodiment of the present disclosure;

6A, 6B, 6C, and 6D are diagrams illustrating a method for determining whether a profile server can bind one or more events with a binding to perform a binding transfer, according to an embodiment of the present disclosure;

fig. 7A, 7B, and 7C are diagrams illustrating a method in which a profile server transmits an event to be currently performed when configuring an event response message according to an embodiment of the present disclosure;

FIG. 8 is a diagram illustrating a method by which a profile server transmits an event to be executed next time when configuring an event response message according to an embodiment of the present disclosure;

FIG. 9 is a diagram illustrating a process for a profile server to configure an event response message, according to an embodiment of the present disclosure;

fig. 10, 11 and 12 are diagrams illustrating message processes in which a terminal and a profile server continuously receive and execute one or more events according to an embodiment of the present disclosure;

fig. 13 is a diagram illustrating a process in which a terminal requests a "profile download" from a server and receives a response to the request according to an embodiment of the present disclosure;

fig. 14 is a diagram illustrating a process in which a terminal requests "remote profile management" from a server and receives a response to the request according to an embodiment of the present disclosure;

fig. 15 is a diagram illustrating a process in which a terminal requests all types of events from a server and receives a response to the request according to an embodiment of the present disclosure;

fig. 16 is a diagram illustrating a method in which a terminal continuously processes events after preferentially protecting data of all events according to an embodiment of the present disclosure;

fig. 17 is a diagram illustrating a method in which a terminal protects and processes data of respective events in the order of event reception according to an embodiment of the present disclosure;

FIG. 18 is a diagram illustrating a method by which a profile server generates and appends individual signatures to corresponding remote profile management and profile metadata according to an embodiment of the present disclosure;

FIG. 19 is a diagram illustrating a method by which a profile server specifies an order of data processing while generating and appending separate signatures to corresponding remote profile management and profile metadata according to an embodiment of the present disclosure;

FIG. 20 is a diagram illustrating a method by which a profile server generates and appends a public signature to a portion of the profile metadata and corresponding remote profile management in accordance with an embodiment of the present disclosure;

FIG. 21 is a diagram illustrating a method by which a profile server specifies the order of data processing while generating and appending a public signature to profile metadata and a portion of the corresponding remote profile management, according to an embodiment of the present disclosure;

fig. 22 and 23 are diagrams illustrating a signature generation and data deployment method according to an embodiment of the present disclosure;

fig. 24A, 24B, 25, and 26 are diagrams illustrating a method of configuring a User Interface (UI) in a terminal according to an embodiment of the present disclosure;

fig. 27 is a diagram illustrating an operation of a terminal according to a time-series flow according to an embodiment of the present disclosure;

fig. 28 is a block diagram illustrating constituent elements of a terminal according to an embodiment of the present disclosure; and

fig. 29 is a block diagram illustrating constituent elements of a server according to an embodiment of the present disclosure.

Throughout the drawings, it should be noted that the same reference numerals are used to depict the same or similar elements, features and structures.

Detailed Description

The following description with reference to the accompanying drawings is provided to assist in a comprehensive understanding of various embodiments of the disclosure as defined by the claims and their equivalents. It includes various specific details to aid understanding, but these are to be considered exemplary only. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the various embodiments described herein can be made without departing from the scope and spirit of the present disclosure. In addition, descriptions of well-known functions and constructions may be omitted for clarity and conciseness.

The terms and words used in the following description and claims are not limited to the written meaning, but are used only by the inventor to enable a clear and consistent understanding of the disclosure. Accordingly, it will be apparent to those skilled in the art that the following descriptions of the various embodiments of the present disclosure are provided for illustration only and not for the purpose of limiting the disclosure as defined by the appended claims and their equivalents.

It is understood that the singular forms "a," "an," and "the" include plural referents unless the context clearly dictates otherwise. Thus, for example, reference to a "component surface" includes reference to one or more such surfaces.

In describing various embodiments, in the event that it is determined that an explanation of technical contents that are well known in the technical fields to which the present disclosure pertains and that are not directly related to the present disclosure obscure the subject matter of the present disclosure in unnecessary detail, the explanation will be omitted.

For the same reason, in the drawings, some constituent elements are enlarged, omitted, or roughly shown. In addition, the dimensions of some of the constituent elements may not fully reflect their actual dimensions. In the drawings, like reference numerals are used for like elements in the various drawings.

Aspects and features of the present disclosure and methods for accomplishing the same will become apparent by reference to the various embodiments that will be described in detail with reference to the accompanying drawings. However, the present disclosure is not limited to the various embodiments disclosed below, but may be embodied in various forms. The matters defined in the description, such as detailed construction and elements, are nothing but specific details provided to assist those of ordinary skill in the art in a comprehensive understanding of the disclosure, and the present invention is defined only within the scope of the appended claims. Throughout the description of the present disclosure, the same reference numerals are used for the same elements in the various figures.

It will be understood that each block of the flowchart illustrations, and combinations of blocks in the flowchart illustrations, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart block or blocks. These computer program instructions may also be stored in a non-transitory computer-usable or computer-readable storage device that can direct a computer or another programmable data processing apparatus to function in a particular manner, such that the instructions stored in the non-transitory computer-usable or computer-readable memory produce an article of manufacture including instruction means that implement the function specified in the flowchart block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks.

Moreover, each block of the flowchart illustrations may represent a portion, segment, or module of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved.

The term "unit" as used in an embodiment refers to, but is not limited to, a software or hardware component, such as an FPGA or ASIC, that performs certain tasks. However, "unit" is not meant to be limited to software or hardware. Term "

A unit "may advantageously be configured to reside on the addressable storage medium and configured to run on one or more processors. Thus, by way of example "

A unit "may include components such as software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables. Assembly and "

The functions provided in the unit "may be combined into fewer components and"

Unit "or further divided into additional components and"

A unit ". Further, components and "units" may be implemented to operate one or more CPUs in a device or secure multimedia card.

Specific terms used in the following description are provided to aid understanding of the present disclosure, and may be modified in various forms without departing from the scope of the technical concept of the present disclosure.

First, terms used in the description will be defined.

In the description, a Universal Integrated Circuit Card (UICC) is a smart card for insertion into a mobile communication terminal, and refers to a chip storing personal information therein, such as network Access authentication information of a mobile communication subscriber, a phone book, a Short Message Service (SMS), and can securely use mobile communication by performing user authentication and traffic security key generation when accessing a mobile communication network, such as Global Satellite Mobile (GSM), wideband Code Division Multiple Access (WCDMA), and Long Term Evolution (Long-Term Evolution). In the UICC, communication applications such as a Subscriber Identity Module (SIM), a Universal SIM (USIM), and an Internet Protocol (IP) multimedia SIM (ISIM) are embedded according to the type of a mobile communication network to which a subscriber accesses, and the UICC may provide upper layer security functions for embedding various application programs such as an electronic wallet, a ticket, and an electronic passport.

In the description, an embedded UICC (eUICC) is also a chip-type security module embedded in a terminal, in addition to a detachable type that can be inserted into or detached from the terminal. The eUICC can download and install the configuration file using over-the-air (OTA) techniques. An eUICC can be referred to as a UICC in which profile download and installation can be performed.

In the description, the method of downloading and installing a profile using OTA technology in an eUICC can be applied to a detachable type UICC that can be inserted into or detached from a terminal. That is, embodiments of the present disclosure may be applied to a UICC that is capable of downloading and installing a profile using OTA technology.

In the description, the term "UICC" may be used in mixture with a SIM, and the term "eUICC" may be used in mixture with an eSIM.

In the description, the profile may mean that an application, a file system, and an authentication key value stored in the UICC are packaged in the form of software.

In the description, the USIM configuration file may have the same meaning as the configuration file, or may mean that information included in the USIM application is packaged in the form of software in the configuration file.

In the description, the Profile providing server may include a function of generating a Profile, encrypting the generated Profile, generating a remote Profile management command, or encrypting the generated remote Profile management command, and may be expressed as Subscription Manager Data Preparation (SM-DP), subscription Manager Data Preparation Plus (SM-DP +), an off-card entity of a Profile domain, a Profile encryption server, a Profile generation server, a Profile configurator (PP), a Profile provider, or a Profile configuration certificate holder (PPC holder).

In the description, the profile management server may be represented as a Subscription Manager Secure Routing (SM-SR), a Subscription Manager Secure Routing Plus (SM-SR +), an off-card entity of the eUICC profile Manager, a profile management credential holder (PMC holder), or an eUICC Manager (eUICC Manager, EM).

In the description, the profile providing server may be generally referred to as a profile providing server to which the function of the profile managing server is added. Therefore, in various embodiments of the present disclosure, that is, beyond the scope of the technology, the operation of the profile providing server may also be performed by the profile management server. In the same manner, the operations described with respect to the profile management server or the SM-SR may also be performed by the profile providing server.

The term "Terminal" used in the description may be referred to as a Mobile Station (MS), a User Equipment (UE), a User Terminal (UT), a Wireless Terminal, an Access Terminal (AT), a Terminal, a Subscriber Unit, a Subscriber Station (SS), a Wireless device, a Wireless communication device, a Wireless Transmit/Receive Unit (WTRU), a Mobile node, a Mobile, or other terms. Various embodiments of the terminal may include a cellular phone, a smart phone having a wireless communication function, a Personal Digital Assistant (PDA), a wireless modem, a portable computer having a wireless communication function, an imaging device such as a Digital camera having a wireless communication function, a gaming device having a wireless communication function, a music storage and rendering (reproduction) home application having a wireless communication function, an internet home application capable of wireless internet connection and browsing, a portable unit or terminal that integrates a combination of such functions. Further, the terminal may include a machine-to-machine (M2M) terminal or a Machine Type Communication (MTC) terminal/device, but is not limited thereto. In the description, a terminal may be referred to as an electronic device.

In the description, a UICC capable of downloading and installing a profile may be embedded in an electronic device. If the UICC is not embedded in the electronic device, the UICC, which is physically separated from the electronic device, may be inserted into the electronic device to connect to the electronic device. For example, a card-type UICC may be inserted into the electronic device. The electronic device may comprise a terminal, and in this case, the terminal may be a terminal comprising a UICC capable of downloading and installing the profile. The UICC may be embedded in the terminal, and if the terminal and the UICC are separated from each other, the UICC may be inserted into the terminal to connect to the terminal. A UICC that is capable of downloading and installing a profile may be referred to as an eUICC, for example.

In the description, the terminal or the electronic device may include software or an application installed in the terminal or the electronic device to control the UICC or the eUICC. The software or application may be referred to as, for example, a Local Profile Assistant (LPA).

In the description, the profile discriminator may be referred to as a profile ID, an Integrated Circuit Card ID (ICCID), a machine ID, an event ID, an activation code token, an ISD-P, or a factor matching a Profile Domain (PD). The profile ID may indicate a unique identifier of each profile. The profile discriminator may include an address of a profile providing server (SM-DP +) capable of indexing a profile.

In the description, the eUICC ID may be an inherent identifier of the eUICC embedded in the terminal, and may be referred to as an EUICC Identifier (EID). Further, if the provisioning profile is already embedded in the eUICC, it can be the profile ID of the corresponding provisioning profile. Further, in an embodiment of the present disclosure, if the terminal and the eUICC chip are not separated from each other, it may be a terminal ID. Further, it may be referred to as a specific security domain of the eUICC chip.

In the description, the profile container may be referred to as a profile field. The configuration file container may be a secure domain.

In the description, an Application Protocol Data Unit (APDU) may be a message for interlocking a terminal with an eUICC. In addition, the APDU may be a message for the PP or PM to interlock with the eUICC.

In the description, the PPC may be a tool for performing mutual authentication, profile encryption, and signature between the profile providing server and the eUICC. The PPC may include one or more of a symmetric key, an RSA (Rivest Shamir Adleman) certificate and private key, an Elliptic Curve Cryptography (ECC) certificate and private key, a root Certificate Authority (CA), and a chain of certificates. Further, if a plurality of profile providing servers are provided, different PPCs for the plurality of profile providing servers may be stored in the eUICC or may be used.

In the description, the PMC may be a tool for performing mutual authentication, encryption of transferred data, and signature between the profile management server and the eUICC. The PMC may include one or more of a symmetric key, an RSA certificate and private key, an ECC certificate and private key, a root CA, and a certificate chain. Further, if a plurality of profile management servers are provided, different PMCs for the plurality of profile management servers may be stored in the eUICC or may be used.

In the description, reference may be made to an Application Identifier (AID). This value may be a discriminator to distinguish different applications in the eUICC.

In the description, an event may be a term commonly referred to as a profile download, remote profile management, or other profile or eUICC management/processing command. Profile download may be used in combination with profile installation. Further, the event type may be used as a term indicating whether a specific event is profile download or remote profile management, or as a term indicating whether a specific time is other profile or eUICC management/process command, and may be referred to as an operation type (or OperationType), an operation class (or OperationClass), an event request type, an event class, or an event request class.

In the description, the profile package may be used in combination with a profile or may be used as a term for a data object indicating a specific profile, and may be referred to as a profile TLV or a profile package TLV. If the Profile Package is encrypted using the encryption parameters, it may be referred to as a Protected Profile Package (PPP) or a Protected Profile Package TLV (PPP TLV). If the configuration Package is encrypted using encryption parameters that can only be decrypted by a particular Euicc, it may be referred to as a Bound Profile Package (BPP) or a Bound Profile Package TLV (BPP TLV). The profile package TLV may be a data set representing information constituting a profile in Tag, length, and Value (TLV) type.

In the description, remote Profile Management (RPM) may be referred to as Profile Remote Management, remote Management command, remote command, RPM package, profile Remote Management package, remote Management command package, or Remote command package. The RPM may be used to change the state of a particular profile (enable, disable, or delete) or update the content of a particular profile (e.g., profile nickname or profile metadata). The RPM may include one or more remote management commands, and in this case, profiles that are subjects of the respective remote management commands may be identical to each other or may be different from each other.

In the description, AKA may indicate authentication and key agreement, and may indicate an authentication algorithm for accessing third Generation Partnership project (3 rd Generation Partnership project,3 GPP) and 3GPP2 networks.

In the description, K is an encryption key value for the AKA authentication algorithm stored in the eUICC.

In the description, the OPc is a parameter value for the AKA authentication algorithm that can be stored in the eUICC.

In the description, the NAA is a network access application, and may be an application stored in the UICC to access the network, such as USIM or ISIM. The NAA may be a network access module.

In addition, in describing the present disclosure, if it is determined that a detailed description of a related known function or configuration obscures the subject matter of the present disclosure in unnecessary detail, it is omitted.

Fig. 1 is a diagram illustrating a method of a terminal connecting to a mobile communication network using a UICC embedded with a profile fixed to the terminal according to an embodiment of the present disclosure.

Referring to fig. 1, the uicc 120 may be inserted into the terminal 110. In this case, the UICC may be of a detachable type or may be embedded in the terminal in advance. The fixed profile of the UICC embedded with the fixed profile indicates that the "access information" that can access a particular communication service provider is fixed. The access information may be, for example, an International Mobile Subscriber Identity (IMSI) as a subscriber authenticator and a K or Ki value for authentication with the user authenticator in the network.

Then, the terminal may perform authentication with an authentication processing system (e.g., home Location Register (HLR) or AuC) of the mobile communication service provider using the UICC. The authentication procedure may be an Authentication and Key Agreement (AKA) procedure. If the authentication has been successful, the terminal may then use a mobile communication service, such as a phone call or the use of mobile data, using the mobile communication service provider network 130 of the mobile communication system.

In the following, reference will be made to a terminal 230 and a profile server 250. Terminal 230 may be terminal 110. The terminal 230 may include at least one of an LPA or an eUICC. Profile server 250 may include SM-DP +.

Fig. 2 is a diagram illustrating a message exchange procedure between the terminal 230 and the profile server 250 in case of installing one or more profiles through the profile server according to an embodiment of the present disclosure.

Referring to fig. 2, the terminal 230 may receive an "add profile" command from a user at operation 201, and it may perform TLS connection and mutual authentication with the profile server 250 at operation 203. At operation 205, the terminal may transmit the EID of the terminal to the profile server 250 as a final process of the mutual authentication process. At operation 207, the profile server may confirm the event list to be installed in the corresponding terminal through the EID. At operation 209, the profile server may select the event with the highest priority among the events in the list (profile 1 install in this embodiment). At operation 211, the profile server may send metadata for the selected profile to the terminal in a reply. At operation 213, the terminal may obtain user consent for the profile installation by accounting for the user's metadata of the profile. At operation 215, the terminal may transmit the user consent to the profile server and may receive the profile package. The terminal may successfully install the profile package at operation 217 and it may transmit the result to the profile server at operation 219.

According to the profile package installation process, if one or more events in the profile server are in a standby state, it is impossible to notify the terminal that other events in the standby state remain in the profile server after a specific event is executed and processed. In addition, it may cause inconvenience that a user should input an "add profile" command to a terminal in order to install one or more profiles.

Fig. 3 is a diagram illustrating a message exchange procedure between the terminal 230 and the profile server 250 in case of installing one or more profiles through the profile server and performing one or more remote profile managements according to an embodiment of the present disclosure.

Referring to fig. 3, the terminal 230 may receive an "add profile" command from a user at operation 301, and it may perform TLS connection and mutual authentication with the profile server 250 at operation 303. At operation 305, the terminal may transmit the EID of the terminal to the terminal server 250 as a final process of the mutual authentication process. At operation 307, the profile server may confirm a list of events (profiles or remote management) to be installed in the corresponding terminal through the EID. At operation 309, the profile server may select an event having the highest priority among the events in the list (in this embodiment, remote management 1). At operation 311, the profile server may transmit the selected remote management command to the terminal in reply. At operation 313, the terminal may execute the received remote management command. At operation 315, the terminal may transmit a result of executing the remote management command to the profile server.

According to the profile installation and remote management execution process, if one or more events in the profile server are in a standby state, it is impossible to notify that other events in the standby state of the terminal remain in the profile server after a specific event is executed and processed. In addition, although the user has input an "add profile" command to the terminal at operation 301, the terminal preferentially receives a remote management command from the profile server as an event having the highest priority, and performing an operation that goes against the user's intention may cause confusion to the user.

Fig. 4 is a diagram illustrating a method for specifying a type of an event corresponding to a command input by a user when the terminal 230 requests the event from the profile server 250 according to an embodiment of the present disclosure. Although case 1, case 2, and case 3 of fig. 4 illustrate respective independent embodiments, two or more cases may be performed in succession.

Referring to fig. 4, at operation 401, a terminal may receive an "add profile" command from a user. At operation 403, the terminal may complete TLS secure connection and mutual authentication with the profile server with respect to the user input, and may request an event from the profile server 250 by specifying an event type corresponding to the profile download. In this case, the event type may be displayed as text ("ProfileDownload" in this embodiment) or as a value of the corresponding enumeration. For example, if the enumerated value "0,1" corresponds to "profile download" and "remote profile management," the text "ProfileDownload" may be replaced with the number "0". Further, at operation 403, the terminal may notify the profile server whether the user currently activates (on) the remote profile management function of the terminal, or may notify the corresponding terminal of an identifier (OperatorID) of a service provider currently providing a communication service. At operation 405, the profile server may select a profile installation event having a high priority according to a request of the terminal. A method for the profile server to use the event type, the profile management function activation/deactivation, and the service provider identifier information, and a method for managing the priority of the event will be described in detail according to embodiments described later.

Further, referring to fig. 4, at operation 407, the terminal may receive a "refresh profile" command from the user. At operation 409, the terminal may complete TLS secure connection and mutual authentication with the profile server with respect to the user input and may request an event from the profile server 250 by specifying an event type corresponding to remote profile management. In this case, the event type may be displayed as text (in this embodiment, "RPM") or as a value of the corresponding enumeration. For example, if the enumerated value "0,1" corresponds to "profile download" and "remote profile management," the text "RPM" may be replaced with the number "1". Further, at operation 409, the terminal may inform the profile server whether the user currently activates (on) the remote profile management function of the terminal, or may inform the corresponding terminal of an identifier (OperatorID) of a service provider currently providing a communication service. At operation 411, the profile server may select a remote profile management event having a high priority according to a request of the terminal. A method for the profile server to use the event type, the profile management function activation/deactivation, and the service provider identifier information, and a method for managing the priority of the event will be described in detail according to embodiments described later.

Further, referring to fig. 4, the terminal may receive an "update all" command from the user at operation 413. At operation 4015, the terminal may complete TLS secure connection and mutual authentication with the profile server with respect to user input, and may request an event from the profile server 250 by specifying an event type corresponding to profile download and remote profile management. In this case, the event type may be displayed as text ("ANY" in this embodiment) or as a corresponding enumerated value or values, or a method used in embodiments of profile download or remote profile management by a composite application. For example, the text "ProfileDownload, RPM" may be used instead of the text "ANY", or the number "2" may be used if the enumerated value "0,1,2" corresponds to "profile download", "remote profile management", and "update all", or the enumerated value "0,1" may be used. Further, at operation 415, the terminal may notify the profile server whether the user currently activates (on) the remote profile management function of the terminal, or may notify the corresponding terminal of an identifier (OperatorID) of a service provider currently providing a communication service. At operation 417, the profile server may select an event (profile download or remote profile management) having a high priority according to a request of the terminal. A method for the profile server to use the event type, the profile management function activation/deactivation, and the service provider identifier information, and a method for managing the priority of the event will be described in detail according to embodiments described later.

Fig. 5 is a diagram illustrating a method of a profile server managing an event repository according to an embodiment of the present disclosure.

Referring to fig. 5, the profile server may manage an event memory distinguished by EID. In each event memory, one or more events (profile download or remote profile management) performed by the respective eUICC (or terminal) can be stored. Further, the events stored in the respective event memories may have their priorities, and the method for calculating the priorities may follow one or more of the following composite methods, but the events are not limited to the following list.

-the order of event registrations in the event memory.

-a priority value assigned when the service provider registers for the event.

Event type (e.g. profile download may have priority over remote profile management).

-a priority value optionally determined and assigned by the profile server.

If one or more events have the same priority, the profile server may rank the corresponding events in a particular order. In an embodiment of the present disclosure, it is illustrated that the priority of events is managed In a First-In First-Out (FIFO) type according to the order of event registration In an event memory. However, it is noted that the priority of the event may be calculated in various ways as described above.

Fig. 6A, 6B, 6C, and 6D are diagrams illustrating a method of determining whether a profile server can bundle a plurality of events in one message to perform a binding transmission in case the profile server transmits one or more events to a terminal according to an embodiment of the present disclosure.

Referring to fig. 6A, 6B, 6C, and 6D, the profile server may manage a table for determining whether a specific event type can be bundled with another event type for each event type to perform a binding transmission.

Referring to fig. 6A, regardless of the event type, the profile server may determine to bundle all events to perform a binding transfer.

Referring to fig. 6B, the profile server may be set to allow only the binding of the remote profile management event to perform the binding transmission, but may be set not to allow the binding of the profile download event or the binding of the profile download event and the remote profile management event to perform the binding transmission.

Referring to fig. 6C, the profile server may be set to allow only binding of the remote profile management event and the profile download event to perform the binding transfer, but may be set to disallow binding of the profile download event or disallow binding of the remote profile management event to perform the binding transfer.

Referring to fig. 6D, the profile server may not allow any event to be bound to perform a binding transfer.

In this embodiment, two types of events are exemplified, but as described above, if the number of event types is increased to three or more, the size of the table may be increased accordingly. Further, the determination of the type of event to be transmitted in the bundle is not limited to those shown in fig. 6A, 6B, 6C, and 6D, and it may be different depending on the combination of events to be transmitted in the bundle.

Fig. 7A, 7B, and 7C are diagrams illustrating a method of a profile server configuring information of a "current event" to be currently processed by a terminal and a "next event" in a standby state in an event memory when the profile server configures a response message to an event request message of the terminal including the "current event" and the "next event" according to an embodiment of the present disclosure.

Referring to fig. 7A, 7B, and 7C, the terminal 230 may transmit an event request message to the profile server 250 at operations 701A, 701B, and 701C. The configuration and detailed description of the event request message has been made with reference to the embodiment of fig. 4. With respect to the event request message of the terminal, the profile server may configure an event response message using information on one or more "current events" selected from the event memory according to the priority and the events remaining in the event memory (excluding the current event) at operations 703A, 703B, and 703C. In this case, the selection of the current event may be performed as follows according to the event type specified in the event request message of the terminal, the event memory state of the profile server, and whether the preferential transmission is allowed.

The profile server may manage a priority setting table for allowing whether a low priority event can be transmitted to the terminal before a high priority event according to a corresponding event type.

Referring to fig. 7B, if requested by the terminal, even if the profile download event has a priority lower than that of the remote profile management event, the profile download event may be set to be preferentially transmitted to the terminal, and in response to the request of the terminal, if the remote profile management event has a priority lower than that of the profile download event, the remote profile management event may be set not to be preferentially transmitted to the terminal. In this case, if the terminal specifically requests the Profile download event in a state where the event priorities in the event memory are arranged in order in the embodiment of the Profile server 250, the Profile download event Profile1 corresponding to the third priority may be selected more preferentially than the remote Profile management events RPM1 and RPM2 corresponding to the first and second priorities and may be transmitted to the terminal through the "current event" field. In this case, the remaining events RPM1, RPM2, RPM3, and Profile2 may be included in a "next event" to be transmitted to the terminal 230 according to an embodiment of fig. 8, which will be described later.

Referring to fig. 7C, it may be set that any event cannot be transmitted more preferentially than other events, except for the priority of the event. In this case, even if the terminal specifically requests the profile download event in a state where the event priorities in the event memory are arranged in order in the embodiment of the profile server 250, the remote profile management event RPM1 having the highest priority should be preferentially performed and the "current event" field becomes empty, so no event is transmitted to the terminal. In this case, the remaining events RPM1, RPM2, profile1, RPM3, and Profile2 may be included in a "next event" to be transmitted according to an embodiment of fig. 8, which will be described later.

In the various embodiments of fig. 7A, 7B and 7C, only one "current event" is selected according to the priority transmission setting, but it is noted that one or more events may be selected as described above for the embodiments of fig. 6A, 6B, 6C and 6D. For example, if in addition to the embodiment of fig. 7B, a binding transmission of the Profile download event is set to be possible as in the embodiment of fig. 6A, at operation 703B of fig. 7B, two Profile download events Profile1 and Profile2 may be simultaneously included in the "current event" field to be transmitted to the terminal 230.

Fig. 8 is a diagram illustrating a method of the profile server configuring information of a "next event" when the profile server configures a response message to an event request message including the "current event" to be currently processed by a terminal and the "next event" in a standby state in an event memory according to an embodiment of the present disclosure.

Referring to fig. 8, at operation 801, the terminal 230 may transmit an event request message to the profile server 250. The configuration and detailed description of the event request message has been made with reference to the embodiment of fig. 4. With respect to the event request message of the terminal, the profile server may configure an event response message using information on one or more "current events" selected from the event memory according to the priority and the events (excluding the current event) remaining in the event memory at operation 803. In this embodiment, as a selection of the current event, a case of selecting one remote management event RPM1 to be adapted to the request of the terminal is shown. However, as in the embodiments of fig. 6A, 6B, 6C, and 6D, one or more events may be selected according to whether the profile server can perform the binding transmission, and as in the embodiments of fig. 7A, 7B, and 7C, it is noted that an event type specified in the event request message of the terminal may be searched from the event memory, and the corresponding event may be transmitted more preferentially than the event having the highest priority. Further, the next event information may be compositely configured using one or more information elements as follows, but the available information elements are not limited thereto.

-the event type of the event with the highest priority among the remaining events.

-an event type of one or more remaining events.

-presence/absence of one or more remaining events.

-number of event types when the remaining events are classified by event type.

As an example, in the embodiment of fig. 8, in the case where only the event type of the event having the highest priority is transmitted in the reply, the event response message may be configured as follows.

-Current Events＝RPM1,Next Events＝“RPM”。

As another example, in the embodiment of fig. 8, in the case where the event types of all the remaining events are transmitted in the reply, the event response message may be configured as follows.

-Current Events＝RPM1，Next Events＝“RPM”，ProfileDownload，RPM，ProfileDownload"。

As yet another example, in the embodiment of fig. 8, in the case where the number of event types is transmitted in reply by classifying the remaining events by event type, the event response message may be configured as follows.

-Current Events＝RPM1,Next Events＝“RPM(2),ProfileDownload(2)”。

As yet another example, in the embodiment of fig. 8, in the case where one or more remaining events are replied to remain regardless of the event type, the event response message may be configured as follows.

-Current Events＝RPM1,Next Events＝TRUE。

In the above embodiment, the event type is displayed using text ("RPM" or "ProfileDownload"). However, as in the embodiment of FIG. 4 above, enumeration may be used in addition to text. Further, in the case of notifying the terminal that one or more events exist regardless of the event type, a binary recognizer (Boolean) having true/false instead of text or enumeration may be used.

Fig. 9 is a diagram illustrating a procedure in which a profile server configures an event response message for an event request message of a terminal with reference to event binding transmission and event priority transmission settings as described in various embodiments of fig. 6A, 6B, 6C, 6D, 7A, 7B, 7C, and 8 according to an embodiment of the present disclosure.

Referring to fig. 9, at operation 901, a profile server may receive an event request message from a terminal. The event request message may specify the type of event requested by the terminal according to the above-described embodiment of fig. 4 and whether the remote profile management function is currently activated/deactivated (on/off) in the terminal.

After performing operation 901 or if the confirmation at operation 913 fails, the profile server may arrange the events in an event memory corresponding to the eUICC of the terminal that has sent the event request message in order of priority according to the above-described fig. 5 at operation 903.

At operation 905, the profile server confirms whether the type of the event having the highest priority in the event memory is identical to the type of the event requested by the terminal at operation 901.

If the validation process at operation 905 has failed or the validation process at operation 909 has succeeded, the profile server determines whether an event corresponding to the type of event requested by the terminal according to the embodiments of fig. 7A, 7B and 7C described above can be transmitted more preferentially than the event with the highest priority in the event memory validated at operation 905 at operation 907.

If the confirmation at operation 907 has succeeded in the procedure, the profile server searches for an event having the highest priority among events consistent with the event types requested by the terminal in the event memory at operation 915.

If the confirmation process at operation 905 has succeeded or after the execution of operation 915, the profile server confirms whether the corresponding event is a remote profile management event and whether the remote profile management function of the terminal is currently inactive (off) in the event request message of the terminal received at operation 901 at operation 909.

If the validation process at operation 909 has failed, the profile server extracts the corresponding event from the event store and adds the corresponding event to the "current event" field as described above with respect to the embodiments of FIGS. 7A, 7B, and 7C.

After performing operation 911, at operation 913, the profile server confirms whether binding transmission of the corresponding event and other events is possible as described above with respect to the embodiments of fig. 6A, 6B, 6C, and 6D.

If the validation process at operation 913 has failed or the validation process at operation 907 has failed, at operation 917 the profile server configures the "next event" field as described above with respect to the embodiment of fig. 8.

After performing operation 917, the profile server may transmit an event response message composed of a "current event" and a "next event" to the terminal at operation 919. If the transmission of the event response message fails or a reply to the processing failure of the event response message is received from the terminal thereafter, the profile server may perform one or more recovery event extraction operations in the event memory at operation 911.

Fig. 10 is a diagram illustrating an example of a process in which the terminal 230 continuously receives one or more events from the profile server 250 to perform the received events according to an embodiment of the present disclosure.

In this embodiment, assuming that a profile corresponding to ICCID1 is installed/activated in a terminal, a remote profile management function of the terminal is activated (on), an event memory of a profile server is arranged in order of event registration time, a binding transmission of remote profile management events is impossible, but a binding transmission of profile download events is possible, a priority transmission of any event deviating from priority is impossible, and a "next event" is configured to describe only an event type of an event described in the event memory with the highest priority.

Referring to fig. 10, the terminal may receive a command for "add profile" from a user at operation 1001.

At operation 1003, the terminal may perform a TLS secure connection and mutual authentication procedure with the profile server and may request a profile download event from the profile server to accommodate the user's request as described above with respect to the embodiment of fig. 4.

At operation 1005, the profile server may notify the terminal that one or more remote profile management events are in a standby state with the profile download event ICCID2 as the event with the highest priority in the event memory as described above in accordance with the various embodiments of fig. 6A, 6B, 6C, 6D, 7A, 7B, 7C, 8, and 9.

At operation 1007, the terminal may install the configuration file ICCID2 according to the received configuration file download event.

At operation 1009, the terminal may transmit the execution result of the profile download event that has been completed, i.e., the profile installation result (ICCID 2 installation result), to the profile server.

At operation 1011, the profile server may notify the terminal that the event execution result has been successfully received. Further, the profile server may notify the terminal of the "next event" remaining in the event memory not only at operation 1005 but also at operation 1011. The two types of messages for notifying the "next event" are complementary, and the "next event" may be notified in two messages or in one of the two messages. If the "next event" is notified in both messages, the "next event" lists included in the two messages may be different from each other. As an example, if the priority of an event in the event memory of the profile server is changed during the execution of operations 1007 to 1009 after the message transmission at operation 1005, the "next event" list included in the message at operation 1011 may be changed.

At operation 1013, the terminal may again request the profile server to transmit an event to be executed next according to the "next event" list notified by the profile server in operations 1005 to 1011. If the TLS secure connection and mutual authentication procedure between the terminal and the profile server in operation 1003 is still valid during transmission of the retransmission request message, the terminal may omit the TLS secure connection and mutual authentication procedure with the profile server. Further, if necessary, the terminal may notify the user of an event to be requested from the profile server, and may transmit an event request message to the profile server after obtaining user's approval. If the user disagrees, the terminal may end the process without requesting additional events. Further, if an event to be executed next according to the "next event" list is a remote profile management event, an identifier of a profile that is a subject of the corresponding event is unclear, and thus the event request type EventReqType may be set as remote profile management, but the profile identifier may not be specified. The method of not specifying the profile identifier may send a NULL string or may not send the profile identifier field.

At operation 1015, the profile server may notify the terminal that one or more remote profile management events are in a standby state along with the remote profile management event (update ICCID 1) which is the event with the highest priority in the event store.

At operation 1017, the terminal may manage the profile (change the contents of the profile corresponding to ICCID 1) according to the received remote profile management event.

At operation 1019, the terminal may transmit the execution result of the remote profile management event that has been completed, i.e., the profile change result (ICCID 1 update result), to the profile server.

At operation 1021, the profile server may notify the terminal that the event execution result has been successfully received. Further, in the same manner as the procedure at operation 1011 described above, the profile server may notify the terminal of the "next event" remaining in the event memory not only at operation 1015 but also at operation 1021. For a detailed description of the configuration of the "next event" list, reference may be made to the description of operation 1011.

At operation 1023, in the same manner as the process at operation 1013 described above, the terminal may re-request an event to be executed next from the profile server according to the "next event" list notified by the profile server at operations 1015 to 1021. For a detailed description of TLS and secure connections and user consent, reference may be made to the description of operation 1013. Further, if the event to be executed next is a remote profile management event according to the "next event" list, the identifier of the profile that is the subject of the corresponding event is unclear, and thus the terminal may set the event request type EventReqType to all events "ANY" but may not specify the profile identifier ProfileID. With regard to the method of specifying all events, reference may be made to the embodiment of fig. 4 as described above. Further, it can be easily understood that the subsequent process may be performed by repeating the operations 1001 to 1023 as described above.

Fig. 11 is a diagram illustrating an example of a process in which the terminal 230 continuously receives one or more events from the profile server 250 to perform the received events according to an embodiment of the present disclosure.

In this embodiment, assuming that a profile corresponding to ICCID1 is installed/activated in a terminal, a remote profile management function of the terminal is activated (on), an event memory of a profile server is arranged in order of event registration time, a binding transmission of remote profile management events is possible, but a binding transmission of profile download events is not possible, a priority transmission of any event deviating from priority is not possible, and a "next event" is configured to describe the type and number of all events in the event memory.

Referring to fig. 11, at operation 1101, the terminal may receive a specific profile (ICCID 1 in this embodiment) selected by a user and may receive a command for "refreshing the profile".

At operation 1103, the terminal may perform a TLS secure connection and mutual authentication procedure with the profile server and may request a remote profile management event from the profile server to accommodate the user's request as described above with respect to the embodiment of fig. 4.

At operation 1105, the profile server may search for profile download events, which are events having the highest priority in the event memory according to the embodiments of fig. 6A, 6B, 6C, 6D, 7A, 7B, 7C, 8, and 9 as described above, and since the corresponding events are not consistent with the type of event requested by the terminal (remote profile management) and transmission of priority deviating from the priority is not possible, the profile server does not transmit any event, and the profile server may inform the terminal that one profile download event and three remote profile management events are in a standby state using the "next event" list.

At operation 1107, the terminal may inform the user who has commanded the refresh of the profile that it is currently not possible to refresh the profile and that adding the profile should be performed with priority, and may obtain user consent from the received "next event" list. If the user disagrees, the terminal may end the process without additional operations.

At operation 1109, the terminal may re-request the profile server to transmit a list of "next events" notified by the profile server at operation 1105 and an event to be executed next according to the user's consent received at operation 1107. If one or more of the TLS secure connection and mutual authentication procedures between the terminal and the profile server have ended during transmission of the re-request message at operation 1103 or the new event request message should be distinguished by a new transaction ID with respect to the policy of the profile server, the terminal may perform a new TLS secure connection and mutual authentication procedure with the profile server.

At operation 1111, the profile server may inform the terminal that three remote profile management events are in a standby state using the "next event" list and the profile download event ICCID2 of the event having the highest priority in the event memory, as described above according to the various embodiments of fig. 6A, 6B, 6C, 6D, 7A, 7B, 7C, 8 and 9. In this embodiment, immediate transmission of the profile package is shown in response to operation 1109. However, as described above, as shown in fig. 2, the profile metadata is preferentially transmitted at operation 211, the user's approval for the profile installation is again obtained at operation 213, and the profile package is transmitted to the terminal in case that the terminal requests the profile package from the profile server at operation 215. In this case, at operation 1107, additional user consent may be integrated with the user consent.

At operation 1113, the terminal may assemble the configuration file ICCID2 according to the received configuration file download event (more specifically, the configuration file package).

At operation 1115, the terminal may transmit the execution result of the profile download event that has been completed, i.e., the profile installation result (ICCID 2 installation result), to the profile server.

At operation 1119, the profile server may notify the terminal that the event execution result has been successfully received. Further, although not shown in the figure, at operation 1119 the profile server may repeat the "next event" list at operation 1111 in the same manner as in the embodiment of fig. 10, as described above.

At operation 1119, the terminal may re-request the profile server to transmit an event to be executed next according to the list of "next events" notified by the profile server at operation 1117, in the same manner as the process at operation 1109, as described above. For a detailed description of TLS and secure connections and user consent, reference may be made to the description of operation 1109. Further, if the event to be executed next is a remote profile management event according to the "next event" list, the identifier of the profile that is the subject of the corresponding event is unclear, and thus the terminal may set the event request type EventReqType to all events "ANY".

At operation 1121, the profile server may perform binding transmissions of other remote profile management events Enable ICCID2 and Disable ICCID1 and remote profile management event Update ICCID1, which is the event with the highest priority in the event memory, as described above in accordance with the various embodiments of fig. 6A, 6B, 6C, 6D, 7A, 7B, 7C, 8, and 9. Furthermore, the profile server may notify "no more" in the "next event" list since there are no events in the event memory that are in a standby state after the binding transmission of the corresponding remote profile management event. The notification of "no more" in the "next event" list may be performed using text as in this embodiment, using NULL data, using omission of the "next event" list itself, or using notification of the remaining events "0" with respect to all event types.

At operation 1123, the terminal may continuously process the received remote profile management event. Further, it can be easily understood that the subsequent process may be performed by repeating the operations 1101 to 1123 as described above.

Fig. 12 is a diagram illustrating an example of a process in which the terminal 230 continuously receives one or more events from the profile server 250 to execute the received events according to an embodiment of the present disclosure.

In this embodiment, assuming that a profile corresponding to ICCID1 is installed/activated in a terminal, a remote profile management function of the terminal is activated (on), an event memory of a profile server is arranged in order of event registration time, binding transmission of any event is impossible, but if the terminal requests, only a remote profile management event may be transmitted with priority over a profile download event, and a "next event" is configured to describe only an event type of an event having the highest priority in the event memory.

Referring to fig. 12, the terminal may select a specific profile (ICCID 1 in this embodiment) according to a user and may receive a command for "refreshing the profile" at operation 1201.

At operation 1203, the terminal may perform a TLS secure connection and mutual authentication procedure with the profile server and may request a remote profile management event from the profile server to accommodate the user's request as described above with respect to the embodiment of fig. 4.

At operation 1205, the profile server may search for profile download events, which are events having the highest priority in the event memory according to the embodiments of fig. 6A, 6B, 6C, 6D, 7A, 7B, 7C, 8 and 9 as described above, and may preferentially transmit events having the highest priority (update ICCID1 in this embodiment) among events in the event memory that are adapted to the event type requested by the terminal (remote profile management) since the corresponding events are not identical to the event type requested by the terminal (remote profile management) but a priority transmission deviating from the priority is possible. Furthermore, the profile server may inform the terminal that a profile download event, which is an event having the highest priority in the event memory, is in a standby state in addition to the corresponding event.

At operation 1207, the terminal may perform the received remote profile management event. Thereafter, reporting of the results of the execution of the remote profile management event may be omitted, if desired.

At operation 1209, the terminal may notify the user who has commanded the profile update that he is accustomed to performing "add profile" according to the received "next event" list after the profile update, and may obtain the user's consent. If the user does not agree, the terminal may end the procedure without any additional operations.

At operation 1211, the terminal may re-request the profile server to transmit an event to be executed next according to the list of "next events" notified by the profile server at operation 1205. If one or more of the TLS secure connection and mutual authentication procedures between the terminal and the profile server have ended during the transmission of the re-request message at operation 1203, or the new event request message should be distinguished by a new transaction ID regarding the policy of the profile server, the terminal may perform a new TLS secure connection and mutual authentication procedure with the profile server.

At operation 1213, the profile server may notify the terminal that two remote profile management events are in a standby state using the "next event" list and the profile download event ICCID2, which is the event with the highest priority in the event memory, as described above according to the various embodiments of fig. 6A, 6B, 6C, 6D, 7A, 7B, 7C, 8, and 9. In this embodiment, immediate transmission of the profile package in response to operation 1211 is shown. However, as described above, as shown in fig. 2, the profile metadata is preferentially transmitted in operation 211, the user's approval for the profile installation is again obtained in operation 213, and the profile package is transmitted to the terminal in case that the terminal requests the profile package from the profile in operation 215. In this case, additional user consent may be integrated with the user consent at operation 1209.

At operation 1215, the terminal may install the configuration file ICCID2 according to the received configuration file download event (more specifically, the configuration file package).

The terminal may transmit the execution result of the profile download event that has been completed, i.e., the profile installation result (ICCID 2 installation result), to the profile server at operation 1217.

At operation 1219, the profile server may notify the terminal that the event execution result has been successfully received. Further, although not shown in the figure, at operation 1219 the profile server may repeat the "next event" list at operation 1113 in the same manner as in the embodiment of fig. 10 described above.

At operation 1221, in the same manner as the procedure at operation 1211 described above, the terminal may re-request the profile server to transmit an event to be executed next according to the "next event" list notified by the profile server in operations 1213 to 1219. For a detailed description of TLS and secure connections and user consent, reference may be made to the description of operation 11211. Further, if the event to be executed next is a remote profile management event according to the "next event" list, the identifier of the profile that is the subject of the corresponding event is not clear, and thus the terminal may set the event request type EventReqType to all events "ANY".

At operation 1223, the profile server may notify the terminal that the remote profile management event is in a standby state using the "next event" list and the remote profile management event (ICCID 2 enabled) of the event having the highest priority in the event memory according to the various embodiments of fig. 6A, 6B, 6C, 6D, 7A, 7B, 7C, 8, and 9, as described above.

At operation 1225, the terminal may manage the profile (activate ICCID 2) according to the received remote profile management event. Further, the subsequent process may be performed by repeating operations 1201 to 1225 as described above.

Fig. 13 is a diagram illustrating a procedure in which the terminal 230 requests "profile download" from the profile server 250 in the case of installing a profile through the profile server and receives a response to the request, according to an embodiment of the present disclosure.

Referring to fig. 13, at operation 1301, the terminal 230 may send a specific character string "Chanllenge" to the profile server 250. Communications at operation 1301 may be protected over an HTTPS to TLS secure connection. At operation 1303, the profile server 250 may send the specific string "Challenge" and the signature of the server to the terminal 230. At operation 1305, the terminal 230 may send a terminal authentication request message to the profile server 250. Specifically, the terminal 230 may transmit information about the type (OperationType) of a specific event requested together with the signature of the terminal 230 to the profile server 250 using the terminal authentication request message. In this embodiment, a description will be made of a case where a profile in the event memory 270 of the profile server is in a standby state and a terminal requests a profile download (profile DL). At operations 1303 to 1305, a message exchange process between the terminal 230 and the profile server 250 may be referred to as a mutual authentication process. At operation 1307, the profile server 250 may transmit a terminal authentication response message to the terminal 230. Specifically, the profile server 250 may send a terminal authentication response message including the profile metadata and the one-time public key to the terminal 230 as a preparation for the profile download, as requested by the terminal 230 at operation 1305. The profile metadata may include information about the name of the service provider, the identity set by the service provider, and the billing system. At operation 1309, the terminal 230 may receive input of end user consent for the profile installation based on the profile metadata received at operation 1307. If the user agrees to this, the terminal may send the one-time public key to profile server 250 at operation 1311. At operation 1313, the terminal 230 and the profile server 250 may generate a session key through a combination of the one-time public key and the one-time private key corresponding to the public key, which are exchanged with each other at operations 1307 to 1311. At operation 1315, profile server 250 may send the profile packet encrypted using the session key generated at operation 1313 to terminal 230 in a reply. Thereafter, at operation 1317, the terminal 230 may decrypt and install the encrypted profile package.

In contrast to the remote profile management process that will be described later, the profile download process additionally utilizes one message exchange between the terminal 230 and the profile server 250, as described above at operations 1311 through 1315, in order to receive the profile package for the actual profile installation.

Fig. 14 is a diagram illustrating a procedure in which the terminal 230 requests "remote profile management" from the profile server 250 and receives a response to the request in the case of performing remote management through the profile server according to an embodiment of the present invention.

Referring to fig. 14, the terminal 230 may transmit a specific character string "Challenge" to the profile server 250 at operation 1401. Communications at operation 1401 may be secured over the HTTPS to TLS secure connection. At operation 1403, the profile server 250 may send a specific string "Challenge" to the terminal 230 along with the server's signature. At operation 1405, the terminal 230 may request the type of the specific event (OperationType) and the signature of the terminal from the profile server 250. In this embodiment, a case where the remote management command is in a standby state in the event memory 270 of the profile server and the terminal 230 requests the RPM will be explained. At operations 1403 through 1405, the message exchange process between the terminal 230 and the profile server 250 may be referred to as a mutual authentication process. At operation 1407, the profile server 250 may send a packet (RPM command packet) including the remote profile management command requested at operation 1405 to the terminal 230. At operation 1409, the terminal 230 may receive input of end user consent for profile management based on the remote profile management received at operation 1407. If the user agrees to do so, the terminal 230 may execute a remote profile management command at operation 1411.

In the remote profile management process, the terminal 230 may receive all remote profile management commands at operation 1407 and not additionally require one message exchange between the terminal 230 and the profile server 250 corresponding to operations 1311 to 1315 of fig. 13, as compared to the profile download process described above with reference to fig. 13.

Fig. 15 is a diagram illustrating a procedure in which the terminal 230 requests all types of events from the profile server 250 and receives a response to the request in the case of installing two profiles through the profile server and performing remote management twice according to an embodiment of the present disclosure.

Referring to fig. 15, the terminal 230 may transmit a specific character string "Challenge" to the profile server 250 at operation 1501. Communications at operation 1501 may be protected over an HTTPS to TLS secure connection. At operation 1503, the profile server 250 may send the specific string "Challenge" to the terminal 230 along with the signature of the server. At operation 1505, the terminal 230 can request the type of the specific event (OperationType) and the signature of the terminal from the profile server 250. In this embodiment, a description will be made regarding a case where two remote management commands and two profiles are in a standby state in the event memory 270 of the profile server and the terminal 230 requests ALL types (ALL). At operations 1503 through 1505, a message exchange process between the terminal 230 and the profile server 250 may be referred to as a mutual authentication process. At operation 1507, the profile server 250 may simultaneously transmit the remote profile management 1, the profile metadata 1, the remote profile management 2, and the profile metadata 2 requested by the terminal 230 at operation 1505. At operation 1509, the terminal 230 may receive input of end-user consent for profile management and installation based on remote profile management through the profile metadata received at operation 1507.

After operation 1509, the terminal 230 may perform a remote profile management and profile installation procedure if the user agrees. In this case, remote profile management (remote profile management 1 and remote profile management 2) may be performed immediately after operation 1509, whereas profile installation (profile metadata 1 and profile metadata 2) may be performed to install a protection profile package for each profile by additionally performing one message exchange between the terminal 230 and the profile server 250 as described in operations 1311 to 1355 of fig. 13. A detailed scheme in which the terminal 230 continuously performs remote profile management and profile installation will be described in detail with reference to fig. 16 and 17.

In addition, at operation 1507, the respective profile metadata and remote profile management data are accompanied by a signature of the profile server 250 for the terminal 230 to verify data integrity. In this case, if the method for generating the signature of the profile metadata and the signature (e.g., a digital signature algorithm and a digital certificate type for signature) for the remote profile management data are different from each other, the profile server 250 can support the terminal 230 to easily verify the signature and process the corresponding data by appropriately adjusting the signature generation and data deployment. The method for the profile server 250 to generate the digital signature and the deployment data will be described in detail with reference to fig. 18 to 21.

Fig. 16 is a diagram illustrating a method in which the terminal 230 continuously processes events after preferentially protecting data of all events according to an embodiment of the present disclosure.

Referring to fig. 16, the terminal 230 and the profile server 250 may perform mutual authentication at operation 1601. With respect to the mutual authentication of the terminal 230 and the operation request message, the description of operations 1503 to 1506 of fig. 15 may be referred to. At operation 1603, the profile server 250 may send remote profile management 1, profile metadata 1, remote profile management 2, and profile metadata 2 at the same time. At operation 1605, terminal 230 may receive input of terminal user consent for remote profile management and installation based on the remote profile management and profile metadata received at operation 1603. If the user agrees to this, the terminal 230 may request the profile package 1 and the profile package 2 corresponding to the profile metadata 1 and the profile metadata 2 and may receive them from the profile server 250 at operations 1607 to 1609. Thereafter, according to the data processing sequence specified by the profile server 250 at operation 1603, the terminal 230 may perform remote profile management 1 at operation 1611, install the profile package 1 at operation 1613, perform remote profile management 2 at operation 1615, and install the profile package 2 at operation 1617.

In the process as described above, the terminal 230 may collectively protect data for processing all types of events received at operation 1603 (i.e., a profile package for profile installation) at operations 1607 to 1609, and may perform remote profile management and profile installation according to the data processing order specified by the profile server 250 at operation 1603.

Fig. 17 is a diagram illustrating a method in which the terminal 230 protects and processes data of respective events in the order of event reception according to an embodiment of the present disclosure.

Referring to fig. 17, at operation 1701, the terminal 230 and the profile server 250 may perform mutual authentication. With respect to the mutual authentication and operation request message of the terminal 230, the description of operations 1503 to 1506 of fig. 15 may be referred to. At operation 1703, profile server 250 may send remote profile management 1, profile metadata 1, remote profile management 2, and profile metadata 2 simultaneously. At operation 1705, the terminal 230 may receive input of end user consent for remote profile management and installation based on the remote profile management and profile metadata received at operation 1703. If the user agrees to this, the terminal 230 may perform remote profile management 1 according to the data processing order specified by the profile server 250 at operation 1703, receive the profile package 1 corresponding to the profile metadata 1 at operation 1709, install the profile package 1 at operation 1711, perform remote profile management 2 at operation 1713, receive the profile package 2 corresponding to the profile metadata 2 at operation 1715, and install the profile package 2 at operation 1717 at operation 1707.

In the above procedure, the terminal 230 may preferentially perform remote profile management without protecting additional data for all types of events received at operation 1703, and it may perform profile installation by additionally protecting a profile package from the profile server 250 according to the data processing order specified by the profile server 250 at operation 1703, if necessary.

Fig. 18 is a diagram illustrating a method in which, when the profile server 250 transmits remote profile management and profile metadata regarding the messages of operation 1603 of fig. 16 to the profile server 250 of operation 1703 of fig. 17, the profile server 250 generates and attaches a separate signature to the corresponding remote profile management and profile metadata according to an embodiment of the present disclosure.

Referring to fig. 18, the profile server 250 may generate

digital signatures

1803 and 1811 with respect to remote profile management 1 data 1801 and remote profile management 2 data 1809. In addition, profile server 250 may generate

digital signatures

1807 and 1815 for profile metadata 1 data 1805 and profile metadata 2 data 1813. In this case, even if the profile server 250 does not specify the data processing order, the terminal 230 can process the data in the order in which the data is received from the profile server 250. In this embodiment, the terminal 230 may process data in the order of remote profile management 1, profile metadata 1, remote profile management 2, and profile metadata 2.

In the above configuration, each data is accompanied by a separately distinguished signature, and therefore it is advantageous that the profile server 250 uses an algorithm for generating a signature of each data and a digital certificate type differently.

Fig. 19 is a diagram illustrating a method in which, when the profile server 250 transmits remote profile management and profile metadata regarding the messages of operation 1603 of fig. 16 to the profile server 250 of operation 1703 of fig. 17, the profile server 250 generates and attaches a separate signature to the corresponding remote profile management and profile metadata, and specifies a data processing order, according to an embodiment of the present disclosure.

Referring to fig. 19, the profile server 250 may generate

digital signatures

1903 and 1911 with respect to remote profile management 1 data 1901 and remote profile management 2 data 1909. Further, profile server 250 may generate

digital signatures

1907 and 1915 for profile metadata 1 data 1905 and profile metadata 2 data 1913. In addition, profile server 250 may specify the data processing order. As an example, in this embodiment for sending four pieces of data, profile server 250 may specify the processing order of the data in the manner of four pieces of data: remote profile management 1 data 1901 is designated as first (1/4), profile metadata 1 data 1905 is second (2/4), remote profile management 2 data 1909 is third (3/4), and profile metadata 2 data 1913 is fourth (4/4).

In the above configuration, each data is accompanied by a separately distinguished signature, and therefore it is advantageous that the profile server 250 uses an algorithm for generating a signature of each data and a digital certificate type differently. Further, since each data specifies the processing order separately, it is advantageous that the profile server 250 can freely adjust the data transmission order. In this case, the embodiment in which the profile server 250 specifies the data processing order is not limited to fig. 19, and the data processing order may be specified even in the embodiment of fig. 18 in which data is processed in their reception order.

Fig. 20 is a diagram illustrating a method in which, when the profile server 250 transmits remote profile management and profile metadata regarding the messages of operation 1603 of fig. 16 to operation 1703 of fig. 17 of the profile server 250, the profile server 250 generates and appends a public signature to a portion of each remote profile management and profile metadata, according to an embodiment of the present disclosure.

Referring to fig. 20, the profile server 250 may generate a digital signature (i.e., a public signature) 2011 with respect to the entire remote profile management 1 data 2001 and remote profile management 2 data 2009. Further, profile server 250 can generate a digital signature (i.e., a co-signature) 2015 relating to the entire profile metadata 1 data 2005 and profile metadata 2 data 2013. In this case, even if the profile server 250 does not specify the data processing order, the terminal 230 can process the data in the order in which the data is received from the profile server 250. In this embodiment, the terminal 230 may process data in the order of remote profile management 1, profile metadata 1, remote profile management 2, and profile metadata 2.

In the above configuration, it is noted that the data for which the profile server 250 generates the public signature is not limited to the same type of data. For example, although fig. 20 shows a case where the public signature is generated by separating remote profile management and profile metadata, the profile server 250 may also generate the public signature with respect to data using the same signature generation method (i.e., signature generation algorithm and digital certificate). In the above configuration, since the signature can be omitted for the data sharing the signature, the amount of data transmitted from the profile server 250 to the terminal 230 can be reduced. In the configuration of fig. 20, the terminals 230 respectively collect data to be the object of signature so as to verify the signature after receiving the entire data of the profile server 250. In this embodiment, in order to verify the signature 2011, the terminal 230 should selectively collect the first received remote profile management 1 data 2001 and the third received remote profile management 2 data 2009, and in order to verify the signature 2015, the terminal 230 should selectively collect the second received profile metadata 1 data 2005 and the fourth received profile metadata 2 data 2013.

Fig. 21 is a diagram illustrating a part in which the profile server 250 generates and attaches a common signature to each remote profile management and profile metadata when the profile server 250 transmits the remote profile management and profile metadata with respect to the message of operation 1603 of fig. 16 to operation 1703 of fig. 17, and a method of designating a data processing order according to an embodiment of the present disclosure.

Referring to fig. 21, the profile server 250 may generate a digital signature (i.e., a public signature) 2111 with respect to the entire remote profile management 1 data 2101 and the remote profile management 2 data 2109. In addition, profile server 250 may generate digital signatures (i.e., public signatures) 2115 for the entire profile metadata 1 data 2105 and profile metadata 2 data 2113. In addition, profile server 250 may specify a data processing order. As an example, in this embodiment for sending four pieces of data, profile server 250 may specify the processing order of the data in the manner of four pieces of data: remote profile management 1 data 2101 is designated as first (1/4), profile metadata 1 data 2105 is second (2/4), remote profile management 2 data 2109 is third (3/4), and profile metadata 2 data 2113 is fourth (4/4).

In the same manner as in the case of fig. 20, in the configuration of fig. 21, it is noted that the data for which the profile server 250 generates the public signature is not limited to the same type of data. In the above configuration, since the signature can be omitted for the data sharing the signature, the amount of data transmitted from the profile server 250 to the terminal 230 can be reduced. Further, since the data specifies the processing order, the profile server 250 has an advantage that the data transmission order can be freely adjusted. For example, to eliminate the process of the terminal 230 selectively collecting data for signature verification in the embodiment of fig. 20, the profile server 250 may deploy remote profile management 1 data 2101 and remote profile management 2 data 2109 of the shared signature 2111 before the signature 2111, and may deploy profile metadata 1 data 2105 and profile metadata 2 data 2113 of the shared signature 2115 before the signature 2115. In this case, the terminal 230 may process data in the order of remote profile management 1, profile metadata 1, remote profile management 2, and profile metadata 2, which is a data processing order specified by the profile server 250 after the authentication of the

signatures

2111 and 2115.

It is noted that the signature generation and data deployment of the various embodiments of fig. 18-21 may be used in parallel with the processes of fig. 16 and 17. In this case, the processes of verifying the corresponding signatures of fig. 18 to 21 may be selectively performed once in the processes of fig. 16 and 17. Some detailed examples are as follows, but are not limited to the following examples. The verification process may be performed when signature verification is required.

FIG. 22 is a diagram illustrating an embodiment of a method of using the signature generation and data deployment of FIG. 18 in the process of FIG. 17, according to an embodiment of the disclosure.

In this case, the procedure and reference numerals as described above with reference to fig. 17 and 18 will be omitted, and it is assumed that the terminal 230 receives a message of a type such as 2290 from the profile server 250 at operation 2201. The terminal 230 may receive the end user consent at operation 2203, verify the signature at operation 2205, perform remote profile management 1 at operation 2207, verify the signature at operation 2209, receive the profile package 1 corresponding to the profile metadata 1 at operation 2211, install the profile package 1 at operation 2213, verify the signature at operation 2215, perform remote profile management 2 at operation 2217, verify the signature at operation 2219, receive the profile package 2 corresponding to the profile metadata 2 at operation 2221, and install the profile package 2 at operation 2223.

FIG. 23 is a diagram illustrating an embodiment of a method of using the signature generation and data deployment of FIG. 18 in the process of FIG. 16, according to an embodiment of the disclosure.

In this case, the procedure and reference numerals as described above with reference to fig. 16 and 18 will be omitted, and it is assumed that the terminal 230 receives a type of message such as 2390 from the profile server 250 at operation 2301. The terminal 230 may receive the end user consent at operation 2303, verify the signature at operation 2305, receive the profile package 1 corresponding to the profile metadata 1 at operation 2307, verify the signature at operation 2309, receive the profile package 2 corresponding to the profile metadata 2 at operation 2311, verify the signature at operation 2313, perform remote profile management 1 at operation 2315, install the profile package 1 at operation 2317, verify the signature at operation 2319, perform remote profile management 2 at operation 2321, and install the profile package 2 at operation 2323.

As described above, since the verification of the signature of the data received by the terminal 230 may be performed by the terminal 230 after the data is received, it may be performed before the process of receiving the input agreed by the terminal user. As an example, although not separately illustrated, in the case where the signature generation and data deployment method of fig. 21 is used in the process of fig. 16, the terminal 230 may verify the

signatures

2111 and 2115 of fig. 21 after operation 1603 of fig. 16, and may perform operation 1605 and subsequent operations of fig. 16.

As another example, although not separately illustrated, in the case where the signature generation and data deployment method of fig. 19 is used in the procedure of fig. 17, the terminal 230 may verify the signature 1903 of fig. 19, perform operation 1707 of fig. 17, verify the signature 1907 of fig. 19, perform operations 1709 to 1711 of fig. 17, verify the signature 1911 of fig. 19, perform operation 1713 of fig. 17, verify the signature 815 of fig. 19, and perform operations 1715 to 1717 of fig. 17.

Fig. 24A, 24B, 25, and 26 illustrate various embodiments of a method for the terminal 230 to configure a User Interface (UI) at operation 1605 or operation 1705 to receive input agreed upon by a terminal user in the processes of fig. 16 and 17, according to embodiments of the present disclosure.

Fig. 27 is a diagram illustrating an operation of a terminal according to a time-series flow according to an embodiment of the present disclosure.

Referring to fig. 24A, 24B, 25, and 26, it is assumed that the remote profile management 1 2710, the profile metadata 1 2730, the remote profile management 2 2750, and the profile metadata 2 2770 shown in fig. 27 are received. It is also assumed that profile 0 is installed and activated in the terminal 230, the remote profile management 1 2710 includes profile 0 updates 2711 and profile 0 remote commands to deactivate 2713, profile metadata 1 2730 includes data for profile1 installation 2731, the remote profile management 2 2750 includes remote profile1 updates 2751, profile1 remote commands to activate 2753 and delete 0 2755, and profile metadata 2 2770 includes data for profile2 installation 2771.

Referring to fig. 24A and 24B, if the terminal 230 receives data as shown in fig. 27, it may output a user interface to the user in the form indicated by 2401 of fig. 24A or 2403 of fig. 24B. In

messages

2401 and 2403, the terminal 230 can obtain the user consent through all processes of continuously outputting the data included in fig. 27. The order in which the corresponding processes are output may follow the order in which the corresponding processes are received by the terminal or the order in which the corresponding processes will be processed by the terminal 230. Consent to the corresponding process may be by examination of the individual user, as shown at 2401, or the user agrees to integrate the whole, as shown at 2403. In addition, although not separately shown in fig. 24A and 24B, the terminal 230 may additionally display a name, identification, and service fee of a service provider with respect to a profile that is a subject of a corresponding procedure, or may additionally output a user interface for receiving an input of a separate password or Personal Identification Number (PIN) set by a user or service provider.

Referring to fig. 25, if the terminal 230 receives data as shown in fig. 27, it may output a user interface to the user in the form indicated by 2501. In message 2501, terminal 230 may obtain user consent by classifying the processes included in the data of fig. 27 by the profile that is the subject of the respective process. Further, although not separately shown in fig. 25, in the same manner as the message 1301 of fig. 24A and 24B, the terminal 230 may request the individual user to agree to the setting of the process classified by the profile. Further, although not separately shown in fig. 25, the terminal may additionally display a name, identification, and service fee of a service provider with respect to a profile that is the subject of the corresponding procedure, or may additionally output a user interface for receiving input of a separate password or PIN set by the user or the service provider.

Referring to fig. 26, if the terminal 230 receives the data as shown in fig. 27, it may output a user interface to the user in the form indicated by 2601. In the message 2601, the terminal 230 may obtain the user consent by classifying and outputting the processes included in the data of fig. 27 by the types of the corresponding processes for obtaining the user consent. Further, although not separately shown in fig. 26, in the same manner as the message 2401 of fig. 24A and 24B, the terminal 230 may request the individual user to agree to the setting of the process classified by type. Further, although not separately shown in fig. 26, the terminal may additionally display a name, identification, and service fee of a service provider with respect to a profile that is the subject of the corresponding procedure, or may additionally output a user interface for receiving input of a separate password or PIN set by the user or the service provider.

It is to be noted that the user interfaces corresponding to fig. 24A, 24B, 25, and 26 may be applied to all embodiments of fig. 16 and 17 as described above. Thus, the user interfaces corresponding to fig. 24A, 24B, 25, and 26 may even be applied to the process of receiving user consent at operation 2203 or operation 2303 in the various embodiments of fig. 22 and 23.

Fig. 28 is a diagram illustrating a configuration of a terminal according to an embodiment of the present disclosure.

Referring to fig. 28, the terminal 2800 may include a transceiver 2810 and a processor 2820. Further, terminal 2800 can include a UICC 2830.UICC 2830 may be inserted into terminal 2800 or may be embedded in terminal 2800.

The transceiver 2810 can transmit and receive signals, information, and data.

On the other hand, the processor 2820 may control the overall operation of the terminal 2800. According to embodiments of the present disclosure as described above, the processor 2820 may control the overall operation of the terminal 2800.

In addition, the UICC2830 can download the configuration file and install the downloaded configuration file. In addition, the UICC2830 can manage configuration files. The UICC2830 can operate under the control of the processor 2820. Further, the UICC2830 can include a processor or a processor for installing a profile or can install an application therein.

Fig. 29 is a diagram illustrating constituent elements of a server 2900 according to an embodiment of the present disclosure. For example, server 2900 may be a profile server.

The server 2900 may include a transceiver 2910 and a processor 2920.

The transceiver 2910 may transmit and receive signals, information, and data. For example, the transceiver 2910 may transmit a configuration file to the terminal.

On the other hand, the processor 2920 is a constituent element for controlling the overall operation of the server 2900. The processor 2920 may control the overall operation of the server 2900 according to the embodiments of the present disclosure as described above.

In the detailed embodiments of the present disclosure as described above, constituent elements included in the present disclosure are expressed in a singular form or in a plural form according to the presented detailed embodiments. However, for convenience of explanation, the singular or plural expressions are selected to suit the proposed cases, and the present disclosure is not limited to a single or plural constituent elements. Even a constituent element in the plural expression may be expressed in the singular form, and even a constituent element in the singular expression may be expressed in the plural form.

While the disclosure has been shown and described with reference to various embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the disclosure as defined by the appended claims and their equivalents.

Claims

1. A method performed by a terminal in a wireless communication system, the method comprising:

sending a first message to a server, the first message comprising first information associated with the operation type requested by the terminal and a signature of a Universal Integrated Circuit Card (UICC) of the terminal, the first information indicating a profile download;

receiving a second message based on the first information from the server, the second message including first data for the profile download and a signature of the server for the first data, wherein the first data includes information indicating that a remote profile management RPM pack is in a standby state for the terminal;

sending a third message to the server, the third message comprising second information associated with the type of operation requested by the terminal and a UICC signature of the terminal, the second information indicating an RPM; and

receiving a fourth message based on the second information from the server, the fourth message including second data of the RPM and a signature of the second data by the server,

wherein the second data comprises the RPM packet and the RPM packet comprises an RPM command.

2. The method of claim 1, wherein the second data further includes information indicating that another RPM packet is in a standby state for the terminal.

3. The method of claim 1, wherein the RPM packet comprises a plurality of RPM commands, the plurality of RPM commands comprising an RPM command based on a priority of the plurality of RPM commands, and

wherein the method further comprises:

receiving a user agreed-to input for executing a plurality of RPM commands contained in an RPM package, the user agreed-to input being an integrated integral input of the RPM package; and

the operation is performed based on the input agreed by the user.

4. The method of claim 1, wherein in the event that more than one RPM command is on standby in the server, the priority of the more than one RPM command is determined based on a priority value assigned when a service provider registers an event, and

wherein the priority of the more than one profile download is determined based on a priority value assigned when the service provider registers the event, in case the more than one profile download is in a standby state in the server.

5. A terminal in a wireless communication system, the terminal comprising:

a transceiver; and

a controller configured to:

sending a first message to a server via the transceiver, the first message comprising first information associated with a type of operation requested by the terminal and a signature of a universal integrated circuit card, UICC, of the terminal, the first information indicating a profile download,

receiving, via the transceiver, a second message based on the first information from the server, the second message including first data for the profile download and a signature of the server for the first data, wherein the first data includes information indicating that a Remote Profile Management (RPM) pack is in a standby state for the terminal,

sending a third message to the server via the transceiver, the third message comprising second information associated with the type of operation requested by the terminal and a UICC signature of the terminal, the second information indicating an RPM, an

Receiving, via the transceiver, a fourth message based on the second information from the server, the fourth message including second data of the RPM and a signature of the second data by the server,

6. The terminal of claim 5, wherein the second data further includes information indicating that another RPM packet is in a standby state for the terminal.

7. The terminal of claim 5, wherein the RPM packet comprises a plurality of RPM commands, the plurality of RPM commands comprising an RPM command based on a priority of the plurality of RPM commands, and

wherein the controller is further configured to:

receiving user-agreed-to input for executing a plurality of RPM commands contained in an RPM package, the user-agreed-to input being an integrated integral input of the RPM package, and

the operation is performed based on the input agreed by the user.

8. The terminal of claim 5, wherein in the case where more than one RPM command is on standby in the server, the priority of the more than one RPM command is determined based on a priority value assigned when a service provider registers an event, and

9. A method performed by a server in a wireless communication system, the method comprising:

receiving a first message from a terminal, the first message comprising first information associated with a requested operation type of the terminal and a signature of a Universal Integrated Circuit Card (UICC) of the terminal, the first information indicating a profile download;

sending a second message to the terminal based on the first information, the second message including first data for the profile download and a signature of the server for the first data, wherein the first data includes information indicating that a Remote Profile Management (RPM) package is in a standby state for the terminal;

receiving a third message from the terminal, the third message including second information associated with the operation type requested by the terminal and a UICC signature of the terminal, the second information indicating an RPM; and

transmitting a fourth message based on the second information to the terminal, the fourth message including second data of the RPM and a signature of the second data by the server,

wherein the second data includes an RPM packet including an RPM command.

10. The method of claim 9, wherein the second data further includes information indicating that another RPM packet is in a standby state for the terminal.

11. The method of claim 9, wherein the RPM packet comprises a plurality of RPM commands, the plurality of RPM commands comprising an RPM command based on a priority of the plurality of RPM commands,

wherein operations corresponding to the plurality of RPM commands included in the RPM pack are performed based on user agreed-to inputs for performing the plurality of RPM commands, the user agreed-to inputs being an integrated integral input of the RPM pack,

wherein in case that more than one RPM command is in a standby state in the server, the priority of the more than one RPM command is determined based on a priority value allocated when the service provider registers an event, and

wherein in the event that more than one profile download is on standby in the server, the more than one profile download is prioritized based on a priority value assigned when the service provider registers the event.

12. A server in a wireless communication system, the server comprising:

a transceiver; and

a controller configured to:

receiving a first message from a terminal via the transceiver, the first message comprising first information associated with a type of operation requested by the terminal and a signature of a universal integrated circuit card, UICC, of the terminal, the first information indicating a profile download,

transmitting a second message based on the first information to the terminal via the transceiver, the second message including first data for the profile download and a server signature for the first data, wherein the first data includes information indicating that the remote profile management RPM pack is in a standby state for the terminal,

receiving a third message from the terminal via the transceiver, the third message including second information associated with a type of operation requested by the terminal and a UICC signature of the terminal, the second information indicating an RPM, and

transmitting a fourth message based on the second information to the terminal via the transceiver, the fourth message including second data of the RPM and a signature of the second data by the server,

wherein the second data includes an RPM packet including an RPM command.

13. The server of claim 12, wherein the second data further includes information indicating that another RPM packet is in a standby state for the terminal.

14. The server of claim 12, wherein the RPM packet comprises a plurality of RPM commands, the plurality of RPM commands comprising an RPM command based on a priority of the plurality of RPM commands,

wherein operations corresponding to the plurality of RPM commands included in the RPM package are performed based on user agreed-to input for performing the plurality of RPM commands, the user agreed-to input being an integrated integral input of the RPM package.

15. The server of claim 12, wherein in the event that more than one RPM command is on standby in the server, the priority of the more than one RPM command is determined based on a priority value assigned when a service provider registers an event, and