KR20240146514A - Method and apparatus of handling profile loading result in a wireless communication system - Google Patents

Abstract

The present disclosure relates to a 5G or 6G communication system for supporting higher data rates. A method performed by a base station in a wireless communication system, the method may include a control signal processing step, characterized by including: receiving a first control signal transmitted from the base station; processing the received first control signal; and transmitting a second control signal generated based on the processing to the base station.

Description

METHOD AND APPARATUS OF HANDLING PROFILE LOADING RESULT IN A WIRELESS COMMUNICATION SYSTEM

The present disclosure relates to a method and apparatus for provisioning a profile in a wireless communication system, and more particularly, the present disclosure relates to a method and apparatus for provisioning or deleting a plurality of profiles to eUICCs (embedded universal integrated circuit cards) of a terminal in a wireless communication system and providing a processing result therefor.

5G mobile communication technology defines a wide frequency band to enable fast transmission speeds and new services, and can be implemented not only in the sub-6GHz frequency band, such as 3.5 gigahertz (3.5GHz), but also in the ultra-high frequency band called millimeter wave (㎜Wave), such as 28GHz and 39GHz ('Above 6GHz'). In addition, for 6G mobile communication technology, which is called the system after 5G communication (beyond 5G), implementation in the terahertz band (for example, the 3 terahertz (3THz) band at 95GHz) is being considered to achieve a transmission speed that is 50 times faster than 5G mobile communication technology and an ultra-low delay time that is reduced to one-tenth.

In the early stages of 5G mobile communication technology, the goal is to support services and satisfy performance requirements for enhanced mobile broadband (eMBB), ultra-reliable low-latency communications (URLLC), and massive machine-type communications (mMTC). The technologies include beamforming and massive MIMO to mitigate path loss and increase transmission distance of radio waves in ultra-high frequency bands, support for various numerologies (such as operation of multiple subcarrier intervals) and dynamic operation of slot formats for efficient use of ultra-high frequency resources, initial access technology to support multi-beam transmission and wideband, definition and operation of BWP (band-width part), new channel coding methods such as LDPC (low density parity check) codes for large-capacity data transmission and polar codes for reliable transmission of control information, L2 pre-processing, and dedicated networks specialized for specific services. Standardization has been made on network slicing, etc.

Currently, discussions are underway on improving and enhancing the initial 5G mobile communication technology, taking into account the services that the 5G mobile communication technology was intended to support, and physical layer standardization is in progress for technologies such as V2X (vehicle-to-everything) to help autonomous vehicles make driving decisions and increase user convenience based on their own location and status information transmitted by the vehicle, NR-U (new radio unlicensed) for the purpose of system operation that complies with various regulatory requirements in unlicensed bands, NR terminal low power consumption technology (UE power saving), non-terrestrial network (NTN), which is direct terminal-satellite communication to secure coverage in areas where communication with terrestrial networks is impossible, and positioning.

In addition, standardization of radio interface architecture/protocols for technologies such as the industrial internet of things (IIoT) to support new services through linkage and convergence with other industries, integrated access and backhaul (IAB) to provide nodes for expanding network service areas by integrating wireless backhaul links and access links, mobility enhancement technologies including conditional handover and dual active protocol stack (DAPS) handover, and 2-step RACH for NR to simplify random access procedures is also in progress, and standardization of system architecture/services for 5G baseline architecture (e.g., service based architecture, service based interface) for grafting network functions virtualization (NFV) and software-defined networking (SDN) technologies, and mobile edge computing (MEC) that provides services based on the location of the terminal is also in progress.

When such 5G mobile communication systems are commercialized, an explosive increase in connected devices will be connected to the communication network, which will require enhanced functions and performance of 5G mobile communication systems and integrated operation of connected devices. To this end, new research will be conducted on improving 5G performance and reducing complexity using extended reality (XR), artificial intelligence (AI), and machine learning (ML) to efficiently support augmented reality (AR), virtual reality (VR), and mixed reality (MR), AI service support, metaverse service support, and drone communications.

In addition, the development of these 5G mobile communication systems will require the development of new waveforms for coverage guarantee in the terahertz band of 6G mobile communication technology, multi-antenna transmission technologies such as full-dimensional MIMO (FD-MIMO), array antennas, and large-scale antennas, metamaterial-based lenses and antennas to improve the coverage of terahertz band signals, high-dimensional spatial multiplexing technology using orbital angular momentum (OAM), and reconfigurable intelligent surface (RIS) technology, as well as full duplex technology for improving the frequency efficiency and system network of 6G mobile communication technology, satellite, and AI-based communication technology that utilizes artificial intelligence (AI) from the design stage and internalizes end-to-end AI support functions to realize system optimization, and next-generation distributed computing technology that realizes services with complexity that exceeds the limits of terminal computing capabilities by utilizing ultra-high-performance communication and computing resources. It could be the basis.

The technical challenge to be achieved in the present disclosure is to provide a device and method capable of effectively providing a service in a wireless communication system.

According to various embodiments of the present disclosure, a method performed by a terminal in a wireless communication system may include a control signal processing step, characterized by including: a step of receiving a first control signal transmitted from a factory IT; a step of processing the received first control signal; and a step of transmitting a second control signal generated based on the processing to the factory IT.

In addition, according to various embodiments of the present disclosure, in a method performed by factory IT in a wireless communication system, the method may include a control signal processing step characterized by including: a step of receiving a first control signal transmitted from a profile server; a step of transmitting the received first control signal to a terminal and causing the terminal to receive a result of processing; and a step of transmitting a second control signal generated based on the processing to the profile server.

In addition, according to various embodiments of the present disclosure, in a method performed by a profile server in a wireless communication system, the method may include a control signal processing step, characterized by including: a step of receiving a first control signal transmitted from a factory IT; a step of processing the received first control signal; and a step of transmitting a second control signal generated based on the processing to the factory IT.

The technical problems to be achieved in the embodiments of the present invention are not limited to the technical problems mentioned above, and other technical problems not mentioned will be clearly understood by a person having ordinary skill in the art to which the present invention belongs from the description below.

According to various embodiments of the present disclosure, a device and method capable of effectively providing a service in a mobile communication system can be provided.

The effects obtainable from the present disclosure are not limited to the effects mentioned in the various embodiments, and other effects not mentioned will be clearly understood by those skilled in the art to which the present disclosure belongs from the description below.

FIG. 1 is a diagram illustrating relationships between components for provisioning a profile according to one embodiment of the present disclosure.
FIG. 2 is an exemplary drawing of a method for returning an installation result when installing a profile according to one embodiment of the present disclosure.
FIG. 3 is a diagram illustrating an exemplary embodiment of a method for providing a BPP (Bound Profile Package) Loading Report according to an embodiment of the present disclosure.
FIG. 4 is a diagram illustrating an exemplary embodiment of a procedure for requesting and processing cancellation during profile loading in a Factory Profile Assistant (FPA) according to an embodiment of the present disclosure.
FIG. 5 is a block diagram showing the structure of a profile server (500), a factory IT (520), and a terminal (540) in a wireless communication system according to one embodiment of the present disclosure.
FIG. 6 is a diagram for explaining an operation of preparing a large number of profiles for In-Factory Profile provisioning (IFPP) according to one embodiment of the present disclosure.
FIG. 7 is a diagram illustrating an exemplary embodiment of a procedure for processing a message transmitted from an FPA to an eUICC before transmitting a loading message including a BPP from an FPA to an eUICC according to one embodiment of the present disclosure.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the attached drawings. At this time, it should be noted that in the attached drawings, the same components are indicated by the same symbols as much as possible. In addition, detailed descriptions of well-known functions and configurations that may obscure the gist of the present invention will be omitted.

In describing the embodiments in this disclosure, descriptions of technical contents that are well known in the technical field to which the present invention belongs and are not directly related to the present disclosure are omitted. This is to transmit the gist of the present disclosure more clearly without obscuring it by omitting unnecessary descriptions.

For the same reason, some components in the attached drawings are exaggerated, omitted, or schematically illustrated. In addition, the size of each component does not entirely reflect the actual size. The same or corresponding components in each drawing are given the same reference numbers.

The advantages and features of the present disclosure, and the methods for achieving them, will become apparent by referring to the embodiments described in detail below together with the accompanying drawings. However, the present disclosure is not limited to the embodiments disclosed below, but may be implemented in various different forms, and the embodiments are provided only to make the present disclosure complete and to fully inform those skilled in the art of the scope of the invention, and the present disclosure is defined only by the scope of the claims. Like reference numerals refer to like elements throughout the specification.

At this time, it will be understood that each block of the processing flow diagrams and combinations of the flow diagrams can be performed by computer program instructions. These computer program instructions can be loaded onto a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing equipment, so that the instructions executed by the processor of the computer or other programmable data processing equipment create a means for performing the functions described in the flow diagram block(s). These computer program instructions can also be stored in a computer-available or computer-readable memory that can be directed to a computer or other programmable data processing equipment to implement the function in a specific manner, so that the instructions stored in the computer-available or computer-readable memory can also produce a manufactured article including an instruction means for performing the functions described in the flow diagram block(s). Since the computer program instructions may also be installed on a computer or other programmable data processing apparatus, a series of operational steps may be performed on the computer or other programmable data processing apparatus to produce a computer-executable process, so that the instructions executing the computer or other programmable data processing apparatus may also provide steps for executing the functions described in the flowchart block(s).

Additionally, each block may represent a module, segment, or portion of code that contains one or more executable instructions for performing a particular logical function(s). It should also be noted that in some alternative implementation examples, the functions mentioned in the blocks may occur out of order. For example, two blocks shown in succession may in fact be performed substantially concurrently, or the blocks may sometimes be performed in reverse order, depending on their corresponding functionality.

Here, the term '~ part' used in the present embodiment means software or hardware components such as FPGA (field programmable gate array) or ASIC (application specific integrated circuit), and the '~ part' performs certain roles. However, the '~ part' is not limited to software or hardware. The '~ part' may be configured to be in an addressable storage medium and may be configured to reproduce one or more processors. Accordingly, as an example, the '~ part' includes components such as software components, object-oriented software components, class components, and task components, processes, functions, properties, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables. The functions provided in the components and '~ parts' may be combined into a smaller number of components and '~ parts' or further separated into additional components and '~ parts'. Additionally, the components and '~parts' may be implemented to regenerate one or more CPUs within the device or secure multimedia card.

Hereinafter, the base station is an entity that performs resource allocation of a terminal, and may be at least one of a Node B, a BS (base station), an eNB (eNode B), a gNB (gNode B), a wireless access unit, a base station controller, or a node on a network. The terminal may include a UE (user equipment), an MS (mobile station), a cellular phone, a smartphone, a computer, or a multimedia system capable of performing a communication function. In addition, the embodiments of the present disclosure may be applied to other communication systems having a similar technical background or channel form to the embodiments of the present disclosure described below. In addition, the embodiments of the present disclosure may be applied to other communication systems through some modifications without significantly departing from the scope of the present disclosure at the discretion of a person having skilled technical knowledge. For example, the 5th generation mobile communication technology (5G, new radio, NR) developed after LTE-A (long term evolution-advanced) may be included here, and the 5G below may be a concept that includes the existing LTE (long term evolution), LTE-A, and other similar services. In addition, the present disclosure may be applied to other communication systems through some modifications without significantly departing from the scope of the present disclosure, as judged by a person having skilled technical knowledge.

