Electronic device for supporting profile transfer procedure and operation method thereof

Abstract

The present disclosure provides an electronic device (101) comprising: a communication circuit (190); one or more processors (120) including a processing circuit; and a memory (130) for storing instructions. The instructions, when individually or collectively executed by the one or more processors, cause the electronic device to: receive, from an external electronic device (102, 104, or 700) through the communication circuit, authentication information related to a procedure for transferring a profile from the external electronic device to the electronic device; in response to the reception of the authentication information, identify a first identifier for identifying the procedure; transmit, to a first server (520) through the communication circuit, a request message for requesting the transfer of the profile, the request message including the first identifier; in response to the transmission of the request message, receive, from the first server or a second server (210 or 560) different from the first server through the communication circuit, a response message including information for downloading the profile from a third server (220 or 530); identify a second identifier for identifying the procedure on the basis of the response message; identify whether the second identifier is identical to the first identifier; on the basis the second identifier being identical to the first identifier, identify whether another response message including the second identifier has been received before the reception of the response message; and on the basis of whether the other response message has been received, identify whether to download the profile from the third server. The instructions, when individually or collectively executed by the one or more processors, cause the electronic device to, as at least a part of the operation of, on the basis of whether the other response message has been received, identifying whether to download the profile from the third server, on the basis of the other response message not being received, download the profile from the third server through the communication circuit on the basis of the information for downloading the profile. Other embodiments may be possible.

Description

Electronic device supporting profile transfer procedure and method of operation thereof

[0001] The present disclosure relates to an electronic device supporting a profile transfer procedure and a method of operating the same.

[0002] In wireless communication systems, an on-device service activation (ODSA) procedure is provided to download a profile to an embedded SIM (eSIM) rather than a physical subscriber identity module (SIM) card. The ODSA procedure may refer to a procedure in which an electronic device supporting an eSIM downloads a profile or an electronic device transfers a profile to an external electronic device. However, during the ODSA procedure, various errors may occur while the profile is downloaded to the eSIM.

[0003] For example, when an electronic device including an eSIM transmits a message requesting a profile download to an entitlement server of a telecommunications carrier, in the case of a telecommunications carrier that does not immediately transmit download information (e.g., DownloadInfo) for profile download but instead proceeds with the profile download in a delayed download manner, a push message may be used to transmit information indicating that the profile is ready. In this way, when the profile download is performed in a delayed download manner, both a push message transmitted from a subscription manager discovery server (SM-DS) and a push message transmitted from the entitlement server may be received by the electronic device, and in this case, an error may occur in the electronic device due to multiple push messages.

[0004] For another example, a multiple enabled profiles (MEP) feature has been proposed, allowing multiple profiles to be activated on a single eSIM. Accordingly, when multiple profiles are downloaded to an eSIM, the electronic device may receive multiple push messages from the SM-DS and the entitlement server. However, the electronic device may not be able to identify which profile each of the multiple push messages relates to, and in this case, errors may occur in the electronic device due to the multiple push messages.

[0005] As another example, if an existing profile stored in a physical SIM or eSIM included in an electronic device (e.g., an existing electronic device) needs to be moved to an external electronic device (e.g., a new electronic device), the carrier may deactivate the existing profile, activate a new profile, and transmit download information for the new profile to the external electronic device so that the external electronic device downloads the new profile. Alternatively, the carrier may transmit a message to the electronic device requesting deletion of the existing profile, and when the electronic device deletes the existing profile and the carrier receives the message indicating that the existing profile has been deleted, the carrier may transmit information for downloading a new profile to the external electronic device so that the external electronic device downloads the new profile. In such a profile transfer (or subscription transfer or line transfer) procedure, if the new electronic device cannot receive download information for downloading the new profile due to various reasons, such as a Wi-Fi (wireless fidelity) error and / or a network error after the carrier deactivates the existing profile or the electronic device deletes the existing profile, an error may occur. In this case, the electronic device needs to update authentication information (e.g., a token) to access the carrier's entitlement server, but authentication based on the existing profile (e.g., extensible authentication protocol authentication and key agreement (EAP-AKA) authentication) may not be possible because the existing profile has already been deactivated or deleted.

[0006] One aspect of the present disclosure is to conditionally download profiles from a server (e.g., an SM-DP+ server) to improve the profile download procedure.

[0007] According to the present disclosure, a method of updating a token without performing a new authentication procedure may be proposed when an error situation occurs, such as when the validity period of a token expires during a profile transmission procedure and authentication based on an existing profile is not possible.

[0008] When an electronic device needs to update authentication information (e.g., a token) to access a carrier's entitlement server, authentication based on an existing profile (e.g., extensible authentication protocol authentication and key agreement (EAP-AKA) authentication) may not be possible because the existing profile has already been deactivated or deleted. One aspect of the present disclosure can address such a problem.

[0009] According to one embodiment of the present disclosure, an electronic device (101) may include a communication circuit (190), one or more processors (120) including processing circuitry, and a memory (130) for storing instructions.

[0010] According to one embodiment of the present disclosure, the instructions, when individually or collectively executed by the one or more processors, may cause the electronic device to receive authentication information related to a procedure for transferring a profile from the external electronic device (102; 104; 700) to the electronic device via the communication circuit.

[0011] According to one embodiment of the present disclosure, the instructions, when individually or collectively executed by the one or more processors, may cause the electronic device, in response to receiving the authentication information, to verify a first identifier identifying the procedure.

[0012] According to one embodiment of the present disclosure, the instructions, when individually or collectively executed by the one or more processors, may cause the electronic device to transmit a request message to the first server (520) via the communication circuit, the request message including the first identifier, requesting movement of the profile.

[0013] According to one embodiment of the present disclosure, the instructions, when individually or collectively executed by the one or more processors, may cause the electronic device, in response to transmission of the request message, to receive a response message through the communication circuit, the response message including information for downloading the profile from the first server or a second server (210; 560) different from the first server, from a third server (220; 530).

[0014] According to one embodiment of the present disclosure, the instructions, when individually or collectively executed by the one or more processors, may cause the electronic device to identify a second identifier identifying the procedure based on the response message.

[0015] According to one embodiment of the present disclosure, the instructions, when individually or collectively executed by the one or more processors, may cause the electronic device to determine whether the second identifier is identical to the first identifier.

[0016] According to one embodiment of the present disclosure, the instructions, when individually or collectively executed by the one or more processors, may cause the electronic device to determine, based on whether the second identifier is identical to the first identifier, whether another response message including the second identifier has been received prior to receiving the response message.

[0017] According to one embodiment of the present disclosure, the instructions, when individually or collectively executed by the one or more processors, may cause the electronic device to determine whether to download the profile from the third server based on whether the other response message has been received.

[0018] According to one embodiment of the present disclosure, the instructions, when individually or collectively executed by the one or more processors, cause the electronic device to, at least as part of an operation of determining whether to download the profile from the third server based on whether the other response message has been received, download the profile from the third server through the communication circuit based on information for downloading the profile, based on the other response message not being received.

[0019] According to one embodiment of the present disclosure, a method of an electronic device (101) may be provided, the method including an operation of receiving authentication information from an external electronic device (102; 104; 700) related to a procedure for transferring a profile from the external electronic device to the electronic device.

[0020] According to one embodiment of the present disclosure, the method may include, in response to receiving the authentication information, an operation of identifying a first identifier identifying the procedure.

[0021] According to one embodiment of the present disclosure, the method may include an operation of transmitting a request message requesting movement of the profile, including the first identifier, to the first server (520).

[0022] According to one embodiment of the present disclosure, the method may include, in response to transmitting the request message, receiving a response message including information for downloading the profile from a third server (220; 530), from the first server or a second server (210; 560) different from the first server.

[0023] According to one embodiment of the present disclosure, the method may include an operation of identifying a second identifier identifying the procedure based on the response message.

[0024] According to one embodiment of the present disclosure, the method may include an operation of determining whether the second identifier is identical to the first identifier.

[0025] According to one embodiment of the present disclosure, the method includes an operation of determining whether another response message including the second identifier has been received before receiving the response message, based on whether the second identifier is identical to the first identifier.

[0026] According to one embodiment of the present disclosure, the method may include an operation of determining whether to download the profile from the third server based on whether the other response message has been received.

[0027] According to one embodiment of the present disclosure, the operation of determining whether to download the profile from the third server based on whether the other response message has been received may include the operation of downloading the profile from the third server based on information for downloading the profile, based on whether the other response message has not been received.

[0028] According to one embodiment of the present disclosure, a storage medium storing at least one computer-readable instruction may be provided.

[0029] According to one embodiment of the present disclosure, the at least one instruction, when executed individually or collectively by one or more processors (120) of the electronic device (101), may cause the electronic device to perform at least one operation.

[0030] According to one embodiment of the present disclosure, the at least one operation may include receiving authentication information from an external electronic device (102; 104; 700) that is related to a procedure for transferring a profile from the external electronic device to the electronic device.

[0031] According to one embodiment of the present disclosure, the at least one operation may include, in response to receiving the authentication information, an operation of identifying a first identifier identifying the procedure.

[0032] According to one embodiment of the present disclosure, the at least one operation may include transmitting a request message requesting movement of the profile, including the first identifier, to the first server (520).

[0033] According to one embodiment of the present disclosure, the at least one operation may include, in response to transmitting the request message, receiving a response message including information for downloading the profile from a third server (220; 530), from the first server or a second server (210; 560) different from the first server.

[0034] According to one embodiment of the present disclosure, the at least one operation may include an operation of identifying a second identifier identifying the procedure based on the response message.

[0035] According to one embodiment of the present disclosure, the at least one operation may include an operation of determining whether the second identifier is identical to the first identifier.

[0036] According to one embodiment of the present disclosure, the at least one operation may include an operation of determining whether another response message including the second identifier has been received prior to receiving the response message, based on the second identifier being identical to the first identifier.

[0037] According to one embodiment of the present disclosure, the at least one operation includes an operation of determining whether to download the profile from the third server based on whether the other response message has been received.

[0038] According to one embodiment of the present disclosure, the operation of determining whether to download the profile from the third server based on whether the other response message has been received includes the operation of downloading the profile from the third server based on information for downloading the profile, based on whether the other response message has not been received.

[0039] According to one aspect of the present disclosure, a profile download procedure can be improved by conditionally downloading a profile from a server (e.g., an SM-DP+ server).

[0040] According to the present disclosure, by updating a token without a new authentication procedure, technical problems such as an error situation occurring during a profile transmission procedure, where the validity period of a token expires and authentication based on an existing profile becomes impossible, can be solved.

[0041] Additionally, if an electronic device needs to update authentication information (e.g., a token) to access a carrier's entitlement server, authentication based on the existing profile (e.g., extensible authentication protocol authentication and key agreement (EAP-AKA) authentication) may not be possible because the existing profile has already been deactivated or deleted. One aspect of the present disclosure can address such a problem.

[0042] FIG. 1A is a block diagram of an electronic device within a network environment, according to one embodiment.

[0043] FIG. 1b is a diagram illustrating a network environment including an electronic device according to one embodiment.

[0044] FIG. 2 is a diagram illustrating a system for providing a profile-based communication connection to an electronic device, according to one embodiment.

[0045] FIG. 3 is a block diagram showing the configuration of an electronic device according to one embodiment.

[0046] FIG. 4 is a drawing for explaining the internal structure of an eUICC according to one embodiment.

[0047] FIG. 5 is a block diagram illustrating a network system for profile downloading according to one embodiment.

[0048] Figure 6 is a flowchart illustrating an operation process of an electronic device according to one embodiment.

[0049] FIG. 7a is a signal flow diagram illustrating an ODSA procedure in a wireless communication network according to one embodiment.

[0050] FIG. 7b is a signal flow diagram illustrating an ODSA procedure in a wireless communication network according to one embodiment.

[0051] FIG. 8a is a signal flow diagram illustrating an ODSA procedure in a wireless communication network according to one embodiment.

[0052] FIG. 8b is a signal flow diagram illustrating an ODSA procedure in a wireless communication network according to one embodiment.

[0053] FIG. 8c is a signal flow diagram illustrating an ODSA procedure in a wireless communication network according to one embodiment.

[0054] FIG. 9a is a signal flow diagram illustrating an ODSA procedure in a wireless communication network according to one embodiment.

[0055] FIG. 9b is a signal flow diagram illustrating an ODSA procedure in a wireless communication network according to one embodiment.

[0056] FIG. 10A is a signal flow diagram illustrating an ODSA procedure in a wireless communication network according to one embodiment.

[0057] FIG. 10b is a signal flow diagram illustrating an ODSA procedure in a wireless communication network according to one embodiment.

[0058] FIG. 10c is a signal flow diagram illustrating an ODSA procedure in a wireless communication network according to one embodiment.

[0059] FIG. 11 is a signal flow diagram illustrating an ODSA procedure in a wireless communication network according to one embodiment.

[0060] FIG. 12 is a drawing for explaining an example of screens displayed on an electronic device according to one embodiment.

[0061] FIG. 13 is a drawing for explaining an example of screens displayed on an electronic device according to one embodiment.

[0062] FIG. 14 is a drawing for explaining an example of screens displayed on an electronic device according to one embodiment.

[0063] FIG. 15a is a signal flow diagram illustrating an ODSA procedure in a wireless communication network according to one embodiment.

[0064] FIG. 15b is a signal flow diagram illustrating an ODSA procedure in a wireless communication network according to one embodiment.

[0065] FIG. 16 is a diagram for explaining an operation of an electronic device managing multiple pieces of authentication information in a wireless communication network according to one embodiment.

[0066] FIG. 17a is a signal flow diagram illustrating an ODSA procedure in a wireless communication network according to one embodiment.

[0067] FIG. 17b is a signal flow diagram illustrating an ODSA procedure in a wireless communication network according to one embodiment.

[0068] Hereinafter, an embodiment of the present disclosure will be described in detail with reference to the attached drawings. In addition, when describing an embodiment of the present disclosure, if it is determined that a detailed description of a related known function or configuration may unnecessarily obscure the gist of an embodiment of the present disclosure, such detailed description will be omitted. In addition, the terms described below are terms defined in consideration of the functions in an embodiment of the present disclosure, and these may vary depending on the intention or custom of the user or operator. Therefore, the definitions should be made based on the contents throughout this specification.

[0069] It should be noted that the technical terms used in this specification are merely used to describe specific embodiments and are not intended to limit the embodiments of the present disclosure. Alternatively, unless specifically defined otherwise herein, the technical terms used in this specification should be interpreted as having a meaning generally understood by a person skilled in the art to which the present disclosure pertains, and should not be interpreted in an excessively broad or narrow sense. Alternatively, if a technical term used in this specification is an incorrect technical term that does not accurately express the spirit of the present disclosure, it should be replaced with a technical term that can be correctly understood by a person skilled in the art. Alternatively, general terms used in the embodiments of the present disclosure should be interpreted as defined in the dictionary or according to the context, and should not be interpreted in an excessively narrow sense.

[0070] Alternatively, the singular expressions used herein include plural expressions unless the context clearly dictates otherwise. In this application, terms such as "consist of" or "comprises" should not be construed to necessarily include all of the various components or various operations described in the specification, and should be construed to mean that some of the components or some of the operations may not be included, or that additional components or operations may be included.

[0071] Alternatively, terms including ordinal numbers, such as "first," "second," etc., used herein may be used to describe various components, but the components should not be limited by these terms. These terms are used solely to distinguish one component from another. For example, without departing from the scope of the present disclosure, a first component could be referred to as a "second component," and similarly, a second component could also be referred to as a "first component."

[0072] When a component is referred to as being "connected" or "connected" to another component, it may be directly connected or connected to that other component, but there may also be other components intervening. Conversely, when a component is referred to as being "directly connected" or "connected" to another component, it should be understood that there are no other components intervening.

[0073] Hereinafter, an embodiment of the present disclosure will be described in detail with reference to the attached drawings. Regardless of the drawing numbers, identical or similar components will be given the same reference numbers and redundant descriptions thereof will be omitted. Alternatively, when describing an embodiment of the present disclosure, if a detailed description of a related known technology is determined to obscure the gist of the present disclosure, the detailed description thereof will be omitted. Alternatively, it should be noted that the attached drawings are only intended to facilitate easy understanding of the spirit of the present disclosure and should not be construed as limiting the spirit of the present disclosure by the attached drawings. The spirit of the present disclosure should be construed to extend to all modifications, equivalents, and substitutes other than the attached drawings.

[0074] Hereinafter, in one embodiment of the present disclosure, an electronic device will be described as an example, but the electronic device may be referred to as a terminal, a mobile station, mobile equipment (ME), user equipment (UE), user terminal (UT), subscriber station (SS), wireless device, handheld device, or access terminal (AT). Alternatively, in one embodiment of the present disclosure, the electronic device may be a device having a communication function, such as a mobile phone, a personal digital assistant (PDA), a smart phone, a wireless MODEM, or a laptop.

[0075] FIG. 1a is a block diagram illustrating an electronic device (101) within a network environment (100) according to one embodiment.

[0076] Referring to FIG. 1A, in a network environment (100), an electronic device (101) may communicate with an electronic device (102) via a first network (198) (e.g., a short-range wireless communication network), or may communicate with an electronic device (104) or a server (108) via a second network (199) (e.g., a long-range wireless communication network). In one embodiment, the electronic device (101) may communicate with the electronic device (104) via the server (108). According to one embodiment, the electronic device (101) may include a processor (120), a memory (130), an input module (150), an audio output module (155), a display module (160), an audio module (170), a sensor module (176), an interface (177), a connection terminal (178), a haptic module (179), a camera module (180), a power management module (188), a battery (189), a communication module (190), a subscriber identification module (196), or an antenna module (197). In some embodiments, the electronic device (101) may omit at least one of these components (e.g., the connection terminal (178)), or may have one or more other components added. In some embodiments, some of these components (e.g., the sensor module (176), the camera module (180), or the antenna module (197)) may be integrated into one component (e.g., the display module (160)).

[0077] The processor (120) may, for example, execute software (e.g., a program (140)) to control at least one other component (e.g., a hardware or software component) of the electronic device (101) connected to the processor (120) and perform various data processing or operations. According to one embodiment, as at least a part of the data processing or operations, the processor (120) may store commands or data received from other components (e.g., a sensor module (176) or a communication module (190)) in a volatile memory (132), process the commands or data stored in the volatile memory (132), and store result data in a non-volatile memory (134). According to one embodiment, the processor (120) may include a main processor (121) (e.g., a central processing unit or an application processor) or an auxiliary processor (123) (e.g., a graphics processing unit, a neural processing unit (NPU), an image signal processor, a sensor hub processor, or a communication processor) that can operate independently or together with the main processor (121). For example, when the electronic device (101) includes the main processor (121) and the auxiliary processor (123), the auxiliary processor (123) may be configured to use less power than the main processor (121) or to be specialized for a given function. The auxiliary processor (123) may be implemented separately from the main processor (121) or as a part thereof.

[0078] The auxiliary processor (123) may control at least a portion of functions or states associated with at least one component (e.g., a display module (160), a sensor module (176), or a communication module (190)) of the electronic device (101), for example, on behalf of the main processor (121) while the main processor (121) is in an inactive (e.g., sleep) state, or together with the main processor (121) while the main processor (121) is in an active (e.g., application execution) state. In one embodiment, the auxiliary processor (123) (e.g., an image signal processor or a communication processor) may be implemented as a part of another functionally related component (e.g., a camera module (180) or a communication module (190)). In one embodiment, the auxiliary processor (123) (e.g., a neural network processing unit) may include a hardware structure specialized for processing artificial intelligence models. The artificial intelligence models may be generated through machine learning. This learning can be performed, for example, in the electronic device (101) itself where artificial intelligence is performed, or can be performed through a separate server (e.g., server (108)). The learning algorithm can include, for example, supervised learning, unsupervised learning, semi-supervised learning, or reinforcement learning, but is not limited to the examples described above. The artificial intelligence model can include multiple artificial neural network layers.The artificial neural network may be one of a deep neural network (DNN), a convolutional neural network (CNN), a recurrent neural network (RNN), a restricted Boltzmann machine (RBM), a deep belief network (DBN), a bidirectional recurrent deep neural network (BRDNN), a deep Q-network, or a combination of two or more of the above, but is not limited to the examples described above. In addition to, or alternatively to, a hardware structure, an artificial intelligence model may include a software structure.

[0079] The memory (130) can store various data used by at least one component (e.g., a processor (120) or a sensor module (176)) of the electronic device (101). The data can include, for example, software (e.g., a program (140)) and input data or output data for commands related thereto. The memory (130) can include a volatile memory (132) or a non-volatile memory (134).

[0080] The program (140) may be stored as software in memory (130) and may include, for example, an operating system (142), middleware (144), or an application (146).

[0081] The input module (150) can receive commands or data to be used in a component of the electronic device (101) (e.g., a processor (120)) from an external source (e.g., a user) of the electronic device (101). The input module (150) can include, for example, a microphone, a mouse, a keyboard, a key (e.g., a button), or a digital pen (e.g., a stylus pen).

[0082] The audio output module (155) can output audio signals to the outside of the electronic device (101). The audio output module (155) can include, for example, a speaker or a receiver. The speaker can be used for general purposes, such as multimedia playback or recording playback. The receiver can be used to receive incoming calls. According to one embodiment, the receiver can be implemented separately from the speaker or as part of the speaker.

[0083] The display module (160) can visually provide information to an external party (e.g., a user) of the electronic device (101). The display module (160) may include, for example, a display, a holographic device, or a projector and a control circuit for controlling the device. In one embodiment, the display module (160) may include a touch sensor configured to detect a touch, or a pressure sensor configured to measure the intensity of a force generated by the touch.

[0084] The audio module (170) can convert sound into an electrical signal, or vice versa, convert an electrical signal into sound. According to one embodiment, the audio module (170) can acquire sound through the input module (150), output sound through the sound output module (155), or an external electronic device (e.g., electronic device (102)) (e.g., speaker or headphone) directly or wirelessly connected to the electronic device (101).

[0085] The sensor module (176) can detect the operating status (e.g., power or temperature) of the electronic device (101) or the external environmental status (e.g., user status) and generate an electrical signal or data value corresponding to the detected status. According to one embodiment, the sensor module (176) can include, for example, a gesture sensor, a gyro sensor, a barometric pressure sensor, a magnetic sensor, an acceleration sensor, a grip sensor, a proximity sensor, a color sensor, an IR (infrared) sensor, a biometric sensor, a temperature sensor, a humidity sensor, or an illuminance sensor.

[0086] The interface (177) may support one or more designated protocols that may be used to directly or wirelessly connect the electronic device (101) with an external electronic device (e.g., the electronic device (102)). In one embodiment, the interface (177) may include, for example, a high definition multimedia interface (HDMI), a universal serial bus (USB) interface, an SD card interface, or an audio interface.

[0087] The connection terminal (178) may include a connector through which the electronic device (101) may be physically connected to an external electronic device (e.g., the electronic device (102)). According to one embodiment, the connection terminal (178) may include, for example, an HDMI connector, a USB connector, an SD card connector, or an audio connector (e.g., a headphone connector).

[0088] A haptic module (179) can convert electrical signals into mechanical stimuli (e.g., vibration or movement) or electrical stimuli that a user can perceive through tactile or kinesthetic sensations. According to one embodiment, the haptic module (179) can include, for example, a motor, a piezoelectric element, or an electrical stimulation device.

[0089] The camera module (180) can capture still images and videos. According to one embodiment, the camera module (180) may include one or more lenses, image sensors, image signal processors, or flashes.

[0090] The power management module (188) can manage power supplied to the electronic device (101). According to one embodiment, the power management module (188) can be implemented as, for example, at least a part of a power management integrated circuit (PMIC).

[0091] A battery (189) may power at least one component of the electronic device (101). In one embodiment, the battery (189) may include, for example, a non-rechargeable primary battery, a rechargeable secondary battery, or a fuel cell.

[0092] The communication module (190) may support the establishment of a direct (e.g., wired) communication channel or a wireless communication channel between the electronic device (101) and an external electronic device (e.g., the electronic device (102), the electronic device (104), or the server (108)), and the performance of communication through the established communication channel. The communication module (190) may operate independently from the processor (120) (e.g., an application processor) and may include one or more communication processors that support direct (e.g., wired) communication or wireless communication. According to one embodiment, the communication module (190) may include a wireless communication module (192) (e.g., a cellular communication module, a short-range wireless communication module, or a global navigation satellite system (GNSS) communication module) or a wired communication module (194) (e.g., a local area network (LAN) communication module, or a power line communication module). Among these communication modules, the corresponding communication module can communicate with an external electronic device (104) via a first network (198) (e.g., a short-range communication network such as Bluetooth, Wi-Fi (wireless fidelity) direct, or IrDA (infrared data association)) or a second network (199) (e.g., a long-range communication network such as a legacy cellular network, a 5G network, a next-generation communication network, the Internet, or a computer network (e.g., a LAN or WAN)). These various types of communication modules can be integrated into a single component (e.g., a single chip) or implemented as a plurality of separate components (e.g., multiple chips). The wireless communication module (192) can verify or authenticate the electronic device (101) within a communication network such as the first network (198) or the second network (199) by using subscriber information (e.g., an international mobile subscriber identity (IMSI)) stored in the subscriber identification module (196).

[0093] The wireless communication module (192) can support 5G networks and next-generation communication technologies following the 4G network, such as NR access technology (new radio access technology). The NR access technology can support high-speed transmission of high-capacity data (eMBB (enhanced mobile broadband)), minimization of terminal power and connection of multiple terminals (mMTC (massive machine type communications)), or high reliability and low latency (URLLC (ultra-reliable and low-latency communications)). The wireless communication module (192) can support, for example, a high-frequency band (e.g., mmWave band) to achieve a high data transmission rate. The wireless communication module (192) can support various technologies for securing performance in a high-frequency band, such as beamforming, massive multiple-input and multiple-output (MIMO), full dimensional MIMO (FD-MIMO), array antenna, analog beam-forming, or large scale antenna. The wireless communication module (192) can support various requirements specified in the electronic device (101), an external electronic device (e.g., the electronic device (104)), or a network system (e.g., the second network (199)). According to one embodiment, the wireless communication module (192) can support a peak data rate (e.g., 20 Gbps or more) for eMBB realization, a loss coverage (e.g., 164 dB or less) for mMTC realization, or a U-plane latency (e.g., 0.5 ms or less for downlink (DL) and uplink (UL), or 1 ms or less for round trip) for URLLC realization.

[0094] The antenna module (197) can transmit or receive signals or power to or from an external device (e.g., an external electronic device). According to one embodiment, the antenna module (197) may include an antenna including a radiator formed of a conductor or a conductive pattern formed on a substrate (e.g., a PCB). According to one embodiment, the antenna module (197) may include a plurality of antennas (e.g., an array antenna). In this case, at least one antenna suitable for a communication method used in a communication network, such as the first network (198) or the second network (199), may be selected from the plurality of antennas, for example, by the communication module (190). A signal or power may be transmitted or received between the communication module (190) and an external electronic device via the selected at least one antenna. According to some embodiments, in addition to the radiator, another component (e.g., a radio frequency integrated circuit (RFIC)) may be additionally formed as a part of the antenna module (197).

[0095] In one embodiment, the antenna module (197) may form a mmWave antenna module. In one embodiment, the mmWave antenna module may include a printed circuit board, an RFIC disposed on or adjacent a first side (e.g., a bottom side) of the printed circuit board and capable of supporting a designated high-frequency band (e.g., a mmWave band), and a plurality of antennas (e.g., an array antenna) disposed on or adjacent a second side (e.g., a top side or a side side) of the printed circuit board and capable of transmitting or receiving signals in the designated high-frequency band.

[0096] At least some of the above components may be interconnected and exchange signals (e.g., commands or data) with each other via a communication method between peripheral devices (e.g., a bus, a general purpose input and output (GPIO), a serial peripheral interface (SPI), or a mobile industry processor interface (MIPI)).