In the following description, terms used to identify connection nodes, terms referring to network entities or NFs (network functions), terms referring to messages, terms referring to interfaces between network objects, terms referring to various identification information, etc. are examples for convenience of explanation. Therefore, the present invention is not limited to the terms described below, and other terms referring to objects having equivalent technical meanings may be used.

For convenience of explanation below, some terms and names defined in the 3GPP (3rd generation partnership project) LTE (long term evolution) standard and/or the 3GPP NR (new radio) standard may be used. However, the present invention is not limited to the above terms and names, and may be equally applied to systems conforming to other standards.

For convenience of explanation below, the present disclosure uses terms and names defined in the remote SIM provisioning (RSP) specifications (SGP.XX series), which are standards defined by the GSMA (global system for mobile communications association, GSM association) among the existing eSIM standards. However, the present disclosure is not limited by the above terms and names, and can be equally applied to eSIMs conforming to other standards. A universal integrated circuit card (UICC) is a smart card inserted and used in a terminal, such as a mobile communication terminal, and is also referred to as a UICC card. The UICC may include an access control module for accessing the network of a mobile communication service provider. Examples of such an access control module include a universal subscriber identity module (USIM), a subscriber identity module (SIM), an Internet protocol multimedia service identity module (ISIM), etc.

Based on the above discussion, the present disclosure seeks to provide a method and device for installing profiles in an eUICC of a terminal in a factory environment of a manufacturer terminal in a wireless communication system.

The present disclosure can provide a method and device for effectively providing a result of processing one or more profiles in a terminal manufacturer factory environment to one eUICC in a wireless communication system.

A UICC with a USIM is commonly referred to as a USIM card. Similarly, a UICC with a SIM module is commonly referred to as a SIM card. It should be noted that in the following description, the term SIM card may be used in the general sense including a UICC card, a USIM card, a UICC with an ISIM, etc. Even if it is a SIM card, its technical application can be equally applied to a USIM card, an ISIM card, or a general UICC card.

SIM cards can store the personal information of mobile subscribers and perform subscriber authentication and traffic security key generation when connecting to a mobile network, thereby enabling secure mobile communication use.

SIM cards are generally manufactured as dedicated cards for mobile carriers at the request of a specific mobile carrier when manufacturing SIM cards, and authentication information for network access of the carrier, such as USIM (universal subscriber identity module) application and IMSI (international mobile subscriber identity), K value, OPc value, etc., are pre-loaded onto the card before shipment. Accordingly, the manufactured SIM card is delivered to the mobile carrier and provided to the subscriber, and if necessary, management such as installation, modification, and deletion of applications in the UICC can also be performed by utilizing technologies such as OTA (over the air).

Subscribers can use the network and application services of mobile communication service providers by inserting a UICC card into their mobile terminals. In addition, when replacing a mobile terminal, subscribers can use authentication information, mobile phone numbers, and personal phonebooks stored in the UICC card as they are on the new mobile terminal by moving and inserting the UICC card from the existing mobile terminal to the new mobile terminal.

However, SIM cards can be inconvenient for mobile terminal users to receive services from other mobile carriers. Mobile terminal users may experience the inconvenience of having to physically obtain a SIM card to receive services from mobile carriers. For example, when traveling to another country, there may be the inconvenience of having to obtain a local SIM card to receive local mobile services. Roaming services can solve some of the inconvenience, but there may also be problems such as high fees and inability to receive services if there is no contract between mobile carriers.

Meanwhile, if a SIM module is downloaded remotely and installed on a UICC card, this inconvenience can be significantly resolved. For example, a user can download a SIM module of a mobile communication service that he or she wants to use at a desired time onto a UICC card. This UICC card can also download and install multiple SIM modules and select and use at least one SIM module among them. This UICC card can be fixed or not fixed to a terminal. A UICC fixed and used on a terminal is usually called an eUICC, but in the present disclosure, a UICC card that can download and select a SIM module remotely can be collectively referred to as an eUICC. That is, among the UICC cards that can download and select a SIM module remotely, a UICC card that is fixed to a terminal and a UICC card that is not fixed can be collectively referred to as an eUICC. In addition, the downloaded SIM module information can be collectively referred to as a profile. Examples of profiles can be further categorized by purpose, such as provisioning profiles, which are restricted to initial setup (e.g., only allowing profile server access), operational profiles, which do not have such restrictions, and test profiles, which are restricted to testing purposes. Provisioning profiles may also be referred to as bootstrap profiles.

In order to install a profile in an eUICC, it is generally assumed that the terminal user downloads the profile through a real-time network connection with the profile download server after the terminal is released. Currently, according to the remote Profile provisioning standards, which are eSIM standardization standards defined by the GSMA, such as SGP.21/22, a remote SIM provisioning standard for consumer terminals, SGP.31/32, a remote SIM provisioning standard for IoT terminals, and SGP.01/02, a remote SIM provisioning standard for M2M terminals, the terminal can be defined as a process in which a terminal is connected to a profile download server in real-time through a network, messages are exchanged between the terminal and the profile server multiple times, and common mutual authentication is performed during this process to download a profile. However, the terminal cannot always assume that the network is connected to the profile download server at the time of downloading the profile. Therefore, in order to resolve this, a provisioning profile, which is a limited-purpose profile that provides only connectivity for initial setup to the terminal, was introduced in SGP.21/22. Accordingly, terminal manufacturers may ship eUICCs with provisioning profiles loaded. In addition, it may be possible for manufacturers to pre-load operational profiles of telecommunications service providers that do not have usage restrictions as mentioned above into eUICCs based on contracts with service providers.

In addition, there may be cases where support is required to change and re-inject the installed profile after the initial installation of the business profile on the eSIM terminal at the factory due to reasons such as a change in the business order or a refurbished terminal. In addition, there may be cases where support is required to provide a large amount of profile installation or deletion processing information generated from individual terminals (FPA or eUICC) to the profile server. The present invention may attempt to solve the following problems.

Meanwhile, a new work item for provisioning profiles to terminals at the factory has recently been approved by the GSMA (GSM Association, a telecommunications operator association), and discussions on standardization of devices and methods for provisioning profiles to terminals at the factory will be held as SGP.41 (technical requirements specification) and SGP.42 (technical specification (planned)).

In the present disclosure, the function for provisioning a profile in a factory is referred to as an IFPP (in factory Profile provisioning) function, and when entering a state supporting the IFPP function, it can be indicated as entering the IFPP mode or the IFPP state. Alternatively, "f" may be additionally added to the end of the name of each entity to indicate that it is operating in the IFPP mode. For example, specific entities such as a terminal, an LPA (local profile assistant), an eUICC, a profile server, a factory IT, an SP (service provider) server, and an EUM (eUICC manufacturer) server may be entities that further support the IFPP mode, or may be entities that only support the IFPP function. For example, SM-DP+, which is one of the profile servers, may be a server that supports the consumer-oriented remote SIM provisioning function defined in SGP.21/22, but additionally supports some of the IFPP functions defined in SGP.41/42. Alternatively, SM-DP+, which is a profile server, may be a profile server that only supports the IFPP function. A profile server operating in IFPP state may also be referred to in this disclosure as, for example, profile serverf, SM-DPf.

In the present disclosure, a UICC (universal integrated circuit card) is a smart card that is inserted into a mobile communication terminal and used, and stores personal information such as network access authentication information, a phone book, and SMS (short message service) of a mobile communication subscriber, and performs subscriber authentication and traffic security key generation when accessing a mobile communication system such as GSM, WCDMA (wideband code division multiple access), LTE, and 5G, thereby enabling safe use of mobile communication. Depending on the type of mobile communication network to which the subscriber is accessing, a UICC may be loaded with communication applications such as a SIM (subscriber identification module), a USIM (universal SIM), and an ISIM (IP multimedia SIM), and may also provide a higher level security function for loading various application programs such as an electronic wallet, ticketing, and an electronic passport.

In the present disclosure, the eUICC (embedded UICC) is not limited to a security module embedded in a terminal, and may include a removable security module that can be inserted and removed from the terminal. The eUICC can download and install a profile in real time or non-real time via a wired or wireless network. The eUICC can be referred to as a UICC capable of downloading and installing profiles. In the case where the eUICC installs a profile in a factory environment where real-time communication with the outside is difficult, the SM-DPf server that created the profile can be configured separately as a device that injects the profile into the eUICC via wired or wireless from the factory IT/OEM (original equipment manufacturer).

The method of downloading and installing a profile on an eUICC in the present disclosure can also be applied to a removable UICC that can be inserted and removed from a terminal as described above. For example, the embodiment of the present disclosure can be applied to a removable UICC that can download and install a profile. In the present disclosure, the eUICC unique identification number (eUICC ID) can be referred to as EID. The UICC referred to in the present disclosure can be used interchangeably with SIM, and the term eUICC can be used interchangeably with eSIM.

In the present disclosure, a profile may mean an application, a file system, an authentication key value, etc. stored in a UICC, packaged in software form. In addition, a profile may be named as connection information. In addition, a USIM profile in the present disclosure may mean information included in a USIM application in the profile that has the same meaning as a profile or that is packaged in software form. In the present disclosure, a profile package or an encrypted profile package (bound Profile package, BPP) may be used interchangeably with a profile or as a term indicating a data object of a specific profile, and may be named a profile TLV (tag, length, value) or a profile package TLV. A profile identifier may be referred to as an integrated circuit card identifier (ICCID) indicating a unique identification number of a profile. If a profile package is encrypted using an encryption parameter, it may be named a protected Profile package (PPP) or a protected profile package TLV (PPP TLV). When a profile package is encrypted using encryption parameters that can only be decrypted by a specific eUICC, it may be named a bound Profile package (BPP) or bound Profile Package TLV (BPP TLV). A profile package TLV may be a data set representing information that constitutes a profile in the TLV (tag, length, value) format.

In the present disclosure, a profile server is a server that provides a function of generating a profile, encrypting a generated profile, storing a generated profile, generating a profile remote management command, encrypting a generated profile remote management command, or providing an IFPP mode, and may be expressed as SM-DP (subscription manager data preparation), SM-DP+ (subscription manager data preparation plus), or SM-SR (subscription manager secure routing). As mentioned above, a profile server that operates by providing an IFPP function in the present invention can be used as SM-DPf.

The term 'terminal' or 'device' used in the present disclosure may refer to a mobile station (MS), a user equipment (UE), a mobile equipment (ME), a user terminal (UT), a wireless terminal, an access terminal (AT), a terminal, a subscriber unit (SS), 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 telephone, a smart phone having a wireless communication function, a personal digital assistant (PDA) having a wireless communication function, a wireless modem, a portable computer having a wireless communication function, a photographing device such as a digital camera having a wireless communication function, a gaming device having a wireless communication function, a music storage and playback home appliance having a wireless communication function, an Internet home appliance capable of wireless Internet access and browsing, as well as portable units or terminals incorporating combinations of such functions. In addition, the terminal may include an M2M (machine to machine) terminal, an MTC (machine type communication) terminal/device, and an IoT terminal/device depending on the performance characteristics supported. In the present disclosure, the terminal may also be referred to as an electronic device or simply a device. A terminal (120) that provides a function of installing a profile with an eUICC may also be referred to as an eSIM terminal.

In this disclosure, EUM refers to an eUICC manufacturer, a manufacturer that produces eUICCs and provides them by personalizing eUICCs, and information transmitted by EUM can be transmitted online or offline through a channel between an EUM server or separate components. According to an embodiment of the present disclosure, EUM may refer to an EUM server or a role performed by an EUM.

In the present disclosure, a terminal or device may include software or an application installed in the terminal or device to control a UICC or eUICC. The software or application may be, for example, an application such as a local Profile assistant (LPA), a SIM manager, or an IoT Profile assistant (IPA). The software or functions may be provided in an integrated manner. For example, LPA and IPA may be provided as a single integrated app. In the present disclosure, when software or an application installed in a terminal or device to control a UICC or eUICC operates as an IFPP function, it may be collectively referred to as FPA or LPAf.

In the present disclosure, an APDU (application protocol data unit) may be a message format or message that a controller in a terminal or device exchanges with an eUICC. An APDU is a pair of a command and a response, and an APDU command and an APDU response may be defined in ETSI 102.221 with reference to ISO 7816. As defined in ETSI 102.221, an APDU command has a structure of a CLA (class of instruction), INS (Instruction), P1 (instruction parameter 1), P2 (instruction parameter 2) as a header of the APDU, and Lc (number of bytes in the command data field), data, Le (number of bytes expected in response of the command) as a body, and an APDU response has a structure of an optional data field, SW1 (status byte 1), SW2 (status byte 2), and a detailed description thereof may refer to the ETSI 102.221 standard. Application messages transmitted from LPA or terminals can be transmitted to eUICC in the form of APDU, and the information transmitted at this time can be included in the data of the APDU and transmitted.

In the present disclosure, AKA may represent authentication and key agreement, and may represent an authentication algorithm for accessing 3GPP and 3GPP2 networks. K is an encryption key value stored in an eUICC used for the AKA authentication algorithm, and OPc in the present disclosure may be a parameter value that may be stored in an eUICC used for the AKA authentication algorithm.

In the present disclosure, NAA is a network access application, which may be an application such as USIM or ISIM stored in a UICC for accessing a network. NAA may be a network access module.

In the present disclosure, end user, user, subscriber, service subscriber, and user may be used interchangeably as a user of a terminal.

In the present disclosure, the factory IT refers to a device that handles provisioning specific data or settings to a terminal in a manufacturing process, and may refer to a module that includes a function for downloading a profile to the terminal, and may further include a function for acquiring and storing profiles from a profile server, or may be a device that can perform a function for collecting profile processing results and transmitting them. The factory IT may be used interchangeably with factory IT equipment, a factory IT server, factory provisioning equipment, a factory server, an OEM, and a terminal manufacturer, and even if expressed as a server hereinafter, the factory IT in the present invention may also be composed of one or more modules, for example, a server that acquires and collects or stores or processes data and transmits it, and a terminal that injects settings or data or obtains processing results at a contact point with an eSIM terminal.

In the present disclosure, OEM may be used interchangeably with terminal manufacturer and manufacturer. Some of the various devices of the OEM in the present disclosure may be connected wirelessly only within the manufacturer and may not allow an external network. For example, a data storage server used for a manufacturing process or a communication device that injects a profile into a terminal may not provide a network connection with the outside of the manufacturer and may be connected only to an internal network. The profile storage server within the manufacturer may be the same device as the server that responds with a profile BPP Loading Report to the outside or may be another device. In the present disclosure, factory IT/OEM may be described as one or more devices that install a profile on a terminal at a manufacturer factory and respond with a BPP Loading Report.

In this disclosure, the BPP Loading Report, Profile Loading Report, and Profile Loading Report can be described as reports created by a terminal manufacturer by collecting processing results generated and returned by an eUICC after the terminal manufacturer installs, deletes, etc. profiles acquired from SM-DPf on the terminal.

In the present disclosure, the Profile Order ID is an identification ID for specific profile orders, which can be generated by a profile server vendor and shared with a terminal manufacturer upon a profile order request from a communication service provider or a communication service provider. The Profile Order ID is defined as a unique value between MSP-SM-DPf, and can be utilized as information by which SM-Yellow can determine which order a profile mapped to is requested by a terminal manufacturer by presenting the Profile Order ID. An example of the notation of the Profile Order ID may be expressed as a combination of 0-9, A-Z, and "-" in hexadecimal. In the present disclosure, a service provider (SP) may be used interchangeably with a communication service provider (MSP, mobile service operator), an MNO (mobile network operator), a mobile network operator, an operator, a communication company, and an (M)SP server, and depending on the embodiment, a service provider may mean a server of a service provider or a role performed by a service provider.

In this disclosure, a server vendor means a vendor that operates a profile server, and may mean a role performed by a profile server vendor.

In this disclosure, the encryption key is used to encompass all encryption and decryption keys. For example, it may include a private key used to encrypt data or a public key used to decrypt it, and the public key may be shared in the form of a certificate.

In the present disclosure, otSK.EUICC.KA to otPK.EUICC.KA represent one time secret key (otSK) of eUICC and one time public key (otPK) of eUICC defined in SGP.22, and KA may mean key agreement. In the present disclosure, a one-time encryption key pair or a one-time eUICC encryption key pair may mean otSK.EUICC.KA and otPK.EUICC.KA. The secret key is used interchangeably as a secret key or a private key, and the public key is used interchangeably as a public key.

In the present disclosure, key material necessarily includes otPK.EUICC.KA and may represent encryption key data information for one-time profile installation on a specific eUICC as eUICC information that further includes an eUICC certificate chain or, and capability information such as eUICC info. otPK.EUICC.KA in the key material may be transmitted as signed data of the eUICC. If transmitted as signed data of the eUICC, a profile server that generates a profile using it may need to verify the signed data by checking whether it has the same root of trust certificate. In the description of the drawing below, key material may be used interchangeably with key information and encryption key information.

The present disclosure provides a method and device for enabling shipment by inserting a profile into a terminal including an eUICC.

In particular, the present disclosure is intended to provide a method and device for supporting collecting the results of processing a profile in a factory and providing the same to a profile server. Currently, SGP.22 to SGP.32 process the results of processing the profile on the assumption that they are processed and returned on a 1:1 basis based on real-time connection between a profile server (SM-DP+) and a terminal, and therefore, a large number of profile processing results cannot be efficiently acquired and transmitted.

In addition, currently, multiple round trip messages are required between the terminal and the profile server (SM-DP+) for a processing result reply. The present disclosure is directed to a method and device for overcoming the difficulty of performing a process of exchanging messages in multiple round trips, including a procedure for real-time network connection and mutual authentication between the profile server and individual terminals, due to the characteristics of the factory environment in which profile injection and acquisition of the results for injection are required for terminals in a large-scale terminal process, and for quickly processing profiles for a large number of terminals and obtaining the corresponding results. In addition, since real-time connection between the profile server and the terminals is not considered, a method for transmitting and verifying, installing, and verifying the installation result of the profile encryption key considering "non-real-time" between the profile server (e.g., SM-DPf) - eUICC may be required.

According to various embodiments of the present disclosure, a terminal manufacturer can pre-install a large number of profiles on an eSIM terminal and ship them without a real-time connection with a profile server. In addition, the terminal manufacturer can support shipment by re-injecting installed profiles that have been changed due to returns, changes in business orders, etc., thereby efficiently managing inventory. In addition, the terminal manufacturer can provide transparency on the processing results and use them for settlement by providing such profile processing in the form of a BPP Loading Report that can be verified by SM-DPf.

In addition, according to various embodiments of the present disclosure, a user can directly connect to a network by purchasing a terminal on which a profile is already installed, thereby eliminating the inconvenience of having to go to a Wi-Fi or mobile network to download a profile, thereby increasing user convenience.

In addition, according to various embodiments of the present disclosure, a telecommunications operator can provide a terminal to a user with a provisioning Profile for downloading the operator's profile or an operational Profile installed for immediate use of the operator's network service, thereby improving the user's convenience in using eSIM.

The examples below describe the procedures for injecting profiles at the factory and shipping them out. It should be noted that, at a certain point after the profiles are injected at the factory and shipped out, a terminal user may also provision and install the profiles in a general user environment outside the factory according to the procedures defined in SGP.21/22. That is, the examples below describe provisioning in a factory-installed environment, and it can be made clear that this does not mean that profile installation in a general environment after factory shipment is impossible.

FIG. 1 is a diagram showing the relationship between components for supporting In-Factory Profile Provisioning according to one embodiment of the present disclosure.

Referring to FIG. 1, a profile server/server vendor (hereinafter, referred to as a profile server or server vendor) (100) may support a function of generating a profile for IFPP, storing a profile generated for IFPP, or encrypting a profile generated for IFPP. In addition, it may support a function of generating a profile to be generally used in the field as defined in SGP.22. The profile server/server vendor (100) may support a function of storing a generated profile. The profile server/server vendor (100) may provide a function of encrypting a generated profile. The profile server/server vendor (100) may include a function of generating a remote profile management command (RPM) or encrypting a generated profile remote management command. The profile server/server vendor (100) may also support a function of transmitting a generated profile to an eSIM terminal or another profile storage server. RPM may collectively refer to a series of procedures in which profile installation, activation, deactivation, deletion, and other functions are performed by commands transmitted from a profile server/server vendor (100) to a terminal (120). RPM may be requested by a telecommunications carrier, a service provider, or a terminal owner, and the command may be generated by the profile server/server vendor (100).

The profile server/server vendor (100) can receive a profile order request from an SP (service provider)/SP server (hereinafter, referred to as SP or SP server) (150) and determine whether the request is for profile creation for IFPP. The profile server/server vendor (100) can combine profile order information received from a factory IT server/OEM (hereinafter, referred to as factory IT, factory server, or OEM) (110) or SP/SP server (150) with ordered EID information to map the profile and EID and prepare it in the profile server/server vendor (100). The SP/SP server (150) can receive a profile order request received from a factory IT server/OEM (110) and determine whether the request is for providing an order for profiles for IFPP. After determination, the SP/SP server (150) can place an order for provision of profiles to the profile server/server vendor (100), thereby causing the profile server/server vendor (100) to provide one or more BPPs (bound Profile packages) to the factory IT/OEM (110).

The terminal (120) may include an eUICC (140) and a communication modem (not shown). The communication modem may be equipped with one or more baseband processors (hereinafter, baseband) for wireless communication. The communication modem may be referred to as a communication unit or a transceiver unit. The terminal (120) may provide a function of receiving BPP(s) generated for IFPP from a factory IT/OEM (110) and installing the BPP(s) into the eUICC (140). The terminal (120) may transmit the BPP to the eUICC (140), and may transmit it to the eUICC (140) via the FPA (130) or may transmit it to the eUICC (140) without going through the FPA (130). The transmitted messages may include, together with the BPP, parameters included in or added to the BPP, specifically. This is detailed in step 675 described in Fig. 6.

As an example of methods for transmitting a message for BPP installation and encryption key information transmitted to eUICC (140) using FPA (130), the method may include, but is not limited to, a method of being transmitted by being included in one or more messages starting with ES10x. In case of transmission without going through FPA, the message may be transmitted as the body of the data as data of APDU such as STORE DATA.

Meanwhile, although the profile server/server vendor (100) is expressed as one in Fig. 1, there may be multiple profile servers/server vendors (100). The factory IT/OEM (110) can receive and store BPPs from multiple profile servers/server vendors (100).

As described above, FPA (130) may be eUICC control software or application supporting IFPP function. FPA (130) may also be implemented as a logical function of terminal (120) or eUICC (140). FPA (130) may receive additional authentication information for authenticating profile and profile server/server vendor (100) from factory IT/OEM (110) and provide the same to eUICC (140). FPA (130) may perform a role of acquiring profile installation result from eUICC (140) and transmitting it to factory IT/OEM (110).