[0097] According to one embodiment, commands or data may be transmitted or received between the electronic device (101) and an external electronic device (104) via a server (108) connected to a second network (199). Each of the external electronic devices (102 or 104) may be the same or a different type of device as the electronic device (101). According to one embodiment, all or part of the operations executed in the electronic device (101) may be executed in one or more of the external electronic devices (102, 104, or 108). For example, when the electronic device (101) is to perform a certain function or service automatically or in response to a request from a user or another device, the electronic device (101) may, instead of or in addition to executing the function or service itself, request one or more external electronic devices to perform the function or at least a part of the service. One or more external electronic devices that receive the request may execute at least a portion of the requested function or service, or an additional function or service related to the request, and transmit the result of the execution to the electronic device (101). The electronic device (101) may process the result as is or additionally and provide it as at least a portion of a response to the request. For this purpose, cloud computing, distributed computing, mobile edge computing (MEC), or client-server computing technology may be used, for example. The electronic device (101) may provide an ultra-low latency service by using distributed computing or mobile edge computing, for example. In one embodiment, the external electronic device (104) may include an Internet of Things (IoT) device. The server (108) may be an intelligent server using machine learning and / or a neural network. According to one embodiment, the external electronic device (104) or the server (108) may be included in the second network (199).The electronic device (101) can be applied to intelligent services (e.g., smart home, smart city, smart car, or healthcare) based on 5G communication technology and IoT-related technology.

[0098] Electronic devices according to embodiments disclosed herein may take various forms. Electronic devices may include, for example, portable communication devices (e.g., smartphones), computer devices, portable multimedia devices, portable medical devices, cameras, wearable devices, or home appliances. Electronic devices according to embodiments disclosed herein are not limited to the aforementioned devices.

[0099] The embodiments of this document and the terms used herein are not intended to limit the technical features described in this document to a specific embodiment, but should be understood to include various modifications, equivalents, or substitutes of the embodiment. In connection with the description of the drawings, similar reference numerals may be used for similar or related components. The singular form of a noun corresponding to an item may include one or more of the item, unless the context clearly indicates otherwise. In this document, each of the phrases "A or B", "at least one of A and B", "at least one of A or B", "A, B, or C", "at least one of A, B, and C", and "at least one of A, B, or C" can include any one of the items listed together in the corresponding phrase among those phrases, or all possible combinations thereof. Terms such as "first," "second," or "first" or "second" may be used merely to distinguish one component from another, and do not limit the components in any other respect (e.g., importance or order). When a component (e.g., a first component) is referred to as "coupled" or "connected" to another (e.g., a second component), with or without the terms "functionally" or "communicatively," it means that the component can be connected to the other component directly (e.g., wired), wirelessly, or through a third component.

[0100] The term "module" used in one embodiment of this document may include a unit implemented in hardware, software, or firmware, and may be used interchangeably with terms such as logic, logic block, component, or circuit. A module may be an integral component, or a minimum unit or part of such a component that performs one or more functions. For example, according to one embodiment, a module may be implemented in the form of an application-specific integrated circuit (ASIC).

[0101] An embodiment of the present document may be implemented as software (e.g., a program (140)) including one or more instructions stored in a storage medium (e.g., an internal memory (136) or an external memory (138)) readable by a machine (e.g., an electronic device (101)). For example, a processor (e.g., a processor (120)) of the machine (e.g., an electronic device (101)) may call at least one instruction among the one or more instructions stored from the storage medium and execute it. This enables the machine to operate to perform at least one function according to the at least one called instruction. The one or more instructions may include code generated by a compiler or code executable by an interpreter. The machine-readable storage medium may be provided in the form of a non-transitory storage medium. Here, 'non-transitory' simply means that the storage medium is a tangible device and does not contain signals (e.g., electromagnetic waves), and the term does not distinguish between cases where data is stored semi-permanently or temporarily on the storage medium.

[0102] According to one embodiment, the method according to one embodiment disclosed in the present document may be provided as a computer program product. The computer program product may be traded between sellers and buyers as a product. The computer program product may be distributed in the form of a device-readable storage medium (e.g., compact disc read-only memory (CD-ROM)) or may be provided through an application store (e.g., Play Store). TM ) or directly between two user devices (e.g., smartphones), online distribution (e.g., downloading or uploading). In the case of online distribution, at least a portion of the computer program product may be at least temporarily stored or temporarily created in a machine-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or an intermediary server.

[0103] According to one embodiment, each component (e.g., a module or a program) of the above-described components may include one or more entities, and some of the entities may be separated and placed in other components. According to one embodiment, one or more components or operations of the aforementioned components may be omitted, or one or more other components or operations may be added. Alternatively or additionally, a plurality of components (e.g., a module or a program) may be integrated into a single component. In such a case, the integrated component may perform one or more functions of each of the plurality of components identically or similarly to those performed by the corresponding component among the plurality of components prior to the integration. According to one embodiment, the operations performed by a module, program, or other component may be executed sequentially, in parallel, iteratively, or heuristically, or one or more of the operations may be executed in a different order, omitted, or one or more other operations may be added.

[0104] FIG. 1b is a diagram illustrating a network environment (100) including an electronic device according to one embodiment.

[0105] Referring to FIG. 1b, a network according to an embodiment of the present invention may include an electronic device (101), a first communication network (111a), and / or a second communication network (112a).

[0106] According to one embodiment, the electronic device (101) may operate as a dual SIM dual standby (DSDS) electronic device or a dual SIM dual active (DSDA) electronic device that supports two subscriber identity modules (SIMs) in one device. For example, the electronic device (101) may include a first SIM (111) and an embedded SIM (eSIM) (201). The first SIM (111) may be a removable SIM (rSIM). For example, the electronic device (101) may be equipped with a SIM card. Hereinafter, for convenience of description, the SIM card will be referred to as a SIM. The electronic device (101) may include a slot (not shown) to accommodate the first SIM (111). According to one embodiment, although not separately illustrated in FIG. 1B, the electronic device (101) may accommodate two or more SIMs. In this case, the electronic device (101) may include multiple slots for accommodating multiple SIMs.

[0107] For example, the first SIM (111) may be a SIM subscribed to a telecommunications carrier of the first communication network (111a). The electronic device (101) may receive wireless communication services by connecting to the first communication network (111a) using the first SIM (111). According to one embodiment, the electronic device (101) may include an eSIM (201). The eSIM may also be referred to as an embedded UICC (eUICC). The electronic device (101) may receive wireless communication services by connecting to the second communication network (112a) using the eSIM (201). The first communication network (111a) and the second communication network (112a) may be provided by the same telecommunications carrier, or may be provided by different telecommunications carriers.

[0108] FIG. 2 is a diagram illustrating a system for providing a profile-based communication connection to an electronic device according to one embodiment.

[0109] Referring to FIG. 2, a system (200) according to one embodiment may include an electronic device (101), a subscription manager discovery server (SM-DS) (210), a subscription manager data preparation plus (SM-DP+) server (220), a mobile network operator (MNO) server (230), and a communication service server (240).

[0110] According to one embodiment, an electronic device (101) (e.g., the electronic device (101) of FIG. 1A or FIG. 1B) may include an eSIM (201). Although not separately illustrated in FIG. 2 for convenience of explanation, the electronic device (101) may include at least one slot capable of accommodating at least one rSIM. According to one embodiment, the electronic device (101) may include or accommodate N (wherein N is a natural number) SIMs (e.g., eSIMs or rSIMs) and may perform a switching operation to enable use of some of the N SIMs. In one embodiment, there is no limitation on the combination of the N SIMs, and there may also be no limitation on the value of N.

[0111] According to one embodiment, the eSIM (201) may be inserted into the electronic device (101), may be provided as an integral part of the electronic device (101), or may be implemented so that the electronic device (101) can access it. According to one embodiment, the eSIM (201) may enable the electronic device (101) to perform an authentication operation with the MNO server (230) using information stored in the eSIM (201) (e.g., a profile including universal subscriber identity module (USIM) information). According to one embodiment, the eSIM (201) may be referred to as a SIM card in the global system for mobile communications (GSM) scheme, and may be referred to as a universal subscriber identity module (USIM) card in the case of wideband code division multiple access (WCDMA) scheme, long term evolution (LTE) scheme, and new radio (NR) scheme. In addition, the eSIM (201) may be referred to by various names depending on the communication scheme. For example, when a user of an electronic device (101) subscribes to a wireless communication service provided by a communication service provider, the electronic device (101) may use information in the eSIM (201) (e.g., an international mobile subscriber identity (IMSI) value and a K value, which is an encryption key value for authentication) to perform an appropriate authentication process with an MNO server (230) in which the same IMSI value and encryption key value are stored. If authentication through the authentication process is successful, the electronic device (101) can use the wireless communication service. In one embodiment, the authentication process may be based on an authentication method.The authentication method may be an extensible authentication protocol authentication and key agreement (EAP-AKA), an open identification (OPEN ID), or a short message service one-time password (SMS-OTP). EAP-AKA may be an authentication method that uses a physical SIM (e.g., USIM) or eSIM profile, and may follow RFC 4187, but may not be limited thereto. OPEN ID may be an authentication method that uses an ID / password on a telecommunications operator's web page. SMS-OTP may be an OTP method that uses SMS.

[0112] According to one embodiment, the eSIM (201) may be manufactured as a dedicated card for a specific telecommunications carrier at the request of the telecommunications carrier, and may be pre-loaded with authentication information for network access of the telecommunications carrier (e.g., USIM application and subscriber ID (e.g., IMSI)) and an encryption key value (e.g., a known K value or Ki value). Applications (or information) in the eSIM (201) may be installed, modified, deleted, or updated using various technologies such as OTA (over the air) when necessary.

[0113] According to one embodiment, the eSIM (201) can download and / or store information for providing communication services in the form of a profile. According to one embodiment, the profile can be installed or stored during the manufacturing process of the eSIM (201), or downloaded by the electronic device (101) via OTA and installed or stored in the eSIM (201). For example, the profile can include a provisioning profile and an operational profile. Even if the provisioning profile is not installed, the electronic device (101) can download the operational profile through a short-range connection based on Wi-Fi or an Internet connection, and those skilled in the art will understand that the provisioning profile does not necessarily need to be installed in the electronic device (101). For example, the operational profile may be a profile including subscriber identification information of a user of the electronic device (101), and the provisioning profile may include information (hereinafter also referred to as “first information”) for downloading a profile (hereinafter also referred to as “first operational profile”) including subscriber identification information or subscriber identification information (hereinafter also referred to as “first subscriber identification information”) from the electronic device (101). The electronic device (101) may download the first operational profile based on the first information on the provisioning profile in the eSIM (201).

[0114] According to one embodiment, the electronic device (101) may receive communication services using subscriber identification information (hereinafter also referred to as “second subscriber identification information”) of an operational profile (hereinafter also referred to as “second operational profile”) installed or stored in an eSIM (201). For example, the profile including subscriber identification information may be a SIM profile.

[0115] According to one embodiment, the operational profile may further include, in addition to subscriber identification information, at least one of subscriber network access authentication information, subscriber phone book, subscriber personal information (e.g., short message service (SMS), name of subscribed telecommunications carrier, available services, available data volume, rates or service provision speed, or information related to subscriber authentication and traffic security key generation required when connecting to a wireless communication network such as a GSM communication network, a WCDMA communication network, an LTE communication network, or an NR communication network).

[0116] According to one embodiment, the first information used to download data (e.g., a first operational profile) including first subscriber identification information may include communication session information for a first communication connection designated for downloading the first operational profile. For example, the communication session information may include connection information for an SM-DS (210) for downloading the first operational profile and / or information about a communication service provider network available for connection to the SM-DS (210).

[0117] According to one embodiment, the SM-DS (210) may provide the electronic device (101) with the address of an SM-DP+ server (220) from which the first operational profile can be downloaded based on the provisioning profile.

[0118] According to one embodiment, the SM-DP+ server (220) may be a profile provisioning server, an off-card entity of a profile domain, a profile encryption server, a profile creation server, a profile provisioner, or a profile provider. The SM-DP+ server (220) may establish a first communication connection (22) with the electronic device (101) through a wireless communication network based on a first communication connection request based on a provisioning profile from the electronic device (101), and may provide a first operational profile to the electronic device (101) through the first communication connection (22).

[0119] In one embodiment, the wireless communication network may be a specific node of the wireless communication network. For example, the wireless communication network may be a base station, a subscriber information management node, and / or a mobility management node of the wireless communication network. In one embodiment, the wireless communication network may include a home location register (HLR) and / or an authentication center (AuC) server to which the electronic device (101) connects and performs subscriber authentication functions. If subscriber authentication is successful, the electronic device (101) may connect to the communication service server (240) and receive various communication services, such as voice communication or data communication.

[0120] According to one embodiment, the MNO server (230) may be a server associated with a mobile communication network operator. According to one embodiment, the MNO server (230) may request the SM-DP+ server (220) to prepare at least one profile (or profile package) (e.g., a first operational profile) associated with at least one subscriber identification piece (e.g., first subscriber identification piece) and may transmit information associated with the first operational profile to the SM-DP+ server (220). According to one embodiment, the MNO server (230) may transmit a signal to the SM-DP+ server (220) to update and manage the first operational profile. The MNO server (230) may allow a second communication connection (24) between the electronic device (101) and the communication service server (240) through the second operational profile installed in the eSIM (201) of the electronic device (101).

[0121] According to one embodiment, the communication service server (240) may be a server that provides a communication service. According to one embodiment, the communication service may be a service associated with transmitting and / or receiving data via a wireless communication network. According to one embodiment, the communication service may include a service associated with transmitting and / or receiving other profiles (or data) that do not include subscriber identification information in addition to downloading an operational profile (e.g., a first operational profile including first subscriber identification information). For example, the communication service server (240) may include various service servers associated with transmitting and receiving data, such as a server associated with each of various applications, a push server, a search server, and / or a market server. The communication service by the communication service server (240) may include various services such as transmitting and receiving data by an application, receiving notifications, receiving push messages, receiving and connecting links, and / or requesting services.

[0122] According to one embodiment, the electronic device (101) may establish a second communication connection (24) with a communication service server (240) based on a second operational profile when requesting a service associated with transmission and / or reception of a profile (or data) that does not include subscriber identification information.

[0123] According to one embodiment, the SM-DS (210), the SM-DP+ server (220), the MNO server (230), and / or the communication service server (240) are merely examples of entities implemented in the form of servers for performing the corresponding functions, and may also be referred to by other names, and each of the SM-DS (210), the SM-DP+ server (220), the MNO server (230), and / or the communication service server (240) may be implemented as one or more servers. Some or all of the SM-DS (210), the SM-DP+ server (220), the MNO server (230), and / or the communication service server (240) may also be implemented as a single integrated server.

[0124] Figure 3 is a block diagram showing the configuration of an electronic device according to one embodiment.

[0125] Referring to FIG. 3, the electronic device (101) of FIG. 1A or FIG. 1B, or the electronic device (101) of FIG. 2 according to one embodiment may include a processor (120), an eSIM (201), a communication module (190), a display module (160), and an input module (150). Although not separately illustrated for convenience of explanation, the electronic device (101) may include two or more slots capable of accommodating two or more rSIMs.

[0126] According to one embodiment, the processor (120) (e.g., the processor (120) of FIG. 1A) may include one or more processors (e.g., the main processor (121) and the auxiliary processor (123) of FIG. 1A or the application processor and the communication processor), and may include a local profile assistant (LPA) (312) (e.g., LPAd (device)) according to one embodiment. According to one embodiment, when the processor (120) includes multiple processors, some of the multiple processors may include a part of the LPA (312), and other parts of the LPA (312) may be included in other processors. According to one embodiment, the LPA (312) may be included in the eSIM (201), in which case the LPA (312) may be referred to as LPAe (eUICC).

[0127] According to one embodiment, the LPA (312) may perform operations to communicate with a server to support profile download, installation, and management operations of the eSIM (201), or to provide a user interface (UI) required for the profile download, installation, and management operations. The LPA (312) may be a module that provides local discovery services (LDS) (31), local profile download (LPD) (33), and local user interface (LUI) (35) operations within the electronic device (101).

[0128] According to one embodiment, the LDS (31) may perform an operation of communicating with the SM-DS (210), and an operation of receiving an address of an SM-DP+ server (220) capable of downloading an operational profile based on a provisioning profile from the SM-DS (210).

[0129] According to one embodiment, the LPD (33) may perform an operation of establishing a first communication connection (22) with the SM-DP+ server (220) through a wireless communication network based on the address of the SM-DP+ server (220), and receiving a first operational profile from the SM-DP+ server (220) through the first communication connection (22). According to one embodiment, the LPD (33) may support a profile download, enable, disable, delete, or profile policy rule (PPR) download operation initiated by the network, or support a profile activation, disable, delete, or eUICC reset operation by the electronic device (101).

[0130] According to one embodiment, the LUI (35) can perform an operation of providing various UIs when downloading an operational profile. According to one embodiment, the LUI (35) can support data exchange between the LDS (31) and the LPD (33) and the user, and can include a UI that transmits the user's input to the LDS (31) or the LPD (33).

[0131] According to one embodiment, the processor (120) may perform a communication service based on information stored in the eSIM (201) by using (or executing) the LPA (312). For example, the processor (120) may use the LPA (312) to establish a first communication connection to download a profile (e.g., a first operational profile) including first subscriber identification information from the SM-DP+ server (220) through the communication module (190) based on a provisioning profile stored in the eSIM (201). While establishing the first communication connection using the LPA (312), the processor (120) may release the first communication connection when a request is made to transmit and / or receive a profile and / or data that does not include subscriber identification information, and may establish a second communication connection based on second subscriber identification information to perform an operation of transmitting and / or receiving a profile and / or data that does not include subscriber identification information.

[0132] According to one embodiment, an eSIM (201) (e.g., the subscriber identification module (196) of FIG. 1A or the eSIM (201) of FIG. 2) may include one or more profiles as information for receiving communication services. A profile may mean at least one of an application, a file system, or an authentication key value stored in the eSIM (201) packaged in software form. For example, the profile may include a provisioning profile and an operational profile. The operational profile may include subscriber identification information, and in addition to the subscriber identification information, may further include at least one of the subscriber's network access authentication information, the subscriber's phone book, the subscriber's personal information (e.g., SMS), the name of the subscribed telecommunications carrier, available services, available data volume, rates or service provision speed, or information related to subscriber authentication and traffic security key generation required when connecting to a wireless communication network such as a GSM communication network, a WCDMA communication network, an LTE communication network, or an NR communication network. In one embodiment, the operational profile may include a SIM profile. For example, the SIM profile may include a SIM file system (master file (MF), dedicated file (DF), and elementary files (EF)), and the elementary files may store subscriber identification information (e.g., IMSI) values.

[0133] According to one embodiment, the provisioning profile may be a profile including first information for downloading a first operational profile from the electronic device (101). For example, the first information may include communication session information for a first communication connection designated for downloading the first operational profile. For example, the communication session information may include connection information for an SM-DS (e.g., SM-DS (210) of FIG. 2) for downloading the first operational profile, and may include information on a communication service provider network available for connection to the SM-DS.

[0134] According to one embodiment, the communication module (190) (e.g., the communication module (190) of FIG. 1A) may perform a first communication based on a provisioning profile or a second communication based on a second operational profile. At least one screen associated with the first communication based on the provisioning profile or the second communication based on the second operational profile may be displayed on the display module (160).

[0135] In FIG. 3, the form in which the LPA (312) is included in the processor (120) is described as an example, but at least some functions of the LPA (312) may be performed in the processor (120), or a separate LPA (312) may operate in conjunction with the processor (120). For example, the LPA (312) may be included in a program (e.g., the program (140) of FIG. 1A), may be loaded into the processor (120) and executed, and when the LPA (312) is loaded into the processor (120) and executed, it may be understood as the operation of the processor (120). According to one embodiment, the function modules included in the LPA (312) (e.g., the LDS (31), the LPD (33), and / or the LUI (35)) are illustratively separated, may be expressed as other function modules, and may not be limited to that form. According to one embodiment, the LPA (312) may be included within the eSIM (201).

[0136] FIG. 4 is a drawing for explaining the internal structure of an eUICC according to one embodiment.

[0137] Referring to FIG. 4, an eUICC (401) (e.g., an eSIM (201) of FIG. 2 or 3) may have a form such as a card or a chip, and at least one profile (e.g., profile (410), profile (420), profile (430)) having a software format may be installed. According to one embodiment, each of the profiles (410, 420, 430) may be a provisioning profile or an operational profile. The profiles (410, 420, 430) may operate on an eUICC operating system (OS) (450). Each of the profiles (410, 420, 430) may be enabled or disabled by a processor or an LPA (e.g., LPA (312) of FIG. 3 or LPA (480) of FIG. 4). In FIG. 4, it can be assumed that one profile (410) is in an enabled state, and the remaining profiles (420, 430) are in a disabled state. In one embodiment, two or more profiles may be activated within the eUICC (401).

[0138] According to one embodiment, the eUICC OS (450) of the eUICC (401) may include a profile policy enabler (452), a profile package interpreter (454), and a telecom framework (456). According to one embodiment, the profile policy enabler (452) may manage policy rules (e.g., profile policy rules (PPR)) for each of the profiles (410, 420, 430). According to one embodiment, the profile package interpreter (454) may unpackage a profile package received from an SM-DP+ server (e.g., the SM-DP+ server (220) of FIG. 2) into a form that can be installed in the eUICC (401). According to one embodiment, the telecom framework (456) may perform functions related to communication of applications in the eUICC (401). According to one embodiment, the eUICC (401) may include an issuer security domain root (ISD-R) (460) and an eUICC controlling authority security domain (ECASD) (470). According to one embodiment, the ISD-R (460) may manage profiles (410, 420, 430) installed in the eUICC (401). For example, the ISD-R (460) may include LPA services (462), and the LPA services (462) may manage profiles (410, 420, 430) installed in the eUICC (401) through an interface with a processor or an LPA (e.g., an LPA (312) of FIG. 3 or an LPA (480) of FIG. 4).According to one embodiment, ECASD (470) can perform security processing for profiles (410, 420, 430) installed in eUICC (401).

[0139] According to one embodiment, each of the profiles (410, 420, 430) may include an ISD-P (410-1, 420-1, or 430-1), an MNO-SD (410-2, 420-2, or 430-2), an SSD (supplementary security domain) (410-3, 420-3, or 430-3), a CASD (controlling authority security domain) (410-4, 420-4, or 430-4), Applets (410-5, 420-5, or 430-5), NAAs (network access applications) (410-6, 420-6, or 430-6), a file system (410-7, 420-7, or 430-7), or profile metadata (410-8, 420-8, or 430-8) may be included.

[0140] According to one embodiment, the ISD-P (410-1, 420-1, or 430-1) may include information for decoding and interpreting a profile package and may be used in cooperation with a profile package interpreter (454) to unpackage and install a profile package received from an SM-DP+ server.

[0141] According to one embodiment, the MNO-SD (410-2, 420-2, or 430-2) may include an OTA key of the MNO and may include information for providing a secure OTA channel to communicate with the MNO.

[0142] According to one embodiment, the SSD (410-3, 420-3, or 430-3) and the CASD (410-4, 420-4, or 430-4) may include information for performing security processing on the profile.

[0143] According to one embodiment, Applets (410-5, 420-5, or 430-5) may include various application information associated with a user of the profile.

[0144] In one embodiment, the NAAs (410-6, 420-6, or 430-6) may include application information that enables the profile to connect to the network.

[0145] According to one embodiment, the file system (410-7, 420-7, or 430-7) may include a file system associated with each piece of information in the profile.

[0146] According to one embodiment, profile metadata (410-8, 420-8, or 430-8) may also be referred to as a profile record and may include metadata information about the profile in text form. The metadata information may include at least one of an integrated circuit card ID (ICCID) of the profile, a profile name, a name of an MNO providing the profile, a user's profile nickname, an icon, a profile class, notification configuration information, profile owner information, or a PPR.

[0147] According to one embodiment, the ICCID of a profile may represent a unique identifier of each profile as a profile identifier. The name of the profile may include the name of each profile. The name of the MNO providing the profile may include the name of the telecommunications operator providing the profile. The user's profile nickname may include a profile nickname specified by the user. The icon may include an icon corresponding to the profile. The profile class may include information indicating whether the type of the profile is a provisioning profile or an operational profile. The notification configuration information may include the address of a server to receive the notification (e.g., the SM-DP+ server (220) of FIG. 2). The profile owner information may include at least one of a mobile country code (MCC), a mobile network code (MNC), or group identifier (GID) 1 or 2 information associated with the profile owner. For example, the MCC may be a code for identifying a country, and the MNC may be a code for identifying a mobile communications operator. GID 1 or 2 may be code region information identifying the group or region to which the profile belongs. Region information may include information about a group that includes multiple countries. PPR may include policy rule information for managing the profile.

[0148] According to one embodiment, an electronic device (e.g., the electronic device (101) of FIG. 1A or FIG. 1B, the electronic device (101) of FIG. 2, or the electronic device (101) of FIG. 3) may identify whether each of the profiles (410, 420, 430) is a provisioning profile or an operational profile based on profile class information of profile metadata (410-8, 420-8, or 430-8) included in each of the profiles (410, 420, 430) included in an eUICC (401), and may activate or deactivate the provisioning profile or the operational profile, respectively, through an LPA (480) (e.g., the LPA (312) of FIG. 3).

[0149] FIG. 5 is a block diagram illustrating a network system for circuit movement according to one embodiment.

[0150] Referring to FIG. 5, a network system according to one embodiment may include an electronic device (101) (e.g., the electronic device (101) of FIG. 1A or FIG. 1B, the electronic device (101) of FIG. 2, or the electronic device (101) of FIG. 3), and a communication service provider server (500).

[0151] The telecommunications operator server (500) may include at least one of an entitlement server (or entitlement configuration server) (520), an SM-DP+ server (530), an authentication server (540), business support systems (BSS) / operation support systems (OSS) (550), or an SM-DS (560).

[0152] According to one embodiment, the telecommunications carrier server (500) may or may not include a web server (510). For example, at least one of the web server (510), the entitlement server (520), the SM-DP+ server (530), the authentication server (540), or the BSS / OSS (550) may be included in the telecommunications carrier server (500) managed by the telecommunications carrier. According to one embodiment, the web server (510) and the entitlement server (520) may be servers managed by the same telecommunications carrier or different telecommunications carriers. According to one embodiment, the entitlement server (520) and the SM-DP+ server (530) may be servers managed by the same telecommunications carrier or different telecommunications carriers.

[0153] An electronic device (101) may have an eSIM (201) inserted therein, or the eSIM (201) may be built into the electronic device (101). A profile may be downloaded and installed on the eSIM (201). A service client (202) may be installed on the electronic device (101) for communication with a telecommunications service provider server (500) according to an embodiment described below. In one embodiment, the electronic device (101) may not include an eSIM (201) but may include a physical SIM, and a profile may be downloaded and installed on the physical SIM.

[0154] According to one embodiment, the electronic device (101) may connect to an entitlement server (520) via a service client (202), and may connect to a web server (510) via the connected entitlement server (520). For example, when the electronic device (101) connects to the entitlement server (520), the entitlement server (520) may perform authentication operations and eligibility check operations on the electronic device (101) or the user of the electronic device (101) via the BSS / OSS (550) or the authentication server (540). The entitlement server (520) may transmit information required for access to the web server (510) to the electronic device (101) when the authentication operation and eligibility check operation for the electronic device (101) or the user of the electronic device (101) are successful (e.g., when the authentication for the electronic device (101) or the user of the electronic device (101) is successful and the electronic device (101) or the user of the electronic device (101) is eligible).