The eUICC (140) can determine whether one or more messages of ES10x received from the FPA (130) or a profile installation message received through an application or software for factory settings of the factory IT (110) or the terminal are requests for profile installation at the factory, and decide to enter the IFPP mode. If the eUICC (140) does not support the IFPP function (e.g., does not understand the received function), the eUICC (140) can return an error and terminate the IFPP processing.

The eUICC (140) can process and reply to a request received through the FPA (130). The eUICC (140) can obtain information for authentication of a profile and a profile server/server vendor (100) from the terminal (130), perform decryption of the profile using information for pre-stored authentication, and process the installation. The eUICC (140) can reply to the component that transmitted the request, that is, a specific application of the terminal or the FPA (130) of the terminal, with the installation result. In addition, the eUICC (140) can verify the profile server/server vendor (100) that encrypted the profile through signature verification of the component that signed the received message, or perform authentication of the profile server/server vendor (100) that transmitted the message. The eUICC (140) may include an embedded UICC controlling Authority security domain (ECASD), which is a space for storing credentials required in the security domains of the eUICC (140), such as a certificate Issuer's root public key for verifying an SM-DPf certificate, which is a profile server/server vendor (100), a keyset of an eUICC manufacturer, etc., and an eSIM operating platform. In addition, a part of the functions of the FPA may be implemented in the eUICC (140).

The factory IT/OEM (110) is a device that provisions a profile to a terminal at a factory and may be configured to include one or more servers or terminals such as PCs. The factory IT/OEM (110) may obtain certain information about eUICCs (140) including a one-time encryption key from an EUM/EUM server (hereinafter, referred to as an EUM or EUM server) (160), transmit all or part of the obtained information to a profile server/server vendor (100), or transmit information for mapping an EID to be ordered and a profile to an SP/SP server (150). The factory IT/OEM (110) may be a server that stores or manages received encryption key information and BPP. The factory IT/OEM (110) may request a BPP (S) for injection at the factory from the profile server/server vendor (100), or may obtain a BPP for installation in the eUICC (140) and data signed by the profile server/server vendor (100) from the profile server/server vendor (100) as a result of the BPP (S) request. The factory IT/OEM (110) may store the received BPPs and the signed data in the factory IT/OEM (110). The factory IT/OEM (110) may select a BPP mapped to the EID of the target terminal on which the profile is to be installed among the received or stored BPPs and transmit the BPP to the terminal mapped during the factory setup process. The factory IT/OEM (110) may obtain the processing result from the terminal (120) through the FPA (130).

Factory IT/OEM (110) may be a server that acquires the received BPP processing result from the terminal (120), stores the acquired result, processes the result to generate a BPP Loading Report, or transmits the generated report to the profile server/server vendor (100).

As described above, factory IT/OEM (110) refers to an operation performed by a terminal manufacturer or a factory IT of a terminal manufacturer, and therefore, although it is expressed as a single entity in the drawings below, it should be noted that it may be composed of multiple devices (e.g., terminals such as servers or PCs). Accordingly, for example, it should be noted that the device in the factory IT/OEM (110) that connects the BPPs to the profile server/server vendor (100) and the device of the factory IT/OEM (110) that is at the point of contact with the eSIM terminal (120) may be the same or different devices. Some of the information exchanged between the profile server/server vendor (100), SP server (150), and EUM (160) in the factory IT/OEM (110) may be shared between entities (i.e., terminal manufacturers, profile server operating vendors, service providers, eUICC manufacturers) that perform roles in other forms (e.g., email transmission, etc.) other than message transmission and reception through the server-to-server interface.

The EUM (eUICC manufacturer) (160) can provide personalized eUICCs (140) to terminal manufacturers by injecting key information for eUICC authentication credentials into the eUICC (140). The EUM (eUICC manufacturer) (160) can provide OEM/factory IT/OEM (110) with certain information about the eUICCs (140) including a one-time encryption key from the EUM (eUICC manufacturer)/EUM server (160). In addition, although not shown in the drawing, certain information about the eUICCs (140) including a one-time encryption key can also be transmitted from the EUM (eUICC manufacturer)/EUM server (160) to the profile server/server vendor (100) at the request of the OEM (110).

As described above, the SP (service provider) (150) is a business operator that provides network services using profiles, and can order profile(s) for IFPP functions from the SP/SP server (150) to the profile server/server vendor (100) so that the profile server/server vendor (100) can create and prepare the ordered profiles. In addition, a profile order ID can be created and provided to the profile server/server vendor (100) and OEM (110). In addition, the profile processing result can be received from the profile server/server vendor (100) so that additional management can be processed for the corresponding profiles thereafter.

Hereinafter, the description of the aforementioned configuration modules can also be applied to the roles and relationships of the modules indicated in the drawings that will be described later. In addition, among the aforementioned configuration modules, order information as information exchanged between the profile server/server vendor (100), factory IT server/OEM (110), EUM/EUM server (160), and SP/SP server (150) may be transmitted in other forms such as interface linkage between servers of each entity or email.

Figure 2 is an exemplary drawing of a method for returning an installation result when installing a profile according to one embodiment of the present disclosure.

Figure 2 is a detailed implementation example drawing of a method for returning an installation result when installing a profile in Figure 3, which will be described later. Procedures not mentioned in this drawing can be applied in the same way by referring to Figure 3. The description of Figure 2 can be applied as a description of returning an installation result when installing a profile in various embodiments of the present disclosure. Figure 2 is intended to describe in detail a case where Handle Notification does not occur in the ES9+ interface, as described later in Figure 3, by processing the remove notification to proceed after installing the profile.

Factory IT/OEM (215) may store and acquire profiles to be loaded from the factory. Acquisition of the profile may follow the procedure mentioned in Fig. 6. Factory IT/OEM (215) may transmit to the terminal a request or request message including at least one of otPK.EUCC.KA, OtPK.DP.KA, DP certificate, and certificate chain as BPP and encryption key information for BPP installation for profile installation to FPA (220) of the terminal (230). In addition, information indicating that the notification will be deleted after performing the operation requested by eUICC may be added and transmitted. Depending on the terminal setting, FPA (220) may perform one of the following operations.

The difference between Option 1 and Option 2 below is whether FPA (220) explicitly sends an ES10f message for a notification deletion request, and eUICC (225) processes and responds to it. Option 1 is an example that uses an explicit notification deletion request, and Option 2 is an example that does not use an explicit notification deletion request.

Option 1-1: FPA (220) transmits a profile installation request including BPP (step 235), first obtains the installation result for the profile installation (step 245), and as a follow-up action thereto, transmits a notification deletion request generated thereto to eUICC (225) (step 255), and when the eUICC (225) receives it, performs deletion processing therefor according to the received deletion request, and then receives a message including the result of the deletion processing (step 260). Thereafter, FPA (220) can transmit a response message to Factory IT/OEM (215) or an equivalent entity at step 285. The response message includes at least Profile Installation Result, and may further include NotificationSentResponse.

Option 1-2: FPA (220) transmits a profile installation request including BPP (step 235), first obtains the installation result for the profile installation (step 245), and then replies to factory IT/OEM (215) with a response thereto (step 250), and then obtains an instruction for the next operation as a normal response to the reception from factory IT/OEM (215). This may be, for example, a message such as (Request ([ok], [remove notification])). After receiving the message, FPA (220) transmits a notification deletion request generated to eUICC (225) (step 255), and when the eUICC (225) receives it, deletes it according to the received deletion request, and then receives a message including the result of the deletion processing (step 260). Thereafter, in step 285, FPA (220) can transmit a response message to Factory IT/OEM (215) or a corresponding entity. The response message may contain at least one of Profile Installation Result or NotificationSentResponse. If step 250 was performed, only Notification Sent Response may be sent in step 285.

Option 2-1: FPA (220) transmits a profile installation request including BPP to eUICC (225) (step 235). Upon receiving this, eUICC (225) transmits the installation result to FPA (220) when a function requesting profile installation from the factory, for example, ES10f, is received and completes the BPP installation request (step 280). FPA (220) upon receiving the installation result does not generate an additional notification and completes the operation, and can transmit the Profile Installation Result to Factory IT/OEM (215) or an equivalent entity at step 285.

Option 2-2: FPA (220) transmits a profile installation request including BPP (step 235). Upon receiving this, eUICC (225) performs a function requesting profile installation from the factory, for example, when receiving a BPP installation request and a remove notification together with ES10f, the notification is not additionally created, or the notification is created and then deleted (step 275) and the profile installation result is transmitted to FPA (220) (step 280). For example, in the case of creating and then deleting the notification, eUICC (225) can include NotificationSentReponse in the profile installation result, and FPA (220) can transmit a response message including the received result to factory IT/OEM (215) or an equivalent entity (step 285). The response message can include at least one of Profile Installation Result or NotificationSentResponse.

The factory IT/OEM (215) that receives the response message from the FPA (220) can generate a BPP Loading Report including at least ProfileInstallationResults and transmit it to the profile server/server vendor (210) (step 290). The profile server/server vendor (210) can verify the signed data of the eUICC of the received message and provide the verification result to the SP/SP server and/or the factory IT/OEM (215) (see steps 355 to 370 of FIG. 3 described below).

If a request message for a profile loading operation at step 230 is transmitted without an additional request for notification deletion, the remaining notifications in the eUICC (225) can be individually delivered to the profile server/server vendor through the ES9+ function defined in SGP.22 after the terminal is shipped (see step 374 of FIG. 3 described below).

FIG. 3 is a drawing specifically illustrating a procedure for providing a BPP Loading Report according to one embodiment of the present disclosure.

The terminal manufacturer (315) may collect the processing results when installing or deleting a profile in the terminal manufacturing process and provide a BPP Loading Report to the profile server/server vendor (310). In operation 327, detailed steps for this are indicated through steps 330 to 370.

In this drawing, for the purpose of distinction, the profile server/server vendor (310) is used as SM-DPf when using the IFPP function, and as SM-DP+ (372) when following the operation of SGP.22 performed after the terminal is shipped. In addition, when using the IFPP function in the terminal, it is used as FPA (320) and when following the operation of SGP.22, it is used as LPA (373).

Factory IT/OEM (315) can transmit a profile loading processing request message to FPA (320) to be performed (step 330). This may be, for example, a transmission request that triggers profile installation or eUICC Memory Reset. FPA (320) that receives the request performs the requested action (335) and transmits the processing result to Factory IT/OEM (315) (step 340).

For example, depending on the content of the profile loading processing request in step 330, one of the following may be responded:

● In case of a profile installation request, one of the Profile Installation Result or Cancel Session Response (including or not including eUICC certificate information) or Prepare Loading Response or Prepare Loading Response Error described later in Fig. 7

● Other Signed Notification in case of eUICC Memory Reset

The definitions of Profile Installation Result and Other Signed Notification are defined in the GSMA SGP.22 standard and will not be described separately. Factory IT/OEM (315) can collect processing results received from each terminal, classify them by SM-DPf, and create a BPP Loading Report by collecting a list of the corresponding values (step 345). In order to classify them by SM-DPf, Factory IT/OEM (315) can store information on which Profile order ID each of the collected profile installation result, cancel session response, prepare loading response (with error), and other signed notification is grouped into, and can then group them by Profile Order ID and transmit them to the profile server/server vendor.

Meanwhile, as predetermined information for classification, the address of SM-DPf to transmit the processing result may be included in profile installation result, cancel session response, prepare loading response (with error), and other signed notification and received by Factory IT/OEM (315). This may be received as ServerAddress or notification Address. If the information is included and received, Factory IT/OEM (315) may obtain the information and use it as predetermined information for classification. In the case of other signed notification, eUICC (325) obtains ServerAddress or notification Address as information in the metadata of the Profile received together through BPP and adds it when generating the notification and returns it, so that FPA (320) receiving it may transmit it to Factory IT/OEM (315), so that Factory IT/OEM (315) may receive it. Meanwhile, before the ServerAddress or notification Address performs step (330), the Factory IT/OEM (315) can receive this as signed or unsigned information of the profile server from the profile server/server vendor (310). The Factory IT/OEM (315) can transmit this to the eUICC (325) through the FPA (320) at step 335. This can be transmitted by including it in the message of ES10f.PrepareLoading, for example. When the eUICC (325) obtains the information, the eUICC (325) can include it when generating the processing result of the RSP session, profile installation result, cancel session response, and prepare loading response (with error), and the FPA (320) can include it and transmit it again at step 340. In the case where Factory IT/OEM (315) receives ServerAddress or notification Address as unsigned information of the profile server in a message received from the profile server/server vendor (310), Factory IT/OEM (315) may keep it without forwarding it in step 330 and use it by referencing it in step 345.

Factory IT/OEM (315) can also send the Profile Order ID shared when ordering the Profile prior to the BPP Loading Report. The BPP Loading Report can be sent with at least one list from among the Profile Installation Result List, Cancel Session Response List, Other Signed Notification List, and Prepare Loading Response (with Error) List. This can be expressed in the form of the data in Table 1 below, for example.

[Table 1]

Meanwhile, depending on the settings, Factory IT/OEM (315) may transmit a RetriveNotification message to eUICC (325) again after FPA (320) receives the Profile Installation Result, thereby obtaining the Profile Installation Result in the form of other SignNotifiation including the eUICC certificate chain information, i.e. the pending notification stored by eUICC (325), and transmitting it to the profile server/server vendor (310).

Factory IT/OEM (315) can send the generated BPP Loading Report to the profile server/server vendor (310). This is, for example, ESbpp.HandleBppLoadingReport.

(BppLoadingReport) may be a function such as the profile server/server vendor (310) that receives it may reply with a confirmation notification regarding the reception (step 355). The profile server/server vendor (310) may perform a verification procedure for the BPP Loading Report (step 360). The profile server/server vendor (310) may transmit a response message for a confirmation notification regarding the reception of the message according to step 350 to Factory IT/OEM (315) before or during the start of performing the BPP Loading Report verification procedure (step 355).

The profile server/server vendor (310) may perform an operation including at least one of the following procedures for the received BPP Loading Report, including signature verification of the eUICC.

● When a Profile Order ID is received, the validity of the received Profile Order ID is verified. If an unknown or invalid Profile Order ID is received, the profile server/server vendor may not perform verification for each item in the received list.

● If received without a Profile Order ID, the profile server/server vendor (310) may return an error to Factory IT/OEM (315) as a result of processing the report (step 370) and may not perform any subsequent procedures.

The profile server/server vendor (310) can perform verification for each item included in the list. If the item is a cancel Session Response, ICCID and sequence number verification may not be performed.

● Signature Verification: When verifying the signature of the eUICC for Profile Installation Result or cancel Session Response or prepare Loading Response Error, the eUICC certificate and certificate chain information may have been transmitted without it. If the information has not been included and transmitted, the profile server/server vendor (310) can use the eUICC certificate and certificate chain provided by Factory IT/OEM (315) to perform verification. This may have been included and transmitted by Factory IT/OEM (315) in the profile request as described in (step 645) of FIG. 6, for example, and the profile request may be a function such as ESbpp.GetBoundProfilePackageForIfpp.

When receiving Other Signed Notification, verification can be performed using the eUICC certificate and certificate chain information received together.

● ICCID verification: If the profile server/server vendor (310) has EID information, when receiving a Profile Installation Result or Other Signed Notification, verification can be performed to see whether the received ICCID has been installed to the EID mapped thereto.

● Verify sequence number: Verification can be performed upon receipt of Profile Installation Result or Other Signed Notification as defined in SGP.22.

● Meanwhile, in the case where the RSP Server Address or notification Address is received as eUICC signed information, the profile server/server vendor (310) can verify whether the information is identical to its own server address.

Meanwhile, the verification/confirmation of the Profile Order ID may be performed before step 360 after receiving the message at step 350, so that the profile server/server vendor (310) may include the result in the Response (step 355) and transmit it to Factory IT/OEM (315). In case of receiving an error regarding the Profile Order ID, Factory IT/OEM (315) may re-confirm/correct the Profile Order ID and re-transmit the message of step 350.

After receiving a BPP Loading Report (step 350) or performing verification (step 360), the profile server/server vendor (310) can terminate RSP sessions for the received lists and delete the Transaction ID created in the corresponding RSP session and/or the encryption key information used in the corresponding RSP session.

The profile server/server vendor (310) can transmit the BPP Loading Report verification result to the SP/SP server (305) or/and the Factory IT/OEM (315) (step 365, step 370). The verification result can be transmitted by the profile server/server vendor (310) by calling ES2+.HandleNotification (HandleNotification) defined in GSMA SGP.22 as many times as the list number or in the form of data including the list of HandleNotification. The verification result can include the profile installation result.

Upon receiving the profile installation results, the SP/SP server (305) and Factory IT/OEM (315) may perform necessary actions such as updating the profile processing status.

When the terminal is shipped, the terminal can perform subsequent operations according to the operations defined in the SGP.22 standard of the GSMA. Notifications can be transmitted to the SM-DP+ (372) according to the Handle Notification defined in SGP.22 after the terminal is shipped. This can also occur, for example, when the Factory IT/OEM (315) does not cause the FPA (320) to perform a remove Notification to the eUICC (325) before the terminal is shipped.

Alternatively, Factory IT/OEM (315) may provide a replacement without providing the BPP Loading Report.

Factory IT/OEM (315) can cause FPA (320) to perform remove Notification to eUICC (325) before terminal shipment. For example, immediately after Factory IT/OEM (315) receives Profile Installation Result or OtherSignedNotification at step 340, Factory IT/OEM (315) can transmit a message for Notification deletion to FPA (320) and process it. In another example, Factory IT/OEM (315) provides an indication at step 330, and as a result of performing an operation such as profile installation or deletion at step 335, after FPA (320) receives a response message from eUICC (325), FPA (320) can instruct eUICC (325) to process deletion. Alternatively, in the case of an eUICC (325) operating in factory setting mode, it may be possible for the eUICC (325) to delete itself after performing profile installation or deletion with ES10f and sending a response message.

After the terminal is shipped, Notifications can be transmitted and processed via ES9+ according to the method defined in SGP.22 as follows (Operation 374). For example, during the initial booting process after the terminal is shipped, ES10b. RetriveNotification can be performed by the terminal setting in the LPA (323) (Step 375). At this time, if the eUICC (325) does not manage the pending Notifications generated in the IFPP process by distinction (for example, by using a different response data name), all pending Notifications generated in the IFPP process can be replied to the LPA (373) without distinction (Step 380). The LPA (373) can obtain and sort the pending Notifications received in the eUICC (325) and transmit a message including the same to the profile server. The profile server can be SM-DP+ (Step 385). The message can be ES9+.HandleNotification (pending Notification). SM-DP+ (372) can verify data and send a message including the verification result to the SP/SP server (305) (step 390). The message can be ES2+.HandleNotification.

FIG. 4 is a diagram illustrating an exemplary embodiment of a procedure for requesting and processing a cancellation during profile loading in an FPA according to an embodiment of the present disclosure.

An installation error may occur during the process of receiving and processing a profile installation request (step 430) in the terminal manufacturing process. This may be an error that occurs in eUICC (425) during the process of receiving and processing BPP, or an error that occurs in FPA (420). An example of an error that occurs during the BPP installation process in FPA (420) may be a case where an error occurs during the process of segmenting BPP in order for FPA (420) to segment and transmit the received BPP to LoadBoundProfilePackageForIfpp.

FPA (420) may obtain a signature of eUICC and provide it to Factory IT/OEM (415) for BPP installation error that occurs during the process of installing Bound Profile Package, and/or may transmit a command or command message to eUICC (425) to discard RSP session of eUICC due to corresponding BPP installation error (step 435). For example, the command may be a function such as ES10f.CancelSession. The command message may include at least transaction ID and one error reason.

FPA (420) may receive BPP, but may also send a cancel session to eUICC (425) before sending LoadBoundProfilePackageForIfpp.

The eUICC (425) that has received a message for a cancel session can process the Cancel Session (step 440) by including one or more of the procedures below and transmit the result to the FPA (420) (step 450).

● Determining whether there is an RSP session: Whether there is an RSP session can be determined by whether the eUICC (425) has received a transaction ID for the corresponding profile installation prior to this function call. If there is no Transaction ID received previously, the eUICC may sign and reply to the received data without returning an error for an invalid Transaction ID. If a previously received Transaction ID is received, the eUICC (425) may compare the received transaction ID with the previously received Transaction ID, and return an error for an invalid Transaction ID if the Transaction IDs are different. For example, if the eUICC (425) determines that LoadBoundProfilePackageForIfpp is the start of an RSP session, LoadBoundProfilePackageForIfpp includes a transaction ID and is received, and in this case, the eUICC can perform a comparison verification using this as a previously received Transaction ID.

● Generate Signed Data: Data to be signed by the eUICC (425) can be generated, including data received from the FPA (420). If the eUICC (425) has not received the Object ID (smdpOid) of the SM-DPf before this function call, the eUICC (425) can generate data without adding smdpOid. Since smdpOid is received while being included in the DPf certificate, an example of a case where the eUICC has not received the Object ID (smdpOid) of the SM-DPf before this function call may occur when the eUICC (425) receives a cancel session before receiving a function call (e.g., LoadBoundProfilePackageForIfpp) including the SM-DPf certificate (CERT.DPpb.SIG or CERT.DPauth.SIG) from the FPA (420).

● Signature Creation: Sign the Signed Data with the private key of the eUICC.

● When discarding an RSP session by receiving a Cancel Session, eUICC (425) can store pre-provisioned keys including otPK.EUCC.KA and otSK.EUICC.KA used in the RSP session without discarding them.

eUICC (425) can respond by configuring a cancel session processing result message Cancel Session Response. This can be expressed in the data format of Table 2 and Table 3 below, for example.

[Table 2]

[Table 3]

The FPA (420) that receives this may transmit a Cancel Session Response to the Factory IT/OEM (415) (step 455) in response to the Profile Loading Operation (step 430) previously received from the Factory IT/OEM (415). Alternatively, the FPA (420) may store the Cancel Session Response (step 450) and provide it when requested by the Factory IT/OEM (415). In addition, the FPA (420) may provide information requested to be reported through step 430 according to the contents of the Cancel session processing as a response to the message of step 430, and store other information and provide it when requested by the Factory IT/OEM (415).

Thereafter, Factory IT/OEM (415) may transmit the Cancel Session Responses to the profile server/server vendor (410) so that the profile server/server vendor (410) may provide the processing result to the SP/SP server (405) and/or Factory IT/OEM (415) (step 460). Step 460 may correspond to the operations of steps 345 to 370 of FIG. 3. For a detailed description thereof, FIG. 3 will be applied in the same manner and reference will be made to FIG. 3.

FIG. 5 is a block diagram showing the structure of a profile server (500), a factory IT (520), and a terminal (540) in a wireless communication system according to one embodiment of the present disclosure.