[0155] The electronic device (101) may access the web server (510) using information required for accessing the web server (510) received through the entitlement server (520). According to one embodiment, the electronic device (101) may request subscription, opening, or line transfer (or subscription transfer or profile transfer) through a web page provided by the web server (510). According to one embodiment, the electronic device (101) may also request subscription, opening, or line transfer through the entitlement server (520) without the web server (510). For example, if the telecommunications service provider server (500) does not include a web server (510), or if the telecommunications service provider server (500) includes a web server (510) but does not provide information related to the web server (510) (e.g., the address of the web server (510)) (e.g., does not provide web services or web pages through the web server (510)), the electronic device (101) may request subscription, opening, or line transfer through the entitlement server (520). In one embodiment, the web server (510) may provide a UI or web page for the entitlement server (520). For example, the electronic device (101) may request subscription, opening, or line transfer through a web page provided from the web server (510). In one embodiment, the entitlement server (520) may provide management and creation of lines, service control, and status information. For example, the entitlement server (520) may include an entitlement server or an entitlement setting server specified in the GSMA (GSM association) standard document TS. 43. Standard document TS.In 43, the term "entitlement" may include the meaning of the applicability, availability, or status of a service required before providing a service (e.g., a communication service) to a user of an electronic device (101). For example, the entitlement server (520) may perform a function of transmitting information related to a profile provided to the electronic device (101) (e.g., profile download information or profile download-related information). In the description below, the profile information may include information related to the profile, and for the convenience of description, may also be referred to as profile download information or profile download-related information. The entitlement server (520) may include, but is not limited to, a discovery and push function (DPF), an SM-DS, an SM-SR (subscription manager secure routing), an SM-SR+ (subscription manager secure routing plus), an off-card entity of an eUICC Profile Manager or a PMC holder (profile management credentials holder), or an EM (eUICC manager).

[0156] According to one embodiment, the SM-DP+ server (530) may perform functions of managing and downloading profiles. For example, the SM-DP+ server (530) may further include, but is not limited to, at least one of an SM-DP (subscription manager data preparation), an off-card entity of a Profile Domain, a profile encryption server, a profile creation server, a profile provisioner (PP), a profile provider, or a PPC holder (profile provisioning credentials holder), in addition to the SM-DP+.

[0157] According to one embodiment of the present disclosure, an electronic device (101) may include a communication circuit (190), one or more processors (120) including processing circuitry, and a memory (130) for storing instructions.

[0158] According to one embodiment of the present disclosure, the instructions, when individually or collectively executed by the one or more processors, may cause the electronic device to receive authentication information related to a procedure for transferring a profile from the external electronic device (102; 104; 700) to the electronic device via the communication circuit.

[0159] According to one embodiment of the present disclosure, the instructions, when individually or collectively executed by the one or more processors, may cause the electronic device, in response to receiving the authentication information, to verify a first identifier identifying the procedure.

[0160] According to one embodiment of the present disclosure, the instructions, when individually or collectively executed by the one or more processors, may cause the electronic device to transmit a request message to the first server (520) via the communication circuit, the request message including the first identifier, requesting movement of the profile.

[0161] According to one embodiment of the present disclosure, the instructions, when individually or collectively executed by the one or more processors, may cause the electronic device, in response to transmission of the request message, to receive a response message through the communication circuit, the response message including information for downloading the profile from the first server or a second server (210; 560) different from the first server, from a third server (220; 530).

[0162] According to one embodiment of the present disclosure, the instructions, when individually or collectively executed by the one or more processors, may cause the electronic device to identify a second identifier identifying the procedure based on the response message.

[0163] According to one embodiment of the present disclosure, the instructions, when individually or collectively executed by the one or more processors, may cause the electronic device to determine whether the second identifier is identical to the first identifier.

[0164] According to one embodiment of the present disclosure, the instructions, when individually or collectively executed by the one or more processors, may cause the electronic device to determine, based on whether the second identifier is identical to the first identifier, whether another response message including the second identifier has been received prior to receiving the response message.

[0165] According to one embodiment of the present disclosure, the instructions, when individually or collectively executed by the one or more processors, may cause the electronic device to determine whether to download the profile from the third server based on whether the other response message has been received.

[0166] According to one embodiment of the present disclosure, the instructions, when individually or collectively executed by the one or more processors, cause the electronic device to, at least as part of an operation of determining whether to download the profile from the third server based on whether the other response message has been received, download the profile from the third server through the communication circuit based on information for downloading the profile, based on the other response message not being received.

[0167] According to one embodiment of the present disclosure, the instructions, when individually or collectively executed by the one or more processors, may cause the electronic device to refrain from downloading the profile from the third server based on whether the other response message has been received, at least as part of an operation of determining whether to download the profile from the third server based on whether the other response message has been received.

[0168] According to one embodiment of the present disclosure, the instructions, when individually or collectively executed by the one or more processors, may cause the electronic device to discard the response message based on the receipt of the other response message.

[0169] According to one embodiment of the present disclosure, the instructions, when individually or collectively executed by the one or more processors, may cause the electronic device to verify the second identifier from a third identifier included in the response message based on the response message being received from the second server.

[0170] According to one embodiment of the present disclosure, the third identifier is used to identify an event between the second server and the third server and may be associated with the procedure.

[0171] According to one embodiment of the present disclosure, the third identifier may be generated based on the second identifier and a setting rule.

[0172] According to one embodiment of the present disclosure, the third identifier may be generated based on the fourth identifier.

[0173] According to one embodiment of the present disclosure, the fourth identifier is used to identify an event between the first server and the third server and may be associated with the procedure.

[0174] According to one embodiment of the present disclosure, the fourth identifier can be identified from the first identifier.

[0175] According to one embodiment of the present disclosure, the fourth identifier may be generated based on the first identifier and other setup rules.

[0176] According to one embodiment of the present disclosure, the other setting rule may include one of a rule for generating the first identifier as the fourth identifier, a rule for generating the fourth identifier by concatenating a value generated by the first server or the third server, a setting delimiter, and the first identifier, or a rule for generating the fourth identifier by concatenating a prefix for detecting the first identifier, the first identifier, and the value.

[0177] According to one embodiment of the present disclosure, the response message received from the first server may include the second identifier.

[0178] According to one embodiment of the present disclosure, the instructions, when individually or collectively executed by the one or more processors, may cause the electronic device to receive the first identifier from the second server via the communication circuitry, in response to receiving the authentication information.

[0179] According to one embodiment of the present disclosure, the instructions, when individually or collectively executed by the one or more processors, may cause the electronic device to generate the first identifier in response to receiving the authentication information.

[0180] According to one embodiment of the present disclosure, the instructions, when individually or collectively executed by the one or more processors, may cause the electronic device to identify a user input to initiate downloading of the profile before downloading the profile.

[0181] Figure 6 is a flowchart illustrating an operation process of an electronic device according to one embodiment.

[0182] Referring to FIG. 6, at operation 611, an electronic device (e.g., electronic device (101) of FIGS. 1A, 1B, 2, 3, and / or 5) (e.g., processor (e.g., processor (120) of FIGS. 1A and / or 3)) may receive authentication information from an external electronic device (e.g., electronic device (102) and / or electronic device (104) of FIG. 1A) related to a procedure for moving a profile from the electronic device to the external electronic device. For example, the electronic device may be an existing electronic device that has stored a profile associated with the subscription (e.g., an existing profile), and the external electronic device may be a new electronic device from which to download a profile associated with the subscription (e.g., a new profile). In one embodiment, the procedure for moving a profile may be an ODSA procedure. Hereinafter, for convenience of explanation, the movement of a profile (subscription or line) from an electronic device to an external electronic device may be referred to as "moving a profile from an electronic device to an external electronic device." In the following explanation, "moving a profile from an electronic device to an external electronic device" may be used interchangeably with "moving a subscription from an electronic device to an external electronic device," "moving a line from an electronic device to an external electronic device," or "moving a SIM of an electronic device to an external electronic device." Hereinafter, for convenience of explanation, the procedure for moving a profile may be referred to as a "profile movement procedure." In one embodiment, the authentication information may include a temporary token used for the profile movement procedure, and may be generated by a first server (e.g., the entitlement server (520) of FIG. 5) based on a request from an external electronic device.

[0183] An electronic device that has received authentication information related to a profile migration procedure may, in operation 613, verify a first identifier (e.g., OdsaEventID) that identifies the profile migration procedure in response to receiving the authentication information. In one embodiment, the first identifier may include an identifier for identifying the profile migration procedure (or ODSA procedure). In one embodiment, the electronic device may generate the first identifier in response to receiving the authentication information. In one embodiment, a generation rule (or generation function) for generating the first identifier may be implemented in various forms. Alternatively, the electronic device may, in response to receiving the authentication information, receive from a second server (e.g., SM-DS (210) of FIG. 2 or SM-DS (560) of FIG. 5) related to the profile migration procedure.

[0184] An electronic device that has identified a first identifier for identifying a profile migration procedure may, in operation 615, transmit a request message requesting migration of a profile, including the first identifier, to a first server related to the profile migration procedure. For example, the request message requesting migration of a profile may be a hypertext transfer protocol (HTTP) request (HTTP REQUEST) message and may include "ManageSubscription" as ODSA operation information. "ManageSubscription" may be ODSA operation information used to request a subscription-related operation. The ODSA operation information may be implemented similarly or substantially identically to the ODSA information specified in the standard document TS. 43, and the ODSA operation information will be described with reference to Table 1 below, and therefore a detailed description thereof will be omitted herein.

[0185] An electronic device that has transmitted a request message requesting profile transfer may, in operation 617, receive a response message including information for downloading a profile from a third server (e.g., the SM-DP+ server (220) of FIG. 2 or the SM-DP+ server (530) of FIG. 5) in response to the transmission of the request message, from the first server or the second server. For example, the response message including information for downloading a profile may be a push message or an answer message. Hereinafter, for convenience of explanation, the information for downloading a profile may also be referred to as download information. In one embodiment, the download information may include an address of a third server from which the profile can be downloaded. In one embodiment, the download information may be implemented similarly or substantially identically to the download information specified in the standard document TS. 43, and since the download information will be described with reference to Table 6 below, a detailed description thereof will be omitted herein.

[0186] An electronic device that receives a response message including download information may, in operation 619, check a second identifier (e.g., OdsaEventID) that identifies a profile migration procedure based on the response message. In one embodiment, if the response message is a push message received from a first server, the push message may include the second identifier. In one embodiment, if the response message is a reply message received from a second server, the reply message may include a third identifier (e.g., EventID), and the electronic device may check the second identifier based on the third identifier. In one embodiment, the EventID may be an identifier used to identify an event between the second server and the third server (e.g., an ongoing ODSA procedure (e.g., an ongoing profile migration procedure)), and since the EventID may be implemented similar to or substantially identical to the EventID specified in GSMA standard document SPG. 22, a detailed description thereof will be omitted herein.

[0187] The electronic device, having verified the second identifier, may, in operation 621, verify whether the second identifier is identical to the first identifier. If the verification result shows that the second identifier is not identical to the first identifier (operation 621—No), the electronic device may verify that the profile migration procedure corresponding to the second identifier is not a profile migration procedure related to the electronic device. In this case, the electronic device may, in operation 627, refrain from downloading the profile from the third server. In operation 627, the electronic device may additionally discard the received response message and perform no further operations.

[0188] If the verification result shows that the second identifier is the same as the first identifier (operation 621 - Yes), the electronic device can, in operation 623, check whether another response message including the second identifier has been received before receiving the response message.

[0189] If, upon verification, no other response message containing the second identifier was received prior to receiving the response message (action 623-No), the electronic device may, in action 625, download the profile from the third server based on the download information.

[0190] If, upon verification, another response message including the second identifier is received prior to receiving the response message (operation 623 - Yes), the electronic device may, in operation 627, refrain from downloading the profile from the third server. In operation 627, the electronic device may additionally discard the received response message and perform no further actions.

[0191] FIG. 7a is a signal flow diagram illustrating an ODSA procedure in a wireless communication network according to one embodiment.

[0192] FIG. 7b is a signal flow diagram illustrating an ODSA procedure in a wireless communication network according to one embodiment.

[0193] Referring to FIGS. 7A and 7B , the wireless communication network may include an electronic device (101) (e.g., the electronic device (101) of FIGS. 1A , 1B , 2 , 3 , and / or 5 ), an external electronic device (700) (e.g., the electronic device (102) of FIG. 1A and / or the electronic device (104) of FIG. 1A ), an entitlement server (520) (e.g., the entitlement server (520) of FIG. 5 ), an SM-DP+ server (530) (e.g., the SM-DP+ server (220) of FIG. 2 and / or the SM-DP+ server (530) of FIG. 5 ), and / or an SM-DS (560) (e.g., the SM-DS (210) of FIG. 2 and / or the SM-DS (560) of FIG. 5 ). The external electronic device (700) may be an existing electronic device that stores a profile associated with the subscription (e.g., an existing profile), and the electronic device (101) may be a new electronic device from which to download a profile associated with the subscription (e.g., a new profile). The ODSA procedure illustrated in FIGS. 7A and 7B may include a profile transfer (or subscription transfer or line transfer) procedure between electronic devices.

[0194] In operation 701, the external electronic device (700) can confirm a user input associated with a profile transfer between electronic devices (e.g., a user input selecting a profile transfer (or subscription transfer or line transfer) between electronic devices). For example, the external electronic device (700) can output (e.g., display) a UI (e.g., a profile transfer menu between electronic devices) for selecting a profile transfer between electronic devices, and can confirm the user input through the UI. The UI can include information to the effect of selecting to transfer a profile of the external electronic device (700) to the electronic device (101), or can include information to the effect of selecting to transfer a profile (or subscription or line) from the external electronic device (700) to the electronic device (101) for intuitive recognition by the user.

[0195] Based on a user input selecting to move a profile between electronic devices, the external electronic device (700) may perform an EAP-AKA authentication process with the entitlement server (520) in operation 701. In one embodiment, the EAP-AKA authentication process may represent an authentication process based on the EAP-AKA method. Although FIGS. 7A and 7B illustrate an example where the authentication process between the external electronic device (700) and the entitlement server (520) is an EAP-AKA authentication process, there may be no limitations on the authentication process between the external electronic device (700) and the entitlement server (520).

[0196] If the result of the EAP-AKA authentication process indicates success, the external electronic device (700) can obtain authentication information (e.g., a token). In FIGS. 7A and 7B , it is assumed that the result of the EAP-AKA authentication process indicates success. If the result of the EAP-AKA authentication process indicates failure, the external electronic device (700) may not perform any further operations.

[0197] The external electronic device (700) that has acquired authentication information may perform an eligibility check with the entitlement server (520) in operation 702 to transfer the profile of the external electronic device (700) to the electronic device (101). The external electronic device (700) may request an eligibility check for the electronic device (101) to the entitlement server (520) based on the hypertext transfer protocol (HTTP) GET method or the HTTP POST method. For example, the external electronic device (700) may request an eligibility check for the electronic device (101) by transmitting a first request message requesting an eligibility check to the entitlement server (520). According to one embodiment, the first request message may be a request message requesting an eligibility check, for example, an HTTP REQUEST message.

[0198] An external electronic device (700) may transmit a first request message including any one of the ODSA operation (OSDA) information as shown in Table 1 below to an entitlement server (520) according to the ODSA procedure specified in standard document TS. 43. The ODSA information as shown in Table 1 may be implemented similarly or substantially identically to the ODSA information specified in standard document TS. 43, and thus a detailed description thereof will be omitted herein.

[0199] Table 1

[0200]

[0201] Referring to , an external electronic device (700) may request an eligibility check by sending a first request message (e.g., an HTTP REQUEST("CheckEligibility") message) including "CheckEligibility" as ODSA operation information to an entitlement server (520) according to the ODSA procedure specified in standard document TS. 43 in operation 702.

[0202] Although not depicted separately in FIGS. 7A and 7B , the entitlement server (520) may transmit a profile query to the BSS / OSS (e.g., the BSS / OSS (550) of FIG. 5 ). The profile query may include subscription identification information (e.g., "SubscriptionID"). The BSS / OSS may transmit a profile answer corresponding to the profile query to the entitlement server (520).

[0203] The entitlement server (520), which has received a first request message including CheckEligibility as ODSA operation information from an external electronic device (700), can perform an eligibility check on the electronic device (101) based on the first request message including CheckEligibility as ODSA operation information in operation 703.

[0204] If the result of the eligibility check for the electronic device (101) indicates success, the entitlement server (520) may, in operation 703, transmit a 200 OK message (e.g., an HTTP 200 OK message) as a response message to the first request message to the external electronic device (700). In FIGS. 7A and 7B , it is assumed that the result of the eligibility check for the electronic device (101) indicates success, and if the result of the eligibility check for the electronic device (101) indicates failure, no further operations may be performed. In one embodiment, if the result of the eligibility check indicates success, the 200 OK message may include information of "ENABLED."

[0205] The external electronic device (700), which has received a 200 OK message from the entitlement server (520), may request temporary authentication information (e.g., a temporary token) that may be used by the electronic device (101) by sending a second request message (e.g., an HTTP REQUEST("AcquireTemporaryToken") message) including "AcquireTemporaryToken" as ODSA operation information to the entitlement server (520) in operation 704. In one embodiment, the temporary authentication information may be temporary authentication information related to an ongoing ODSA procedure (e.g., an ongoing profile transfer procedure).

[0206] The entitlement server (520), which receives a second request message including AcquireTemporaryToken as ODSA operation information from the external electronic device (700), may generate a temporary token based on the second request message including AcquireTemporaryToken as ODSA operation information in operation 705. The entitlement server (520) may generate the temporary token if the electronic device (101) is permitted to use the subscription (or profile) for the external electronic device (700). In FIGS. 7A and 7B , it is assumed that the electronic device (101) is permitted to use the subscription (or profile) for the external electronic device (700), and if the electronic device (101) is not permitted to use the subscription (or profile) for the external electronic device (700), no further operations may be performed.

[0207] The entitlement server (520) that generated the temporary token can, in operation 705, transmit a 200 OK message (e.g., an HTTP 200 OK (TemporaryToken) message) including the temporary token as a response message to the second request message to the external electronic device (700).

[0208] An external electronic device (700) that has received a 200 OK message including a temporary token from an entitlement server (520) may transmit a message including the temporary token to the electronic device (101) in operation 706. For example, operation 706 is illustrated as "TemporaryToken".

[0209] The electronic device (101), which has received a message including a temporary token from the electronic device (101), may generate a first identifier (e.g., OdsaEventID) associated with an ongoing ODSA procedure (e.g., an ongoing profile migration procedure) in operation 707. In one embodiment, the first identifier may be an identifier for identifying the ongoing ODSA procedure. In one embodiment, a generation rule (or generation function) for generating the first identifier may be implemented in various forms.

[0210] The electronic device (101) that generated the first identifier may, in operation 708, transmit a third request message (e.g., an HTTP REQUEST("ManageSubscription") message) that includes "ManageSubscription" as ODSA operation information and the first identifier (e.g., OdsaEventID) to the entitlement server (520). In one embodiment, the third request message may be a message requesting a subscription management operation. In one embodiment, the subscription management operation may include various operations related to subscription.

[0211] In one embodiment, the third request message may include ODSA operation information of "ManageSubscrition" as shown in Table 2. "ManageSubscrition" may be ODSA operation information used to request a subscription-related operation. According to one embodiment, the third request message may include operation type (operation_type) information as shown in Table 2 below. The operation type information as shown in Table 2 may be implemented similarly or substantially identically to the operation type information specified in the standard document TS. 43, and therefore, a detailed description thereof will be omitted herein.

[0212] Table 2

[0213]

[0214] Referring to , the third request message including "ManageSubscription" of as ODSA operation information may include one of the operation types of "SUBSCRIBE", "UNSUBSCRIBE", "CHANGE SUBSCRIPTION", "TRANSFER SUBSCRIPTION", "UPDATE SUBSCRIPTION", "ACTIVATE TERMINAL ICCID", "DEACTIVATE TERMINAL ICCID", "ACTIVATE SERVICE", and / or DEACTIVATE SERVICE.

[0215] The third request message may include an action type having a value of "3-TRANSFER SUBSCRIPTION" in Table 2, and "TRANSFER SUBSCRIPTION" may be an action type for transferring a subscription (e.g., a profile) of an existing electronic device (e.g., an external electronic device (700)) having an eSIM to another electronic device (e.g., an electronic device (101)) having an eSIM.

[0216] The entitlement server (520) that receives the third request message from the electronic device (101) may store the first identifier (e.g., OdsaEventID) included in the third request message in operation 709.

[0217] An entitlement server (520) storing a first identifier (e.g., OdsaEventID) may, in operation 710, cooperate with an SM-DP+ server (530) to prepare a profile to be downloaded to an electronic device (101). For example, operation 710 is illustrated as “ES2+ Exchange.”

[0218] In one embodiment, the entitlement server (520) may update the first identifier (e.g., OdsaEventID) if necessary. Meanwhile, although not separately illustrated in FIGS. 7A and 7B , the entitlement server (520) may transmit a subscription query to the BSS / OSS (550). The subscription query may include subscription identification information (e.g., “SubscriptionID”) or the international mobile equipment identity (IMEI) of the electronic device (101). In response to receiving the subscription query, the BSS / OSS (550) may transmit a subscription answer message to the entitlement server (520). According to one embodiment, the subscription answer message may include address information (e.g., uniform resource locator (URL) information) that can access a web server. In response to receiving a subscription response message, the entitlement server (520) may transmit address information (e.g., uniform resource locator (URL) information) that allows the electronic device (101) to access a web server. The electronic device (101) that receives the address information (e.g., URL information) that allows the electronic device to access a web server from the entitlement server (520) may display a webpage based on the address information and obtain user consent for profile movement.