Referring to FIG. 5, a profile server (500) according to one embodiment of the present disclosure may include a communication unit (505), a control unit (510), and an encryption unit (515). The control unit (510) may be composed of at least one processor.

The communication unit (505) can transmit data to other devices or receive data from other devices. The communication unit (505) can transmit or receive encrypted keys, encrypted profiles, etc. To this end, the communication unit (505) can be equipped with at least one communication module and an antenna, etc.

The control unit (510) can control each component of the profile server (500) to install a profile according to the present invention. The specific operation of the control unit (510) is as described above or below. According to one embodiment, the profile server (500) can determine whether the order is the same by referring to the information received from the service provider server or the manufacturer's server or the service provider and the manufacturer, and map the profile and the eUICC provided information for the same order and store them in the storage unit (517). In addition, the operation can be controlled to prepare in advance by referencing the EID information received from the service provider by mapping the profile to a specific EID. According to another embodiment, the control unit (510) can perform the operation by entering the operation of preparing the profile by determining whether the profile should be prepared for IFPP using the information received from the message received through the communication unit (505).

According to another embodiment, the control unit (510) determines whether the information received from the message through the communication unit (505) is a profile loading report, sends each item included in the report to the encryption unit, and determines the result of processing through signature verification by the encryption unit, and may return information about the processing result to Factory IT (520) and/or SP/SP server (not shown) through the communication unit (505). According to another embodiment, the control unit (510) determines whether the information received from the message through the communication unit (505) is a profile loading report, and if eUICC certificate information is not included in the information included in the report and is not received, the control unit may obtain the certificate information used to create the profile from the storage unit (517) and provide it so that the encryption unit (515) can utilize it when processing signature verification.

According to another embodiment, the control unit (510) can control the operation of the profile server (500) described in various embodiments of the present disclosure.

According to another embodiment, the profile server (500) may receive a message received from factory IT through the communication unit (505) in a preliminary process of preparing and providing BPP, determine that the received message is a request for downloading a profile for IFPP, process an operation to prepare profiles for the factory, and transmit the processing result to the factory IT through the communication unit (505). The encryption unit (515) may perform encryption on the profile under the control of the control unit (510) to generate a Bound Profile Package and provide the Bound Profile Package to the control unit (510). Part or all of the information received through the communication unit (505), for example, the Profile Order ID received from the SP/SP server (not shown) and the eUICC certificate chain information received from the factory IT (520), may be stored in the storage unit (517) to verify the BPP Loading Report.

The encryption unit (515) may include a hardware security module (HSM) or may be named as an HSM itself, and may perform encryption and decryption of a profile without exposing an encryption key. Depending on the implementation, the encryption unit (515) may be built into the control unit (510) or implemented in the form of software code driven by the control unit (510).

Referring to FIG. 5, a factory IT (520) according to an embodiment of the present disclosure may include a communication unit (525), a control unit (530), and a storage unit (535). The factory IT (520) may be configured as a combination of multiple devices including at least one of the communication unit, the control unit, and the storage unit. When multiple devices are connected to each other, each device for connection may be implemented to include a communication unit, and a device for centrally controlling each device may be configured to include. The factory IT (520) may also be configured as one or more devices as described above. For this, additional reference is made to the description of FIG. 1.

In addition, according to one embodiment of the present disclosure, the communication unit (525) can transmit or receive an encrypted key, an encrypted profile, etc. To this end, the communication device (525) can be equipped with at least one communication module and an antenna, etc. According to one embodiment of the present disclosure, the storage unit (535) and the communication unit (525) can be equipped as one device for the factory IT (520) itself. The factory IT (520) can transmit encrypted key information to the profile server (500) or receive at least one of the encrypted profiles from the profile server (500) through the communication unit (525) that provides a wireless communication connection.

According to one embodiment of the present disclosure, the factory IT (520) may transmit a BPP Loading Report as a profile processing result received from a terminal (520) through a communication unit (525) providing a wireless communication connection, or may receive a processing result thereof from a profile server (500).

In addition, according to one embodiment of the present disclosure, the factory IT (520) can transmit a stored encrypted profile to the terminal (520) through the communication unit (525), transmit a message requesting deletion of an already installed profile to the terminal (520), or transmit a command to delete Notifications generated by the eUICC to the terminal (520), and receive a response message regarding the processing result from the terminal.

In addition, according to one embodiment of the present disclosure, the factory IT (520) may store a profile received from the profile server (500) through the communication unit (525) or an encrypted key previously acquired from an EUM (not shown) in the storage unit (513) by the control unit (530), or may transmit the profile to a device within the factory IT (520) responsible for profile injection through the communication unit (525), and may transmit the profile to a terminal (540) via wired or wireless means from the communication unit (525) of the device within the factory IT (520) responsible for profile injection.

In addition, according to one embodiment of the present disclosure, the storage (535) of the factory IT (520) may store at least one encrypted profile, or store encrypted key information for one encrypted profile, or receive a loading result received from the terminal (540). The control unit (530) of the factory IT (520) may store the profile loading results received through the communication unit (525) in the storage unit (535), and may use the corresponding information to generate a BPP Loading Report, or may collectively provide the same to the profile server (500) through the communication unit (525) that provides a wireless connection. The storage unit (535) may include at least one type of storage medium among a hard disk type, a random access memory (RAM), a static random access memory (SRAM), a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), a programmable read-only memory (PROM), a magnetic memory, a magnetic disk, and an optical disk. In addition, according to one embodiment of the present disclosure, the factory IT (510) may be composed of a plurality of devices as described above, and when composed of a plurality of devices, the communication unit may provide a communication service limited to only a terminal manufacturer's external network connection or a terminal manufacturer's internal network connection.

Additionally, according to one embodiment of the present disclosure, the control unit (530) may include at least one processor. The control unit (530) may control the operation of the Factory IT (520) according to various embodiments of the present disclosure.

Referring to FIG. 5, the terminal (540) may include a communication unit (545), a control unit (550), a storage unit (555), and an eUICC (560). The eUICC (560) may be detachable as described above, but is usually shipped in a non-detachable manner from the terminal, so it is indicated as a part of the terminal (540). The communication unit (545) may receive or transmit data to other devices. For example, the received data may be one of an encryption key, an encrypted profile, and certificate information. The transmitted data may be a response message according to the profile loading result. For this purpose, the communication unit (545) may be equipped with at least one communication module and an antenna, etc.

In addition, according to one embodiment of the present disclosure, the control unit (550) can control each component of the terminal (540) for installing a profile according to the present invention. The control unit (550) can control the overall operations of the terminal (540). For example, the control unit (550) can transmit and receive signals through the communication unit (545). In addition, the control unit (550) can record and read data in the storage unit (555). The control unit (550) can include at least one processor. For example, the control unit (550) can include a CP (communication processor) that performs control for communication and an AP (application processor) that controls upper layers such as application programs. According to one embodiment, when there is configuration information stored in the storage unit (555), the control unit (550) can request the configuration information from the storage unit (555) so that the screen display unit (not shown) can display it or receive the configuration information and process additional operations.

According to another embodiment, the control unit (550) may perform a processing process in which the terminal infers information that can be referenced for selecting a profile installation in the factory by matching the data record read through the storage unit (555) or the information collected through the control unit (550) and the communication unit (545). The control unit (550) may control the terminal (540) to perform a corresponding operation. According to one embodiment, the control unit (550) may include an FPA responsible for driving and controlling the eUICC (560), an application in which the FPA is integrated and implemented, and an application managing the factory installation. In addition, the control unit (550) may include a terminal framework that interprets information received by the FPA or the application and processes a specific command APDU request to the CP (communication processor) or collects part or all of the requested information from the storage unit (555) and returns it to the FPA or the application.

In addition, according to one embodiment of the present disclosure, the control unit (555) may determine an operation to enter the IFPP mode by synthesizing predetermined information acquired from the eUICC (560) through the terminal (540) and the communication unit (545), and control the eUICC (560) to enter the IFPP mode. The eUICC (560) may operate under the control of the control unit (550). According to one embodiment of the present disclosure, the eUICC (560) may process a request for profile installation received from the control unit (550) and return the processing result to the control unit (550).

In addition, the control unit (550) according to one embodiment of the present disclosure may receive profile information or a response message of a profile package received from the factory IT (520), and, by referring to terminal settings or user input information at the time of reception, determine whether to perform profile installation in the factory mode, decide to enter the IFPP mode, or configure a message to be transmitted to the eUICC (560) to install the profile with IFPP. In addition, the control unit (550) may configure profile information of the profile package into one or more messages, and control to transmit a message including the profile information to the eUICC (560), or detect that an error occurs during the profile installation process and transmit a request for a cancel session to the eUICC (560). In addition, the control unit (550) can control the terminal (540) to receive the processing result received from the eUICC (560) at the terminal (540) or to determine whether to terminate the procedure and store the processing result in the storage unit (555), transmit the processing result to the communication unit (545), or control the terminal (540) to transmit the processing result to the factory IT (520) by the communication unit (545).

In addition, according to one embodiment of the present disclosure, the control unit (550) may determine whether to further transmit a command for deleting a notification to the eUICC (560) through a message previously received through the communication unit (545), or may further obtain a processing result from the eUICC (560) based on the determination and transmit it to the Factory IT (520) through the communication unit (545).

The storage (555) can store data such as basic programs, application programs, and setting information for the operation of the terminal (540). In one embodiment of the present disclosure, the storage (555) can include at least one storage medium from among a flash memory type, a hard disk type, a multimedia card micro type, a card type memory (for example, an SD or XD memory, etc.), a magnetic memory, a magnetic disk, an optical disk, a random access memory (RAM), a static random access memory (SRAM), a read-only memory (ROM), a programmable read-only memory (PROM), and an electrically erasable programmable read-only memory (EEPROM). The storage (555) can be implemented as an integrated system on chip (SoC) with the control unit (550). The control unit (550) can perform various operations using various programs, contents, data, etc. stored in the storage unit.

In FIG. 5, eUICC (560) is a UICC chip embedded in a terminal (540) and can perform functions of storing, managing, and deleting at least one profile. A profile can collectively refer to one or more applications and subscriber authentication information, phone book, and other data information stored in an existing UICC card. eUICC (560) can be included as a part of terminal (540) as illustrated in FIG. 1, and in FIGS. 2 to 6, each is expressed as a separate module to explain the operation between terminal (540) and eUICC (560). eUICC (560) may include a control unit, a storage unit, and a communication unit for installing a profile. Some of the applications in eUICC (560) may be installed in the control unit (550), and the installed applications may include some of the functions of FPA.

According to one embodiment of the present disclosure, the control unit of the eUICC (560) may obtain profile installation request or deletion request information through a message of the terminal (520) received through the communication unit, and then process profile installation or deletion, reply with a different loading result for installation or deletion, generate a pending notification after installation or deletion and process it to store in the storage unit, determine whether to additionally delete the generated pending notification, or proceed with deleting the pending notification accordingly and reply with a response message. In addition, the control unit of the eUICC (560) may determine whether to enter the IFPP through information in the received message or a new function defined for IFPP, and determine an operation accordingly, and may process a profile installation or deletion procedure for IFPP and compare and verify the received information with the information in the storage unit of the eUICC (560). For example, when a command for a profile installation request is received, the control unit may verify the received profile package to perform an operation for installation, and sign and reply with the processing result to the terminal (540) through the communication unit. As mentioned in the embodiments of the present invention, examples of information that is processed through the control unit (550) by comparing and verifying with information in the storage of the eUICC (560) may include information such as the presence or absence of otPK.EUICC.KA used when installing or deleting a profile, a transaction ID mapped to a session, and certificate information of SM-DPf.

However, the components mentioned in FIG. 5 are not limited to the examples described above. For example, the factory IT (520) may include more or fewer components than the components described above. For example, the profile server (500) may include more or fewer components than the components described above. For example, the terminal (540) may include more or fewer components than the components described above. The terminal (540) according to various embodiments disclosed in the present document may be an electronic device, and the electronic device may be a variety of devices. The electronic device may include, for example, a portable communication device (e.g., a smartphone), a computer device, a portable multimedia device, a portable medical device, a camera, a wearable device, or a home appliance device. The electronic device according to an embodiment of the present document is not limited to the devices described above.

FIG. 6 is a diagram for explaining an operation of preparing a large number of profiles for IFPP according to one embodiment of the present disclosure.

Fig. 6 illustrates an example of a step for preparing a profile in Factory IT/OEM (315) before Fig. 3 is performed. Referring to Fig. 6, a factory IT/OEM (615) that wants to install eUICCs can order eUICCs from an EUM/EUM server (600). The EUM (600) can create a pair of otSK.eUICC.KA and PK.eUICC.KA used in the eUICC in advance and transmit them to the factory IT/OEM (615) (step 630). When delivering an eUICC equipped with otSK.EUICC.KA, EUM (600) can transmit to the factory IT/OEM (615) at least one of otPK.EUICC.KA, [Euicc info], [EID], EUICC's certificate (CERT.EUICC.SIG) and certificate chain, EID, or PK.EUICC.KA for each eUICC (step 630). Among these, otPK.EUICC.KA or eUICC certificate can be transmitted as eUICC signed data. The transmitted information can be transmitted from the profile server through an interface linked with the factory IT (615). The transmitted information can be transmitted online or offline. Each transmitted information can indicate the following. Of course, it is not limited to the following examples and can also indicate other information.

- otPK.EUICC.KA: One-time public key of eUICC

Public key used to generate session keys between the profile server and eUICC

- SK(data including otPK.EUICC.KA): Data including otPK.EUICC.KA signed with the secret key of eUICC

- CERT.EUICC.SIG and certificate chain: eUICC certificate and chain of certificates for eUICC certificate verification

- CERT.EUICC.SIG can contain EID, a unique identification number of the eUICC, and a public key (PK.EUICC.KA) for decrypting the eUICC signature. It can also be used to prove that the eUICC is authenticated by the EUM.

- The parent certificate chain of CERT.EUICC.SIG may include CERT.EUM.SIG, a certificate containing an EUM public key. If a particular eUICCs order has the same certificate chain, the parent certificate chain of CERT.EUICC.SIG may be sent for the order, not for each eUICC.

- eUICC info: Information about eUICC capability, which may or may not include an indication of capability indicating whether the eUICC supports IFPP. If the same eUICC capability is used for a specific order, eUICC info may be transmitted for the order rather than for each eUICC. As described above, information about how to support installation of multiple profiles and how to support installation of multiple profiles may be additionally transmitted.

- EID: Unique identification number assigned to each eUICC

- PK.EUICC.KA: When the public EID of eUICC for decrypting the eUICC signature or PK.EUICC.KA is transmitted, it can be transmitted as a value included in CERT.EUICC.SIG, or as a separate parameter when transmitted without being included in CERT.EUICC.SIG.

The factory IT/OEM (615) that receives the transmitted information stores the information. At a certain point in time, the factory IT/OEM (615) may decide to load the profile on N or all eUICCs that are part of the M eUICCs ordered from the EUM (600). Alternatively, the SP/SP server (605) may request the factory IT/OEM (615) to pre-load the profiles on the terminals (620) to which the profiles will be shipped.

Factory IT/OEM (615) may optionally transmit to SP/SP server (605) at least one of the number of profiles and information on EID(s) so that SP/SP server (605) can prepare profiles linked to EIDs in advance (step 633).

The SP/SP server (605) can order a profile to a profile server/server vendor (610) (step 635).

If the SP/SP server (605) has acquired and has the EID lists at step 633 or earlier, the SP/SP server (605) may place an order to the profile server/server vendor (610) including the EID information while ordering a Profile. The profile order message may be defined in a form that further includes IFPP order identification information in the ES2+ order interface between the service provider and the profile server defined in the new function or the existing GSMA RSP. The information included in the order message may include at least one of the following. Of course, the information is not limited to the information below and inclusion of other information is not excluded.

- Profile Order ID that represents a group of order profiles

- Number of profiles assigned by Profile Order ID or ICCID lists

- Number of order profile(s)

- ICCID(s)

- EID(s) that require linked profiles

- SP(service provider) ID:

Profile server address where order profiles will be prepared

(For example, an address of type FQDN (fully qualified domain name))

- IFPP Order Identifier (IFPP indication)

- Factory IT serial number to which the generated BPP will be transferred

- OEM identification number (manufacturer number) to which the generated BPP will be transmitted

The IFPP order identifier can be transmitted as part of the value of the IFPP indication data, or the Profile OrderID can be transmitted as part of the value of the Profile type data of the ES2+ order interface.

The profile server/server vendor (610) may be a profile server that supports only IFPP, or may be a profile server that supports IFPP as one of the functions of the profile server. For example, the profile server/server vendor (610) may be a server that supports SGP.21/22 (a standard for profile provisioning for consumer terminals such as smartphones) defined by GSMA. Alternatively, the profile server/server vendor (610) may be a profile server that supports SGP.31/32 (a standard for profile provisioning for IoT-specific terminals). The profile server/server vendor (610) may be a server that additionally supports a function for profile provisioning in a factory.

The profile server/server vendor (610) that has received the profile download order can identify whether the profile download order is for IFPP by determining whether there is IFPP judgment information as a new function defined by IFPPorder or a new parameter of the existing ES2+.Downloadorder, and manage it. The identification of whether it is for IFPP can be based on the IFPP order identifier or Profile ID described above. Meanwhile, if the EID is not received together in the above (step 635), the profile server/server vendor (610) can change the status of the Profile to the allocated stage and process it, and if the EID is received together in step 635, the EID can be connected to the ICCID and the status of the Profile can be changed to the linked stage and prepared.

At a later stage, the profile server/server vendor (610) may receive a profile provision request from the factory IT/OEM (615) (step 645). According to one embodiment of the present disclosure, the SP/SP server (605) or the profile server/server vendor (610) may share information that may specify a profile download order to the factory IT/OEM (615) (step 640).

When the profile server/server vendor (610) receives a profile provision request for IFPP from the factory IT/OEM (615), the profile server/server vendor (610) can check which order it corresponds to among the profile creation orders previously requested from the SP. Information that can check which order it corresponds to can include at least one of the Profile OrderID, the address of the server storing the profile, identification information of the service provider that requested the profile creation, the start and end numbers of the ordered profile list or EID list, or the ordered profile list, the EID list, and the factory IT identification number. In the embodiment of the present disclosure, the Profile Order ID is described as an example of information that can identify an order in this drawing and other examples thereafter. Information that can identify an order is not limited to the profile order ID.

Thereafter, when the profile server/server vendor (610) receives profile request information from the factory IT/OEM (615) (645), it can optionally verify the included order identification information, and if there are pre-prepared profiles for the optionally included orders, it can prepare BPPs by encrypting the pre-prepared profiles with otPK.EUICC.KA corresponding to eUICC as in the procedure described below.

At step 645, the factory IT/OEM (615) may want to inject a profile into the terminal before shipping the terminal from the factory. To this end, the factory IT/OEM (615) may request a BPP prepared for IFPP from the profile server/server vendor (610).

The method of indicating that the profile server/server vendor (610) is an IFPP request from the factory IT (615) may include at least one of: transmitting a message with a new function indicating that the message is a BPP request for IFPP; transmitting an IFPP identification indication by utilizing the existing ES9+. function; or transmitting a message including parameters required only for IFPP (e.g., at least one of otPK.eUICC.KA, Profile order ID, or SP ID). The method of indicating that the message is an IFPP request to the profile server/server vendor (610) may be determined by the profile server/server vendor (610). As an example of utilizing the ES9+. function defined in the above-mentioned existing SGP.22, it may be a message such as ES9+. GetBoundProfilePackage, and an IFPP identification indication may be included therein. Meanwhile, in one of the data of a series of follow-up messages accompanying a BPP request for IFPP or a BPP generation request, the factory IT/OEM (615) may transmit to the profile server/server vendor (610) key information including otPK.EUICC.KA corresponding to the eUICCs of the target terminals as many as the number of terminals on which the SP (service provider) (605) is to load the profile among the key information of the eUICCs acquired in step 630. In addition, in one of the data of a series of follow-up messages accompanying the BPP generation request transmitted from the factory IT/OEM (615) to the profile server/server vendor (610), eUICC info may be selectively included as additional information provided for BPP generation, such as device info as the capability of the terminal or eUICC capability information.