[0219] If the time required to prepare a profile to be downloaded to the electronic device (101) in cooperation with the SM-DP+ server (530) is greater than or equal to the threshold time, the entitlement server (520) may, in operation 711, transmit a 200 OK message (e.g., an HTTP 200 OK ("SubscriptionResult = 4 - DELAYED DOWNLOAD) message) as a response message to the third request message to the electronic device (101). The 200 OK message as a response message to the third request message may include the subscription result ("SubscriptionResult") information of Table 3 below. The subscription result information as shown in Table 3 may be implemented similarly or substantially identically to the subscription result information specified in the standard document TS. 43, and therefore, a detailed description thereof will be omitted herein.

[0220] Table 3

[0221]

[0222] A response message (e.g., a 200 OK message) to a third request message related to a subscription management operation may include subscription result information ("SubscriptionResult") of one of "CONTINUE TO WEBSHEET", "DOWNLOAD PROFILE", "DONE", "DELAYED DOWNLOAD", "DISMISS", "DELETE PROFILE IN USE", "REDOWNLOADABLE PROFILE IS MANDATORY", and / or "REQUIRES USER INPUT", as shown in Table 3. For example, a 200 OK message, which is a response message to the third request message, may include "DELAYED DOWNLOAD". As shown in Table 3, DELAYED DOWNLOAD may be subscription result information indicating that a profile is not ready to be downloaded (e.g., indicating a delayed download) when a user (e.g., an electronic device (101)) requests a subscription move (or profile move). When the entitlement server (520) updates the first identifier (e.g., OdsaEventID), the response message (e.g., a 200 OK message) to the third request message may include the updated first identifier.

[0223] Although not shown separately in FIGS. 7A and 7B, when the electronic device (101) displays a web page based on address information received from the entitlement server (520), the entitlement server (520) may notify the electronic device (101) of subscription result information indicating DELAYED DOWNLOAD through a JavaScript (JS) callback.

[0224] The electronic device (101) that has received a response message to the third request message from the entitlement server (520) may, in operation 712, transmit a fourth request message to the entitlement server (520) requesting that the entitlement server provide service-related data for a primary device (e.g., an external electronic device (700)) or a companion device. For example, the fourth request message may include ODSA operation information set to "AcquireConfiguration" and a first identifier. For example, the fourth request message may be an HTTP REQUEST ("AcquireConfiguration", "OdsaEventID") message.

[0225] The entitlement server (520) that receives the fourth request message from the electronic device (101) may transmit a 200 OK message, which is a response message to the fourth request message, to the electronic device (101) in operation 713. The 200 OK message, which is a response message to the fourth request message, may include any one of the service status (ServiceStatus) information indicating the service status as shown in Table 4 below. For example, the 200 OK message, which is a response message to the fourth request message, may include “2 - ACTIVATING.” The service status information as shown in Table 4 may be implemented similarly or substantially identically to the service status information specified in the standard document TS. 43, and therefore, a detailed description thereof will be omitted herein.

[0226] Table 4

[0227]

[0228] As shown in Table 4, “2 - ACTIVATING” may indicate that the service of the eSIM device (e.g., electronic device (101)) will be activated.

[0229] The electronic device (101) that receives a 200 OK message from the entitlement server (520) can know that a service (e.g., profile download) for the electronic device (101) will be activated at operation 714, and thus can wait for the profile preparation to be completed.

[0230] The entitlement server (520), which has transmitted a 200 OK message as a response message to the fourth request message to the electronic device (101), may, in operation 715, generate a second identifier (e.g., MatchingID) associated with an ongoing ODSA procedure (e.g., an ongoing profile transfer procedure) when a profile is ready. In one embodiment, the second identifier may be an identifier used to identify an event (e.g., an ongoing ODSA procedure (e.g., an ongoing profile transfer procedure)) between the entitlement server (520) and the SM-DP+ server (530). In one embodiment, the MatchingID may be implemented similar to or substantially identical to the MatchingID specified in the GSMA standard document SPG. 22, and thus, a detailed description thereof will be omitted herein.

[0231] The entitlement server (520) that generates the second identifier can transmit the generated second identifier to the SM-DP+ server (530) in operation 715. In FIGS. 7A and 7B , an example in which the entitlement server (520) generates the second identifier is described, but the second identifier can also be generated by the SM-DP+ server (530). When the second identifier is generated by the SM-DP+ server (530), the SM-DP+ server (530) can transmit the generated second identifier to the entitlement server (520). In this case, the entitlement server (520) can update the first identifier to the second identifier and transmit the updated first identifier to the electronic device (101), thereby enabling the electronic device (101) to use the second identifier as the first identifier.

[0232] In one embodiment, the generation rule (or generation function) for generating the second identifier may be implemented in various forms. In one embodiment, the generation rule for generating the second identifier may be based on the first identifier, as described in detail below.

[0233] (1) First generation rule

[0234] The first generation rule may be a rule that generates the first identifier (e.g., OdsaEventID) as the second identifier.

[0235] (2) Second generation rule

[0236] The second generation rule may be a rule that generates a second identifier by concatenating a first value generated by the entitlement server (520) or the SM-DP+ server (530) and a configuration delimiter (e.g., "-") and the first identifier. For example, if the first identifier (e.g., OdsaEventID) is "ABCD1" and the first value generated by the entitlement server (520) or the SM-DP+ server (530) is "EFGH2", the second identifier (MatchingID) may be generated as "ABCD1-EFGH2". The second generation rule may be changed according to the agreement between the electronic devices (e.g., the electronic device (101)) and the telecommunications carrier.

[0237] (3) Third generation rule

[0238] The third generation rule may be a rule that generates a second identifier by concatenating a prefix (e.g., "OE05") for detecting the first identifier, the first identifier, and a first value generated by the entitlement server (520) or the SM-DP+ server (530). For example, if the first identifier (e.g., OdsaEventID) is "ABCD1", the first value generated by the entitlement server (520) or the SM-DP+ server (530) is "EFGH2", and the prefix capable of detecting the first identifier is "OE05", the second identifier (MatchingID) may be generated as "OE05ABCD1EFGH2". For example, the prefix "OE05" may indicate that the OdsaEventID is a five-digit number, and thus, the five-digit number immediately following the prefix "OE05" may be known to be the OdsaEventID. The third generation rule may be changed according to the agreement between the electronic devices (e.g., electronic device (101)) and the telecommunication carrier.

[0239] The second identifier generated based on the first to third generation rules can be expressed as shown in Table 5 below.

[0240] Table 5

[0241]

[0242] The SM-DP+ server (530), which has received the second identifier from the entitlement server (520), may generate a third identifier (e.g., EventID) associated with an ongoing ODSA procedure (e.g., an ongoing profile transfer procedure) in operation 716. In one embodiment, the third identifier may be an identifier used to identify an event (e.g., an ongoing ODSA procedure (e.g., an ongoing profile transfer procedure)) between the SM-DP+ server (530) and the SM-DS (560). In one embodiment, the EventID may be implemented similar to or substantially identical to the EventID specified in GSMA Standard Document SPG. 22. In one embodiment, a generation rule (or generation function) for generating the third identifier may be implemented in various forms. For example, the second identifier (e.g., MatchingID) may be generated as the third identifier as is.

[0243] The SM-DP+ server (530) that generated the third identifier may call the ES12.RegisterEvent function in operation 717. In one embodiment, the ES12.RegisterEvent function may include the eUICC identifier (EID) of the electronic device (101), the address of the remote SIM provisioning (RSP) server of the SM-DP+ server (530), and / or the third identifier (e.g., EventID). The ES12.RegisterEvent function may be implemented similarly or substantially identically to the ES12.RegisterEvent function specified in GSMA Standard Document SPG. 22.

[0244] As the SM-DP+ server (530) calls the ES12.RegisterEvent function, the SM-DS (560) may store a third identifier (e.g., EventID) in operation 718. The SM-DS (560) that has stored the third identifier (e.g., EventID) may transmit an OK message to the SM-DP+ server (530) in operation 719. In one embodiment, operation 719 may be omitted as needed.

[0245] Although not shown in FIGS. 7A and 7B, when profile preparation is complete, the entitlement server (520) can notify the SM-DS (560) and the electronic device (101) that the profile preparation is complete. The SM-DS (560) that confirms that the profile preparation is complete can notify the electronic device (101) that the profile preparation is complete through a push message, and the entitlement server (520) can also notify the electronic device (101) that the profile preparation is complete through a push message. Which push message among the push message transmitted from the entitlement server (520) and the push message transmitted from the SM-DS (560) arrives at the electronic device (101) first may vary based on the network environment and / or the operations of the entitlement server (520) and the SM-DS (560). In FIGS. 7a and 7b, it is assumed that the push message transmitted from the SM-DS (560) arrives at the electronic device (101) before the push message transmitted from the entitlement server (520).

[0246] The SM-DS (560), which has confirmed that the profile preparation is complete, may transmit a push message including information indicating that the profile is prepared to the electronic device (101) in operation 720. In one embodiment, the push message may include a third identifier (e.g., EventID) or may not include a third identifier (e.g., EventID). In operation 720, it is assumed that the push message does not include a third identifier (e.g., EventID).

[0247] The electronic device (101) that receives a push message from the SM-DS (560) that does not include a third identifier (e.g., EventID) may transmit a query message to the SM-DS (560) in operation 721. In one embodiment, the query message may be a message for querying the address of the SM-DP+ server (530) and the third identifier (e.g., EventID). The SM-DS (560) that receives the query message from the electronic device (101) may transmit a response message (e.g., Response message) to the query message in operation 722. In one embodiment, the Response message may include download information (e.g., the address of the SM-DP+ server (530)) and the third identifier (e.g., EventID). The address of the SM-DP+ server (530) may indicate the address of the SM-DP+ server (530) from which the electronic device (101) can obtain (e.g., download) a profile (e.g., a new profile). In one embodiment, the download information may include not only the address of the SM-DP+ server (530) but also the download information (“Download Info”) of Table 6 below. The download information as shown in Table 6 may be implemented similarly or substantially identically to the download information specified in the standard document TS. 43, and thus, a detailed description thereof will be omitted herein.

[0248] Table 6

[0249]

[0250] In FIGS. 7A and 7B, the Response message is represented as Response(Smdpaddress, "EventID"). If the push message transmitted in operation 720 includes the address of the SM-DP+ server (530) and a third identifier (e.g., EventID), operations 721 and 722 may be omitted.

[0251] The electronic device (101) that receives the Response message from the SM-DS (560) can, in operation 723, verify (e.g., derive) the first identifier (e.g., OdsaEventID) from the third identifier (e.g., EventID) included in the received Response message. In one embodiment, the electronic device (101) knows in advance the generation rule (or generation function) for generating the second identifier and the generation rule (or generation function) for generating the third identifier, and therefore can derive the first identifier (e.g., OdsaEventID) from the third identifier (e.g., EventID) based on the generation rule for generating the second identifier and the generation rule for generating the third identifier. The electronic device (101) may know in advance the generation rule for generating the second identifier and the generation rule for generating the third identifier before receiving a push message including the address of the SM-DP+ server (530) and a third identifier (e.g., EventID) or a Response message including the address of the SM-DP+ server (530) and a third identifier (e.g., EventID). Alternatively, the electronic device (101) may know in advance the derivation rule (or derivation function) for deriving the first identifier (e.g., OdsaEventID) from the third identifier (e.g., EventID), and thus may derive the first identifier (e.g., OdsaEventID) from the third identifier (e.g., EventID) based on the derivation rule.

[0252] The electronic device (101) may know the derivation rule in advance before receiving a push message including the address of the SM-DP+ server (530) and a third identifier (e.g., EventID) or a Response message including the address of the SM-DP+ server (530) and a third identifier (e.g., EventID).

[0253] The electronic device (101) that derives the first identifier (e.g., OdsaEventID) from the third identifier (e.g., EventID) can check whether the derived first identifier (e.g., OdsaEventID) is identical to the first identifier generated in operation 707. If the derived first identifier is identical to the first identifier generated in operation 707, the electronic device (101) can check whether another push message including the derived first identifier has been received before receiving the reply message in operation 723. In one embodiment, the other push message may represent a push message received before operation 720. For example, the electronic device (101) that obtains the first identifier (e.g., OdsaEventID) from the third identifier (e.g., EventID) can check whether another push message including the same first identifier as the obtained first identifier (e.g., OdsaEventID) has been received before receiving the push message.

[0254] If, as a result of the verification, no other push message including the same first identifier as the acquired first identifier (e.g., OdsaEventID) is received, the electronic device (101) may perform an operation corresponding to an ODSA procedure (e.g., a profile migration procedure) corresponding to the first identifier. The operation corresponding to the profile migration procedure corresponding to the first identifier may include an operation of displaying a notification message indicating that a user input is required to initiate profile migration (e.g., to initiate profile downloading) (e.g., operation 724), an operation of identifying a user input indicating to initiate profile migration (e.g., to initiate profile downloading) (e.g., operation 730), and / or an operation of acquiring (e.g., downloading) a profile from the SM-DP+ server (530) (e.g., operation 731).

[0255] If, as a result of the verification in operation 723, no other push message containing the same first identifier as the acquired first identifier (e.g., OdsaEventID) is received, the electronic device (101) may, in operation 724, display a notification message indicating that user input is required to initiate profile movement.

[0256] The electronic device (101) displaying the notification message can identify a user input indicating that a profile movement is to be initiated at operation 730.

[0257] An electronic device (101) that has identified a user input indicating that a profile movement is to be initiated can, at operation 731, obtain (e.g., download) a profile from an SM-DP+ server (530).

[0258] Alternatively, if another push message is received that includes the same first identifier (e.g., OdsaEventID) as the first identifier obtained from the third identifier (e.g., EventID), the electronic device (101) may not perform an operation corresponding to the ODSA procedure (e.g., profile migration procedure) corresponding to the first identifier (e.g., refrain from performing an operation corresponding to the ODSA procedure (e.g., profile migration procedure) corresponding to the first identifier).

[0259] As described above, after the push message transmitted from the SM-DS (560) arrives at the electronic device (101) before the push message transmitted from the entitlement server (520), in operation 725, the push message transmitted from the entitlement server (520) may arrive at the electronic device (101). The push message of operation 725 may include a first identifier (e.g., OdsaEventID).

[0260] An electronic device (101) that receives a push message from an entitlement server (520) can obtain a first identifier (e.g., OdsaEventID) from a third identifier (e.g., EventID) included in the received push message in operation 726.

[0261] An electronic device (101) that has obtained a first identifier (e.g., OdsaEventID) from a third identifier (e.g., EventID) can check whether another push message including the same first identifier as the obtained first identifier (e.g., OdsaEventID) has been received before receiving the push message in operation 726. For example, operation 726 is illustrated as "compare "OdsaEventID" manage it as duplicated push event."

[0262] As a result of the verification, if another push message including the same first identifier as the acquired first identifier (e.g., OdsaEventID) is received, the electronic device (101) may not perform an operation corresponding to the ODSA procedure (e.g., profile migration procedure) corresponding to the first identifier in operation 726. In one embodiment, the receipt of another push message including the same first identifier as the acquired first identifier (e.g., OdsaEventID) may indicate that a push message for the same ODSA procedure (e.g., the same profile migration procedure) has already been received, and thus, an operation corresponding to the ODSA procedure (e.g., profile migration procedure) corresponding to the first identifier has already been started or has already been performed. In one embodiment, the receipt of another push message including the same first identifier as the acquired first identifier (e.g., OdsaEventID) may indicate that multiple push messages including the same first identifier have been received. In one embodiment, the receipt of another push message containing the same first identifier as the acquired first identifier (e.g., OdsaEventID) may indicate that push messages containing the same first identifier have been received in duplicate.

[0263] Alternatively, the push message transmitted from the SM-DS (560) may arrive at the electronic device (101) before the push message transmitted from the entitlement server (520), and then, in operation 727, the push message transmitted from the entitlement server (520) may arrive at the electronic device (101). The push message of operation 727 may include a first identifier (e.g., OdsaEventID).

[0264] An electronic device (101) that receives a push message from an entitlement server (520) can obtain a first identifier (e.g., OdsaEventID) from a third identifier (e.g., EventID) included in the received push message in operation 728.

[0265] An electronic device (101) that has obtained a first identifier (e.g., OdsaEventID) from a third identifier (e.g., EventID) can check whether another push message including the same first identifier as the obtained first identifier (e.g., OdsaEventID) has been received before receiving the push message in operation 728. For example, operation 728 is illustrated as "compare "OdsaEventID" manage it as duplicated push event."

[0266] If, as a result of the verification, no other push message including a first identifier identical to the acquired first identifier (e.g., OdsaEventID) is received, the electronic device (101) may perform an operation corresponding to an ODSA procedure (e.g., a profile migration procedure) corresponding to the first identifier. The fact that no other push message including a first identifier identical to the acquired first identifier (e.g., OdsaEventID) is received may indicate that the acquired first identifier (e.g., OdsaEventID) is a first identifier for another ODSA procedure. The operation corresponding to the profile migration procedure corresponding to the first identifier may include an operation of displaying a notification message indicating that user input is required to initiate profile migration (e.g., operation 729), an operation of identifying a user input indicating to initiate profile migration, and / or an operation of obtaining (e.g., downloading) a profile from the SM-DP+ server (530). In one embodiment, the operation of identifying a user input indicating the initiation of a profile movement may be implemented similar to or substantially identical to operation 730, and thus a detailed description thereof will be omitted. In one embodiment, the operation of obtaining (e.g., downloading) a profile from an SM-DP+ server (530) may be implemented similar to or substantially identical to operation 731, and thus a detailed description thereof will be omitted.

[0267] In FIGS. 7A and 7B, the case where the electronic device (101) generates the first identifier (e.g., OdsaEventID) is described as an example, but the first identifier may also be generated by the entitlement server (520). In one embodiment, the entitlement server (520) may generate the first identifier and transmit it to the electronic device (101) before the electronic device (101) transmits the third request message including the ODSA operation information "ManageSubscription." For example, the entitlement server (520) may generate the first identifier at any time before the electronic device (101) transmits the third request message including the ODSA operation information "ManageSubscription," and transmit the generated first identifier to the electronic device (101), so that the electronic device (101) includes the first identifier in the third request message including the ODSA operation information "ManageSubscription." Alternatively, the entitlement server (520) may generate a first identifier after receiving a third request message including ODSA operation information, “ManageSubscription,” from the electronic device (101), and transmit the first identifier to the electronic device (101) in response to the “ManageSubscription.” In one embodiment, there may be no limitation on the format of the message for the entitlement server (520) to transmit the first identifier to the electronic device (101).

[0268] In FIGS. 7A and 7B, an example is described in which, when the electronic device (101) receives a push message from the SM-DS (560) in operation 720, a query message is sent to the SM-DS (560) in operation 721 to inquire about the address of the SM-DP+ server (530) and a third identifier (e.g., EventID). However, if the SM-DS (560) includes the address of the SM-DP+ server (530) and a third identifier (e.g., EventID) in the push message, operations 721 and 722 may be omitted.

[0269] FIG. 8a is a signal flow diagram illustrating an ODSA procedure in a wireless communication network according to one embodiment.

[0270] FIG. 8b is a signal flow diagram illustrating an ODSA procedure in a wireless communication network according to one embodiment.

[0271] FIG. 8c is a signal flow diagram illustrating an ODSA procedure in a wireless communication network according to one embodiment.

[0272] Referring to FIGS. 8A to 8C, the wireless communication network includes an electronic device (101) (e.g., the electronic device (101) of FIGS. 1A, 1B, 2, 3, and / or 5), an external electronic device (700) (e.g., the electronic device (102) and / or the electronic device (104) of FIG. 1A), an entitlement server (520) (e.g., the entitlement server (520) of FIG. 5), an SM-DP+ server (530) (e.g., the SM-DP+ server (220) of FIG. 2 and / or the SM-DP+ server (530) of FIG. 5), an authentication server (540) (e.g., the authentication server (540) of FIG. 5), a BSS / OSS (550) (e.g., the BSS / OSS (550) of FIG. 5), and / or an SM-DS (560) (e.g., the BSS / OSS (550) of FIG. 2). The external electronic device (700) may be an existing electronic device that has stored a profile associated with the subscription (e.g., an existing profile), and the electronic device (101) may be a new electronic device from which to download a profile associated with the subscription (e.g., a new profile). The ODSA procedure illustrated in FIGS. 8A to 8C may include a profile transfer (or subscription transfer or line transfer) procedure between electronic devices.

[0273] In operation 801, the external electronic device (700) and the electronic device (101) may be connected to a data network based on a WiFi method (WiFi Connected). In one embodiment, the case where the external electronic device (700) and the electronic device (101) are connected to a data network based on a WiFi method is described as an example, but the external electronic device (700) and the electronic device (101) may be connected to a data network based on various short-range communication methods in addition to the WiFi method.

[0274] In operation 802, the external electronic device (700) may verify a user input associated with a profile transfer between electronic devices (e.g., a user input selecting a profile transfer (or subscription transfer or line transfer) between electronic devices). For example, the external electronic device (700) may output (e.g., display) a UI (e.g., a profile transfer menu between electronic devices) for selecting a profile transfer between electronic devices, and may verify the user input through the UI. The UI may include information to the effect of selecting to transfer a profile of the external electronic device (700) to the electronic device (101), or may include information to the effect of selecting to transfer a profile (or subscription or line) from the external electronic device (700) to the electronic device (101) for intuitive recognition by the user.

[0275] Based on a user input selecting to move a profile between electronic devices, the external electronic device (700) may, at operation 802, transmit a first request message to the entitlement server (520) requesting to move the profile (or subscription or line). The first request message may include an extensible authentication protocol (EAP) identifier (EAP_ID) and device information of the electronic device (101). For example, the first request message may be an HTTP REQUEST message, and in FIGS. 8A to 8C the first request message is represented as HTTP REQUEST("EAP_ID"). In FIGS. 8A to 8C, the authentication process between the external electronic device (700) and the entitlement server (520) is described as an example of an EAP-AKA authentication process, but there may be no limitations on the authentication process between the external electronic device (700) and the entitlement server (520). In one embodiment, the EAP-AKA authentication process may represent an authentication process based on the EAP-AKA method.

[0276] The entitlement server (520), which has received a first request message from an external electronic device (700), may, in operation 803, detect the EAP capability of the electronic device (101) based on the first request message and initiate an EAP procedure with the authentication server (540). For example, operation 803 is illustrated as “initiate EAP procedure.”

[0277] The authentication server (540) and the entitlement server (520) that initiated the EAP procedure can, at operation 804, confirm (e.g., obtain) an EAP challenge (EAP Challenge) from the authentication server (540). For example, operation 804 is illustrated as "EAP Challenge."

[0278] The entitlement server (520), which has obtained an EAP Challenge from the authentication server (540), may transmit a 200 OK message (e.g., an HTTP 200 OK message) as a response message to the first request message to the external electronic device (700) in operation 805. In one embodiment, the 200 OK message may include the EAP-challenge as an eap-relay-packet. For example, operation 805 is illustrated as "HTTP 200 OK ("eap-relay-packet: EAP-challenge")."

[0279] An external electronic device (700) that receives a 200 OK message from an entitlement server (520) may, in operation 806, generate a payload (e.g., EAP-payload) based on the received 200 OK message.

[0280] The external electronic device (700) that generated the payload can perform an EAP-AKA authentication process with the entitlement server (520), and therefore, the external electronic device (700) can transmit a second request message including eap-relay-packet as the EAP-payload to the entitlement server (520) at operation 807. For example, the second request message can be an HTTP REQUEST message. For example, the second request message can be an HTTP REQUEST("eap-relay-packet: EAP-payload") message.

[0281] The entitlement server (520) that received the second request message from the external electronic device (700) may, in operation 808, transmit a 200 OK message including authentication information (e.g., a token) to the external electronic device (700) if the result of the EAP-AKA authentication process for the external electronic device (700) indicates success. For example, the 200 OK message may be an HTTP 200 OK message. For example, the 200 OK message may be an "HTTP 200 OK ("token")" message.

[0282] The external electronic device (700) that has acquired authentication information may perform an eligibility check with the entitlement server (520) in order to move the profile of the external electronic device (700) to the electronic device (101) in operation 809. The external electronic device (700) may request an eligibility check for the electronic device (101) to the entitlement server (520) based on the HTTP GET method or the HTTP POST method. For example, the external electronic device (700) may request an eligibility check for the electronic device (101) by transmitting a third request message requesting an eligibility check to the entitlement server (520). According to one embodiment, the third request message may be a request message requesting an eligibility check, for example, an HTTP REQUEST message.

[0283] An external electronic device (700) may transmit a third request message containing any one of the ODSA operation information to the entitlement server (520) according to the ODSA procedure specified in standard document TS. 43. The ODSA operation information is described in Table 1, and therefore, a detailed description thereof will be omitted here.

[0284] The external electronic device (700) may request an eligibility check by transmitting a third request message including "CheckEligibility" as ODSA operation information to the entitlement server (520) in accordance with the ODSA procedure specified in standard document TS. 43 at operation 809. In one embodiment, the third request message may include authentication information (e.g., a token) obtained from the entitlement server (520). For example, the third request message may be an HTTP REQUEST("CheckEligibility", "token") message.

[0285] Although not separately illustrated in FIGS. 8A to 8C , the entitlement server (520) may transmit a profile query to the BSS / OSS (550). The profile query may include subscription identification information (e.g., "SubscriptionID"). The BSS / OSS (550) may transmit a profile answer corresponding to the profile query to the entitlement server (520).

[0286] The entitlement server (520), which has received a third request message including CheckEligibility as ODSA operation information from an external electronic device (700), can perform an eligibility check on the electronic device (101) based on the third request message including CheckEligibility as ODSA operation information in operation 810.

[0287] If the result of the eligibility check for the electronic device (101) indicates success, the entitlement server (520) may, in operation 810, transmit a 200 OK message (e.g., an HTTP 200 OK message) as a response message to the third request message to the external electronic device (700). In FIGS. 8A to 8C , it is assumed that the result of the eligibility check for the electronic device (101) indicates success, and if the result of the eligibility check for the electronic device (101) indicates failure, no further operations may be performed. In one embodiment, if the result of the eligibility check indicates success, the 200 OK message may include information of "ENABLED."

[0288] The external electronic device (700) that has received a 200 OK message from the entitlement server (520) may request temporary authentication information (e.g., a temporary token) that may be used by the electronic device (101) by transmitting a fourth request message including “AcquireTemporaryToken” as ODSA operation information to the entitlement server (520) in operation 811. In one embodiment, the temporary authentication information may be temporary authentication information related to an ongoing ODSA procedure (e.g., an ongoing profile transfer procedure). In one embodiment, the fourth request message may include authentication information (e.g., a token). For example, the fourth request message may be an HTTP REQUEST(“AcquireTemporaryToken”, “token”) message.

[0289] The entitlement server (520), which receives the fourth request message including AcquireTemporaryToken as ODSA operation information from the external electronic device (700), may generate a temporary token based on the fourth request message including AcquireTemporaryToken as ODSA operation information in operation 812. The entitlement server (520) may generate the temporary token if the electronic device (101) is permitted to use the subscription (or profile) for the external electronic device (700). In FIGS. 8A to 8C , it is assumed that the electronic device (101) is permitted to use the subscription (or profile) for the external electronic device (700), and if the electronic device (101) is not permitted to use the subscription (or profile) for the external electronic device (700), no further operations may be performed.

[0290] The entitlement server (520) that generated the temporary token can transmit a 200 OK message (e.g., an HTTP 200 OK ("TemporaryToken = New TemporaryToken") message) including the temporary token as a response message to the fourth request message to the external electronic device (700) in operation 812.

[0291] An external electronic device (700) that has received a 200 OK message including a temporary token from an entitlement server (520) may transmit a message including the temporary token to the electronic device (101) in operation 813. For example, operation 813 is illustrated as "Deliver TemporaryToken."

[0292] The electronic device (101), which has received a message including a temporary token from the electronic device (101), may generate a first identifier (e.g., OdsaEventID) associated with an ongoing ODSA procedure (e.g., an ongoing profile migration procedure) in operation 814. In one embodiment, the first identifier may be an identifier used to identify the ongoing ODSA procedure. In one embodiment, a generation rule (or generation function) for generating the first identifier may be implemented in various forms.

[0293] The electronic device (101) that generated the first identifier may, in operation 815, include "ManageSubscription" as ODSA operation information and transmit a fifth request message (e.g., an HTTP REQUEST("ManageSubscription") message) including the first identifier (e.g., OdsaEventID) to the entitlement server (520). In one embodiment, the fifth request message may be a message requesting a subscription management operation. In one embodiment, the subscription management operation may include various operations related to subscription.

[0294] In one embodiment, the fifth request message may include ODSA operation information for "ManageSubscription." "ManageSubscription" may be ODSA operation information used to request subscription-related operations. According to one embodiment, the fifth request message may include operation type information. Since the operation type information is described in Table 2, a detailed description thereof will be omitted here.

[0295] The fifth request message may include an action type and authentication information (e.g., a token) having a value of “3-TRANSFER SUBSCRIPTION” in Table 2, and “TRANSFER SUBSCRIPTION” may be an action type for transferring a subscription (e.g., a profile) of an existing electronic device (e.g., an external electronic device (700)) having an eSIM to another electronic device (e.g., an electronic device (101)) having an eSIM.

[0296] The entitlement server (520) that receives the fifth request message from the electronic device (101) may store the first identifier (e.g., OdsaEventID) included in the fifth request message in operation 816.

[0297] An entitlement server (520) storing a first identifier (e.g., OdsaEventID) may transmit a subscription query to a BSS / OSS (550) at operation 817. The subscription query may include subscription identification information (e.g., “SubscriptionID”) and may be used to request activation of a new subscription (or profile) (e.g., activation of a new subscription (or profile) for an external electronic device (700).

[0298] The BSS / OSS (550), which has received a subscription query from the entitlement server (520), may determine whether a deletion operation is required in operation 818-1. For example, the BSS / OSS (550), in operation 818-1, may request a new profile to the SM-DP+ server (530) through an ES2+ interface (e.g., DownloadOrder, ConfirmOrder, and ReleaseProfile). The SM-DP+ server (530), which has confirmed the new profile request from the BSS / OSS (550), may determine that a profile in use (e.g., an existing profile) needs to be deleted, and may notify the BSS / OSS (550) that the existing profile needs to be deleted.

[0299] The BSS / OSS (550), which has been notified by the SM-DP+ server (530) that an existing profile needs to be deleted, may transmit a response message indicating that the existing profile needs to be deleted to the entitlement server (520) in operation 818-2. For example, operation 818-2 is represented as "Answer(NeedToDeleteICCID)".

[0300] The entitlement server (520), which receives a response message from the BSS / OSS (550), may determine that the profile in use (e.g., an existing profile) needs to be deleted, and thus may transmit a 200 OK message (e.g., an HTTP 200 OK ("SubscriptionResult = 6 - DELETE PROFILE IN USE") message) as a response message to the fifth request message in operation 819 to the electronic device (101). In one embodiment, "6 - DELETE PROFILE IN USE" may be subscription result information indicating that the profile in use needs to be deleted. The 200 OK message as a response message to the fifth request message may include subscription result information, and since the subscription result information is described in Table 3, a detailed description thereof will be omitted here.

[0301] The electronic device (101) that receives the 200 OK message from the entitlement server (520) can determine that the profile in use needs to be deleted, and thus can transmit a message requesting the deletion of the profile in use to the external electronic device (700) at operation 820. For example, operation 820 is illustrated as "Request to delete the profile in use."

[0302] An external electronic device (700) that has received a message requesting to delete a profile in use from an electronic device (101) can delete the profile in use in operation 821.

[0303] In this way, when the profile being used by the external electronic device (700) is deleted, the connection to the data network based on the WiFi method of the electronic device (101) and the external electronic device (700) may be disconnected (WiFi Disconnected). For example, the connection to the data network of the electronic device (101) and the external electronic device (700) may be disconnected when a network error occurs in the server of the data network and / or due to various errors such as a WiFi connection error.

[0304] In this case, when the electronic device (101) and the external electronic device (700) are not connected to the data network, it may be impossible for the external electronic device (700) to transmit a message (e.g., a HandleNotification(ProfileDeleteResult) message) indicating that the external electronic device (700) has deleted the profile being used to the SM-DP+ server (530), as in operations 823 and 825, or even if the external electronic device (700) transmits a message indicating that the profile being used has been deleted to the SM-DP+ server (530), it may be impossible for the SM-DP+ server (530) to receive a message indicating that the profile being used has been deleted. In this case, the external electronic device (700) may wait to receive an “ok” message in response to a message indicating that the profile in use has been deleted, as in operations 824 and 826, but since the SM-DP+ server (530) cannot receive a message indicating that the profile in use has been deleted from the external electronic device (700), the validity time for temporary authentication information (e.g., temporary token) may expire, as in operation 827. For example, operation 827 is illustrated as “TemporaryToken expired.”

[0305] Thereafter, when a network error occurs in the server of the data network and / or when various reasons such as a WiFi connection error are resolved, as in operation 828, the external electronic device (700) and the electronic device (101) can be connected to the data network again based on the WiFi method (WiFi Connected). The external electronic device (700) connected to the data network can, in operation 829, transmit a message (e.g., a HandleNotification(ProfileDeleteResult) message) indicating that the profile being used by the external electronic device (700) has been deleted to the SM-DP+ server (530).

[0306] The SM-DP+ server (530), which receives a message from the external electronic device (700) indicating that the external electronic device (700) has deleted the profile being used, can confirm that the external electronic device (700) has deleted the profile being used, and can transmit an OK message to the external electronic device (700) in response to the message indicating that the external electronic device (700) has deleted the profile being used.

[0307] An external electronic device (700) that has received an OK message from an SM-DP+ server (530) may, in operation 831, transmit a message indicating that the profile being used by the electronic device (101) has been deleted. For example, operation 831 is illustrated as “Notify deletion result.”

[0308] The electronic device (101), which has received a message from the external electronic device (700) indicating that the profile in use has been deleted, may, in operation 832, confirm that the profile in use has been deleted and may transmit a sixth request message requesting the entitlement server (520) to provide service-related data for the primary device (e.g., the external electronic device (700)) or the companion device. For example, the sixth request message may include ODSA operation information set to "AcquireConfiguration," a first identifier, and / or authentication information. For example, the sixth request message may be an HTTP REQUEST ("AcquireConfiguration", "token", OdsaEventID) message.

[0309] Alternatively, as the temporary authentication information expires, the entitlement server (520) may require re-authentication of the electronic device (101), in which case the entitlement server (520) may, at operation 833, transmit a message (e.g., an HTTP 511 Network Authentication Required message) to the electronic device (101) indicating that network authentication is required. The electronic device (101) that receives the message from the entitlement server (520) indicating that network authentication is required may, at operation 834, perform an Oauth2.0 / OpenID authentication process with the entitlement server (520) to verify (e.g., obtain) authentication information (e.g., a token).

[0310] The electronic device (101) that has verified the authentication information (e.g., token) may, in operation 835, transmit a seventh request message requesting the entitlement server (520) to provide service-related data for the primary device (e.g., external electronic device (700)) or companion device. The seventh request message of operation 835 may be similar to or substantially identical to the sixth request message of operation 832, and thus, a detailed description thereof will be omitted herein.

[0311] The entitlement server (520) that receives the sixth request message or the seventh request message from the electronic device (101) may transmit a 200 OK message, which is a response message to the sixth request message or the seventh request message, in operation 836. The 200 OK message may include 2 - DOWNLOAD PROFILE as subscription result information, indicating that the profile must be downloaded. The 200 OK message may include download information (e.g., the address of the SM-DP+ server (530)) for the electronic device (101) to download the profile. Since the subscription result information is described in Table 3, a detailed description thereof will be omitted here. For example, operation 836 is illustrated as "HTTP 200 OK ("SubscriptionResult = 2 - DOWNLOAD PROFILE", "DownloadInfo")".

[0312] An electronic device (101) that receives a 200 OK message from an entitlement server (520) can determine that the electronic device (101) must download a profile based on the 200 OK message, and thus, in operation 837, the electronic device (101) can download a profile from the SM-DP+ server (530) based on the download information included in the 200 OK message. For example, operation 837 is illustrated as “Download profile.”

[0313] In FIGS. 8A to 8C, the case where the electronic device (101) generates the first identifier (e.g., OdsaEventID) is described as an example, but the first identifier may also be generated by the entitlement server (520). The entitlement server (520) may generate the first identifier and transmit it to the electronic device (101) before the electronic device (101) transmits the third request message including the ODSA operation information "ManageSubscription." For example, the entitlement server (520) may generate the first identifier at any time before the electronic device (101) transmits the fifth request message including the ODSA operation information "ManageSubscription," and transmit the generated first identifier to the electronic device (101), so that the electronic device (101) includes the first identifier in the fifth request message including the ODSA operation information "ManageSubscription." In one embodiment, there may be no limitation on the format of the message for the entitlement server (520) to transmit the first identifier to the electronic device (101).

[0314] FIG. 9a is a signal flow diagram illustrating an ODSA procedure in a wireless communication network according to one embodiment.

[0315] FIG. 9b is a signal flow diagram illustrating an ODSA procedure in a wireless communication network according to one embodiment.

[0316] Referring to FIGS. 9A and 9B , the wireless communication network may include an electronic device (101) (e.g., the electronic device (101) of FIGS. 1A , 1B , 2 , 3 , and / or 5 ), an external electronic device (700) (e.g., the electronic device (102) of FIG. 1A and / or the electronic device (104) of FIG. 1A ), an entitlement server (520) (e.g., the entitlement server (520) of FIG. 5 ), an SM-DP+ server (530) (e.g., the SM-DP+ server (220) of FIG. 2 and / or the SM-DP+ server (530) of FIG. 5 ), an authentication server (540) (e.g., the authentication server (540) of FIG. 5 ), and / or a BSS / OSS (550) (e.g., the BSS / OSS (550) of FIG. 5 ). The external electronic device (700) may be an existing electronic device that stores a profile associated with the subscription (e.g., an existing profile), and the electronic device (101) may be a new electronic device from which to download a profile associated with the subscription (e.g., a new profile). The ODSA procedure illustrated in FIGS. 9A and 9B may include a profile transfer (or subscription transfer or line transfer) procedure between electronic devices.

[0317] In operation 901, the external electronic device (700) can confirm a user input associated with a profile transfer between electronic devices (e.g., a user input selecting a profile transfer (or subscription transfer or line transfer) between electronic devices). For example, the external electronic device (700) can output (e.g., display) a UI (e.g., a profile transfer menu between electronic devices) for selecting a profile transfer between electronic devices, and can confirm the user input through the UI. The UI can include information to the effect of selecting to transfer a profile of the external electronic device (700) to the electronic device (101), or can include information to the effect of selecting to transfer a profile (or subscription or line) from the external electronic device (700) to the electronic device (101) for intuitive recognition by the user.

[0318] Based on a user input selecting to move a profile between electronic devices, the external electronic device (700) may, in operation 901, transmit a first request message to the entitlement server (520) requesting to move the profile (or subscription or line). The first request message may include an EAP_ID. For example, the first request message may be an HTTP REQUEST message. For example, the first request message may be an HTTP REQUEST("EAP_ID") message. Although FIGS. 9A and 9B illustrate an example where the authentication process between the external electronic device (700) and the entitlement server (520) is an EAP-AKA authentication process, there may be no limitation on the authentication process between the external electronic device (700) and the entitlement server (520). In one embodiment, the EAP-AKA authentication process may represent an authentication process based on the EAP-AKA scheme.

[0319] The entitlement server (520), which has received a first request message from an external electronic device (700), may, in operation 902, detect the EAP capability of the electronic device (101) based on the first request message and initiate an EAP procedure with the authentication server (540). For example, operation 902 is illustrated as “initiate EAP procedure.”

[0320] The authentication server (540) and the entitlement server (520) that initiated the EAP procedure can, at operation 903, verify (e.g., obtain) an EAP challenge from the authentication server (540). For example, operation 903 is illustrated as "EAP Challenge."

[0321] The entitlement server (520), which has obtained an EAP Challenge from the authentication server (540), may transmit a 200 OK message (e.g., an HTTP 200 OK message) as a response message to the first request message to the external electronic device (700) in operation 904. In one embodiment, the 200 OK message may include the EAP-challenge as an eap-relay-packet. For example, operation 904 is illustrated as "HTTP 200 OK ("eap-relay-packet: EAP-challenge")."

[0322] An external electronic device (700) that receives a 200 OK message from an entitlement server (520) may, in operation 905, generate a payload (e.g., EAP-payload) based on the received 200 OK message.

[0323] The external electronic device (700) that generated the payload can perform an EAP-AKA authentication process with the entitlement server (520), and therefore, the external electronic device (700) can transmit a second request message including eap-relay-packet as the EAP-payload to the entitlement server (520) at operation 906. For example, the second request message can be an HTTP REQUEST message. For example, the second request message can be an HTTP REQUEST("eap-relay-packet: EAP-payload") message.

[0324] The entitlement server (520) that received the second request message from the external electronic device (700) may, in operation 907, transmit a 200 OK message including authentication information (e.g., a token) to the external electronic device (700) if the result of the EAP-AKA authentication process for the external electronic device (700) indicates success. For example, the 200 OK message may be an HTTP 200 OK message. For example, the 200 OK message may be an "HTTP 200 OK ("token")" message.

[0325] The external electronic device (700) that has acquired authentication information may perform an eligibility check with the entitlement server (520) in order to transfer the profile of the external electronic device (700) to the electronic device (101) in operation 908. The external electronic device (700) may request an eligibility check for the electronic device (101) to the entitlement server (520) based on the HTTP GET method or the HTTP POST method. For example, the external electronic device (700) may request an eligibility check for the electronic device (101) by transmitting a third request message requesting an eligibility check to the entitlement server (520). According to one embodiment, the third request message may be a request message requesting an eligibility check. For example, the third request message may be an HTTP REQUEST message.

[0326] An external electronic device (700) may transmit a third request message containing any one of the ODSA operation information to the entitlement server (520) according to the ODSA procedure specified in standard document TS. 43. The ODSA operation information is described in Table 1, and therefore, a detailed description thereof will be omitted here.

[0327] The external electronic device (700) may request an eligibility check by sending a third request message including "CheckEligibility" as ODSA operation information to the entitlement server (520) according to the ODSA procedure specified in standard document TS. 43 at operation 908. In one embodiment, the third request message may include authentication information (e.g., a token) obtained from the entitlement server (520). For example, the third request message may be an HTTP REQUEST("CheckEligibility", "token") message.

[0328] Although not separately illustrated in FIGS. 9A and 9B , the entitlement server (520) may transmit a profile query to the BSS / OSS (550). The profile query may include subscription identification information (e.g., "SubscriptionID"). The BSS / OSS (550) may transmit a profile answer corresponding to the profile query to the entitlement server (520).

[0329] The entitlement server (520), which has received a third request message including CheckEligibility as ODSA operation information from an external electronic device (700), can perform an eligibility check on the electronic device (101) based on the third request message including CheckEligibility as ODSA operation information in operation 909.

[0330] If the result of the eligibility check for the electronic device (101) indicates success, the entitlement server (520) may, in operation 909, transmit a 200 OK message (e.g., an HTTP 200 OK message) as a response message to the third request message to the external electronic device (700). In FIGS. 9A and 9B , it is assumed that the result of the eligibility check for the electronic device (101) indicates success, and if the result of the eligibility check for the electronic device (101) indicates failure, no further operations may be performed. In one embodiment, if the result of the eligibility check indicates success, the 200 OK message may include information of "ENABLED."

[0331] An external electronic device (700) that receives a 200 OK message from an entitlement server (520) may, in operation 910, generate a first identifier (e.g., OdsaEventID) associated with an ongoing ODSA procedure (e.g., an ongoing profile migration procedure). In one embodiment, the first identifier may be an identifier used to identify an ongoing ODSA procedure. In one embodiment, a generation rule (or generation function) for generating the first identifier may be implemented in various forms.

[0332] The external electronic device (700) that generated the first identifier may, in operation 911, transmit a fourth request message (e.g., an HTTP REQUEST("ManageSubscription") message) that includes "ManageSubscription" as ODSA operation information and the first identifier (e.g., OdsaEventID) to the entitlement server (520). In one embodiment, the fourth request message may be a message requesting a subscription management operation. In one embodiment, the subscription management operation may include various operations related to subscription.

[0333] In one embodiment, the fourth request message may include ODSA operation information for "ManageSubscription." "ManageSubscription" may be ODSA operation information used to request subscription-related operations. According to one embodiment, the fourth request message may include operation type information. Since the operation type information is described in Table 2, a detailed description thereof will be omitted here.

[0334] The fourth request message may include an action type and authentication information (e.g., a token) having a value of “3-TRANSFER SUBSCRIPTION” in Table 2, and “TRANSFER SUBSCRIPTION” may be an action type for transferring a subscription (e.g., a profile) of an existing electronic device (e.g., an external electronic device (700)) having an eSIM to another electronic device (e.g., an electronic device (101)) having an eSIM.

[0335] The entitlement server (520), which has received the fourth request message from the external electronic device (700), may, in operation 912, reserve a profile to be moved to the electronic device (101) based on the current subscription (or current profile or existing profile). For example, operation 912 is illustrated as "Reserve profile based on current subscription."

[0336] In one embodiment, the entitlement server (520) may, at operation 913, send a message (e.g., an "Activate Subscription" message) to the BSS / OSS (550) requesting activation of a subscription (or profile).

[0337] The BSS / OSS (550), which has received a message requesting activation of a subscription (or profile) from the entitlement server (520), may transmit a profile request to the SM-DP+ server (530) via an ES2+ interface (e.g., DownloadOrder, ConfirmOrder, and ReleaseProfile) at operation 914. The SM-DP+ server (530), which has received the profile request from the BSS / OSS (550), may prepare a new profile for the electronic device (101) and transmit download information for downloading the new profile to the BSS / OSS (550). For example, the download information for downloading the new profile may include the address of the SM-DP+ server (530). For example, operation 914 is illustrated as “ES2+ exchange.”

[0338] The BSS / OSS (550), which has received download information for downloading a new profile from the SM-DP+ server (530), can transmit a response message including the download information to the entitlement server (520) in operation 915.

[0339] The entitlement server (520) that receives the response message including the download information may transmit a 200 OK message, which is a response message to the fourth request message, to the external electronic device (700) in operation 916. The 200 OK message may include 2 - DOWNLOAD PROFILE as subscription result information, indicating that the profile must be downloaded. The 200 OK message may include download information (e.g., the address of the SM-DP+ server (530)) for the electronic device (101) to download the profile. Since the subscription result information is described in Table 3, a detailed description thereof will be omitted here. For example, operation 916 is illustrated as "HTTP 200 OK ("SubscriptionResult = 2 - DOWNLOAD PROFILE", "DownloadInfo")".

[0340] In this way, even though the entitlement server (520) transmits a 200 OK message, which is a response message to the fourth request message, to the external electronic device (700), the external electronic device (700) may not be able to receive the 200 OK message due to various errors, such as an error occurring on the external electronic device (700) side and / or a network error.

[0341] Since the entitlement server (520) sent a 200 OK message to the external electronic device (700) even though the external electronic device (700) was unable to receive the 200 OK message, the entitlement server (520) may cancel the existing subscription (or existing profile) at operation 917. For example, operation 917 is illustrated as "Cancel Subscription."

[0342] The entitlement server (520) that has cancelled the existing subscription may, at operation 918, send a message (e.g., a Deactivate Subscription message) to the BSS / OSS (550) requesting that the existing subscription (or existing profile) be deactivated.

[0343] The BSS / OSS (550), which has received a message from the entitlement server (520) requesting to deactivate an existing subscription (or an existing profile), may, in operation 919, deactivate the existing subscription and transmit a response message indicating that the existing subscription has been deactivated.

[0344] In operation 916, an example is described in which the external electronic device (700) cannot receive the 200 OK message even though the entitlement server (520) transmits the 200 OK message, which is a response message to the fourth request message, to the external electronic device (700). However, alternatively, the external electronic device (700) may be able to receive the 200 OK message. In this case, in operation 920, the external electronic device (700) may transmit (e.g., provide) an activation code to the electronic device (101) that permits the download of a profile (e.g., a new profile) from the SM-DP+ server (530). In one embodiment, the activation code may notify the electronic device (101) to download the profile. For example, operation 920 is illustrated as "Provide Activation Code."

[0345] Even though the external electronic device (700) transmits the activation code to the electronic device (101), the electronic device (101) may not be able to receive the activation code due to various errors, such as an error occurring on the electronic device (101) side and / or a network error. In this case, even though the external electronic device (700) has deactivated the existing profile, the electronic device (101) may not be able to download a new profile, and thus an error may occur, as in operation 921.

[0346] Thereafter, as in operation 922, the validity time for the authentication information (e.g., token) of the external electronic device (700) may expire. For example, operation 922 is illustrated as “token expired.”

[0347] After the validity period for the token has expired, the external electronic device (700) may, at operation 923, verify user input associated with profile transfer between electronic devices as a result of the user of the external electronic device (700) retrying the subscription transfer, or determine that a recovery scenario of the external electronic device (700) needs to be performed. In one embodiment, the recovery scenario may be a scenario for retrying profile transfer between electronic devices. For example, operation 923 is illustrated as "User trigger Transfer again and run recovery scenario."

[0348] The external electronic device (700) that verifies user input associated with profile movement between electronic devices or determines that a recovery scenario needs to be performed may, at operation 924, transmit a fifth request message (e.g., an HTTP REQUEST("ManageSubscription") message) that includes "ManageSubscription" as ODSA operation information and a first identifier (e.g., OdsaEventID) to the entitlement server (520). In one embodiment, the fifth request message may include ODSA operation information of "ManageSubscrition," an operation type having a value of "3-TRANSFER SUBSCRIPTION," authentication information (e.g., a token), and / or a first identifier (e.g., OdsaEventID).

[0349] The entitlement server (520) that receives the fifth request message from the external electronic device (700) may, even though the validity period for the authentication information has expired, determine an ongoing ODSA procedure (e.g., an ongoing profile transfer procedure) based on the first identifier included in the fifth request message, and thus may not need to perform a re-authentication procedure for the external electronic device (700). The entitlement server (520) that receives the fifth request message from the external electronic device (700) may, at operation 925, resume the profile transfer procedure based on the first identifier. For example, operation 925 is illustrated as "restore transfer scenario based on OdsaEventID."

[0350] The entitlement server (520) that has resumed the profile transfer procedure may transmit a 200 OK message, which is a response message to the fifth request message, to the external electronic device (700) in operation 926. The 200 OK message may include 2 - DOWNLOAD PROFILE as subscription result information, indicating that the profile must be downloaded. The 200 OK message may include download information (e.g., the address of the SM-DP+ server (530)) for the electronic device (101) to download the profile. Since the subscription result information is described in Table 3, a detailed description thereof will be omitted here. For example, operation 926 is illustrated as "HTTP 200 OK ("SubscriptionResult = 2 - DOWNLOAD PROFILE", "DownloadInfo")".

[0351] An external electronic device (700) that receives a 200 OK message from an entitlement server (520) can determine that the electronic device (101) must download a profile based on the 200 OK message, and thus, the external electronic device (700) can transmit download information for downloading a new profile to the electronic device (101) in operation 927. For example, operation 927 is illustrated as "DownloadInfo".

[0352] An electronic device (101) that has received download information for downloading a new profile from an external electronic device (700) can, in operation 928, download the profile from the SM-DP+ server (530) based on the download information. For example, operation 928 is illustrated as “Download profile.”

[0353] In FIGS. 9A and 9B, an example in which an external electronic device (700) generates a first identifier (e.g., OdsaEventID) is described, but the first identifier may also be generated by the entitlement server (520). The entitlement server (520) may generate the first identifier and transmit it to the external electronic device (700) before the external electronic device (700) transmits the fourth request message including the ODSA operation information, "ManageSubscription." For example, the entitlement server (520) may generate the first identifier at any time before the external electronic device (700) transmits the fourth request message including the ODSA operation information, "ManageSubscription," and transmit the generated first identifier to the external electronic device (700), so that the external electronic device (700) includes the first identifier in the fourth request message including the ODSA operation information, "ManageSubscription." In one embodiment, there may be no limitation on the format of the message for the entitlement server (520) to transmit the first identifier to the external electronic device (700).

[0354] FIG. 10A is a signal flow diagram illustrating an ODSA procedure in a wireless communication network according to one embodiment.

[0355] FIG. 10b is a signal flow diagram illustrating an ODSA procedure in a wireless communication network according to one embodiment.

[0356] FIG. 10c is a signal flow diagram illustrating an ODSA procedure in a wireless communication network according to one embodiment.

[0357] Referring to FIGS. 10A to 10C , the wireless communication network may include an electronic device (101) (e.g., the electronic device (101) of FIGS. 1A , 1B , 2 , 3 , and / or 5 ), an external electronic device (700) (e.g., the electronic device (102) of FIG. 1A and / or the electronic device (104) of FIG. 1A ), an entitlement server (520) (e.g., the entitlement server (520) of FIG. 5 ), an SM-DP+ server (530) (e.g., the SM-DP+ server (220) of FIG. 2 and / or the SM-DP+ server (530) of FIG. 5 ), an authentication server (540) (e.g., the authentication server (540) of FIG. 5 ), and / or a BSS / OSS (550) (e.g., the BSS / OSS (550) of FIG. 5 ). The external electronic device (700) may be an existing electronic device that has stored a profile associated with the subscription (e.g., an existing profile), and the electronic device (101) may be a new electronic device from which to download a profile associated with the subscription (e.g., a new profile). The ODSA procedure illustrated in FIGS. 10A to 10C may include a profile transfer (or subscription transfer or line transfer) procedure between electronic devices. In one embodiment, the electronic device (101) and the external electronic device (700) may be connected to a data network based on a WiFi method. In one embodiment, a case where the external electronic device (700) and the electronic device (101) are connected to a data network based on a WiFi method is described as an example, but the external electronic device (700) and the electronic device (101) may be connected to a data network based on various short-range communication methods in addition to the WiFi method.

[0358] In operation 1001, the external electronic device (700) can confirm a user input associated with a profile transfer between electronic devices (e.g., a user input selecting a profile transfer (or subscription transfer or line transfer) between electronic devices). For example, the external electronic device (700) can output (e.g., display) a UI (e.g., a profile transfer menu between electronic devices) for selecting a profile transfer between electronic devices, and can confirm the user input through the UI. The UI can include information to the effect of selecting to transfer a profile of the external electronic device (700) to the electronic device (101), or can include information to the effect of selecting to transfer a profile (or subscription or line) from the external electronic device (700) to the electronic device (101) for intuitive recognition by the user.

[0359] Based on a user input selecting to move a profile between electronic devices, the external electronic device (700) may, in operation 1001, transmit a first request message to the entitlement server (520) requesting to move the profile (or subscription or line). The first request message may include an EAP_ID and device information of the electronic device (101). For example, the first request message may be an HTTP REQUEST message. For example, the first request message may be an HTTP REQUEST("EAP_ID") message. In FIGS. 10A to 10C , the authentication process between the external electronic device (700) and the entitlement server (520) is described as an example of an EAP-AKA authentication process, but there may be no limitation on the authentication process between the external electronic device (700) and the entitlement server (520). In one embodiment, the EAP-AKA authentication process may represent an authentication process based on the EAP-AKA scheme.

[0360] The entitlement server (520), which has received a first request message from an external electronic device (700), may, in operation 1002, detect the EAP capability of the electronic device (101) based on the first request message and initiate an EAP procedure with the authentication server (540). For example, operation 1002 is illustrated as “initiate EAP procedure.”

[0361] The authentication server (540) and the entitlement server (520) that initiated the EAP procedure can, in operation 1003, verify (e.g., obtain) an EAP Challenge from the authentication server (540). For example, operation 1003 is illustrated as "EAP Challenge."

[0362] The entitlement server (520), which has obtained an EAP Challenge from the authentication server (540), may transmit a 200 OK message (e.g., an HTTP 200 OK message) as a response message to the first request message to the external electronic device (700) in operation 1004. In one embodiment, the 200 OK message may include the EAP-challenge as an eap-relay-packet. For example, operation 1004 is illustrated as "HTTP 200 OK ("eap-relay-packet: EAP-challenge")."

[0363] An external electronic device (700) that receives a 200 OK message from an entitlement server (520) may, in operation 1005, generate a payload (e.g., EAP-payload) based on the received 200 OK message.

[0364] The external electronic device (700) that generated the payload can perform an EAP-AKA authentication process with the entitlement server (520), and thus, the external electronic device (700) can transmit a second request message including eap-relay-packet as the EAP-payload to the entitlement server (520) in operation 1006. For example, the second request message can be an HTTP REQUEST message. For example, the second request message can be an HTTP REQUEST("eap-relay-packet: EAP-payload") message.

[0365] The entitlement server (520) that received the second request message from the external electronic device (700) may, in operation 1007, transmit a 200 OK message including authentication information (e.g., a token) to the external electronic device (700) if the result of the EAP-AKA authentication process for the external electronic device (700) indicates success. For example, the 200 OK message may be an HTTP 200 OK message. For example, the 200 OK message may be "HTTP 200 OK ("token")."

[0366] The external electronic device (700) that has acquired authentication information may perform an eligibility check with the entitlement server (520) in order to transfer the profile of the external electronic device (700) to the electronic device (101) in operation 1008. The external electronic device (700) may request an eligibility check for the electronic device (101) to the entitlement server (520) based on the HTTP GET method or the HTTP POST method. For example, the external electronic device (700) may request an eligibility check for the electronic device (101) by transmitting a third request message requesting an eligibility check to the entitlement server (520). According to one embodiment, the third request message may be a request message requesting an eligibility check. For example, the third request message may be an HTTP REQUEST message.

[0367] An external electronic device (700) may transmit a third request message containing any one of the ODSA operation information to the entitlement server (520) according to the ODSA procedure specified in standard document TS. 43. The ODSA operation information is described in Table 1, and therefore, a detailed description thereof will be omitted here.

[0368] An external electronic device (700) may request an eligibility check by transmitting a third request message including "CheckEligibility" as ODSA operation information to the entitlement server (520) according to the ODSA procedure specified in standard document TS. 43 at operation 1009. In one embodiment, the third request message may include authentication information (e.g., a token) obtained from the entitlement server (520). For example, the third request message may be an HTTP REQUEST("CheckEligibility", "token") message.

[0369] Although not separately illustrated in FIGS. 10A to 10C , the entitlement server (520) may transmit a profile query to the BSS / OSS (550). The profile query may include subscription identification information (e.g., "SubscriptionID"). The BSS / OSS (550) may transmit a profile answer corresponding to the profile query to the entitlement server (520).

[0370] The entitlement server (520), which has received a third request message including CheckEligibility as ODSA operation information from an external electronic device (700), can perform an eligibility check on the electronic device (101) based on the third request message including CheckEligibility as ODSA operation information in operation 1009.

[0371] If the result of the eligibility check for the electronic device (101) indicates success, the entitlement server (520) may, in operation 1009, transmit a 200 OK message (e.g., an HTTP 200 OK message) as a response message to the third request message to the external electronic device (700). In FIGS. 10A to 10C , it is assumed that the result of the eligibility check for the electronic device (101) indicates success, and if the result of the eligibility check for the electronic device (101) indicates failure, no further operations may be performed. In one embodiment, if the result of the eligibility check indicates success, the 200 OK message may include information of "ENABLED."

[0372] An external electronic device (700) that receives a 200 OK message from an entitlement server (520) may, in operation 1010, generate a first identifier (e.g., OdsaEventID) associated with an ongoing ODSA procedure (e.g., an ongoing profile migration procedure). In one embodiment, the first identifier may be an identifier used to identify an ongoing ODSA procedure. In one embodiment, a generation rule (or generation function) for generating the first identifier may be implemented in various forms.

[0373] The external electronic device (700) that generated the first identifier may, in operation 1011, include "ManageSubscription" as ODSA operation information and transmit a fourth request message (e.g., an HTTP REQUEST("ManageSubscription") message) including the first identifier (e.g., OdsaEventID) to the entitlement server (520). In one embodiment, the fourth request message may be a message requesting a subscription management operation. In one embodiment, the subscription management operation may include various operations related to subscription.

[0374] In one embodiment, the fourth request message may include ODSA operation information for "ManageSubscription." "ManageSubscription" may be ODSA operation information used to request subscription-related operations. According to one embodiment, the fourth request message may include operation type information. Since the operation type information is described in Table 2, a detailed description thereof will be omitted here.

[0375] The fourth request message may include an action type and authentication information (e.g., a token) having a value of “3-TRANSFER SUBSCRIPTION” in Table 2, and “TRANSFER SUBSCRIPTION” may be an action type for transferring a subscription (e.g., a profile) of an existing electronic device (e.g., an external electronic device (700)) having an eSIM to another electronic device (e.g., an electronic device (101)) having an eSIM.

[0376] The entitlement server (520) that receives the fourth request message from the external electronic device (700) may store the first identifier (e.g., OdsaEventID) included in the fourth request message in operation 1012.

[0377] The entitlement server (520) storing the first identifier (e.g., OdsaEventID) may, in operation 1013, transmit a subscription query to the BSS / OSS (550). The subscription query may include subscription identification information (e.g., “SubscriptionID”) and may be used to request activation of a new subscription (or profile) (e.g., activation of a new subscription (or profile) for an external electronic device (700).

[0378] The BSS / OSS (550), which has received a subscription query from the entitlement server (520), may request a new profile to the SM-DP+ server (530) through the ES2+ interface (e.g., DownloadOrder, ConfirmOrder, and ReleaseProfile) in operation 1014-1. The SM-DP+ server (530), which has confirmed the new profile request from the BSS / OSS (550), may notify the BSS / OSS (550) that download information for downloading the new profile is delayed. The BSS / OSS (550), which has been notified from the SM-DP+ server (530) that download information for downloading the new profile is delayed, may transmit a response message indicating that the download information is delayed to the entitlement server (520) in operation 1014-2. For example, operation 1014-2 is illustrated as “Answer (Delayed).”

[0379] The entitlement server (520) that received the response message from the BSS / OSS (550) may, in operation 1015, transmit a 200 OK message (e.g., an HTTP 200 OK ("SubscriptionResult = 4 - DELAYED DOWNLOAD) message) as a response message to the fourth request message to the external electronic device (700). The DELAYED DOWNLOAD may be subscription result information indicating that the profile is not ready to be downloaded when a user (e.g., the external electronic device (700)) requests a subscription move (or profile move).

[0380] The external electronic device (700), which has received a response message to the fourth request message from the entitlement server (520), may transmit a fifth request message to the entitlement server (520) in operation 1016, requesting that the entitlement server (520) provide service-related data for the primary device (e.g., the external electronic device (700)) or the companion device. For example, the fifth request message may include ODSA operation information set to "AcquireConfiguration," a first identifier, and / or authentication information (e.g., a token). For example, the fifth request message may be an HTTP REQUEST ("AcquireConfiguration", "token", "OdsaEventID") message.

[0381] The entitlement server (520), which has received the fifth request message from the external electronic device (700), may, in operation 1017, transmit a message (e.g., a Subscription Status Query message) querying the subscription (or profile) status to the BSS / OSS (550). In one embodiment, the message querying the subscription (or profile) status may include a SubscriptionID.

[0382] The BSS / OSS (550), which has received a message from the entitlement server (520) inquiring about the subscription (or profile) status, may, in operation 1018, check the subscription status and transmit a response message including information related to whether the profile download is ready to the entitlement server (520). The response message of operation 1018 may indicate that profile download information for downloading the profile is not available and that the subscription (or profile) is not ready.

[0383] The entitlement server (520), which has received a response message from the BSS / OSS (550), may transmit a 200 OK message, which is a response message to the fifth request message, to the external electronic device (700) in operation 1019. The 200 OK message, which is a response message to the fifth request message, may include any one of the ServiceStatus information indicating the service status as described in . For example, the 200 OK message, which is a response message to the fifth request message, may include “2 - ACTIVATING.” In one embodiment, “2 - ACTIVATING” may indicate that the service of the eSIM device (e.g., the electronic device (101)) will be activated.

[0384] The external electronic device (700) that receives the 200 OK message from the entitlement server (520) can know that a service (e.g., profile download) for the electronic device (101) will be activated in operation 1019-1, and thus can wait for the profile preparation to be completed. For example, the external electronic device (700) can wait for a push message containing download information to be received in operation 1019-1. For example, operation 1019-1 is illustrated as "wait push."

[0385] The entitlement server (520), which has transmitted a 200 OK message as a response message to the fifth request message to the external electronic device (700), can confirm that the profile is prepared and the service is activated in operation 1020.

[0386] The entitlement server (520), which has confirmed that the profile is ready, may transmit a push message including information indicating that the profile is ready to the external electronic device (700) in operation 1021. However, the external electronic device (700) may not be able to receive the push message transmitted from the entitlement server (520) for various reasons, such as when an error occurs in the network and / or when an error occurs in the external electronic device (700). In this way, since the external electronic device (700) cannot receive the push message transmitted from the entitlement server (520), the external electronic device (700) may continuously wait to receive the push message, and thus, as in operation 1022, the validity time for authentication information (e.g., a token) of the external electronic device (700) may expire or the authentication information of the external electronic device (700) may be lost. For example, operation 1022 is illustrated as “token expired or lost.”

[0387] After the validity time for the token has expired or the token has been lost, the external electronic device (700) may, at operation 1028, verify a user input associated with profile migration between electronic devices as a user of the external electronic device (700) reattempts the subscription migration, or determine that a recovery scenario of the external electronic device (700) needs to be performed. In one embodiment, the recovery scenario may be a scenario for reattempting profile migration between electronic devices. The external electronic device (700) that has verified a user input associated with profile migration between electronic devices or determined that a recovery scenario needs to be performed, may, at operation 1028, transmit an eighth request message to the entitlement server (520) requesting that the entitlement server (520) provide service-related data for the primary device (e.g., the external electronic device (700)) or the companion device. For example, the eighth request message may include ODSA operation information set to "AcquireConfiguration," a first identifier, and / or authentication information. For example, the 8th request message could be an HTTP REQUEST ("AcquireConfiguration", "token", OdsaEventID) message.

[0388] Alternatively, as authentication information expires, the entitlement server (520) may require re-authentication of the external electronic device (700). In this case, the external electronic device (700), which verifies user input associated with profile migration between electronic devices or determines that a recovery scenario needs to be performed, may, at operation 1023, transmit a sixth request message to the entitlement server (520) requesting that the entitlement server provide service-related data for the primary device (e.g., the external electronic device (700)) or the companion device. For example, the sixth request message may include ODSA operation information set to "AcquireConfiguration," a first identifier, and / or authentication information. For example, the sixth request message may be an HTTP REQUEST ("AcquireConfiguration", "token", OdsaEventID) message. The eighth request message of operation 1028 may be similar to or substantially identical to the sixth request message of operation 1023, and therefore its detailed description is omitted here.

[0389] The entitlement server (520) may, at operation 1024, transmit a message (e.g., an HTTP 511 Network Authentication Required message) to the external electronic device (700) indicating that network authentication is required. The external electronic device (700), which has received the message from the entitlement server (520) indicating that network authentication is required, may, at operation 1025, transmit a seventh request message requesting that the profile (or subscription or line) be transferred to the entitlement server (520). The seventh request message may include an EAP_ID. For example, the seventh request message may be an HTTP REQUEST message, and may be an HTTP REQUEST("EAP_ID") message.

[0390] The entitlement server (520), which has received the seventh request message from the external electronic device (700), may transmit a message indicating that network authentication is required (e.g., an HTTP 511 Network Authentication Required message) in operation 1026. The external electronic device (700), which has received the message indicating that network authentication is required from the entitlement server (520), may perform an Oauth2.0 / OpenID authentication process with the entitlement server (520) to verify (e.g., obtain) authentication information (e.g., a token) in operation 1027.

[0391] The entitlement server (520) that receives the sixth request message or the eighth request message from the external electronic device (700) may, in operation 1029, resume the profile transfer procedure based on the first identifier. For example, operation 1029 is illustrated as "restore transfer scenario based on OdsaEventID."

[0392] The entitlement server (520) that has resumed the profile transfer procedure may, at operation 1030, send a message (e.g., a Subscription Status Query message) to the BSS / OSS (550) to query the subscription (or profile) status. In one embodiment, the message querying the subscription (or profile) status may include a SubscriptionID.

[0393] The BSS / OSS (550), which has received a message from the entitlement server (520) inquiring about the subscription (or profile) status, may, in operation 1031, check the subscription status and transmit a response message including information related to whether the profile download is ready to the entitlement server (520). The response message of operation 1031 may indicate that profile download information for downloading the profile is available and that the subscription (or profile) is ready.

[0394] Operations 1016 to 1031 after the external electronic device (700) receives a 200 OK message, which is a response message to the fourth request message in operation 1015, may be operations when the push method is used, and in contrast, operations when the polling method is used may be implemented as operations 1032 to 1047. This can be described in detail as follows.

[0395] The external electronic device (700), which has received the 200 OK message as a response message to the fourth request message in operation 1015, may transmit a ninth request message to the entitlement server (520) in operation 1032, requesting that the entitlement server provide service-related data for the primary device (e.g., the external electronic device (700)) or the companion device. For example, the ninth request message may include ODSA operation information set to "AcquireConfiguration," a first identifier, and / or authentication information (e.g., a token). For example, the ninth request message may be an HTTP REQUEST ("AcquireConfiguration", "token", "OdsaEventID") message.

[0396] The entitlement server (520), which has received the 9th request message from the external electronic device (700), may, in operation 1033, transmit a message (e.g., a Subscription Status Query message) querying the subscription (or profile) status to the BSS / OSS (550). In one embodiment, the message querying the subscription (or profile) status may include a SubscriptionID.

[0397] The BSS / OSS (550), which has received a message from the entitlement server (520) inquiring about the subscription (or profile) status, may, in operation 1034, check the subscription status and transmit a response message including information related to whether the profile download is ready to the entitlement server (520). The response message of operation 1034 may indicate that profile download information for downloading the profile is not available and that the subscription (or profile) is not ready.

[0398] The entitlement server (520) that receives the response message from the BSS / OSS (550) may transmit a 200 OK message, which is a response message for the ninth request message, to the external electronic device (700) in operation 1035. The 200 OK message, which is a response message for the ninth request message, may include any one of the ServiceStatus information indicating the service status as described in and / or a polling interval. For example, the 200 OK message, which is a response message for the ninth request message, may include “2 - ACTIVATING.” In one embodiment, “2 - ACTIVATING” may indicate that the service of the eSIM device (e.g., the electronic device (101)) will be activated. For example, action 1035 is depicted as "HTTP 200 OK ("ServiceStatus = 2 - ACTIVATING", "PollingInterval = < PollingIntervalMinutes>")".

[0399] An external electronic device (700) that receives a 200 OK message from an entitlement server (520) can know that a service (e.g., profile download) for the electronic device (101) will be activated at operation 1036, and can perform a delay operation during the polling interval included in the 200 OK message.

[0400] The external electronic device (700) that performed the delay operation may, at operation 1037, transmit a tenth request message requesting the entitlement server (520) to provide service-related data for the primary device (e.g., the external electronic device (700)) or the companion device. For example, the tenth request message may include ODSA operation information set to "AcquireConfiguration," a first identifier, and / or authentication information. For example, the tenth request message may be an HTTP REQUEST ("AcquireConfiguration", "token", OdsaEventID) message.

[0401] However, for various reasons, such as when an error occurs in the network and / or when an error occurs in the external electronic device (700), the validity period for the authentication information (e.g., token) of the external electronic device (700) may expire or the authentication information of the external electronic device (700) may be lost, as in operation 1038. For example, operation 1038 is illustrated as “token expired or lost.”

[0402] After the validity time for the token has expired or the token has been lost, the external electronic device (700) may, at operation 1044, verify user input associated with profile migration between electronic devices as the user of the external electronic device (700) retries the subscription migration, or determine that a recovery scenario of the external electronic device (700) needs to be performed. The external electronic device (700) that has verified user input associated with profile migration between electronic devices or determines that a recovery scenario needs to be performed, at operation 1044, may transmit a thirteenth request message to the entitlement server (520) requesting that the entitlement server (520) provide service-related data for the primary device (e.g., the external electronic device (700)) or the companion device. For example, the thirteenth request message may include ODSA operation information set to "AcquireConfiguration," a first identifier, and / or authentication information. For example, the 13th request message is depicted as HTTP REQUEST ("AcquireConfiguration", "token", OdsaEventID).

[0403] Alternatively, as authentication information expires, the entitlement server (520) may require re-authentication of the external electronic device (700). In this case, the external electronic device (700), which verifies user input associated with profile migration between electronic devices or determines that a recovery scenario needs to be performed, may, at operation 1039, transmit an eleventh request message to the entitlement server (520) requesting that the entitlement server provide service-related data for the primary device (e.g., the external electronic device (700)) or the companion device. For example, the eleventh request message may include ODSA operation information set to "AcquireConfiguration," a first identifier, and / or authentication information. For example, the eleventh request message may be an HTTP REQUEST ("AcquireConfiguration", "token", OdsaEventID) message. The 13th request message of operation 1044 may be similar to or substantially identical to the 11th request message of operation 1039, and therefore, a detailed description thereof is omitted here.

[0404] The entitlement server (520) may, at operation 1040, transmit a message (e.g., an HTTP 511 Network Authentication Required message) to the external electronic device (700) indicating that network authentication is required. The external electronic device (700), which has received the message from the entitlement server (520) indicating that network authentication is required, may, at operation 1041, transmit a twelfth request message requesting the transfer of a profile (or subscription or line) to the entitlement server (520). The twelfth request message may include an EAP_ID. For example, the twelfth request message may be an HTTP REQUEST message, and may be an HTTP REQUEST("EAP_ID") message.

[0405] The entitlement server (520), which has received the 12th request message from the external electronic device (700), may transmit a message indicating that network authentication is required (e.g., an HTTP 511 Network Authentication Required message) at operation 1042. The external electronic device (700), which has received the message indicating that network authentication is required from the entitlement server (520), may perform an Oauth2.0 / OpenID authentication process with the entitlement server (520) to verify (e.g., obtain) authentication information (e.g., a token) at operation 1043.

[0406] The entitlement server (520) that receives the 11th request message or the 13th request message from the external electronic device (700) may, in operation 1045, resume the profile transfer procedure based on the first identifier. For example, operation 1045 is illustrated as "restore transfer scenario based on OdsaEventID."

[0407] The entitlement server (520) that has resumed the profile transfer procedure may, at operation 1046, send a message (e.g., a Subscription Status Query message) to the BSS / OSS (550) querying the subscription (or profile) status. In one embodiment, the message querying the subscription (or profile) status may include a SubscriptionID.

[0408] The BSS / OSS (550), which has received a message from the entitlement server (520) inquiring about the subscription (or profile) status, may, in operation 1047, check the subscription status and transmit a response message including information related to whether the profile download is ready to the entitlement server (520). The response message of operation 1047 may indicate that profile download information for downloading the profile is available and that the subscription (or profile) is ready.

[0409] The entitlement server (520) that received the response message of operation 1031 or the response message of operation 1047 may transmit a 200 OK message, which is a response message for the 6th request message, the 8th request message, the 11th request message, or the 13th request message, to the external electronic device (700) in operation 1048. The 200 OK message may include 2 - DOWNLOAD PROFILE as subscription result information, which indicates that the profile must be downloaded. The 200 OK message may include download information (e.g., the address of the SM-DP+ server (530)) for the electronic device (101) to download the profile. Since the subscription result information is described in Table 3, a detailed description thereof will be omitted here. For example, operation 1048 is illustrated as "HTTP 200 OK ("SubscriptionResult = 2 - DOWNLOAD PROFILE", "DownloadInfo")".

[0410] An external electronic device (700) that receives a 200 OK message from an entitlement server (520) can determine that the electronic device (101) must download a profile based on the 200 OK message, and thus, the external electronic device (700) can transmit download information for downloading a new profile to the electronic device (101) in operation 1049. For example, operation 1049 is illustrated as "DownloadInfo".

[0411] An electronic device (101) that has received download information for downloading a new profile from an external electronic device (700) can, in operation 1050, download the profile from the SM-DP+ server (530) based on the download information. For example, operation 1050 is illustrated as “Download profile.”

[0412] In FIGS. 10A to 10C, an example in which an external electronic device (700) generates a first identifier (e.g., OdsaEventID) is described, but the first identifier may also be generated by the entitlement server (520). The entitlement server (520) may generate the first identifier and transmit it to the external electronic device (700) before the external electronic device (700) transmits the fourth request message including the ODSA operation information, "ManageSubscription." For example, the entitlement server (520) may generate the first identifier at any time before the external electronic device (700) transmits the fourth request message including the ODSA operation information, "ManageSubscription," and transmit the generated first identifier to the external electronic device (700), so that the external electronic device (700) includes the first identifier in the fourth request message including the ODSA operation information, "ManageSubscription." In one embodiment, there may be no limitation on the format of the message for the entitlement server (520) to transmit the first identifier to the external electronic device (700).

[0413] FIG. 11 is a signal flow diagram illustrating an ODSA procedure in a wireless communication network according to one embodiment.

[0414] Referring to FIG. 11, when a profile transfer is performed between electronic devices, for example, an electronic device (e.g., the electronic device (101) of FIG. 1A, FIG. 1B, FIG. 2, FIG. 3, and / or FIG. 5) and an external electronic device (e.g., the electronic device (102) and / or the electronic device (104) of FIG. 1A), the external electronic device needs to communicate with a telecommunications carrier. In one embodiment, the external electronic device may be an existing electronic device that has stored a profile associated with a subscription (e.g., an existing profile), and the electronic device may be a new electronic device from which to download a profile associated with the subscription (e.g., a new profile). In order for the external electronic device to communicate with a telecommunications carrier, a method may be required that can specify (or select) a telecommunications carrier from among a plurality of telecommunications carriers with which the external electronic device will communicate.

[0415] Since the external electronic device itself has the physical SIM or eSIM profile it wants to move, it can identify the carrier based on the information contained in the physical SIM or eSIM profile and perform the profile move by connecting to the entitlement server of the specific carrier.

[0416] However, in the case of reusable profiles, it may be necessary to delete the existing profile stored in the external electronic device. In this case, if various errors, such as Wi-Fi errors and / or network errors, occur while the existing profile is deleted, the external electronic device may not be able to specify the telecommunications carrier with which to perform communication. Since the external electronic device must know which telecommunications carrier's entitlement server to connect to in order to connect to and communicate with the telecommunications carrier, if the external electronic device is unable to specify the telecommunications carrier, the external electronic device (or the user of the external electronic device) may have to select the telecommunications carrier to which it wishes to connect. However, it may be difficult for the external electronic device (or the user of the external electronic device) to select the desired telecommunications carrier among numerous telecommunications carriers, which may cause inconvenience to both users and telecommunications carriers.

[0417] Referring to FIG. 11, the external electronic device may store a first identifier (e.g., OdsaEventID) associated with an ongoing (e.g., incomplete) ODSA procedure (e.g., a profile migration procedure) between the external electronic device and the electronic device, carrier information associated with a carrier associated with the ODSA procedure, and / or scenario information associated with the ODSA procedure. In one embodiment, the first identifier may be an identifier used to identify an ongoing ODSA procedure.

[0418] An error may occur during the profile migration procedure when the external electronic device stores an OdsaEventID related to the profile migration procedure, carrier information related to the carrier related to the profile migration procedure, and / or scenario information related to the profile migration procedure. In this case, even if the existing profile has been deleted, the external electronic device can specify the carrier corresponding to the profile migration procedure based on the OdsaEventID, and thus resume and complete the profile migration procedure. In one embodiment, even if the existing profile has been deleted, the external electronic device can resume and complete the profile migration procedure by specifying the carrier corresponding to the profile migration procedure based on the OdsaEventID, rather than restarting the profile migration procedure from the beginning, thereby increasing convenience for users and carriers.

[0419] If an error occurs during the profile transfer procedure, the external electronic device may output (e.g., display) a UI (e.g., a profile transfer menu between electronic devices) for selecting profile transfer between electronic devices, as shown in the screen (1110), and may confirm a user input (1120) for selecting to transfer the profile of the external electronic device to the electronic device through the UI.

[0420] Upon receiving a user input (1120) selecting to move a profile of an external electronic device to the electronic device, the external electronic device may determine whether an incomplete profile move procedure exists in operation 1130. In one embodiment, the external electronic device may determine that an incomplete profile move procedure exists if an OdsaEventID corresponding to the incomplete profile move procedure exists.

[0421] If, as a result of the verification, there is an incomplete profile transfer procedure, the external electronic device can, in operation 1140, check the carrier corresponding to the OdsaEventID for the incomplete profile transfer procedure. The external electronic device, having checked the carrier corresponding to the OdsaEventID for the incomplete profile transfer procedure, can, in operation 1150, output a carrier webview corresponding to the carrier corresponding to the OdsaEventID.

[0422] In operation 1130, if the verification result shows that there is no incomplete profile transfer procedure, the external electronic device can output (e.g., display) a list of telecommunications carriers as shown on the screen (1160) in operation 1160, and based on a user input for selecting a telecommunications carrier, output a carrier webview corresponding to the selected telecommunications carrier in operation 1150.

[0423] FIG. 12 is a drawing for explaining an example of screens displayed on an electronic device according to one embodiment.

[0424] The screens (1210, 1220, 1230, 1240, 1250, and 1260) illustrated in FIG. 12 may be screens according to an ODSA procedure. The ODSA procedure corresponding to the screens (1210, 1220, 1230, 1240, 1250, and 1260) illustrated in FIG. 12 may be a profile transfer (or subscription transfer or line transfer) procedure between electronic devices. The screens (1210, 1220, 1230, 1240, 1250, and 1260) illustrated in FIG. 12 may be screens according to the profile transfer procedure between electronic devices described in FIGS. 7A and 7B.

[0425] Referring to FIG. 12, as described in FIGS. 7A and 7B, the external electronic device (e.g., the electronic device (102) and / or the electronic device (104) of FIG. 1A) may be an existing electronic device that has stored a profile associated with the subscription (e.g., an existing profile), and the electronic device (e.g., the electronic device (101) of FIGS. 1A, 1B, 2, 3, and / or 5) may be a new electronic device from which to download a profile associated with the subscription (e.g., a new profile).

[0426] As described in operation 711, when the electronic device receives a 200 OK message (e.g., an HTTP 200 OK ("SubscriptionResult = 4 - DELAYED DOWNLOAD) message) as a response message to a third request message (e.g., an HTTP REQUEST ("ManageSubscription") message) that includes "ManageSubscription" as ODSA operation information and includes a first identifier (e.g., OdsaEventID) from an entitlement server (e.g., the entitlement server (520) of FIG. 5), the electronic device can determine that the profile is not ready for download (e.g., that it is a delayed download) based on the subscription result information set to "DELAYED DOWNLOAD". The electronic device that determines that it is a delayed download can output (e.g., display) a screen (1210) indicating that it is preparing the profile.

[0427] The electronic device may wait for reception of a push message including download information for downloading a profile from an SM-DS (e.g., SM-DS (210) of FIG. 2 and / or SM-DS (560) of FIG. 5) or an entitlement server while outputting the screen (1210) in this manner. While waiting for reception of the push message, if a push message is received from the SM-DS or the entitlement server as described in operation 720, operation 725, or operation 727, the electronic device may check a first identifier (e.g., OdsaEventID) included in the push message, and may check whether the checked first identifier is identical to a first identifier for a profile transfer procedure between electronic devices that is in progress in the electronic device.

[0428] As a result of the verification, if the first identifier identified from the push message is not the same as the first identifier for the profile migration procedure between electronic devices in progress in the electronic device, since the first identifier identified from the push message is the first identifier for a new profile migration procedure, not the profile migration procedure between electronic devices in progress in the electronic device, the electronic device may output a screen (1220) indicating that a push message including download information for a new profile corresponding to the new profile migration procedure has arrived. The screen (1220) may correspond to operation 729.

[0429] As a result of the verification, if the first identifier identified from the push message is the same as the first identifier for the profile transfer procedure between electronic devices in progress in the electronic device, since the first identifier identified from the push message is the first identifier for the profile transfer procedure between electronic devices in progress in the electronic device, the electronic device may discard the received push message, and the electronic device may output a screen (1230) indicating that a profile ready to be downloaded exists.

[0430] An electronic device that outputs a screen (1230) may output a screen (1240) indicating that it is downloading a profile according to a profile transfer procedure between electronic devices that is in progress. If a push message is received from an SM-DS or an entitlement server while downloading a profile in this manner, the electronic device may check a first identifier (e.g., OdsaEventID) included in the push message and check whether the checked first identifier is identical to the first identifier for the profile transfer procedure between electronic devices that is in progress in the electronic device.

[0431] As a result of the verification, if the first identifier identified from the push message is not the same as the first identifier for the profile migration procedure between electronic devices in progress in the electronic device, since the first identifier identified from the push message is the first identifier for a new profile migration procedure, not the profile migration procedure between electronic devices in progress in the electronic device, the electronic device may output a screen (1250) indicating that a push message including download information for a new profile corresponding to the new profile migration procedure has arrived. The screen (1250) may correspond to operation 729.

[0432] As a result of the verification, if the first identifier identified from the push message is the same as the first identifier for the profile transfer procedure between electronic devices in progress in the electronic device, the first identifier identified from the push message is the first identifier for the profile transfer procedure between electronic devices in progress in the electronic device, and therefore the electronic device may discard the received push message and output a screen (1260) indicating that it is downloading the profile according to the profile transfer procedure between electronic devices in progress.

[0433] FIG. 13 is a drawing for explaining an example of screens displayed on an electronic device according to one embodiment.

[0434] The screens (1310, 1320, 1330, 1340, 1350, 1360, 1370, and 1380) illustrated in FIG. 13 may be screens according to an ODSA procedure. The ODSA procedure corresponding to the screens (1310, 1320, 1330, 1340, 1350, 1360, 1370, and 1380) illustrated in FIG. 13 may be a profile transfer (or subscription transfer or line transfer) procedure between electronic devices. The screens (1310, 1320, 1330, 1340, 1350, 1360, 1370, and 1380) illustrated in FIG. 13 may be screens according to the profile transfer procedure between electronic devices described in FIGS. 8A to 8C, or FIGS. 9A and 9B, or FIGS. 10A to 10C.

[0435] Referring to FIG. 13, as described in FIGS. 8A to 8C, or FIGS. 9A and 9B, or FIGS. 10A to 10C, the external electronic device (e.g., the electronic device (102) and / or the electronic device (104) of FIG. 1A) may be an existing electronic device that has stored a profile associated with the subscription (e.g., an existing profile), and the electronic device (e.g., the electronic device (101) of FIGS. 1A, 1B, 2, 3, and / or 5) may be a new electronic device from which to download a profile associated with the subscription (e.g., a new profile).

[0436] The external electronic device can output (e.g., display) a UI (e.g., a menu for moving profiles between electronic devices) for selecting to move profiles between electronic devices, as shown on the screen (1310), and can confirm a user input (1320) for selecting to move a profile of the external electronic device to the electronic device through the UI.

[0437] The external electronic device, upon confirming a user input (1320) selecting to move a profile of an external electronic device to the electronic device, may output a screen (1330) indicating that a procedure for moving the profile has begun. After outputting the screen (1330), the external electronic device may output a screen (1340) for entering a verification code for starting the procedure for moving the profile. When the verification code (e.g., "123456") is confirmed through the screen (1340) for entering the verification code, the external electronic device may output a screen (1350) indicating that a profile stored in the external electronic device (e.g., a profile corresponding to SIM1) has been selected.

[0438] The external electronic device that outputs the screen (1350) may output a screen (1360) indicating that a profile transfer procedure between electronic devices is in progress. While the external electronic device outputs the screen (1360) indicating that a profile transfer procedure between electronic devices is in progress, if a network error occurs in the server of the data network, various errors may occur, such as a WiFi connection error, an error occurring in the external electronic device, or an error occurring in the electronic device itself.

[0439] If an error occurs during the profile transfer procedure, the external electronic device may output (e.g., display) a UI (e.g., a profile transfer menu between electronic devices) for selecting profile transfer between electronic devices, as shown in the screen (1370), and may confirm a user input (1380) for selecting to transfer the profile of the external electronic device to the electronic device through the UI.

[0440] Upon receiving a user input (1380) selecting to move a profile of an external electronic device to the electronic device, the external electronic device may determine whether an incomplete profile transfer procedure exists. In one embodiment, the external electronic device may determine the presence of an incomplete profile transfer procedure if an OdsaEventID corresponding to the incomplete profile transfer procedure exists.

[0441] If the verification result shows that there is an incomplete profile transfer procedure, the external electronic device can check the telecommunications carrier corresponding to the OdsaEventID for the incomplete profile transfer procedure. The external electronic device that has checked the telecommunications carrier corresponding to the OdsaEventID for the incomplete profile transfer procedure can resume the profile transfer procedure between electronic devices corresponding to the OdsaEventID and output a screen (1390) indicating that the profile transfer procedure between electronic devices is in progress.

[0442] FIG. 14 is a drawing for explaining an example of screens displayed on an electronic device according to one embodiment.

[0443] The screens (1410, 1420, 1430, 1440) illustrated in FIG. 14 may be screens according to an ODSA procedure. The ODSA procedure corresponding to the screens (1410, 1420, 1430, 1440) illustrated in FIG. 14 may be a profile transfer (or subscription transfer or line transfer) procedure between electronic devices. The screens (1410, 1420, 1430, 1440) illustrated in FIG. 14 may be screens according to the profile transfer procedure between electronic devices described in FIG. 11.

[0444] Referring to FIG. 14, when a profile transfer is performed between electronic devices, for example, an electronic device (e.g., the electronic device (101) of FIG. 1A, FIG. 1B, FIG. 2, FIG. 3, and / or FIG. 5) and an external electronic device (e.g., the electronic device (102) and / or the electronic device (104) of FIG. 1A), the external electronic device needs to communicate with a telecommunications carrier. In one embodiment, the external electronic device may be an existing electronic device that has stored a profile associated with a subscription (e.g., an existing profile), and the electronic device may be a new electronic device from which to download a profile associated with the subscription (e.g., a new profile). In order for the external electronic device to communicate with a telecommunications carrier, a method may be required that can specify (or select) a telecommunications carrier from among a plurality of telecommunications carriers with which the external electronic device will communicate.

[0445] Since the external electronic device itself has the physical SIM or eSIM profile it wants to move, it can identify the carrier based on the information contained in the physical SIM or eSIM profile and perform the profile move by connecting to the entitlement server of the specific carrier.

[0446] However, in the case of reusable profiles, it may be necessary to delete the existing profile stored on the external electronic device. In this case, if various errors, such as Wi-Fi errors and / or network errors, occur while the existing profile is deleted, the external electronic device may not be able to specify the telecommunications carrier with which to communicate. Since the external electronic device must know which telecommunications carrier's entitlement server to connect to in order to connect to and communicate with the telecommunications carrier, if the external electronic device is unable to specify the telecommunications carrier, the external electronic device (or the user of the external electronic device) may have to select the telecommunications carrier to which it wishes to connect. However, it may be difficult for the external electronic device (or the user of the external electronic device) to select the desired telecommunications carrier among numerous telecommunications carriers, which may cause inconvenience to both users and telecommunications carriers.

[0447] Referring to FIG. 14, the external electronic device may store a first identifier (e.g., OdsaEventID) associated with an ongoing (e.g., incomplete) ODSA procedure (e.g., a profile migration procedure) between the external electronic device and the electronic device, carrier information associated with a carrier associated with the ODSA procedure, and / or scenario information associated with the ODSA procedure. In one embodiment, the first identifier may be an identifier used to identify an ongoing ODSA procedure.

[0448] An error may occur during the profile migration procedure when the external electronic device stores an OdsaEventID related to the profile migration procedure, carrier information related to the carrier related to the profile migration procedure, and / or scenario information related to the profile migration procedure. In this case, even if the existing profile has been deleted, the external electronic device can specify the carrier corresponding to the profile migration procedure based on the OdsaEventID, and thus resume and complete the profile migration procedure. In one embodiment, even if the existing profile has been deleted, the external electronic device can resume and complete the profile migration procedure by specifying the carrier corresponding to the profile migration procedure based on the OdsaEventID, rather than restarting the profile migration procedure from the beginning, thereby increasing convenience for users and carriers.

[0449] If an error occurs during the profile transfer procedure, the external electronic device may output (e.g., display) a UI (e.g., a profile transfer menu between electronic devices) for selecting profile transfer between electronic devices, as shown in the screen (1410), and may confirm a user input (1420) for selecting to transfer the profile of the external electronic device to the electronic device through the UI.

[0450] Upon receiving a user input (1420) selecting to move a profile of an external electronic device to the electronic device, the external electronic device may determine whether an incomplete profile transfer procedure exists. In one embodiment, the external electronic device may determine the presence of an incomplete profile transfer procedure if an OdsaEventID corresponding to the incomplete profile transfer procedure exists.

[0451] If the verification result indicates that an incomplete profile transfer procedure exists, the external electronic device can identify the telecommunications carrier corresponding to the OdsaEventID for the incomplete profile transfer procedure. The external electronic device, having identified the telecommunications carrier corresponding to the OdsaEventID for the incomplete profile transfer procedure, can output a carrier webview (1430) corresponding to the telecommunications carrier corresponding to the OdsaEventID.

[0452] If the verification result shows that there is no incomplete profile transfer procedure, the external electronic device can output (e.g., display) a list of telecommunications carriers as shown on the screen (1440) and output a carrier webview (1430) corresponding to the selected telecommunications carrier based on a user input for selecting the telecommunications carrier.

[0453] FIG. 15a is a signal flow diagram illustrating an ODSA procedure in a wireless communication network according to one embodiment.

[0454] FIG. 15b is a signal flow diagram illustrating an ODSA procedure in a wireless communication network according to one embodiment.

[0455] Before describing FIGS. 15A and 15B, it should be noted that the ODSA procedure may include a profile transfer (or subscription transfer or line transfer) procedure between electronic devices.

[0456] In a profile migration procedure, a reusable profile (or a redownloadable profile) may need to be deleted by the existing electronic device. However, before the existing electronic device deletes the profile (e.g., the existing profile) and receives download information (e.g., DownloadInfo) for downloading the profile (e.g., the new profile) on the new electronic device, the validity period for authentication information (e.g., a token) may expire. In this way, when the validity period for authentication information expires, various errors may occur, such as authentication based on the existing profile (e.g., EAP-AKA authentication) being impossible because the existing profile has been deleted.

[0457] In this case, various errors may occur due to the expiration of the authentication information.

[0458] Additionally, in the profile transfer procedure, if the profile download proceeds in a delayed download manner, the authentication information may expire while the new electronic device receives a push message containing information indicating that the profile is ready, or while performing an operation according to the polling method. In this way, if the authentication information expires, various errors may occur, such as authentication based on the existing profile (e.g., EAP-AKA authentication) becoming impossible if the carrier has deactivated the existing profile.

[0459] Therefore, in one embodiment of the present disclosure, when an error occurs, such as when authentication based on an existing profile becomes impossible due to an expiration of the token's validity time during a profile migration procedure, a method for updating a token without a new authentication procedure may be proposed. In one embodiment, the method for updating a token without a new authentication procedure may have restrictions, such as limiting the token's operation_targets to AcquireConfiguration and / or allowing only one-time updates to the token. In one embodiment, operation_targets may be used by the AcquireTemporaryToken operation, and may be used to acquire a temporary token associated with an ODSA operation(s) and an application ID (AppID). Since the AcquireTemporaryToken operation has been described in Table 1, a redundant description thereof may be omitted here. In one embodiment, operation_targets may represent a list with all ODSA operations allowed to be requested using the TemporaryToken.

[0460] Referring to FIGS. 15A and 15B , the wireless communication network may include an electronic device (101) (e.g., the electronic device (101) of FIGS. 1A , 1B , 2 , 3 , and / or 5 ), an external electronic device (700) (e.g., the electronic device (102) of FIG. 1A and / or the electronic device (104) of FIG. 1A ), an entitlement server (520) (e.g., the entitlement server (520) of FIG. 5 ), an SM-DP+ server (530) (e.g., the SM-DP+ server (220) of FIG. 2 and / or the SM-DP+ server (530) of FIG. 5 ), an authentication server (540) (e.g., the authentication server (540) of FIG. 5 ), and / or a BSS / OSS (550) (e.g., the BSS / OSS (550) of FIG. 5 ). The external electronic device (700) may be an existing electronic device that stores a profile associated with the subscription (e.g., an existing profile), and the electronic device (101) may be a new electronic device from which to download a profile associated with the subscription (e.g., a new profile). The entitlement server (520) may also be referred to as an “ODSA device GW entitlement configuration server.”

[0461] According to one embodiment, an ODSA client application may be executed on each of the electronic device (101) and the external electronic device (700). The ODSA client application may be executed on the requesting device or the primary device and may allow an end-user to perform seamless activation of subscription and associated services on the eSIM of the companion device or the primary device without intervention of a customer or support representative of the service provider. The ODSA client application may be implemented similarly or substantially identically to the ODSA client application specified in the standard document TS. 43, and thus, a redundant description thereof may be omitted herein. According to one embodiment, each of the electronic device (101) and the external electronic device (700) may include an eSIM. In FIG. 15a and FIG. 15b, the operation of the electronic device (101) can be performed by the ODSA client application, and the operation of the external electronic device (700) can also be performed by the ODSA client application.

[0462] In operation 1501, an EAP-AKA authentication exchange operation may be performed by an external electronic device (700), an entitlement server (520), and an authentication server (540). In the EAP-AKA authentication exchange operation, the external electronic device (700) transmits a request message requesting to trigger an authentication procedure to the entitlement server (520), and accordingly, the external electronic device (700) and the entitlement server (520) may perform an authentication exchange procedure (e.g., an EAP-AKA authentication process). In FIG. 15A, an example in which the authentication process between the external electronic device (700) and the entitlement server (520) is an EAP-AKA authentication process is described, there may be no restrictions on the authentication process between the external electronic device (700) and the entitlement server (520). If the result of the EAP-AKA authentication process indicates success, the entitlement server (520) transmits authentication information (e.g., a token) to the external electronic device (700), so that the external electronic device (700) can obtain the authentication information. In FIG. 15A, it is assumed that the result of the EAP-AKA authentication process indicates success, and if the result of the EAP-AKA authentication process indicates failure, the external electronic device (700) may not perform any further operations. In FIG. 15A, operation 1501 is expressed as "EAP-AKA Authentication Exchange."

[0463] In operation 1502, an eligibility check operation may be performed by the external electronic device (700) that has acquired authentication information, the entitlement server (520), the authentication server (540), and the BSS / OSS (550). In the eligibility check operation, the external electronic device (700) may perform an eligibility check with the entitlement server (520) to transfer the profile of the external electronic device (700) to the electronic device (101). The external electronic device (700) may request an eligibility check for the external electronic device (700) to the entitlement server (520) based on the HTTP GET method or the HTTP POST method. For example, the external electronic device (700) may request an eligibility check to the entitlement server (520) by sending a first request message requesting an eligibility check to determine whether the ODSA client application and the corresponding external electronic device (700) can support an ODSA service (e.g., a primary ODSA service (or primary ODSA procedure) and / or a companion ODSA service (or companion ODSA procedure)). The eligibility check of operation 1502 may include an eligibility check to determine whether the external electronic device (700) supports moving a profile installed on the external electronic device (700) to the electronic device (101). The primary ODSA procedure and the companion ODSA procedure may be implemented similarly or identically to those specified in the standard document TS. 43, and thus, their redundant description may be omitted herein. In one embodiment, the first request message may be a request message requesting an eligibility check, for example, an HTTP REQUEST message. The external electronic device (700) may be a standard document TS in operation 1502.According to the ODSA procedure specified in 43, an eligibility check can be requested by sending a first request message (e.g., an HTTP REQUEST message) that includes "CheckEligibility" as ODSA operation information to the entitlement server (520). The entitlement server (520), which receives the first request message that includes CheckEligibility as ODSA operation information from the external electronic device (700), can perform an eligibility check on the external electronic device (700) based on the first request message that includes CheckEligibility as ODSA operation information. If the result of the eligibility check on the external electronic device (700) indicates success, the entitlement server (520) can send a 200 OK message (e.g., an HTTP 200 OK message) as a response message to the first request message to the external electronic device (700). In FIG. 15A, it is assumed that the result of the eligibility check for the external electronic device (700) indicates success. If the result of the eligibility check for the external electronic device (700) indicates failure, no further operations may be performed. In one embodiment, if the result of the eligibility check indicates success, the 200 OK message may include the information "ENABLED." In FIG. 15A, operation 1502 is expressed as "Eligibility Check."

[0464] In operation 1503, an operation of acquiring temporary authentication information (e.g., a temporary token) may be performed by the external electronic device (700) and the entitlement server (520). In the operation of acquiring temporary authentication information, the external electronic device (700), which has received a 200 OK message including information of "ENABLED", may request temporary authentication information usable by the electronic device (101) by sending a second request message (e.g., an HTTP REQUEST message) to the entitlement server (520), which includes "AcquireTemporaryToken" as ODSA operation information and includes operation_targets for indicating which requests may be used by a trusted third party (e.g., the electronic device (101)). In one embodiment, the temporary authentication information may be temporary authentication information related to an ongoing ODSA procedure (e.g., an ongoing profile migration procedure). The entitlement server (520), which receives a second request message including AcquireTemporaryToken as ODSA operation information from the external electronic device (700), may generate a temporary token based on the second request message including AcquireTemporaryToken as ODSA operation information. The entitlement server (520) may generate temporary authentication information if the electronic device (101) is permitted to use the subscription (or profile) for the external electronic device (700). In FIG. 15A, it is assumed that the electronic device (101) is permitted to use the subscription (or profile) for the external electronic device (700), and if the electronic device (101) is not permitted to use the subscription (or profile) for the external electronic device (700), no further operations may be performed. In one embodiment, the temporary authentication information may be used during the validity period, and thus, the temporary authentication information may not be used when the validity period expires.The entitlement server (520) that generated the temporary authentication information can transmit a 200 OK message (e.g., an HTTP 200 OK message) including the temporary authentication information as a response message to the second request message to the external electronic device (700), and the external electronic device (700) can acquire the temporary authentication information based on the 200 OK message received from the external electronic device (700). In FIG. 15A, operation 1503 is expressed as “Acquire Temporary Token.”

[0465] In operation 1504, an eSIM transfer information exchange operation may be performed between the external electronic device (700) and the electronic device (101). In the eSIM transfer information exchange operation, the external electronic device (700) may transmit all relevant eSIM transfer information to the electronic device (101), and the eSIM transfer information may include temporary authentication information. In FIG. 15A, operation 1504 is expressed as "eSIM Transfer Information Exchange."

[0466] The electronic device (101), which has received eSIM transfer information including temporary authentication information from the external electronic device (700), may transmit a third request message (e.g., an HTTP REQUEST message) including the temporary authentication information and “ManageSubscription” as ODSA operation information to the entitlement server (520) in operation 1505. In one embodiment, the third request message may include terminal_id, which is a terminal ID of the electronic device (101), and old_terminal_iccid, which is a terminal ICCID of the external electronic device (700). For example, the terminal_id of the electronic device (101) may be IMEIesim or UUIDapp, and it is assumed to be IMEIesim in FIG. 15A. For example, the old_terminal_iccid of the external electronic device (700) may be ICCIDold. In one embodiment, the third request message may be a message requesting a subscription management operation. In one embodiment, the subscription management operation may include various operations related to subscription. In one embodiment, "ManageSubscription" may be ODSA operation information used to request a subscription-related operation. According to one embodiment, the third request message may include operation type information, and since the operation type information is described in Table 2, a redundant description thereof will be omitted here. The third request message may include an operation type having a value of "3-TRANSFER SUBSCRIPTION" in Table 2 and temporary authentication information (e.g., a temporary token), and "TRANSFER SUBSCRIPTION" may be an operation type for transferring a subscription (e.g., a profile) of an existing electronic device (e.g., an external electronic device (700)) having an eSIM to another electronic device (e.g., an electronic device (101)) having an eSIM.

[0467] The entitlement server (520), which has received the third request message from the electronic device (101), may transmit a subscription query to the BSS / OSS (550) in operation 1506. The subscription query may include subscription identification information (e.g., “SubscriptionID”), the terminal ID of the electronic device (101) (e.g., IMEIesim), and the terminal ICCID of the external electronic device (700) (e.g., ICCIDold), and may be used to request activation of a new subscription (or profile) (e.g., activation of a new subscription (or profile) for the external electronic device (700).

[0468] The BSS / OSS (550), which has received a subscription query from the entitlement server (520), may perform an ES2+ exchange operation with the SM-DP+ server (530) in operation 1507. In the ES2+ exchange operation, the BSS / OSS (550) may request a new profile from the SM-DP+ server (530) through the ES2+ interface. The SM-DP+ server (530), which has confirmed the new profile request from the BSS / OSS (550), may create a new profile. In FIG. 15A, profile downloading may be considered when a delayed download method is used or when a reusable profile (or a re-downloadable profile) is used. In this case, the SM-DP+ server (530) may notify the BSS / OSS (550) that download information for downloading a new profile is delayed, or may notify that a profile in use (e.g., an existing profile) needs to be deleted. In Figure 15a, operation 1507 is expressed as “ES2+ Exchange”.

[0469] The BSS / OSS (550), which is notified from the SM-DP+ server (530) that download information for downloading a new profile is delayed, may, in operation 1508, transmit a subscription response message to the entitlement server (520) in response to a subscription query message, indicating that the download information is delayed or that an existing profile needs to be deleted. For example, when a delayed download method is used, the BSS / OSS (550) may, in operation 1508, transmit a subscription response message to the entitlement server (520) in response to the subscription query message, indicating that the download information is delayed. For example, when a reusable profile (or a re-downloadable profile) is used, the BSS / OSS (550) may, in operation 1508, transmit a subscription response message to the entitlement server (520) in response to the subscription query message, indicating that an existing profile needs to be deleted.

[0470] The entitlement server (520), which has received a subscription response message from the BSS / OSS (550), may transmit a 200 OK message, which is a response message to the third request message, to the electronic device (101) in operation 1509, and the 200 OK message may include subscription result information and authentication information update permission information. In one embodiment, the subscription result information may indicate “4 - DELAYED DOWNLOAD” or “6 - DELETE PROFILE IN USE.” DELAYED DOWNLOAD may be subscription result information indicating that the profile is not ready to be downloaded when a user (e.g., an external electronic device (700)) requests a subscription move (or profile move). In one embodiment, DELETE PROFILE IN USE may be subscription result information indicating that a profile in use should be deleted. Additionally, if the telecommunications carrier supports websheets and uses a delayed download method, the subscription result information included in the 200 OK message may indicate "1-CONTINUE TO WEBSEET." CONTINUE TO WEBSEET may be subscription result information indicating that the end-user must perform the subscription web view procedure. Since the subscription result information is described in Table 3, a detailed description thereof will be omitted here.

[0471] In one embodiment, the authentication information renewal permission information may be TokenRenewalAllowed, and TokenRenewalAllowed may be information indicating that renewal of authentication information (e.g., a token) is permitted. In one embodiment, TokenRenewalAllowed may be information indicating that renewal of authentication information is permitted in a set situation, such as a situation where download information for downloading a new profile is waiting due to the use of a delayed download method, and / or a situation where a profile in use (e.g., an existing profile) is deleted due to the use of a reusable profile (or a re-downloadable profile). A name such as TokenRenewalAllowed may be changed or modified to another name as needed.

[0472] An electronic device (101) that receives a 200 OK message from an entitlement server (520) can determine, based on TokenRenewalAllowed included in the 200 OK message, that renewal of authentication information is permitted in a set situation, for example, a situation where download information for downloading a new profile is waiting as a delayed download method is used, and / or a situation where a profile in use (for example, an existing profile) is deleted as a reusable profile (or a redownloadable profile) is used.

[0473] Meanwhile, for various reasons, the validity period of the authentication information (e.g., token) of the external electronic device (700) may expire in operation 1510. The reasons for the expiration of the validity period of the authentication information (e.g., token) may be similar to or substantially identical to those described in FIGS. 8A to 8C and / or FIGS. 10A to 10C , and thus, their redundant descriptions are omitted herein. In FIG. 15A , operation 1510 is expressed as "token expired."

[0474] When the validity period of the token has expired, the electronic device (101) may, in operation 1511, transmit a fourth request message to the entitlement server (520) to request renewal of temporary authentication information (e.g., temporary token). For example, the fourth request message may be an HTTP REQUEST message. In one embodiment, the fourth request message may include TokenRenewalAllowed, "AcquireTemporaryToken" as ODSA operation information, "AcquireConfiguration" as operation_targets, and the expired temporary token as a token. In one embodiment, the fourth request message may include the terminal_id (e.g., IMEIesim or UUIDapp) of the electronic device (101).

[0475] The entitlement server (520), which has received the fourth request message from the electronic device (101), can confirm that renewal of authentication information (e.g., token) is permitted based on TokenRenewalAllowed included in the fourth request message. In one embodiment, the entitlement server (520), based on TokenRenewalAllowed, can confirm that renewal of temporary authentication information for the electronic device (101) is possible even if the validity period of the temporary authentication information (e.g., temporary token) generated in the temporary authentication information acquisition operation of operation 1503 has expired.

[0476] The entitlement server (520) may generate new temporary authentication information (e.g., a new temporary token) in operation 1512. The entitlement server (520) that generated the new temporary authentication information may transmit a 200 OK message (e.g., an HTTP 200 OK message) including the new temporary authentication information as a response message to the fourth request message to the external electronic device (700) in operation 1512, and the external electronic device (700) may acquire the new temporary authentication information based on the 200 OK message received from the external electronic device (700). In one embodiment, the 200 OK message of operation 1512 may include information indicating a validity period for the temporary authentication information, an operation type having a value of "3-TRANSFER SUBSCRIPTION", and "AcquireConfiguration" as operation_targets. In the 200 OK message of Action 1512, Temporary Token Expiry, which is information indicating the validity period for temporary authentication information, can be set to New Temporary Token Expiry, which is the validity period for new temporary authentication information.

[0477] Meanwhile, although not separately illustrated in FIGS. 15A and 15B , in one embodiment, the entitlement server (520) may, based on TokenRenewalAllowed, check the validity time for temporary authentication information (e.g., temporary token) generated in the temporary authentication information acquisition operation of operation 1503, and check that renewal of the temporary authentication information for the electronic device (101) is possible before the validity time for the temporary authentication information expires. For example, if the validity time for the temporary token is given in operation 1503, the electronic device (101) may check the validity time for the temporary token and perform operation 1511 before the validity time for the temporary token expires (before operation 1510). For example, the electronic device (101) may transmit a fourth request message to the entitlement server (520) to request renewal of the temporary authentication information (e.g., temporary token) before the validity time for the temporary token expires. For example, the fourth request message may be an HTTP REQUEST message. In one embodiment, the fourth request message may include TokenRenewalAllowed, include "AcquireTemporaryToken" as ODSA operation information, include "AcquireConfiguration" as operation_targets, and include an expired temporary token as a token. In this case, the token in operation 1511 may be a temporary token whose validity period has not yet expired, and the entitlement server (520) that receives the fourth request message from the electronic device (101) may perform operation 1512 and subsequent operations based on TokenRenewalAllowed.Even if the entitlement server (520) receives AcquireTemporaryToken through the fourth request message before the expiration of the validity time for the temporary token, if the fourth request message does not include TokenRenewalAllowed, the entitlement server (520) can confirm that renewal of the authentication information (e.g., token) is not allowed, and even if the validity time for the temporary authentication information (e.g., temporary token) generated in the temporary authentication information acquisition operation of operation 1503 has not expired, the entitlement server (520) can confirm that renewal of the temporary authentication information for the electronic device (101) is not possible. Accordingly, the entitlement server (520) can reject a request to renew the authentication information by responding with an ERROR message to the fourth request message received from the electronic device (101).

[0478] The electronic device (101), which has received a 200 OK message as a response message to the fourth request message from the entitlement server (520), may, in operation 1513, transmit a fifth request message to the entitlement server (520) requesting that the entitlement server provide service-related data for the primary device (e.g., the external electronic device (700)) or the companion device. For example, the fifth request message may be an HTTP REQUEST message. In one embodiment, the fifth request message may include ODSA operation information set to "AcquireConfiguration," the terminal_id of the electronic device (101) (e.g., IMEIesim or UUIDapp), and new temporary authentication information. In this way, the electronic device (101) may access the entitlement server (520) using the new temporary authentication information.

[0479] The entitlement server (520) that receives the HTTP REQUEST message from the electronic device (101) may, in operation 1514, resume the profile transfer procedure based on the new temporary authentication information. The entitlement server (520) that resumed the profile transfer procedure may, in operation 1514, transmit a message querying the subscription (or profile) status to the BSS / OSS (550). For example, the message querying the subscription (or profile) status may be a Subscription Status Query message. In one embodiment, the Subscription Status Query message may include a SubscriptionID and IMEIesim, which is the terminal_id of the electronic device (101).

[0480] The BSS / OSS (550) that receives the Subscription Status Query message from the entitlement server (520) may, in response to the Subscription Status Query message at operation 1515, transmit a Subscription Status Answer message to the entitlement server (520) that includes information related to whether a profile download is ready by checking the subscription status. The Subscription Status Answer message may include information about a subscription status indicating that profile download information for downloading a profile is available and that the subscription (or profile) is ready.

[0481] The entitlement server (520), which has received the Subscription Status Answer message from the BSS / OSS (550), may transmit a 200 OK message (e.g., an HTTP 200 OK message) to the electronic device (101) in response to the fifth request message at operation 1516. The 200 OK message of operation 1516 may include a primary configuration (PrimaryConfiguration), and the primary configuration may be mandatory for the OPSA procedure. The primary configuration may include parameters that provide configuration settings for subscription and services, and may include an ICCID set to "ICCIDesim", a service status (ServiceStauts) set to "1 - ACTIVATED", DownloadInfo, which is download information for downloading a profile (e.g., a new profile) from the electronic device (101), and a profile activation code (ProfileActivationCode) set to an activation code (ActivationCode). In one embodiment, a service status of "1 - ACTIVATED" may indicate that the service of the eSIM device (e.g., electronic device (101)) is activated. In one embodiment, the activation code may be a code defined to allow downloading of a profile from the SM-DP+ server (530). The primary configuration may be implemented similar to or substantially identical to the primary configuration specified in the standard document TS. 43, and thus, a detailed description thereof is omitted herein.

[0482] The ODSA client of the electronic device (101), which has received a 200 OK message in response to the fifth request message from the entitlement server (520), may, in operation 1517, notify the eSIM to download a profile (e.g., an eSIM profile). In FIG. 15b, operation 1517 is expressed as "Download profile (ActCode)".

[0483] As the ODSA client of the electronic device (101) notifies the eSIM to download the profile, in operation 1518, the eSIM of the electronic device (101) may download the profile from the SM-DP+ server (530) based on the DownloadInfo included in the 200 OK message of operation 1516. In one embodiment, the eSIM of the electronic device (101) may download the profile from the SM-DP+ server (530) via the ES9+ channel. In FIG. 15B, operation 1518 is expressed as "Get the profile ES9+ Exchange."

[0484] As the profile is downloaded from the SM-DP+ server (530) to the eSIM, the ODSA client of the electronic device (101) may request service activation to the eSIM of the electronic device (101) at operation 1519. Service activation may indicate that the downloaded profile is installed and the service status is activated. In this way, as the service is activated, the electronic device (101) may initiate a service (e.g., cellular service). In FIG. 15B, operation 1519 is expressed as "Activate Service."

[0485] FIG. 16 is a diagram for explaining an operation of an electronic device managing multiple pieces of authentication information in a wireless communication network according to one embodiment.

[0486] Referring to FIG. 16, the wireless communication network may include an electronic device (101) (e.g., the electronic device (101) of FIG. 1A, FIG. 1B, FIG. 2, FIG. 3, and / or FIG. 5), an entitlement server (520) (e.g., the entitlement server (520) of FIG. 5), a push client (1600), and / or a push server (1610).

[0487] The electronic device (101) can access the entitlement server (520) for various procedures, such as a profile transfer procedure between electronic devices, a subscription procedure, and / or a subscription change procedure, perform an authentication procedure with the entitlement server (520), and if the authentication procedure is successful, obtain an authenticated token (AuthToken) from the entitlement server (520). The electronic device (101) can obtain multiple AuthTokens by performing multiple authentication procedures for the same telecommunications carrier, or obtain multiple AuthTokens by performing multiple authentication procedures for different carriers.

[0488] Accordingly, when a communication service provider transmits a push message to an electronic device (101), such as a profile download procedure based on a delayed download method, an operation ID (OperationID) for identifying an operation is shared in advance between the electronic device (101) and the entitlement server (520), and when the entitlement server (520) includes the shared OperationID in the push message, the electronic device (101) can check the corresponding AuthToken based on the OperationID included in the push message among a plurality of AuthTokens. In one embodiment, the OperationID may be similar to or substantially identical to the OdsaEventID, and thus, a redundant description thereof will be omitted. In addition, the operation between the electronic device (101) and the entitlement server (520) may be similar to or substantially identical to the ODSA operation, and thus, a redundant description thereof will be omitted.

[0489] In this way, the electronic device (101) that has verified the corresponding AuthToken based on the OperationID can perform a corresponding procedure with the entitlement server (520) based on the OperationID and AuthToken. This can be described in detail as follows.

[0490] The electronic device (101) may transmit an action request message to the entitlement server (520) in operation 1611. In one embodiment, the action request message may be a message requesting action 2, for example, a profile transfer action.

[0491] The entitlement server (520) that receives the operation request message from the electronic device (101) may generate an OperationID (e.g., OperationID B) for operation 2 in operation 1612. The entitlement server (520) that generated the OperationID for operation 2 may transmit a result message including the OperationID for operation 2 as a response message to the operation request message to the electronic device (101) in operation 1613. The entitlement server (520) that transmitted the result message to the electronic device (101) may transmit an event registration message requesting the push server (1610) to register operation 2 using the OperationID for operation 2 in operation 1614. For example, if operation 2 is a profile transfer operation, the push server (1610) may be an SM-DP+ server.

[0492] The push server (1610), which has received an event registration message from the entitlement server (520), can register OperationID B, which is an OperationID for operation 2, and then, in operation 1615, transmit a push notification message including the OperationID for operation 2 to the push client (1600). For example, if operation 2 is a profile transfer operation, the push client (1600) can be an SM-DS.

[0493] The push client (1600), which has received a push notification message including the OperationID for operation 2 from the entitlement server (520), can transmit the push notification message including the OperationID for operation 2 to the electronic device (101) in operation 1616.

[0494] An electronic device (101) that receives a push notification message including an OperationID for operation 2 from a push client (1600) can map and store an authentication token (e.g., AuthToken Y) for operation 2 and the OperationID for operation 2. In this way, after mapping and storing the authentication token (e.g., AuthToken Y) for operation 2 and the OperationID for operation 2, when the electronic device (101) accesses the entitlement server (520) for operation 2, the electronic device can access the entitlement server (520) using the authentication token (e.g., AuthToken Y) for operation 2 and the OperationID for operation 2, as in operation 1617.

[0495] FIG. 17a is a signal flow diagram illustrating an ODSA procedure in a wireless communication network according to one embodiment.

[0496] FIG. 17b is a signal flow diagram illustrating an ODSA procedure in a wireless communication network according to one embodiment.

[0497] Before describing FIGS. 17a and 17b, the ODSA procedure may include a profile transfer (or subscription transfer or line transfer) procedure between electronic devices.

[0498] As described in FIGS. 15A and 15B , in the profile migration procedure, a reusable profile (or a re-downloadable profile) may need to be deleted by the existing electronic device. However, the authentication information (e.g., a token) may expire before the existing electronic device deletes the profile (e.g., the existing profile) and receives download information (e.g., DownloadInfo) for downloading the profile (e.g., the new profile) from the new electronic device. In this way, when the authentication information expires, various errors may occur, such as authentication (e.g., EAP-AKA authentication) based on the existing profile being impossible because the existing profile has been deleted.

[0499] In this case, various errors may occur due to the expiration of the authentication information.

[0500] Additionally, during the profile migration process, if the profile download proceeds in a delayed download manner, the authentication information may expire while the new electronic device receives a push message indicating that the profile is ready, or while performing an operation based on the polling method. In this way, if the authentication information expires and the carrier deactivates the existing profile, various errors may occur, such as the inability to perform authentication based on the existing profile (e.g., EAP-AKA authentication).

[0501] Therefore, in one embodiment of the present disclosure, a method for updating a token without performing the authentication procedure from the beginning can be proposed, considering a situation where an error occurs during a profile migration procedure, such as when authentication based on an existing profile is impossible. In one embodiment, the method for updating a token without performing the authentication procedure from the beginning can have restrictions, such as limiting the operation_targets of the token (for example, limiting the operation_targets of the token to AcquireConfiguration) and / or allowing only one-time updates to the token. In one embodiment, the operation_targets can include the AcquireTemporaryToken operation, which can be used to acquire a temporary token associated with the ODSA operation(s) and the AppID.

[0502] In the ODSA procedure illustrated in FIGS. 17a and 17b, the entitlement server (520) may indicate that token renewal is permitted by sending a response message to the external electronic device (700) that includes AcquireTemporaryToken in OperationTargets in response to a request message that includes ODSA operation information set to AcquireTemporaryToken.

[0503] The AcquireTemporaryToken operation is described in Table 1, so a redundant description may be omitted here. In one embodiment, operation_targets may represent a list with all ODSA operations allowed to be requested using the TemporaryToken.

[0504] Referring to FIGS. 17A and 17B , the wireless communication network may include an electronic device (101) (e.g., the electronic device (101) of FIGS. 1A , 1B , 2 , 3 , and / or 5 ), an external electronic device (700) (e.g., the electronic device (102) of FIG. 1A and / or the electronic device (104) of FIG. 1A ), an entitlement server (520) (e.g., the entitlement server (520) of FIG. 5 ), an SM-DP+ server (530) (e.g., the SM-DP+ server (220) of FIG. 2 and / or the SM-DP+ server (530) of FIG. 5 ), an authentication server (540) (e.g., the authentication server (540) of FIG. 5 ), and / or a BSS / OSS (550) (e.g., the BSS / OSS (550) of FIG. 5 ). The external electronic device (700) may be an existing electronic device that stores a profile associated with the subscription (e.g., an existing profile), and the electronic device (101) may be a new electronic device from which to download a profile associated with the subscription (e.g., a new profile). The entitlement server (520) may also be referred to as an “ODSA device GW entitlement configuration server.”

[0505] According to one embodiment, an ODSA client application may be executed on each of the electronic device (101) and the external electronic device (700). The ODSA client application may be executed on the requesting device or the primary device and may allow an end-user to perform seamless activation of subscription and associated services on the eSIM of the companion device or the primary device without intervention of a customer or support representative of the service provider. The ODSA client application may be implemented similarly or substantially identically to the ODSA client application specified in the standard document TS. 43, and thus, a redundant description thereof may be omitted herein. According to one embodiment, each of the electronic device (101) and the external electronic device (700) may include an eSIM. In FIG. 17a and FIG. 17b, the operation of the electronic device (101) can be performed by the ODSA client application, and the operation of the external electronic device (700) can also be performed by the ODSA client application.

[0506] In operation 1701, an authentication process between the external electronic device (700), the entitlement server (520), and the authentication server (540) may be performed. The external electronic device (700) may transmit a request message to the entitlement server (520) requesting to trigger an authentication process, and accordingly, the external electronic device (700) and the entitlement server (520) may perform an authentication exchange process (e.g., an EAP-AKA authentication process). If the result of the authentication process indicates success, the entitlement server (520) may transmit authentication information (e.g., an authentication token (Auth Token)) to the external electronic device (700), and thus, the external electronic device (700) may obtain the authentication information. An example of the authentication exchange procedure of operation 1701 may be the EAP-AKA authentication process described in operation 1501 of FIG. 15a. In FIG. 17a, operation 1701 is expressed as "Authentication for Auth Token."

[0507] In operation 1702, an eligibility check operation may be performed by the external electronic device (700) that has acquired authentication information, the entitlement server (520), the authentication server (540), and the BSS / OSS (550). In FIG. 17A, operation 1702 is expressed as "Eligibility Check." The eligibility check operation of operation 1702 may include an eligibility check operation to determine whether the entitlement server (520) is eligible to provide an ODSA client application to the requesting device and the end user. In one embodiment, a result value indicating the result of the eligibility check operation may be determined based on various parameters such as the end user's subscription / subscription plan type and device details. According to one embodiment, the first request message may be a request message requesting an eligibility check, for example, an HTTP REQUEST message. The external electronic device (700) may transmit a standard document TS. According to the ODSA procedure specified in 43, an eligibility check can be requested by sending a first request message (e.g., an HTTP REQUEST message) including “CheckEligibility” as ODSA operation information to the entitlement server (520).

[0508] The entitlement server (520), which receives a first request message including CheckEligibility as ODSA operation information from an external electronic device (700), may perform an eligibility check on the ODSA client application in the external electronic device (700) based on the first request message including CheckEligibility as ODSA operation information. If the result of the eligibility check indicates success, the entitlement server (520) may transmit a 200 OK message (e.g., an HTTP 200 OK message) as a response message to the first request message to the external electronic device (700). In FIG. 17A, it is assumed that the result of the eligibility check for the electronic device (101) indicates success, and if the result of the eligibility check for the electronic device (101) indicates failure, no further operations may be performed. In one embodiment, if the result of the eligibility check indicates success, the 200 OK message may include information of "ENABLED."

[0509] In operation 1703 to operation 1704, an operation of obtaining temporary authentication information (e.g., temporary token) may be performed by the external electronic device (700) and the entitlement server (520), which may be specifically described as follows.

[0510] The external electronic device (700) that receives the 200 OK message including the information of "ENABLED" may, in operation 1703, request temporary authentication information usable by the electronic device (101) by sending a second request message (e.g., an HTTP REQUEST message) to the entitlement server (520) that includes "AcquireTemporaryToken" as ODSA operation information and includes operation_targets for indicating which requests can be used by a trusted third party (e.g., the electronic device (101)) with the issued temporary authentication information. According to one embodiment, "AcquireTemporaryToken" may or may not be explicitly included in operation_targets as a usage indicator in a request for temporary authentication information renewal. In one embodiment, the second request message may include authentication information (e.g., an Auth Token). In one embodiment, the second request message may include terminal_id, which is a terminal ID of the external electronic device (700). For example, the terminal_id of the external electronic device (700) may be IMEIesim or UUIDapp. In FIG. 17A, operation 1703 is "GET / POST [ap200XX, operation = AcquireTemporaryToken, terminal_id = <imeisim> or <uuidapp>, operation_targets =<AcquireTemporaryToken & Operation 1 & Operation 2 & .. > , token =<Auth Token> ] is expressed as follows.

[0511] The entitlement server (520), which receives a second request message including AcquireTemporaryToken as ODSA operation information from the external electronic device (700), may generate a temporary token based on the second request message including AcquireTemporaryToken as ODSA operation information in operation 1704. The entitlement server (520) may generate temporary authentication information if the authentication information (e.g., Auth Token) included in the second request message is valid and allows the temporary authentication information issued to the external electronic device (700) to be used as a token when the electronic device (101) requests specific ODSA operations(e.g., ManageSubscription, AcquireConfiguration). The entitlement server (520) may provide specific ODSA operations(es) that allow the electronic device (101) to use the temporary authentication information issued for the external electronic device (700) as a token to the OperationTargets via a 200 OK message (e.g., an HTTP 200 OK message) as a response message to the second request message. The entitlement server (520) may include AcquireTemporaryToken in the 200 OK message as a response message to the second request message when allowing the temporary token renewal using the temporary authentication information issued by the entitlement server (520). In one embodiment, the 200 OK message as a response message to the second request message may include the generated temporary authentication information (e.g., TemporaryToken) and the validity period for the generated temporary authentication information (e.g., the expiration period for the temporary authentication information) (e.g., TemporaryTokenExpiry).In Figure 17a, operation 1704 is "200 OK [TemporaryToken = TemporaryToken, TemporaryTokenExpiry = TemporaryTokenExpiry, OperationTargets =<AcquireTemporaryToken & Operation 1 & Operation 2 & .. > ] is expressed as follows. Alternatively, if the entitlement server (520) that received the second request message including AcquireTemporaryToken as ODSA operation information from the external electronic device (700) does not permit issuing a temporary token, no further operations may be performed.

[0512] The entitlement server (520) that generated the temporary authentication information can transmit a 200 OK message (e.g., an HTTP 200 OK message) including the temporary authentication information as a response message to the second request message to the external electronic device (700) in operation 1704. Accordingly, the external electronic device (700) that receives the 200 OK message as a response message to the second request message from the entitlement server (520) can obtain the temporary authentication information based on the received 200 OK message. In addition, the entitlement server (520) can include OperationTargets in the 200 OK message in operation 1704 and can include AcquireTemporaryToken in the OperationTargets to indicate that the corresponding operation (e.g., AcquireTemporaryToken) is permitted.

[0513] Meanwhile, even if the second request message received from the external electronic device (700) in operation 1703 does not include AcquiredTemporaryToken in operation_targets, the entitlement server (520) may include operation_targets including AcquiredTemporaryToken in the 200 OK message, which is a response message to the second request message, when allowing token renewal. This case may be provided, for example, to support a case where the versions of the external electronic device (700) and the electronic device (101) do not match. In other words, since the version of the ODSA client application of the external electronic device (700) does not support the token renewal function, the 200 OK message, which is a response message to the second request message, may not include AcquiredTemporaryToken in operation_targets, but this is because the version of the ODSA client application of the electronic device (101) can support the token renewal function.

[0514] In operation 1705, an operation of exchanging eSIM transfer information may be performed between the external electronic device (700) and the electronic device (101). In the operation of exchanging eSIM transfer information, the external electronic device (700) may transmit a message including all relevant eSIM transfer information to the electronic device (101), and the eSIM transfer information may include temporary authentication information. In FIG. 17A, operation 1705 is expressed as "Information Including TemporaryToken."

[0515] An electronic device (101) that receives a message including eSIM transfer information including temporary authentication information may perform operation 1706 at a specific point in time. In FIGS. 17A and 17B , an example is described in which operation 1706 is performed first, and then operations 1707 and 1708 are performed. However, operations 1707 and 1708 may be performed before operation 1706. However, in FIGS. 17A and 17B , it is assumed that operations 1707 and 1708 are performed between operations 1706 and 1709.

[0516] The electronic device (101), which has received a message including eSIM transfer information including temporary authentication information from an external electronic device (700), may transmit a third request message (e.g., an HTTP REQUEST message) including the temporary authentication information and including specific ODSA operation information to the entitlement server (520) in operation 1706. The entitlement server (520), which has received the third request message from the electronic device (101), may perform an operation corresponding to the specific ODSA operation information based on the third request message in operation 1706, and transmit a message including the result to the electronic device (101). The specific ODSA operation information included in the third request message in operation 1706 may be one of the ODSA operation information included in OperationTargets in the 200 OK message of operation 1704. An example of specific ODSA operation information included in the third request message may be "ManageSubscription", and as described in FIGS. 15A and 15B, "ManageSubscription" may be ODSA operation information used to request a subscription-related operation. According to one embodiment, the third request message may further include operation type information, and since the operation type information is described in Table 2, a redundant description thereof will be omitted here. The third request message may include temporary authentication information (e.g., a temporary token) received via the 200 OK message in operation 1704. If the ODSA operation information included in the received third request message is not an operation included in the OperationTargets included in the 200 OK message transmitted in operation 1704, the entitlement server (520) may transmit an error message indicating an error for the third request message to the electronic device (101) and terminate the operation without performing any further operations.The entitlement server (520) may perform a corresponding action based on the received third request message and return the processing result. For example, as described in FIGS. 15A and 15B , the subscription result information may indicate "4 - DELAYED DOWNLOAD" or "6 - DELETE PROFILE IN USE." In FIG. 17A , operation 1706 is expressed as "Operation(s) using the Temporary Token as an auth token."

[0517] The electronic device (101) may, at operation 1707, transmit a fourth request message to the entitlement server (520) to request an update of temporary authentication information (e.g., a temporary token). The electronic device (101) may check the validity period of the temporary authentication information. If the electronic device (101) verifies the temporary authentication information (e.g., a temporary token) received at operation 1705 and determines that the validity period assigned to the temporary authentication information is insufficient for the electronic device (101) to complete the required ODSA operations, the electronic device (101) may, at operation 1707, transmit a fourth request message (e.g., an HTTP REQUEST message) for token update. In one embodiment, the fourth request message may include "AcquireTemporaryToken" as ODSA operation information, "AcquireConfiguration" as operation_target, and a valid temporary token as a token. In one embodiment, the fourth request message may include the terminal_id (e.g., IMEIesim or UUIDapp) of the electronic device (101). In FIG. 17b, operation 1707 is GET / POST [ap200XX, operation = AcquireTemporaryToken, terminal_id = <imeisim> or <uuidapp>, operation_targets =<Operation 1 & Operation 2 & .. > , temporary_token =<Temporary Token> ] is expressed as follows.

[0518] The entitlement server (520) that receives the fourth request message from the electronic device (101) can confirm that the update of authentication information (e.g., token) is permitted based on the “AcquireTemporaryToken” and the Temporary Token, which is temporary authentication information, included in the fourth request message.

[0519] In one embodiment, the entitlement server (520) may verify that the fourth request message received from the electronic device (101) includes temporary authentication information identical to the temporary authentication information provided in operation 1704, that the validity period of the temporary authentication information included in the fourth request message has not yet expired, and that the entitlement server (520) has transmitted a 200 OK message including “AcqurieTemporaryToken” as OperationTargets in operation 1704, and thus, the update of the authentication information (e.g., token) is permitted. Conversely, if the entitlement server (520) does not permit the update of the authentication information (e.g., token), the entitlement server (520) may transmit an error message for the fourth request message to the electronic device (101) and terminate the operation without performing any further operations.

[0520] Action 1708 may correspond to the action taken when token renewal is permitted. The entitlement server (520) may generate new temporary authentication information. For example, the entitlement server (520) may generate new temporary authentication information by generating a new temporary token or by changing (or extending) the validity period of an existing issued temporary token.

[0521] The entitlement server (520) that has generated new temporary authentication information may transmit the new temporary authentication information to the electronic device (101) in operation 1708. In one embodiment, the entitlement server (520) that has generated new temporary authentication information may transmit a 200 OK message (e.g., an HTTP 200 OK message) including the new temporary authentication information as a response message to the fourth request message to the external electronic device (700) in operation 1708, and the external electronic device (700) may obtain the new temporary authentication information based on the 200 OK message received from the external electronic device (700). In one embodiment, the 200 OK message of operation 1708 may include at least one of a temporary authentication token, information on a validity period for the temporary authentication information, an operation type, and operation_targets. In the 200 OK message of operation 1708, Temporary Token Expiry, which is information indicating the validity period of temporary authentication information, can be set to New Temporary Token Expiry, which is the validity period of new temporary authentication information. In FIG. 17b, operation 1708 is expressed as "200 OK [TemporaryToken = NewTemporaryToken, TemporaryTokenExpiry = NewTemporaryTokenExpiry, OperationTargets = <Operation 1 & Operation 2 & .. >]".

[0522] The electronic device (101) that receives a 200 OK message as a response message to the fourth request message from the entitlement server (520) may perform the remaining ODSA operation(s) with the entitlement server (520) using the new temporary authentication information at operation 1709. For example, the electronic device (101) may transmit a fifth request message (e.g., an HTTP REQUEST message) to the entitlement server (520) using the new temporary authentication information. The entitlement server (520) that receives the fifth request message from the electronic device (101) may then proceed with the ODSA operation procedure corresponding to the fifth request message based on the new temporary authentication information at operation 1709. In other words, the electronic device (101) and the entitlement server (520) may perform the remaining ODSA operation procedures based on the new temporary authentication information. In FIG. 17b, operation 1709 is expressed as "Continue the rest of the Operation(s) using the New Temporary Token as an auth token."

[0523] According to one embodiment of the present disclosure, a method of an electronic device (101) may be provided, the method including an operation of receiving authentication information from an external electronic device (102; 104; 700) related to a procedure for transferring a profile from the external electronic device to the electronic device.

[0524] According to one embodiment of the present disclosure, the method may include, in response to receiving the authentication information, an operation of identifying a first identifier identifying the procedure.

[0525] According to one embodiment of the present disclosure, the method may include an operation of transmitting a request message requesting movement of the profile, including the first identifier, to the first server (520).

[0526] According to one embodiment of the present disclosure, the method may include, in response to transmitting the request message, receiving a response message including information for downloading the profile from a third server (220; 530), from the first server or a second server (210; 560) different from the first server.

[0527] According to one embodiment of the present disclosure, the method may include an operation of identifying a second identifier identifying the procedure based on the response message.

[0528] According to one embodiment of the present disclosure, the method may include an operation of determining whether the second identifier is identical to the first identifier.

[0529] According to one embodiment of the present disclosure, the method may include an operation of determining whether another response message including the second identifier has been received prior to receiving the response message, based on whether the second identifier is identical to the first identifier.

[0530] According to one embodiment of the present disclosure, the method includes an operation of determining whether to download the profile from the third server based on whether the other response message has been received.

[0531] According to one embodiment of the present disclosure, the operation of determining whether to download the profile from the third server based on whether the other response message has been received includes the operation of downloading the profile from the third server based on information for downloading the profile, based on whether the other response message has not been received.

[0532] According to one embodiment of the present disclosure, the operation of determining whether to download the profile from the third server based on whether the other response message has been received may include an operation of refraining from downloading the profile from the third server based on whether the other response message has been received.

[0533] According to one embodiment of the present disclosure, the method may include an action of discarding the response message based on the receipt of the other response message.

[0534] According to one embodiment of the present disclosure, the operation of verifying the second identifier may include an operation of verifying the second identifier from a third identifier included in the response message based on the response message being received from the second server.

[0535] According to one embodiment of the present disclosure, the third identifier is used to identify an event between the second server and the third server and may be associated with the procedure.

[0536] According to one embodiment of the present disclosure, the third identifier may be generated based on the second identifier and a setting rule.

[0537] According to one embodiment of the present disclosure, the third identifier may be generated based on the fourth identifier.

[0538] According to one embodiment of the present disclosure, the fourth identifier is used to identify an event between the first server and the third server and may be associated with the procedure.

[0539] According to one embodiment of the present disclosure, the fourth identifier can be identified from the first identifier.

[0540] According to one embodiment of the present disclosure, the fourth identifier may be generated based on the first identifier and other setup rules.

[0541] According to one embodiment of the present disclosure, the other setting rule may include one of a rule for generating the first identifier as the fourth identifier, a rule for generating the fourth identifier by concatenating a value generated by the first server or the third server, a setting delimiter, and the first identifier, or a rule for generating the fourth identifier by concatenating a prefix for detecting the first identifier, the first identifier, and the value.

[0542] According to one embodiment of the present disclosure, the response message received from the first server may include the second identifier.

[0543] According to one embodiment of the present disclosure, the operation of verifying the first identifier may include an operation of receiving the first identifier from the second server in response to receiving the authentication information.

[0544] According to one embodiment of the present disclosure, the operation of verifying the first identifier may include an operation of generating the first identifier in response to receiving the authentication information.

[0545] According to one embodiment of the present disclosure, a storage medium storing at least one computer-readable instruction may be provided.

[0546] According to one embodiment of the present disclosure, the at least one instruction, when executed individually or collectively by one or more processors (120) including processing circuitry of the electronic device (101), may cause the electronic device to perform at least one operation.

[0547] According to one embodiment of the present disclosure, the at least one operation may include receiving authentication information from an external electronic device (102; 104; 700) that is related to a procedure for transferring a profile from the external electronic device to the electronic device.

[0548] According to one embodiment of the present disclosure, the at least one operation may include, in response to receiving the authentication information, an operation of identifying a first identifier identifying the procedure.

[0549] According to one embodiment of the present disclosure, the at least one operation may include transmitting a request message requesting movement of the profile, including the first identifier, to the first server (520).

[0550] According to one embodiment of the present disclosure, the at least one operation may include, in response to transmitting the request message, receiving a response message including information for downloading the profile from a third server (220; 530), from the first server or a second server (210; 560) different from the first server.

[0551] According to one embodiment of the present disclosure, the at least one operation may include an ope...

Claims

In the method of electronic device (101), An operation of receiving authentication information from an external electronic device (102; 104; 700) in connection with a procedure for transferring a profile from the external electronic device to the electronic device; In response to receiving the above authentication information, an action is taken to verify a first identifier identifying the procedure; An action of transmitting a request message requesting movement of the profile, including the first identifier, to the first server (520); In response to the transmission of the request message, an action of receiving a response message including information for downloading the profile from a third server (220; 530) or from a second server (210; 560) different from the first server; An action of identifying a second identifier identifying the procedure based on the response message; An operation of checking whether the second identifier is identical to the first identifier; An operation of checking whether another response message including the second identifier has been received before receiving the response message, based on the second identifier being identical to the first identifier; and An operation of determining whether to download the profile from the third server (220; 530) based on whether the other response message has been received, The operation of determining whether to download the profile from the third server (220; 530) based on whether the other response message has been received is: The method comprising the action of downloading the profile from the third server (220; 530) based on the information for downloading the profile, based on the fact that the other response message has not been received. In the first paragraph, The operation of determining whether to download the profile from the third server (220; 530) based on whether the other response message has been received is: The method comprising an action of refraining from downloading the profile from the third server (220; 530) based on the receipt of the other response message. In the first paragraph, A method comprising the action of discarding the response message based on the receipt of another response message. In any one of the first to third paragraphs, The action of verifying the above second identifier is: Based on the above response message being received from the second server, an operation of confirming the second identifier from the third identifier included in the response message is included. The third identifier is used to identify an event between the second server and the third server (220; 530), and is related to the procedure, and The method wherein the third identifier is generated based on the second identifier and the setting rules. In paragraph 4, The third identifier is generated based on the fourth identifier, The fourth identifier is used to identify an event between the first server and the third server (220; 530) and is related to the procedure. The fourth identifier is identified from the first identifier, and The method wherein the fourth identifier is generated based on the first identifier and other setting rules. In paragraph 5, The other setup rules are: A rule for generating the first identifier as the fourth identifier, A rule for generating the fourth identifier by concatenating a value generated by the first server or the third server (220; 530), a setting delimiter, and the first identifier, or The method comprising one of a prefix for detecting the first identifier, the first identifier, and a rule for generating the fourth identifier by concatenating the value. In any one of claims 1 to 6, The method wherein the response message received from the first server includes the second identifier. In any one of the first to seventh paragraphs, The action of verifying the above first identifier is: A method comprising, in response to receiving the authentication information, an operation of receiving the first identifier from the second server. In any one of the first to seventh paragraphs, The action of verifying the above first identifier is: A method comprising, in response to receiving the authentication information, an operation of generating the first identifier. In any one of claims 1 to 9, A method further comprising, before downloading the profile, an action of identifying a user input to initiate downloading the profile. In an electronic device (101), Communication circuit (190); One or more processors (120) including processing circuitry; and A memory (130) for storing instructions, wherein when the instructions are individually or collectively executed by one or more processors, the electronic device: Receive authentication information related to a procedure for transferring a profile from an external electronic device (102; 104; 700) to the electronic device through the communication circuit, In response to receiving the above authentication information, verify the first identifier identifying the above procedure, Transmitting a request message requesting movement of the profile, including the first identifier, to the first server (520) through the communication circuit; In response to the transmission of the request message, a response message including information for downloading the profile from the third server (220; 530) is received from the first server or a second server (210; 560) different from the first server through the communication circuit, Identifying a second identifier that identifies the procedure based on the response message; Check whether the second identifier is identical to the first identifier, Based on the second identifier being identical to the first identifier, it is determined whether another response message including the second identifier has been received before receiving the response message, and Based on whether the above other response message has been received, it causes the third server (220; 530) to check whether to download the profile, The above instructions, when individually or collectively executed by the one or more processors, cause the electronic device to determine whether to download the profile from the third server (220; 530) based on whether the other response message has been received, at least as part of: The electronic device, based on the fact that the other response message has not been received, causes the profile to be downloaded from the third server (220; 530) through the communication circuit based on the information for downloading the profile. In Article 11, When the above instructions are individually or collectively executed by the one or more processors, the electronic device: An electronic device that causes a method according to any one of claims 2 to 10 to be performed. In a storage medium storing at least one instruction readable by a computer, The at least one instruction, when executed individually or collectively by one or more processors (120) comprising processing circuitry of the electronic device (101), causes the electronic device to perform at least one operation; At least one of the above actions: An operation of receiving authentication information from an external electronic device (102; 104; 700) in connection with a procedure for transferring a profile from the external electronic device to the electronic device; In response to receiving the above authentication information, an action is taken to verify a first identifier identifying the procedure; An action of transmitting a request message requesting movement of the profile, including the first identifier, to the first server (520); In response to the transmission of the request message, an action of receiving a response message including information for downloading the profile from a third server (220; 530) or from a second server (210; 560) different from the first server; An action of identifying a second identifier identifying the procedure based on the response message; An operation of checking whether the second identifier is identical to the first identifier; An operation of checking whether another response message including the second identifier has been received before receiving the response message, based on the second identifier being identical to the first identifier; and An operation of determining whether to download the profile from the third server (220; 530) based on whether the other response message has been received, The operation of determining whether to download the profile from the third server (220; 530) based on whether the other response message has been received is: The storage medium including an operation of downloading the profile from the third server (220; 530) based on information for downloading the profile, based on the fact that the other response message has not been received. In Article 13, When the above instructions are individually or collectively executed by one or more processors (120) including a processing circuit of the electronic device (101), the electronic device: A storage medium that causes a method according to any one of claims 2 to 10 to be performed.

Images