If the profile server/server vendor (610) receives a message from the factory IT (615) that can determine that it is a BPP request for IFPP and receives key information for otPK.eUICC.KA, the profile server/server vendor (610) determines that BPP for IFPP is ready and the profile server/server vendor (610) can perform a step of generating a BPP for IFPP (step 650). The profile server/server vendor (610) can enter a procedure of generating a BPP, which is an encrypted profile package in the IFPP mode. When the profile server/server vendor (610) determines to generate a BPP for IFPP, it may include receiving information that can recognize the message received from the factory IT (615) (for example, information including at least one of a new function defined for IFPP, a new IFPP indication that can recognize that the existing ES9+ message is a profile download request from the factory, or new parameters (such as encryption key information). When the profile server/server vendor (610) determines that a BPP for IFPP should be generated, the profile server/server vendor (610) may generate a BPP for IFPP by including one or more of the following procedures. Of course, the present invention is not limited to the following examples.

- If you have a Profile Order ID, you can verify that it is a known and valid Profile Order ID.

- Profile Eligibility Check

Before performing a profile download, a procedure may be optionally performed by the profile server/server vendor (610) to check whether the profile type received from the SP through the ES2+ order interface is suitable for installation on the target terminal/EID. If at least one of EID, eUICC info, and device info is received through steps 635 to 645, a profile order received at step 650, particularly whether a profile type specified in the order can be installed, may be optionally performed. Accordingly, the profile server/server vendor (610) may or may not perform qualification verification, including whether the profile for IFPP is installed on an EID/terminal.

- Verification of CERT.EUICC.SIG, the certificate of eUICC

The profile server/server vendor (610) may perform verification when it receives the CERT.EUICC.SIG in step 645. The profile server/server vendor (610) may verify the CERT.EUICC.SIG received in step 645 with the certificate of the EUM. For example, the CERT.EUICC.SIG may include an EID, which may be a series of numbers including one of the EINs in the EUM certificate. The profile server may verify that the EID included in the CERT.EUICC.SIG matches one of the values of the allowed EINs (EUM identification IDs) included in the EUM certificate, CERT.EUM.SIG.

- Verify the signature of eUICC

The profile server/server vendor (610) can verify the signature by decrypting the secret key of the eUICC used to sign the data containing otPK.EUICC.KA with the public key of the eUICC contained in CERT.EUICC.SIG.

- otSK/PK.DP.KA: Generate a one-time private key and public key pair for the profile server.

- Generate session key using otSK.DP.KA and otPK.EUICC.KA received in (step 645)

The profile server/server vendor (610) can use otSK.DP.KA and otPK.EUICC.KA to generate a shared secret value to be used for a specific profile transfer session.

- ServerChallenge

If the factory IT/OEM (615) requests the profile server/server vendor (610) to transmit ServerChallenge information including the information at step 645 or a step before step 645, the profile server/server vendor (610) can generate the ServerChallenge information. If the eUICC (625) is designed to be able to send the ServerChallenge value that the profile server/server vendor (610) sends to the eUICC (625) as is during the mutual authentication procedure between the profile server/server vendor (610) and the eUICC (625), it can be provided.

- Creation of BPP (bound profile package)

A profile server/server vendor (610) can generate a profile package bound to an EID that includes a session key, a key replacement package, ISD-P generation and configuration information.

If the profile server/server vendor (610) successfully generates a BPP for an IFPP at step 650, the profile server/server vendor (610) can transmit the BPP and a series of information required for BPP installation to the factory IT/OEM (615) (step 655). The profile server/server vendor (610) can transmit the BPP and a series of information required for BPP installation to the factory IT/OEM (615) via one or more messages (step 655). If the factory IT (615) has registered a push service with the profile server/server vendor (610) at the time of requesting the BPP, the series of information required for BPP and BPP installation may be transmitted by including it in a push message at the time the profile server/server vendor (610) prepares it at step 650, or the profile server/server vendor (610) may notify that the profile is ready via a push message, and the factory IT (615) may access the profile server/server vendor (610) to obtain it.

The profile server/server vendor (610) can transmit a list of a series of encryption key information required for BPP verification in the generated BPP and mapped eUICC to the factory IT/OEM (615) via one or more messages. The encryption key information, for example, public keys, can be transmitted with or without being included in the certificate. In addition, the information transmitted by the profile server/server vendor (610) can include order identification information, for example, Profile order ID. According to one embodiment of the present disclosure, the information transmitted by the profile server/server vendor (610) may include data in the form of ESbpp.GetBoundProfilePackageForIFPP response ([SP ID], ([Profile Order ID], (BPP including otPK.DP.KA, [CERT.EUICC.SIG], [CERT.DPauth.SIG], CERT.DPpb.SIG, [ServerChallenge], [otPK.EUICC.KA], DPf Cert Chain) X N). When the profile server/server vendor (610) generates a BPP, it may also be possible to transmit a message in a form that additionally includes at least one of [CERT.EUICC.SIG], [CERT.DPauth.SIG], CERT.DPpb.SIG, [ServerChallenge], [otPK.EUICC.KA], DPf Cert Chain in the BPP. Alternatively, the information transmitted by the profile server/server vendor (610) may include information in the form of ESbpp.GetBoundProfilePackageForIFPP response ([SP ID], ([Profile Order ID], (BPP including otPK.DP.KA, [CERT.EUICC.SIG], [CERT.DPauth.SIG], CERT.DPpb.SIG, [ServerChallenge], [otPK.EUICC.KA], DPf Cert Chain). For each Profile Order ID, which is the order identification information, it is possible that at least one of [CERT.DPauth.SIG], CERT.DPpb.SIG, and DPf Cert Chain is not transmitted N times, but only once.

The information transmitted in step 655 is composed of one message or more than one message and transmitted to the factory IT/OEM (615), and the factory IT (615) can store the information received in step 655.

Factory IT (615) stores the received BPP, the EID mapped to each BPP, and the encryption key information for downloading and installing the BPP to the EID, and then performs an operation such as BPP installation or deletion after installation on the N terminals (620) at a specific point in time as in step 660 and processes the step of generating a BPP Loading Report. The specific operation of step 660 is described in FIG. 3.

FIG. 7 is a diagram illustrating an exemplary embodiment of a procedure for processing a message transmitted from an FPA to an eUICC before transmitting a loading message including a BPP from an FPA to an eUICC according to one embodiment of the present disclosure.

Any procedure not mentioned in this drawing can be applied equally with reference to FIG. 3. The description of FIG. 3 can be applied as a description for responding when installing a profile in various embodiments of the present disclosure.

Before transmitting the loading message including the BPP described above in Fig. 2, the FPA (720) may first transmit information required for BPP installation to the eUICC (725) as a separate message from the loading message including the BPP. This may be, for example, a new ES10f transmission message such as ES10f. PrepareLoading.

In this case, FPA (720) can receive BPP together with information required for BPP installation from Factory IT/OEM (715), and FPA (720) can first construct an ES10f. PrepareLoading message including the required information and transmit the message to eUICC (725), and then process BPP transmission with eUICC (725) as described above in FIG. 2 based on the result of processing the message. Alternatively, FPA (720) can first receive only information required for BPP installation from Factory IT/OEM (715), and FPA (720) can construct an ES10f. PrepareLoading message including the information and transmit the message to eUICC (725), and then additionally receive BPP from Factory IT/OEM (715) based on the result of processing the message and then process BPP transmission with eUICC (725) as described above in FIG. 2.

An example of information required for BPP installation in this disclosure may be information including one of otPK.EUICC.KA, a certificate of a profile server, a certificate chain of a profile server, and an address of a profile server (to which the processing result will be transmitted).

When receiving a message for ES10f. PrepareLoading from eUICC (725), eUICC (725) performs prepare Loading processing (step 740) and configures a processing result message (expressed as Prepare Loading Response in this disclosure) and transmits it to FPA (720). (Step 745). This may be expressed, for example, in the data format of Table 4 below. For example, a message for successful processing may be returned by eUICC (725) without signing, and a processing error message may be sent to FPA (720) by eUICC (725) signing the message with the secret key of eUICC and including the signature value.

[Table 4]

If an error occurs while performing prepare Loading processing (step 740), eUICC (725) can transmit an error message to FPA (720), discard the corresponding RSP session, and terminate the procedure. When discarding the corresponding RSP session, the encryption keys that are not used for the corresponding session, i.e., otPK.EUCC.KA and the corresponding otSK.EUICC.KA, can be stored without being deleted. The error that occurs can be one of the LoadingErrorCodes mentioned in the table above, and can be interpreted by referring to the description of the Error Code defined in SGP.22. However, installFailedDueToDataMismatch(13) which is not defined in SGP.22 can be interpreted as an error when there is no stored otPK.EUCC.KA matching the received otPK.EUCC.KA or no otSK.EUICC.KA, and noMoreOtpkFactoryUse(126) can be interpreted as an error when the eUICC has exhausted all otSK.EUICC.KA matching the otPK.EUCC.KA to be used in the session.

The FPA (720) that receives the response result (step 745) can perform an action with one of the following options.

Option 1: If the processing result is received as successful, notify Factory IT/OEM (315) (step 750) or not notify (step 760 is entered without performing steps 750 and 755), and then proceed to step 235 of Fig. 2 as the next operation to continue transmitting a message including BPP to eUICC (325) and then perform step 235 and the subsequent procedures mentioned in Fig. 2 (step 760).

Option 1-1: In the case where the processing result is received as successful and this is notified to Factory IT/OEM (315) (step 750), FPA (720) explicitly receives a request for Load BPP from Factory IT/OEM (715) (step 755), proceeds to step 235 of Fig. 2 as the next operation and proceeds to transmit a message including BPP to eUICC (325) and performs step 235 and the subsequent procedures mentioned in Fig. 2 thereafter (step 760). If at least BPP was received in step 730 previously, only an indicator requesting LoadBPP without transmitting BPP may be added and transmitted in step 755.

Option 2: If the processing result is received as an error, send the received error result to Factory IT/OEM (715), discard the corresponding RSP session, and terminate the procedure (step 770).

Option 2-1: Although not indicated in the drawing, if the processing result is received as an error, the received error result is transmitted to Factory IT/OEM (715) and if a message for procedure termination is explicitly received again from Factory IT/OEM (715), FPA (720) may transmit a response message to this and terminate the procedure.

In the case where FPA (720) transmits the processing result (received at step 745) received from eUICC (725) to Factory IT/OEM (715) as above, Factory IT/OEM (715) can perform the subsequent procedure of FIG. 3 to process the subsequent procedure. That is, for example, Prepare Loading Response (with Error) can be transmitted as the received processing result, that is, one of the Loading Result of FIG. 3. If Prepare Loading Response (with Error) is received, FPA (720) must transmit the corresponding message to Factory IT/OEM (715). If Prepare Loading Response (with Success) is received, FPA (720) may not transmit it to Factory IT/OEM (715) as mentioned in Option 1, and Factory IT/OEM (715) may generate BPP Loading Report without including Prepare Loading Response (with Success) accordingly.

When a Prepare Loading Response (with Success) is received, the FPA (720) can forward it to the Factory IT/OEM (715) as mentioned in Option 1 or Option 1-1. If the value is received with an eUICC signature, the Factory IT/OEM (715) can also transmit it including information about a BPP Loading Report to be generated later as described in FIG. 3, and the profile server/server vendor (710) receiving it can verify the signature and report the result of the response to the SP/SP server (705) (not shown).

In the case where Prepare Loading Response (with Error) List information is included and transmitted in the BPP Loading Report as described in FIG. 3, the subsequent procedure can perform operations as described in FIG. 3 (step 775), and since this has been described above in FIG. 3, its description will be omitted in FIG. 7.

In various embodiments of the present disclosure, the operations of FPA, LPA, and eUICC are described separately, but this is for convenience of explanation, and it should be noted that the operations of FPA, LPA, and eUICC can be described as operations of the terminal. For example, the transmission/reception operations of FPA can be described as transmission/reception operations of the terminal.

The methods according to the embodiments described in the claims or specification of the present disclosure may be implemented in the form of hardware, software, or a combination of hardware and software.

In the case of software implementation, a computer-readable storage medium storing one or more programs (software modules) may be provided. The one or more programs stored in the computer-readable storage medium are configured for execution by one or more processors in an electronic device. The one or more programs include instructions that cause the electronic device to execute methods according to the embodiments described in the claims or specification of the present disclosure.

These programs (software modules, software) may be stored in a random access memory, a non-volatile memory including a flash memory, a read only memory (ROM), an electrically erasable programmable read only memory (EEPROM), a magnetic disc storage device, a compact disc-ROM (CD-ROM), digital versatile discs (DVDs) or other forms of optical storage devices, a magnetic cassette. Or, they may be stored in a memory composed of a combination of some or all of these. In addition, each configuration memory may be included in multiple numbers.

Additionally, the program may be stored in an attachable storage device that is accessible via a communications network, such as the Internet, an intranet, a local area network (LAN), a wide LAN (WLAN), or a storage area network (SAN), or a combination thereof. The storage device may be connected to a device performing an embodiment of the present disclosure via an external port. Additionally, a separate storage device on the communications network may be connected to the device performing an embodiment of the present disclosure.

In the specific embodiments of the present disclosure described above, the components included in the disclosure are expressed in the singular or plural form depending on the specific embodiment presented. However, the singular or plural expressions are selected to suit the presented situation for the convenience of explanation, and the present disclosure is not limited to the singular or plural components, and even if a component is expressed in the plural form, it may be composed of the singular form, or even if a component is expressed in the singular form, it may be composed of the plural form.

Meanwhile, although the detailed description of the present disclosure has described specific embodiments, it is obvious that various modifications are possible within the scope of the present disclosure. Therefore, the scope of the present disclosure should not be limited to the described embodiments, but should be determined not only by the scope of the claims described below, but also by equivalents of the scope of the claims.

Claims (1)

A step of receiving a first control signal transmitted from a base station;
a step of processing the received first control signal; and
A control signal processing method, characterized by comprising a step of transmitting a second control signal generated based on the above processing to the base station.

Images