An eSIM card management method, device, equipment and computer storage medium

Abstract

Embodiments of the present application provide a kind of eSIM card management method, device, equipment and computer storage medium.The present application belongs to the technical field of Internet.The method comprises: through the system level plug-in, the instruction information of the eSIM card is issued in the preset channel and is listened to;Identify whether the instruction information is preset subscription instruction;If yes, then intercept the instruction information;For the instruction information, build execution management container, and receive instruction information based on the execution management container;Based on the instruction information received by the execution management container, the configuration file in the eSIM card is operated to obtain the execution result of instruction information.This technical solution can transmit data based on demand, and based on independent container execution, the fault protection mechanism can be set as needed, to improve the stability and security of eSIM card number management, and the purpose of flexible management.

Description

Technical Field

[0001] This application belongs to the field of Internet technology, and in particular relates to a method, apparatus, device and computer storage medium for managing an eSIM card. Background Technology

[0002] With the rapid development of the Internet of Things (IoT), eSIM cards are widely used in various devices such as smart terminals and industrial sensors due to their advantages such as no need for physical insertion and removal and remote configuration. The core of eSIM card number management relies on operations such as downloading, switching, and deleting subscription profiles. In existing technologies, these operations are mainly implemented through the Local Profile Assistant (LPA) based on the ES9+ / ES10X protocol.

[0003] However, in Bearer Independent Protocol (BIP) communication scenarios, traditional eSIM card management has several shortcomings. For example, BIP channels can only establish communication links with specific activated numbers and cannot directly manipulate inactive or unallocated number spaces, thus limiting number management. Furthermore, BIP channels can only perform basic instruction transmission, resulting in large transmitted profile files, leading to high channel load and the possibility of incomplete profile file reception. These issues severely impact the stability and security of eSIM card number management and operation, hindering the deployment progress and scenario adaptation of IoT terminals. Summary of the Invention

[0004] This application provides a method, apparatus, device, and computer storage medium for managing eSIM cards, aiming to solve many technical problems existing in eSIM card management under BIP communication scenarios in the prior art. This technical solution configures system-level plug-ins in the eSIM card chip operating system to build an independent execution management container to execute instruction types. Data can be transmitted based on demand, and fault protection mechanisms can be set as needed based on independent container execution, thereby improving the stability and security of eSIM card number management, as well as the flexibility of management.

[0005] In a first aspect, embodiments of this application provide a method for managing an eSIM card, the method comprising:

[0006] The method is executed by an eSIM card, the eSIM card's chip operating system being configured with a system-level plugin, and the method includes:

[0007] The system-level plugin monitors the instruction information sent to the eSIM card through a preset channel;

[0008] Identify whether the instruction information is a preset subscription instruction; if so, intercept the instruction information.

[0009] An execution management container is constructed for the instruction information, and the instruction information is received based on the execution management container;

[0010] Based on the instruction information received by the execution management container, the configuration file in the eSIM card is operated to obtain the execution result of the instruction information.

[0011] In one executable embodiment, the eSIM card is pre-configured with a blank profile;

[0012] Based on the instruction information received by the execution management container, operations are performed on the configuration file in the eSIM card, including:

[0013] Identify the instruction type of the instruction information received by the execution management container;

[0014] If the instruction type is an update instruction, then the instruction information is written to the blank configuration file.

[0015] In one executable embodiment, after identifying the instruction type of the instruction information received by the execution management container, the method further includes:

[0016] If the instruction type is a download instruction, then the configuration file contained in the instruction information is stored in the eSIM card;

[0017] If the instruction type is a deletion instruction, then the configuration file of the inactive number in the eSIM card is deleted;

[0018] If the instruction type is a switching instruction, then the configuration file of the inactive number in the eSIM card is activated, and the configuration file of the originally activated number in the eSIM card is deactivated.

[0019] In one executable embodiment,

[0020] If the instruction type is an update instruction, the instruction information includes the integrated circuit card identification code field, the operator root key field, the network authentication key field, the International Mobile Subscriber Identity field, and the operation type identifier field of the target configuration file;

[0021] If the instruction type is a switching instruction, then the instruction information includes the integrated circuit card identification code field of the target configuration file;

[0022] If the instruction type is a deletion instruction, the instruction information includes the integrated circuit card identification code field of the target configuration file and the active integrated circuit card identification code field;

[0023] If the instruction type is a download instruction, then the instruction information includes all fields of the target configuration file.

[0024] In one executable embodiment, the system-level plugin has a built-in cache area;

[0025] Before constructing the execution management container for the instruction information, the method further includes:

[0026] The instruction information is stored in a storage unit independently allocated to the instruction information within the cache area.

[0027] In one executable embodiment, after storing the instruction information into a storage unit independently allocated for the instruction information within the cache, the method further includes:

[0028] Identify whether the resource usage status of the eSIM card meets the construction conditions for the execution management container;

[0029] If the conditions are met, an execution management container is constructed for the instruction information in the storage unit.

[0030] In one executable embodiment, identifying whether the instruction information is a preset subscription instruction includes:

[0031] Identify whether the instruction header is a preset instruction header;

[0032] If so, then identify whether the parameters of the instruction information match the preset parameter information;

[0033] If a match is found, the instruction information is determined to be a preset subscription instruction.

[0034] In one executable embodiment, identifying whether the parameters of the instruction information match preset parameter information includes:

[0035] The system identifies whether the ICCID format in the parameters of the instruction information is a preset format. If it is a preset format, it is determined to match the preset parameter information.

[0036] And / or,

[0037] The system identifies whether the operation type identifier in the parameters of the instruction information is a preset operation type. If it is a preset operation type, it is determined that it matches the preset parameter information.

[0038] In one executable embodiment, the method further includes:

[0039] Monitor the execution result of the execution management container on the instruction information;

[0040] If the execution result is an execution error, and the number of consecutive execution errors reaches a preset number, then the state of the system-level plugin will be switched to the circuit breaker state.

[0041] In one executable embodiment, after switching the state of the system-level plugin to a circuit breaker state, the method further includes:

[0042] After the circuit breaker duration is reached, receive the test command issued by the eSIM card management platform;

[0043] If the test command is executed successfully, the status of the system-level plugin is switched to normal.

[0044] If the execution result of the test instruction is failure, then the circuit breaker will enter the next state.

[0045] In one executable embodiment, the system-level plugin listens for instruction information issued to the eSIM card, including:

[0046] The system-level plugin listens for instruction information sent by the eSIM card management platform through the BIP channel.

[0047] Secondly, embodiments of this application provide a method for managing an eSIM card, the method comprising:

[0048] The method is executed by the eSIM card management platform, and the method includes:

[0049] If there is an instruction to be issued, then identify whether the instruction to be issued is a preset subscription instruction;

[0050] If so, then determine the key field information to be sent based on the key fields associated with the preset subscription instruction;

[0051] The instruction information of the instruction to be issued is constructed based on the instruction type of the preset subscription instruction and the key field information;

[0052] The instruction information is sent to the eSIM card through a preset channel.

[0053] In one executable embodiment, the method further includes:

[0054] Receive the fuse status information reported by the eSIM card;

[0055] When the circuit breaker duration is reached, a test command is sent to the eSIM card.

[0056] Thirdly, embodiments of this application provide an eSIM card management device, the device being configured on the eSIM card, the eSIM card's chip operating system being configured with a system-level plug-in, the device comprising:

[0057] The instruction information monitoring module is used to monitor the instruction information sent to the eSIM card in the preset channel through the system-level plug-in;

[0058] The instruction information interception module is used to identify whether the instruction information is a preset subscription instruction; if so, the instruction information is intercepted.

[0059] A container building module is used to build an execution management container for the instruction information and receive instruction information based on the execution management container;

[0060] The execution module is used to operate on the configuration file in the eSIM card based on the instruction information received by the execution management container, so as to obtain the execution result of the instruction information.

[0061] Fourthly, embodiments of this application provide an eSIM card management device, the device being configured on an eSIM card management platform, the device comprising:

[0062] The pending instruction identification module is used to identify whether the pending instruction is a preset subscription instruction if there is a pending instruction.

[0063] The key field information determination module is used to determine the key field information to be sent based on the key fields associated with the preset subscription instruction if it is a preset subscription instruction.

[0064] The instruction information construction module is used to construct the instruction information of the instruction to be issued based on the instruction type of the preset subscription instruction and the key field information;

[0065] The instruction information sending module is used to send the instruction information to the eSIM card through a preset channel.

[0066] Fifthly, embodiments of this application provide an eSIM card management device, the device comprising: a processor, and a memory storing computer program instructions; the processor reads and executes the computer program instructions to implement the eSIM card management method as described above.

[0067] In a sixth aspect, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the eSIM card management method described above.

[0068] In a seventh aspect, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the eSIM card management method described above.

[0069] The eSIM card management method, apparatus, device, and computer storage medium of this application embodiment, by configuring a system-level plug-in in the eSIM card chip operating system, can realize the interception of preset subscription instructions through plug-in listening, support the full lifecycle management across configuration files, and realize operations such as number update, download, switching, and deletion. Furthermore, by constructing an independent execution management container, it can realize the isolated storage and execution of instructions, improve management stability, and this solution can get rid of the dependence on local configuration file assistant, enabling terminals without hardware interfaces to complete configuration file operations, thereby improving the compatibility of IoT terminals. Attached Figure Description

[0070] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0071] Figure 1 This is a flowchart illustrating an eSIM card management method provided in an embodiment of this application;

[0072] Figure 2 This is a flowchart illustrating an eSIM card management method provided in an embodiment of this application;

[0073] Figure 3 This is a schematic diagram of the comprehensive process of eSIM card management provided in the embodiments of this application;

[0074] Figure 4 This is a comparative diagram of the eSIM card management methods provided in the embodiments of this application;

[0075] Figure 5 This is a schematic diagram illustrating the implementation logic of the Deep COS plugin provided in the embodiments of this application;

[0076] Figure 6 This is a schematic diagram of the structure of an eSIM card management device provided in an embodiment of this application;

[0077] Figure 7 This is a schematic diagram of the structure of an eSIM card management device provided in an embodiment of this application;

[0078] Figure 8 This is a schematic diagram of the structure of an eSIM card management device provided in an embodiment of this application. Detailed Implementation

[0079] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0080] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0081] To address the problems of existing technologies, embodiments of this application provide a method, apparatus, device, and computer storage medium for managing eSIM cards. The technical solution provided in this application, through the collaboration of system-level plug-ins and execution management containers, overcomes the limitations of single-number binding in BIP channels, achieving isolated execution throughout the entire lifecycle of configuration file updates, downloads, switching, and deletions. This avoids concurrent conflicts of multiple instructions, eliminates dependence on LPA, adapts to IoT terminals without hardware interfaces, improves compatibility, pre-configures blank configuration files and optimizes operation logic, enabling rapid execution of number operations. Circuit breaker protection and parameter verification mechanisms reduce the risk of execution errors and hardware damage, improve instruction transmission efficiency, and enhance the stability of eSIM card operation.

[0082] The following section first introduces the eSIM card management method provided in the embodiments of this application.

[0083] Figure 1This is a flowchart illustrating a management method for an eSIM card provided in an embodiment of this application. The method is executed by the eSIM card, whose chip operating system (COS) is configured with a system-level plugin. This system-level plugin, namely the deep COS plugin, is a core management module independent of traditional COS logic, integrating an instruction analysis set, a global control mechanism, and a circuit breaker protection mechanism, enabling full-process management of the instruction types in the eSIM card configuration file. Figure 1 As shown, the method may include the following steps:

[0084] S101, the system-level plug-in listens for instruction information sent to the eSIM card in the preset channel;

[0085] System-level plugins can be dedicated management modules deployed at the eSIM card COS layer, with real-time data monitoring, command recognition and interception capabilities. Their core functional modules correspond to the "command analysis set" of the deep COS plugin, and can continuously capture command data in preset channels to ensure that no key management commands are missed.

[0086] The preset channel can be a Bearer Independent Protocol (BIP) channel. This channel is the standard channel for remotely transmitting eSIM card management commands in IoT scenarios, enabling stable data transmission independent of the card carrier, unlike traditional communication methods that rely on hardware interfaces.

[0087] The instruction information can be issued by the eSIM card management platform, i.e., the multi-application IoT SIM card trusted service management platform. It can include instruction headers, operation parameters and verification information, such as 80CA instructions for updating configuration files, 80CB instructions for switching numbers, etc. Each type of instruction corresponds to a specific configuration file operation purpose.

[0088] In this solution, the system-level plugin can start a continuous monitoring process to scan all data transmitted in the BIP channel in real time. By parsing the data frame structure, it can identify the instruction information that is the target of the current eSIM card. During the monitoring process, invalid data frames will be filtered out to improve the efficiency of instruction capture.

[0089] S102, identify whether the instruction information is a preset subscription instruction; if so, intercept the instruction information;

[0090] Preset subscription commands can be a set of commands predefined in a system-level plugin for managing eSIM card subscription profiles. For example, they can include four categories: 80CA (profile update command), 80CB (profile switch command), 80CC (profile delete command), and 80CD (profile download command). Each category of commands has a unique command header identifier.

[0091] This solution can identify whether the instruction information is a preset subscription information by identifying the instruction header matching and / or parameter verification. For example, firstly, the instruction header of the instruction information is extracted to determine whether it belongs to the instruction header set of preset subscription instructions. Alternatively, the compliance of the instruction parameters can be verified, such as whether the Integrated Circuit Card Identifier (ICCID) in the configuration file conforms to the 20-digit number format and whether the operation type identifier is within the preset value range. Or, both instruction header verification and instruction parameter compliance verification can be performed simultaneously to determine whether it is a preset subscription instruction based on these dual conditions.

[0092] In this solution, when the instruction information is determined to be a preset subscription instruction, the system-level plugin immediately triggers the interception logic to prevent the instruction from directly entering the traditional COS instruction execution process. At the same time, the instruction is temporarily stored in the plugin's built-in temporary cache to prevent the instruction from being lost or tampered with, and to reserve processing time for subsequent container construction and parameter parsing.

[0093] S103, construct an execution management container for the instruction information, and receive instruction information based on the execution management container;

[0094] An execution management container can be an independent execution unit created by a system-level plugin. Each container is associated with only one preset subscription instruction and has an independent metadata storage area and instruction execution space. This enables isolated execution of instructions and avoids resource conflicts caused by multiple concurrent instructions.

[0095] In this solution, the system-level plugin can first detect the current resource usage status of the eSIM card, including remaining memory space, CPU utilization, and storage I / O rate, to ensure that resources meet the container's operational requirements. If resources are sufficient, a dedicated execution management container is created for the intercepted instruction information, and the metadata storage area and execution log area within the container are initialized.

[0096] After the management container is created, the system-level plugin can fully synchronize the instruction information in the temporary cache to the container's metadata storage area. The synchronized content includes instruction headers, complete parameters such as ICCID, operator root key, network authentication key, etc., and may also include instruction reception time, and generate a unique instruction identifier for subsequent execution status tracking.

[0097] S104, based on the instruction information received by the execution management container, the configuration file in the eSIM card is operated to obtain the execution result of the instruction information.

[0098] The configuration file can be a subscription profile in the eSIM card, which can be a profile of a currently active number, a profile of a currently inactive number, or a pre-set blank profile.

[0099] In this solution, if it's an 80CA update instruction, the ICCID, KI, and OPC data are extracted from the instruction parameters and written to a blank configuration file. If it's an 80CB switch instruction, the configuration file corresponding to the target ICCID is switched to an active state, while the original active configuration file is set to inactive. If it's an 80CC delete instruction, the inactive configuration file corresponding to the target ICCID is deleted. During the execution of each instruction type, the execution steps can be recorded in real time to the container's execution log area.

[0100] After the operation is completed, the execution management container generates the execution result. If the operation is successful, it returns 00, indicating success, and also returns the execution time. If the operation fails, it returns the corresponding error code, such as 6A82 if the target configuration file is not found, 6A80 if the parameter format is incorrect, or 6985 if the operation conditions are not met. At the same time, the execution result is synchronized to the system-level plugin, which then feeds back to the eSIM card management platform.

[0101] The technical solution provided in this embodiment, through the collaboration of system-level plug-ins and execution management containers, overcomes the limitation of traditional BIP channels that can only transmit basic instructions. It achieves precise control and isolated execution of preset subscription instructions, avoiding metadata tampering and sequential disorder caused by multiple concurrent instructions, and improving the stability of eSIM card configuration file management. At the same time, it eliminates the dependence on local configuration file assistants, enabling IoT terminals without hardware interfaces to complete configuration file operations, thus improving terminal compatibility.

[0102] In one feasible embodiment, the eSIM card is pre-configured with a blank profile;

[0103] Based on the instruction information received by the execution management container, operations are performed on the configuration file in the eSIM card, including:

[0104] Identify the instruction type of the instruction information received by the execution management container;

[0105] If the instruction type is an update instruction, then the instruction information is written to the blank configuration file.

[0106] The instruction type can be the classification of the operation purpose determined by the execution management container through parsing the instruction header, and it corresponds one-to-one with the function of the instruction information. For example, the 80CA instruction corresponds to the update type, the 80CB instruction corresponds to the switching type, the 80CC instruction corresponds to the deletion type, and the 80CD instruction corresponds to the download type. Each type has preset operation logic and parameter requirements.

[0107] In this solution, the execution management container extracts the instruction header information and compares it with the built-in instruction type and instruction header mapping table. For example, if the instruction header is identified as 80CA, the instruction type is determined to be an update instruction. Specifically, during the identification process, the integrity of the instruction header is checked simultaneously. If the instruction header is missing or incorrect, it is directly determined to be an invalid instruction, and no subsequent operations are performed.

[0108] A blank configuration file is a configuration file in the eSIM card specifically used for quickly updating number information. Its storage location is in the eSIM card's storage area, such as the SRAM storage area. The data writing speed is much higher than that of ordinary service number configuration files, and data writing is only allowed through the 80CA update command to avoid accidental operation.

[0109] When the instruction type is an update instruction, the execution management container first performs format conversion on the data in the instruction parameters, such as ICCID, KI, OPC, and International Mobile Subscriber Identity (IMSI), converting the text-formatted data into a format that conforms to the storage requirements of the blank configuration file, such as binary format. Then, according to the field mapping relationship of the blank configuration file, the converted data is written to the corresponding storage address. After the writing is completed, the data integrity can be verified to ensure that the written data is accurate before the writing result is fed back to indicate that the update operation is complete.

[0110] This technical solution, through a pre-set blank configuration file and targeted update operation logic, can complete the code number information update without downloading the complete configuration file, significantly reducing operation time. Simultaneously, the reduced amount of transmitted command information improves transmission and update success rates, preventing excessive data packet content from affecting update operation execution, thereby greatly enhancing eSIM card management efficiency. Furthermore, format conversion and data verification ensure the accuracy and compliance of the data written to the blank configuration file, preventing update failures due to incorrect data formats.

[0111] After identifying the instruction type of the instruction information received by the execution management container, the method further includes:

[0112] If the instruction type is a download instruction, then the configuration file contained in the instruction information is stored in the eSIM card;

[0113] If the instruction type is a deletion instruction, then the configuration file of the inactive number in the eSIM card is deleted;

[0114] If the instruction type is a switching instruction, then the configuration file of the inactive number in the eSIM card is activated, and the configuration file of the originally activated number in the eSIM card is deactivated.

[0115] The download command can be a preset subscription command with the command type "download" and a corresponding command header of 80CD. Its command information contains complete data of the target configuration file, including ICCID, IMSI, KI, OPC, operator network parameters, and security authentication parameters. It can be directly used to generate a new service number configuration file in the eSIM card to realize the download operation of the new number.

[0116] When the instruction type is a download instruction, the execution management container first allocates a new storage area in the secure storage partition of the eSIM card to store the target configuration file. Then, it splits the complete configuration file data in the instruction information by field and writes it into the newly allocated storage area in sequence. Simultaneously, it updates the configuration file directory of the eSIM card and records the storage location, status and creation time of the new configuration file. The initial status can be an inactive state.

[0117] The deletion command can be a preset subscription command with the command type of deletion. The corresponding command header is 80CC. Its command information must include the ICCID of the target configuration file and the ICCID (ACTIVATE-ICCID) of the currently active configuration file to verify the legality of the deletion operation.

[0118] The inactive number configuration file here can be a configuration file that has been stored in the eSIM card but not used for network access. Its status is in the configuration file directory and it is marked as inactive. This type of configuration file can only be removed by the delete command. Activated configuration files can be set to not be deleted directly.

[0119] Specifically, when the instruction type is a delete instruction, the execution management container first locates the corresponding configuration file in the configuration file directory based on the target ICCID, verifies whether its status is inactive, and then verifies whether the ACTIVATE-ICCID in the instruction information is consistent with the ICCID of the currently active configuration file, ensuring that the deletion operation will not result in the eSIM card having no available activation configuration file; after the double verification is passed, the stored data of the target configuration file is deleted, and the configuration file is marked as deleted in the configuration file directory, releasing the occupied storage resources.

[0120] The switching command can be a preset subscription command with the command type "switching". The corresponding command header is 80CB. Its command information only needs to contain the ICCID of the target configuration file to specify the configuration file to be activated.

[0121] The execution management container locates the corresponding inactive configuration file in the configuration file directory based on the target ICCID. It first verifies the data integrity of the configuration file to ensure that the configuration file is not damaged, then updates the status of the configuration file to active, and synchronously updates the network access parameters of the eSIM card, such as loading the IMSI, KI, etc. of the target configuration file into the network authentication module, so that the eSIM card can access the network through the configuration file.

[0122] While performing the activation operation, the management container can update the currently active configuration file to inactive to ensure that the eSIM card always has one and only one active configuration file, thus avoiding network access conflicts.

[0123] This technical solution provides the implementation process for downloading, deleting, and switching operations, enabling complete management of all configuration files in the eSIM card, meeting the configuration file operation needs under different business scenarios, ensuring orderly management of new configuration files, and facilitating subsequent querying and operation.

[0124] In one feasible embodiment, if the instruction type is an update instruction, the instruction information includes the integrated circuit card identification code field, the operator root key field, the network authentication key field, the International Mobile Subscriber Identity field, and the operation type identifier field of the target configuration file.

[0125] If the instruction type is a switching instruction, then the instruction information includes the integrated circuit card identification code field of the target configuration file;

[0126] If the instruction type is a deletion instruction, the instruction information includes the integrated circuit card identification code field of the target configuration file and the active integrated circuit card identification code field;

[0127] If the instruction type is a download instruction, then the instruction information includes all fields of the target configuration file.

[0128] The Integrated Circuit Card Identifier (ICCID) field of the target profile can be a 20-digit code used to uniquely identify a blank profile. The first 6 digits are the operator code, and the last 14 digits are the card identifier and check digit. This field is used to locate the blank profile to be updated, ensuring that the target of the update operation is correct.

[0129] The Carrier Root Key (KI) field can be the root-level authentication key assigned by the operator to the eSIM card. It is 16 bytes of binary data stored in the encrypted storage area of ​​the eSIM card and is used to generate session keys during network authentication. This field is a core security parameter for network access in the blank configuration file and must be sent through encrypted transmission.

[0130] The Network Authentication Key (OPC) field is an authentication key calculated by the KI and the network authentication parameters (OP) provided by the operator using a preset algorithm (such as the AES algorithm). It is also 16 bytes of binary data, and its security is higher than that of the KI. It is used to improve the anti-attack capability of the network authentication process and is a necessary parameter for blank configuration files to access the 5G network.

[0131] The International Mobile Subscriber Identity (IMSI) field is a 15-digit code used to uniquely identify mobile users globally. The first 3 digits are the Mobile Country Code (MCC), the middle 2 digits are the Mobile Network Code (MNC), and the last 10 digits are the Mobile Subscriber Identification Number (MSIN). This field is used for user identification when the eSIM card accesses the network and is a core identification parameter in the blank configuration file.

[0132] The operation type identifier field (TYPE) can be used to distinguish the specific operation purpose of the update command. When the value is 1, it means that only the data is written to the blank configuration file. When the value is 2, it means that the blank configuration file is activated immediately after the data is written. This field can flexibly control the status of the updated configuration file according to business needs.

[0133] If the instruction type is a switching instruction, the instruction information includes the ICCID field of the target configuration file, which can be a unique identifier of the configuration file to be switched to the active state. This field must be completely consistent with the ICCID of an inactive configuration file already stored in the eSIM card. The execution management container accurately locates the target configuration file through this field to ensure that the switching operation does not deviate and the switching logic can be completed without other auxiliary parameters.

[0134] If the instruction type is a deletion instruction, the fields included in the instruction information are fields that ensure the deletion operation proceeds normally, such as:

[0135] The ICCID field of the target configuration file can be a unique identifier for an inactive configuration file to be deleted. The execution management container can use this field to quickly locate the target in the configuration file directory, ensuring that the deletion operation does not miss any other configuration files.

[0136] The ACTIVATE-ICCID field can be the ICCID of the active configuration file in the current eSIM card. This field is used to verify that the deletion operation will not result in the eSIM card having no active configuration file available. If this field is missing or does not match the actual active ICCID, the deletion operation will be terminated directly to avoid the risk of network disconnection.

[0137] If the instruction type is a download instruction, the instruction information includes all fields of the target configuration file, that is, all the data required to build a complete service number configuration file. In addition to the ICCID, IMSI, KI and OPC fields, it also includes the operator name, network frequency band parameters, data service permission parameters, security authentication algorithm identifier and configuration file validity period, etc. These fields together constitute a configuration file that can be directly used for network access and can be activated and used without subsequent data supplementation.

[0138] This technical solution provides the field structure and functions for various command types, offering a standardized basis for the eSIM card management platform to generate commands and for the eSIM card to parse commands. This avoids command parsing failures due to missing fields or inconsistent formats, improving the compatibility of command transmission and execution. Simultaneously, this configuration reduces the amount of data transmitted between the eSIM card and the eSIM card management platform, increasing transmission speed while avoiding channel congestion and reception failures caused by excessive data transmission.

[0139] In one feasible embodiment, the system-level plugin has a built-in cache area;

[0140] Before constructing the execution management container for the instruction information, the method further includes:

[0141] The instruction information is stored in a storage unit independently allocated to the instruction information within the cache area.

[0142] A storage unit can be a separate storage space allocated for each instruction within the cache. Each storage unit has a unique identifier and uses independent access control, allowing only the container management module of the system-level plugin to read the data. The size of the storage unit can be designed based on the maximum data volume of the preset subscribed instructions to ensure that it can accommodate various types of instruction information.

[0143] System-level plugins can first allocate corresponding storage units in the cache based on the length and type of the instruction information, and then perform integrity verification on the instruction information to ensure that the instruction has not been tampered with. After the verification passes, the instruction information is written to the storage unit in the order of fields, and the storage time and unit identifier are recorded; finally, a storage completion confirmation signal is generated to trigger the subsequent resource detection and container building process.

[0144] This technical solution utilizes an independent storage unit within the cache to store instruction information, achieving secure temporary storage of instruction data and preventing instruction loss due to container construction delays or insufficient resources. Simultaneously, the persistent data storage capability of the cache ensures that instruction processing can continue based on cached data even after a brief anomaly in the eSIM card, improving the reliability of instruction processing. Furthermore, independent access control of the storage unit prevents unauthorized modification or reading of instruction information, ensuring the security of instruction data.

[0145] In one feasible embodiment, after storing the instruction information into a storage unit independently allocated for the instruction information within the cache, the method further includes:

[0146] Identify whether the resource usage status of the eSIM card meets the construction conditions for the execution management container;

[0147] If the conditions are met, an execution management container is constructed for the instruction information in the storage unit.

[0148] The resource usage status of the eSIM card can be real-time data reflecting the current hardware resource usage of the eSIM card, including the remaining memory space, CPU utilization, and storage I / O rate. This data is the basis for determining whether the conditions for building an execution management container are met. It is collected in real time by the eSIM card's resource monitoring module and fed back to the system-level plugin.

[0149] The conditions for building the execution management container can be resource thresholds pre-set in the system-level plugin, specifically including that the remaining memory space is not less than 1.5 times the size of the target configuration file. In addition, it can also include one or more other conditions, such as CPU utilization being less than 60% or storage I / O rate being not less than 10KB / s. The execution management container can be built if one or more resource indicators meet the threshold requirements.

[0150] The system-level plugin can obtain resource usage data in real time and then compare each data point with the corresponding build condition threshold. For example, when the target configuration file size is 100KB, it is necessary to confirm that the remaining memory space is not less than 150KB. If the resource indicators do not meet the threshold, the resource data can be re-obtained and compared every 500ms until the resources meet the standard, or the preset waiting time is exceeded. If the resource is identified as insufficient within 5 seconds, the container build will be terminated and an error will be reported.

[0151] This technical solution ensures that the execution management container is built only when eSIM card resources are sufficient by detecting resource occupancy status and judging construction conditions. This avoids container crashes or instruction execution failures due to insufficient resources, thus improving the stability of container operation. The resource detection retry mechanism can fully utilize the dynamic resources of the eSIM card, reduce operation terminations caused by momentary resource shortages, and improve the instruction processing success rate.

[0152] In one feasible embodiment, identifying whether the instruction information is a preset subscription instruction includes:

[0153] Identify whether the instruction header is a preset instruction header;

[0154] If so, then identify whether the parameters of the instruction information match the preset parameter information;

[0155] If a match is found, the instruction information is determined to be a preset subscription instruction.

[0156] The instruction header can be the starting part of the instruction information. It consists of 2 bytes of hexadecimal encoding and is used to quickly identify the instruction type. For example, 80CA corresponds to the update instruction and 80CB corresponds to the switch instruction. It is the core identifier that distinguishes the preset subscription instruction from other instructions.

[0157] Preset command headers can be a set of command headers pre-stored in the subscribed commands of the system-level plugin, such as {80CA,80CB,80CC,80CD}. This set can be updated according to business expansion, but it needs to be modified through authorized commands from the management platform to ensure security.

[0158] The system-level plugin can extract the first two bytes of the instruction information as the instruction header for comparison. If the comparison is successful, the parameter verification stage begins; if the comparison fails, the instruction information is determined to be a non-pre-subscribed instruction, and it is not intercepted, but directly allowed to proceed to the traditional COS process.

[0159] The parameters of the instruction information can be structured data following the instruction header, consisting of multiple fields. Each field has a fixed length and format. For example, the ICCID field is a 20-digit number, and the KI field is a 16-byte binary data. These parameters are the specific basis for instruction execution, and their format and meaning are defined by the specification of the pre-subscribed instruction.

[0160] Preset parameter information can be pre-defined parameter compliance standards, including the length range, data type, value constraints and validation rules of each field, used to verify the validity of command parameters.

[0161] After determining the instruction type based on the instruction header, the system-level plugin retrieves the preset parameter information for that type of instruction. Then, it extracts the parameters of the instruction information in the order of fields, and verifies one by one whether the field length meets the requirements, whether the data type is correct, whether the value is within the constraint range, etc. If it meets the preset parameter information, it is determined that the parameter matches; if it does not meet the requirements, it is determined that the parameter is abnormal and the subsequent interception and container building process is not triggered.

[0162] This technical solution, through dual identification logic of instruction header matching and parameter verification, can accurately filter out preset subscription instructions, avoid misjudging non-management instructions, such as ordinary data transmission instructions, as subscription instructions, and exclude invalid instructions with abnormal parameters, thereby improving the accuracy and efficiency of instruction identification.

[0163] In one feasible embodiment, identifying whether the parameters of the instruction information match preset parameter information includes:

[0164] The system identifies whether the ICCID format in the parameters of the instruction information is a preset format. If it is a preset format, it is determined to match the preset parameter information.

[0165] And / or,

[0166] The system identifies whether the operation type identifier in the parameters of the instruction information is a preset operation type. If it is a preset operation type, it is determined that it matches the preset parameter information.

[0167] ICCID is the Integrated Circuit Card Identifier, a globally unique code used to uniquely identify an eSIM card or profile. It consists of 20 digits and is a core parameter for locating the target profile.

[0168] The preset format can be a pre-defined ICCID valid format standard, specifically a 20-digit number, with the first 6 digits being the carrier code and the 20th digit being a check digit, etc.

[0169] The system-level plugin can extract the ICCID field from the command parameters. For example, it can first check whether its length is 20 characters, then check whether each character is a number, or if the length and character type meet the requirements, then identify the 20th check bit and determine whether it is correct, and so on. If all the previous checks pass, it is determined that the ICCID format conforms to the preset format and the parameter field matches.

[0170] The operation type identifier can be a field in the instruction parameters used to specify the specific operation purpose of the instruction. It takes the value of an integer from 1 to 4, where 1 represents updating only data, 2 represents updating and activating, 3 represents deleting, and 4 represents switching. The value of this field directly determines the execution logic of the instruction and must strictly conform to the preset requirements.

[0171] The preset operation type can be a pre-defined set of legal operation types, namely {1,2,3,4}. Each value corresponds to a unique operation logic and has a fixed association with the instruction header. For example, the operation type identifier of the 80CA instruction can only be 1 or 2.

[0172] The system-level plugin extracts the operation type identifier from the instruction parameters. First, it checks if the identifier is an integer between 1 and 4. Then, it queries the operation type based on the instruction header to confirm whether the operation type identifier is allowed to be consistent with the operation type identifier associated with the current instruction header. For example, the 80CC instruction only allows the operation type identifier to be 3. If both conditions are met, it is determined that the operation type identifier conforms to the preset operation type, and the parameter field is matched.

[0173] This technical solution further refines parameter matching rules through specialized verification of ICCID format and operation type identifiers. It can accurately identify key anomalies in parameters (such as incorrect ICCID check bits, mismatch between operation type and instruction header), avoiding subsequent operation failures (such as inability to locate configuration files, execution of incorrect operation logic) due to these key parameter anomalies. The targeted design of specialized verification logic is more efficient than general parameter verification, can quickly locate parameter problems, reduce parameter verification time, and improve the overall efficiency of instruction recognition.

[0174] In one feasible embodiment, the method further includes:

[0175] Monitor the execution result of the execution management container on the instruction information;

[0176] If the execution result is an execution error, and the number of consecutive execution errors reaches a preset number, then the state of the system-level plugin will be switched to the circuit breaker state.

[0177] The execution result can be status feedback data generated by the execution management container after processing the instruction information, including key operation records such as execution status and execution time. This data is the core basis for judging whether the instruction execution is normal.

[0178] The system-level plugin can start a dedicated execution result monitoring process to receive execution status updates sent by the execution management container in real time. If the container does not return a result after the preset execution time, it is judged as an execution timeout and is regarded as an execution failure. At the same time, all statuses recorded during the monitoring process can be updated to the execution log for easy subsequent fault location.

[0179] Execution errors can be abnormal states that occur during command execution. For example, they may include parameter errors (6A80), file not found (6A82), conditions not met (6985), insufficient permissions (6986), etc. These errors will prevent the command from completing the expected operation. Some errors may be caused by missing or corrupted configuration files, so repeated execution should be avoided.

[0180] The number of consecutive execution errors can be the number of times the execution management container reports consecutive execution failures for the same instruction. For example, if an 80CA instruction returns a 6A82 error three times in a row, this number is counted in real time by the system-level plugin.

[0181] The status of a system-level plugin can include a normal state and a circuit breaker state. In the normal state, the plugin can listen for, identify, intercept and process preset subscription commands normally. In the circuit breaker state, the plugin will pause the processing of new preset subscription commands and only allow the processing of commands that have been started and test commands to avoid erroneous commands from continuously consuming resources.

[0182] When the number of consecutive execution errors of a certain instruction reaches a preset number of 3, the plug-in status can be switched from normal to circuit breaker, and the circuit breaker trigger time, trigger instruction type and error code can be recorded. At the same time, a circuit breaker alarm is sent to the eSIM card management platform to inform it of the current status.

[0183] This technical solution can promptly detect instruction execution anomalies through real-time monitoring of execution results, preventing long-term unresponsive instructions from consuming resources. The mechanism of continuous error counting and triggering circuit breakers after a preset number of attempts can effectively prevent repeated execution of erroneous instructions, reduce logical damage to the eSIM card's COS layer, and reduce the consumption of ineffective communication resources. The clear switching of circuit breaker status and alarm mechanism allow the management platform to know the eSIM card status in a timely manner, facilitating rapid troubleshooting and improving fault handling efficiency.

[0184] In one feasible embodiment, after switching the state of the system-level plug-in to a circuit breaker state, the method further includes:

[0185] After the circuit breaker duration is reached, receive the test command issued by the eSIM card management platform;

[0186] If the test command is executed successfully, the status of the system-level plugin is switched to normal.

[0187] If the execution result of the test instruction is failure, then the circuit breaker will enter the next state.

[0188] The circuit breaker duration can be a pre-defined circuit breaker state duration set in the system-level plugin, combined with a circuit breaker recovery mechanism; for example, it can be set to 2 hours. After the duration reaches 2 hours, the plugin status can be updated to a state of pending recovery detection, allowing the receipt of test commands, but still not processing ordinary preset subscription commands.

[0189] The test command can be a dedicated preset subscription command issued by the eSIM card management platform to detect whether the plugin has returned to normal. After recognizing the test command issued by the management platform, the system-level plugin will normally intercept it, build an execution management container, and execute the operation. The status returned by the execution management container after processing the test command indicates whether the plugin's command processing logic has returned to normal and the fault has been eliminated. If the execution fails, it means that the fault still exists and the circuit breaker duration needs to be extended for further investigation.

[0190] If the test command executes successfully, the system-level plugin can switch to normal status and send a notification to the management platform. If the test command fails, the system-level plugin will extend the circuit breaker duration and switch its status back from pending recovery detection to circuit breaker status.

[0191] This technical solution restores the circuit breaker status by controlling the circuit breaker duration and verifying the test command. The circuit breaker duration extension mechanism provides the management platform with more time for troubleshooting, and the timely notification of the recovery results allows the management platform to keep track of the eSIM card status, facilitating collaborative fault handling and improving fault handling efficiency.

[0192] In one feasible embodiment, the system-level plugin listens for instruction information issued to the eSIM card, including:

[0193] The system-level plugin listens for instruction information sent by the eSIM card management platform through the BIP channel.

[0194] BIP channels can be Bearer Independent Protocol (BIP) channels, specifically BIP channels conforming to the SCP81 specification. This channel is a communication channel designed specifically for remote card management in IoT scenarios. It does not rely on the hardware interface of the eSIM card and can transmit commands through wireless communication networks, making it suitable for IoT terminals without hardware interfaces.

[0195] This technical solution, based on the BIP channel monitoring design, eliminates the dependence on the eSIM card hardware interface, enabling IoT terminals without hardware interfaces to be remotely managed, significantly improving the terminal compatibility range and management capabilities of the eSIM card.

[0196] Figure 2This is a flowchart illustrating an eSIM card management method provided in an embodiment of this application. The method is executed by an eSIM card management platform. The eSIM card's Chip Operating System (COS) is configured with a system-level plugin, namely the Deep COS plugin. This system-level plugin is a core control module independent of traditional COS logic, integrating an instruction analysis set, a global control mechanism, and a circuit breaker protection mechanism, enabling full-process control over the instruction types in the eSIM card configuration file. Figure 2 As shown, the method may include the following steps:

[0197] S201, if there is an instruction to be issued, then identify whether the instruction to be issued is a preset subscription instruction;

[0198] S202, if so, then determine the key field information to be sent based on the key fields associated with the preset subscription instruction;

[0199] S203, construct the instruction information of the instruction to be issued based on the instruction type of the preset subscription instruction and the key field information;

[0200] S204, the instruction information is sent to the eSIM card through a preset channel.

[0201] In one feasible embodiment, the method further includes:

[0202] Receive the fuse status information reported by the eSIM card;

[0203] When the circuit breaker duration is reached, a test command is sent to the eSIM card.

[0204] The eSIM card management method provided in this embodiment has the same execution process and beneficial effects as the eSIM card management method described above, and will not be described in detail here to avoid repetition.

[0205] To enable those skilled in the art to better understand this solution, this application also provides a preferred embodiment.

[0206] This solution constructs a three-in-one management system: a business platform, a multi-application IoT SIM card trusted service management platform, and an IoT eSIM card. It fully covers the entire process, including eSIM card production and pre-configuration, business application deployment, application management, script engine processing, and number management. Figure 3 This is a schematic diagram of the comprehensive eSIM card management process provided in the embodiments of this application. Figure 3 As shown:

[0207] Business Platform: Multi-application IoT SIM Card Trusted Service Management Platform Access Platform, which includes services such as multi-application SIM / eSIM application management, personalization, and number management.

[0208] Multi-application IoT SIM card trusted service management platform: supports full lifecycle management of multi-application SIM cards, eSIM application management, personalized script engine, eSIM profile management, and eSIM card management.

[0209] IoT eSIM Card: An embedded SIM with a built-in number management application, implementing number management via the BIP+APDU protocol stack, and pre-configured service number profiles and blank profiles. The blank profile enables the writing of key network access data, achieving millisecond-level number download. It also installs an LPAE local configuration file assistant, and through COS modifications, supports profile downloading via the BIP+APDU protocol stack. This includes:

[0210] I. IoT eSIM card pre-installation process, specifically including:

[0211] 1. Install LPAE local configuration file assistant and preset code management application;

[0212] 2. Pre-configured Profile, including Business Number Profile and Blank Profile.

[0213] II. Business listing process, specifically including:

[0214] 1. When a business platform applies to list its services, the core parameters include: access provider name, access provider platform public key, access provider platform callback address, application name, application AID, application version number, installation parameters, registration and update parameters, and CAP package information.

[0215] 2. The Super Card Multi-Application Management Platform accepts listing requests and returns listing information after processing. The core parameters include: SP-ID, platform address, platform public key, security domain name, security domain AID, TAR, and personalized script template.

[0216] III. eSIM application management process, specifically including:

[0217] 1. SP access party information management, used for maintaining business party information. The core parameters include: SP-ID, SP status, key index number, and SP platform callback address.

[0218] 2. Auxiliary security domain information management, used for the allocation and management of security domains for business applications. Core parameters include: carrier type, auxiliary security domain AID, TAR, permission string, and installation parameters.

[0219] 3. CAP package information management, used to parse and manage CAP packages provided by business parties. Core parameters include: CAP package name, CAP package version number, package AID, module AIDS, and loading parameters. It includes parsing of 3.0+ version packages and 4.0 version packages.

[0220] 4. Application information and permission management, used for business application maintenance. The core management parameters include: application name, application AID, application version number, and personalized script template [personalized script library].

[0221] 5. eSIM Number Management: Used for managing eSIM number data. Core parameters include: EID, ICCID, operator, number attributes (initial, blank), main security domain AID, and main security domain key version.

[0222] IV. Application installation process, specifically including:

[0223] 1. The business platform initiates an application installation request. The core parameters include: SP-ID, application AID, and ICCID. The multi-application IoT SIM card trusted service management platform establishes a TCP+TLS BIP connection with the IoT eSIM card.

[0224] 2. The multi-application IoT SIM card trusted service management platform assembles application installation APDUs and distributes them to the IoT eSIM card for application installation.

[0225] 3. The business platform initiates an application installation result query to confirm the application installation result.

[0226] V. Personalized script engine processing flow, specifically including:

[0227] 1. The business platform initiates a personalization application, with core parameters including: SP-ID, Application AID, ICCID, and personalized placeholder data;

[0228] 2. The IoT SIM card trusted service management platform retrieves the personalized script library based on the application AID, obtains the personalized script template instruction set, parses the personalized template, and the template rules are as follows:

[0229] Personalized script template rules:

[0230] ["index":"{index}",APDU:"CLA+INS+P1+P2+{@}+Le"];

[0231] index description: placeholder; @ description: Lc+Data;

[0232] Example: ["index":"T1",APDU:"84CB0000@00"];

[0233] 3. The IoT SIM card trusted service management platform analyzes personalized placeholder data, which is as follows:

[0234] Personalized placeholder data rules: ["index":"{index}",data:"{@}"];

[0235] index description: Placeholder for the personalized script template; @ description: Lc+Data for the personalized script template.

[0236] Example: ["index":"T1",data:"0802017910FFFFFFFF"];

[0237] 4. Load historical personalized scripts into the IoT SIM card trusted service management platform to perform personalized modeling. The modeling principles are as follows:

[0238] Preprocessing layer: Historical logs are cleaned using semi-structured data retrieval technology;

[0239] Feature engineering: Extracting combined features of CLA / INS / P1 / P2 from the APDU field;

[0240] Association Analysis: Applying an improved Apriori algorithm to mine failed itemsets;

[0241] Predictive Model: Constructing a random forest classifier to assess risk level;

[0242] 5. The IoT SIM card trusted service management platform is used to assemble the personalization script, analyze and correct it through the personalization model, and send the personalization instructions to the eSIM card through the BIP channel to start the execution of the personalization instructions;

[0243] 6. The business platform initiates an application personalization result query to confirm the application personalization result.

[0244] VI. Code Management Process;

[0245] Figure 4 This is a comparative diagram of the eSIM card management methods provided in the embodiments of this application, such as... Figure 4As shown, current eSIM Profile management strictly follows the GSMA specification, using the LPA (Local Profile Assistant) based on the ES9+ / ES10X protocol to perform operations such as number downloading, deletion, and activation. However, in the BIP (Bearer Independent Protocol) scenario, the SCP81 channel has significant limitations: because BIP connections can only establish communication links with specific activated numbers within the eSIM, they cannot directly manipulate other inactive or unassigned number spaces, resulting in the lack of BIP-based number management functionality. The core defects are as follows:

[0246] Limitations of BIP channel management capabilities: Traditional BIP channels can only achieve basic transmission of instructions by "sending and receiving" and cannot intercept, verify parameters, or control the execution of code management instructions in real time. This can lead to problems such as parameter errors and instruction conflicts during instruction execution, which in turn can cause failures such as profile download failures and abnormal switching.

[0247] Lack of a global execution container: Management commands from different profiles (such as download and delete commands) share the same execution space, without an independent metadata storage and execution isolation mechanism. When multiple commands are executed concurrently, problems such as metadata tampering and disordered command execution order can easily occur, which seriously affects the stability of eSIM card number management.

[0248] Lack of fault protection mechanism: When an instruction execution triggers an error (such as returning a 6A82 error, which means "file not found"), the existing technology does not have automatic fuse protection logic, which will cause erroneous instructions to be repeatedly sent, which not only wastes communication resources, but may also cause irreversible logical damage to the COS (chip operating system) layer of the eSIM card.

[0249] The core of this technical solution lies in embedding a "deep COS plugin" into the COS layer of the eSIM card. This plugin, as a core management module independent of traditional COS logic, achieves full-process control over number management commands issued through the BIP channel through a three-layer architecture: "command analysis set - global control mechanism - circuit breaker protection mechanism." By intercepting number management commands (such as 80CA / 80CB series APDUs) issued through the BIP channel in real time, a global number management container is constructed. This container is uniformly scheduled by the COS kernel, enabling cross-profile command storage and execution, thereby breaking through the single number binding limitation of the BIP channel and ultimately supporting the dynamic download, switching, deletion, and other full lifecycle management of numbers within the BIP environment.

[0250] The specific process is as follows:

[0251] 1. The service provider platform initiates an eSIM number management operation application, including ICCID, OPER-TYPE (operation type: update / switch / delete / download), KI, OPC, IMSI, TYPE, ACTIVATE-ICCID, and Profile. The TSM platform assembles eSIM Profile download, switch, and delete data instructions, according to the following rules:

[0252] Update command: 80CA[Total data length][ICCID][KI][OPC][IMSI][TYPE];

[0253] Switching command: 80CB[Total data length][ICCID];

[0254] Delete command: 80CC[total data length][ICCID][ACTIVATE-ICCID];

[0255] Download command: 80CD[Total data length][Profile];

[0256] TYPE Explanation: 1 indicates download only, 2 indicates download + activation;

[0257] 2. When number management commands are sent to the eSIM card via the BIP channel, the COS layer integrates a deep COS plugin as the core control module. This module is primarily used for intercepting number management commands and creating and executing containers, thereby enabling functions such as downloading, switching, deleting, activating, and updating eSIM profile numbers. This overcomes the limitations of the BIP channel in eSIM profile number management and innovatively adds a new number management method.

[0258] I. The implementation method of the Deepin COS plugin is as follows:

[0259] Figure 5 This is a schematic diagram illustrating the implementation logic of the Deep COS plugin provided in this application embodiment. For example... Figure 5 As shown:

[0260] The instruction analysis set is the "front-end awareness layer" of the Deep COS plugin. Its core function is to perform real-time detection, precise interception, and parameter storage of instructions issued through the BIP channel. Specific implementation steps are as follows:

[0261] Instruction Analysis Set - Real-time Instruction Detection Logic:

[0262] The plugin uses a pre-defined instruction feature library to perform real-time parsing of all instructions transmitted through the BIP channel, with a focus on detecting four core code management instructions: 80CA (Profile download instruction), 80CB (Profile switching instruction), 80CC (Profile deletion instruction), and 80CD (Profile activation / update instruction).

[0263] The detection mechanism adopts a dual logic of "command header matching + parameter feature verification": first, the command type is quickly identified by the command header (such as 80CA), and then the subsequent parameters of the command (such as the ICCID format of the Profile and the operation type identifier) ​​are verified for compliance to avoid invalid interception due to incorrect command format;

[0264] Instruction Analysis Set - Instruction Interception and Parameter Storage:

[0265] When a legitimate code management command is detected, the plugin immediately triggers the interception logic to prevent the command from directly entering the traditional execution flow of the COS layer;

[0266] Intercepted instructions will be stored in the plugin's built-in "global cache." The cache uses a partitioned storage structure, allocating an independent storage unit for each instruction. The core parameters stored include:

[0267] Target Profile Identification Information: such as Profile ICCID (Integrated Circuit Card Identification Code), Profile Name, and Carrier Code;

[0268] Operation type parameters: such as the type identifier of "download", "switch", "delete", "activate", "update", and the operation triggering conditions (such as manual trigger / automatic trigger);

[0269] Profile file information: such as the file path, file size, encryption check value, and signature information;

[0270] The global cache has data persistence capabilities, so even if the eSIM card experiences a brief power outage or communication interruption, the stored instruction parameters will not be lost, ensuring the continuity of subsequent instruction execution.

[0271] The global control mechanism is the "core execution layer" of the Deepin COS plugin. By allocating an independent "global container" for each Profile operation, it achieves isolation of instruction execution and metadata management. The specific process is as follows:

[0272] Global control mechanism - container creation trigger conditions:

[0273] After the global cache stores the instruction parameters, the plugin automatically detects the current eSIM card's resource usage status (such as CPU utilization and remaining memory space). If the resources meet the execution requirements (such as remaining memory space ≥ 1.5 times the size of the Profile file), then the creation of the global container is triggered.

[0274] Global control mechanism - metadata storage logic:

[0275] Each global container corresponds to a unique Profile operation, and the metadata stored within the container includes:

[0276] Basic execution data: Target ProfileICCID, operation type, and file information synchronized from the global cache;

[0277] Execution status data: such as container creation time, instruction execution progress (0%-100%), current execution step (such as "parameter verification in progress", "file transfer in progress", "activation confirmation in progress");

[0278] Related command data: If the current operation depends on other commands (such as the "original profile unregistration command" must be executed first when switching profiles), the container will automatically associate and store the execution results of the dependent commands;

[0279] Global control mechanism - container resource reclamation mechanism:

[0280] Once the instruction is executed (successfully or unsuccessfully), the global control mechanism will automatically release the memory, storage, and other resources occupied by the container to prevent resource leaks. For "zombie containers" caused by communication interruptions (such as those that have not received execution feedback within 10 minutes of creation), the plugin will trigger a timed cleanup logic to forcibly reclaim resources.

[0281] The circuit breaker protection mechanism is a protection strategy designed to prevent repeated execution of erroneous commands from damaging the eSIM card. It achieves automatic fault isolation through error count statistics and function freeze logic. Specific implementation rules are as follows:

[0282] Circuit breaker protection mechanism - error detection and statistical logic:

[0283] The plugin monitors the execution results of instructions across the entire container in real time, with a focus on detecting core errors related to code management, such as 6A82 error (file not found), 6A80 error (parameter error), and 6985 error (condition not met).

[0284] The plugin employs a "continuous error counting" mechanism: when the same profile operation command triggers 3 consecutive 6A82 errors (or other preset critical errors), the plugin automatically determines it to be in a "fault state".

[0285] Fuse protection mechanism - Fuse protection triggering process:

[0286] The plugin monitors the execution results of instructions across the entire container in real time, with a focus on detecting core errors related to code management, such as 6A82 error (file not found), 6A80 error (parameter error), and 6985 error (condition not met).

[0287] The plugin employs a "continuous error counting" mechanism: when the same profile operation command triggers 3 consecutive 6A82 errors (or other preset critical errors), the plugin automatically determines it to be in a "fault state".

[0288] Circuit breaker protection mechanism - Circuit breaker recovery mechanism:

[0289] After the freeze period ends, the plugin automatically enters "recovery detection mode". At this time, the BIP channel is allowed to send one test code management command (such as Profile activation command). If the command is executed successfully, the circuit breaker protection is released and the code management function is restored to normal use.

[0290] If the test command still triggers an error, the freeze duration will be extended and an alarm message will be reported again to avoid blindly restoring the function before the fault is resolved, which could cause secondary damage.

[0291] II. Rules for parsing management instructions:

[0292] 2.1 80CA Command Processing:

[0293] 2.1.1: If a blank profile exists, update the profile;

[0294] 2.1.2: If no blank Profile exists, return 6A82;

[0295] 2.2 80CB Instruction Processing:

[0296] 2.2.1: If the ICCID exists, switch the code number;

[0297] 2.2.2: If the ICCID does not exist, return 6A82 (file not found);

[0298] 2.3 Handling of 80CC deletion commands:

[0299] 2.3.1: Subsequent processing when ACTIVATE-ICCID exists;

[0300] 2.3.2: Returns 6985 if ACTIVATE-ICCID does not exist, condition not met;

[0301] 2.3.3: If the ICCID exists, switch the code number;

[0302] 2.3.4: If the ICCID does not exist, return 6A82;

[0303] 2.4 Handling of 80CD activation / update commands:

[0304] 2.4.1 The code management application calls the LPAE local configuration file assistant to download codes.

[0305] Finally, the business platform initiates a query to confirm the code management operation results.

[0306] The technical solution provided in this embodiment proposes an eSIM Profile management method based on a multi-application IoT SIM card trusted service management platform. By constructing this platform, it integrates the instruction analysis set of a deep COS plugin (real-time interception of 80CA-80CD instructions), a circuit breaker protection mechanism (freezing for 24 hours after 3 6A82 errors), and a global control mechanism (containerized isolated storage). Combined with BIP channels and pre-built blank profile technology, it enables on-demand downloading, secure switching, and instant deletion of profiles. This method overcomes the current limitation of not being able to manage profiles through active commands, ultimately achieving efficient and trusted management of the entire eSIM number lifecycle.

[0307] Meanwhile, this technical solution also proposes an innovative eSIM application management method based on a multi-application IoT SIM card trusted service management platform. By integrating key technologies such as SP access management, auxiliary security domain, CAP package, and multi-application parallel control, it realizes unified management of the lifecycle of multi-application SIM cards and eSIM numbers, solves the problem of fragmented management in traditional IoT scenarios, and significantly improves security and business flexibility.

[0308] Meanwhile, this technical solution also proposes an innovative personalized script engine mechanism based on a multi-application IoT SIM card trusted service management platform. It obtains template instruction sets by applying AID to retrieve personalized script libraries and parses placeholder data. A four-layer intelligent modeling is then implemented using historical personalized scripts: the preprocessing layer employs semi-structured data cleaning and log feature engineering to extract key field combinations of APDU instructions; association analysis utilizes an improved Apriori algorithm to mine failure patterns; and finally, a random forest classifier is used to achieve dynamic risk level assessment. This mechanism effectively improves the development efficiency and reliability of personalized instructions.

[0309] Compared with the prior art, the beneficial effects of this application include, but are not limited to:

[0310] This innovative solution utilizes deep COS plugins to implement instruction analysis sets, circuit breaker protection mechanisms, and global control mechanisms. It also combines the BIP SCP81 channel to manage code profiles, breaking through the limitations of traditional LPAs that rely on the 7816 / SPI protocol. This enables terminal devices without hardware interfaces to still perform operations such as profile downloading and switching, significantly improving the compatibility of IoT terminals.

[0311] It achieves unified and integrated management of traditional SIM cards and eSIM, enabling the same services to run seamlessly on different card carriers, and reduces operation and maintenance costs through standardized interface protocols and virtualized communication stack technology.

[0312] Multi-SIM card carrier adaptation: It realizes unified management of traditional SIM cards and eSIM, enabling the same service to run seamlessly on different card carriers. Through standardized interface protocols and virtualized communication stack technology, it reduces operation and maintenance costs.

[0313] Personalized script automation, through four-layer intelligent modeling to achieve dynamic risk assessment (preprocessing layer feature extraction + improved Apriori algorithm association analysis + random forest classification), significantly reduces the command failure rate; the template command set reuse mechanism based on AID retrieval (using placeholder data dynamic parsing technology) greatly improves development efficiency; effectively solves the core pain points faced in traditional SIM card application development, such as long development cycle, complex multi-terminal adaptation, and difficulty in locating abnormal problems.

[0314] Number management under the BIP+APDU protocol stack. By formulating APDU specifications for number management based on BIP channels, a breakthrough was achieved in overcoming the single dependence on LPAD, enabling multi-channel collaborative capabilities for number management. An optimized APDU instruction set design ensures rapid download and update of number data even in constrained network environments, significantly improving network adaptability. Standardized protocol stack integration ensures compatibility with existing SIM card architectures while expanding the application capabilities of Super SIM cards in 5G scenarios. These innovations effectively address the technical limitations of traditional number management methods, such as single-channel operation and strong network dependence.

[0315] Figure 6 This is a schematic diagram of an eSIM card management device provided in an embodiment of this application. Figure 6 As shown, the device is configured on an eSIM card, and the chip operating system of the eSIM card is configured with a system-level plug-in. The device includes: an instruction information monitoring module 610, an instruction information interception module 620, a container building module 630, and an execution module 640.

[0316] The instruction information monitoring module 610 is used to monitor the instruction information sent to the eSIM card in the preset channel through the system-level plug-in;

[0317] The instruction information interception module 620 is used to identify whether the instruction information is a preset subscription instruction; if so, the instruction information is intercepted.

[0318] The container building module 630 is used to build an execution management container for the instruction information and receive instruction information based on the execution management container;

[0319] The execution module 640 is used to operate on the configuration file in the eSIM card based on the instruction information received by the execution management container, so as to obtain the execution result of the instruction information.

[0320] The eSIM card management device provided in this embodiment has functional modules and beneficial effects corresponding to the eSIM card management method described above. To avoid repetition, it will not be described in detail here.

[0321] Figure 7 This is a schematic diagram of an eSIM card management device provided in an embodiment of this application. Figure 7 As shown, the device is configured on the eSIM card management platform, and the device includes: a command identification module 710 to be issued, a key field information determination module 720, a command information construction module 730, and a command information issuance module 740;

[0322] The pending instruction identification module 710 is used to identify whether the pending instruction is a preset subscription instruction if there is a pending instruction.

[0323] The key field information determination module 720 is used to determine the key field information to be sent based on the key fields associated with the preset subscription instruction if it is a preset subscription instruction;

[0324] The instruction information construction module 730 is used to construct the instruction information of the instruction to be issued based on the instruction type of the preset subscription instruction and the key field information;

[0325] The instruction information sending module 740 is used to send the instruction information to the eSIM card through a preset channel.

[0326] The eSIM card management device provided in this embodiment has functional modules and beneficial effects corresponding to the eSIM card management method described above. To avoid repetition, it will not be described in detail here.

[0327] Figure 8 This is a schematic diagram of the structure of an eSIM card management device provided in an embodiment of this application. Figure 8 As shown, the eSIM card management device may include a processor 801 and a memory 802 storing computer program instructions.

[0328] Specifically, the processor 801 may include a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0329] Memory 802 may include mass storage for data or instructions. For example, and not limitingly, memory 802 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. In one instance, memory 802 may include removable or non-removable (or fixed) media, or memory 802 may be non-volatile solid-state memory. Memory 802 may be internal or external to the integrated gateway disaster recovery device.

[0330] In one instance, memory 802 may be read-only memory (ROM). In one instance, the ROM may be a mask-programmed ROM, a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), an electrically rewritable ROM (EAROM), or flash memory, or a combination of two or more of these.

[0331] Memory 802 may include read-only memory (ROM), random access memory (RAM), disk storage media device, optical storage media device, flash memory device, electrical, optical, or other physical / tangible memory storage device. Therefore, generally, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to one aspect of this disclosure.

[0332] The processor 801 reads and executes computer program instructions stored in the memory 802 to implement the eSIM card management method in the above embodiments.

[0333] In one example, the eSIM card management device may also include a communication interface 803 and a bus 804. For example, Figure 8 As shown, the processor 801, memory 802, and communication interface 803 are connected through bus 804 and complete communication with each other.

[0334] The communication interface 803 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0335] Bus 804 includes hardware, software, or both, that couples components of the eSIM card management device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 804 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0336] The eSIM card management device can execute the eSIM card management method in the embodiments of this application, thereby realizing the eSIM card management method described in the above embodiments.

[0337] Furthermore, in conjunction with the eSIM card management device method in the above embodiments, this application embodiment can provide a computer storage medium for implementation. The computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the eSIM card management device methods in the above embodiments.

[0338] This application also provides a computer program product, including a computer program that, when executed by a processor, implements any of the eSIM card management device methods described in the above embodiments.

[0339] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0340] The functional blocks shown in the above-described block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, read-only memory (ROM), flash memory, erasable read-only memory (EROM), floppy disks, compact disc read-only memory (CD-ROM), optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0341] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0342] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0343] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A method for managing an eSIM card, characterized in that, The method is executed by an eSIM card, the eSIM card's chip operating system being configured with a system-level plugin, and the method includes: The system-level plugin listens for instruction information sent to the eSIM card through a preset channel. The system-level plugin is a dedicated management and control module deployed at the eSIM card's COS layer, and the system-level plugin has a built-in cache area. The system-level plugin identifies whether the instruction information is a preset subscription instruction; if so, the instruction information is intercepted. Based on the length and type of the instruction information, a storage unit is independently allocated for each instruction information in the cache area, and the storage unit is subject to independent access control. The instruction information is stored in the storage unit; The system-level plugin constructs an execution management container for the instruction information, and receives the instruction information based on the execution management container; Based on the instruction information received by the execution management container, the configuration file in the eSIM card is operated to obtain the execution result of the instruction information; The system-level plugin monitors the execution results of the instruction information by the execution management container. If the execution result is an execution error, and the number of consecutive execution errors reaches a preset number, then the state of the system-level plugin will be switched to the circuit breaker state.

2. The eSIM card management method according to claim 1, characterized in that, The eSIM card is pre-configured with a blank configuration file; Based on the instruction information received by the execution management container, operations are performed on the configuration file in the eSIM card, including: Identify the instruction type of the instruction information received by the execution management container; If the instruction type is an update instruction, then the instruction information is written to the blank configuration file.

3. The eSIM card management method according to claim 2, characterized in that, After identifying the instruction type of the instruction information received by the execution management container, the method further includes: If the instruction type is a download instruction, then the configuration file contained in the instruction information is stored in the eSIM card; If the instruction type is a deletion instruction, then the configuration file of the inactive number in the eSIM card is deleted; If the instruction type is a switching instruction, then the configuration file of the inactive number in the eSIM card is activated, and the configuration file of the originally activated number in the eSIM card is deactivated.

4. The eSIM card management method according to claim 2 or 3, characterized in that, If the instruction type is an update instruction, the instruction information includes the integrated circuit card identification code field, the operator root key field, the network authentication key field, the International Mobile Subscriber Identity field, and the operation type identifier field of the target configuration file; If the instruction type is a switching instruction, then the instruction information includes the integrated circuit card identification code field of the target configuration file; If the instruction type is a deletion instruction, the instruction information includes the integrated circuit card identification code field of the target configuration file and the active integrated circuit card identification code field; If the instruction type is a download instruction, then the instruction information includes all fields of the target configuration file.

5. The eSIM card management method according to claim 1, characterized in that, After storing the instruction information into a storage unit independently allocated for the instruction information within the cache, the method further includes: Identify whether the resource usage status of the eSIM card meets the construction conditions of the execution management container; If the conditions are met, an execution management container is constructed for the instruction information in the storage unit.

6. The eSIM card management method according to claim 1, characterized in that, Identifying whether the instruction information is a preset subscription instruction includes: Identify whether the command header is a preset command header; If so, then identify whether the parameters of the instruction information match the preset parameter information; If a match is found, the instruction information is determined to be a preset subscription instruction.

7. The eSIM card management method according to claim 6, characterized in that, Identifying whether the parameters of the instruction information match preset parameter information includes: The system identifies whether the ICCID format in the parameters of the instruction information is a preset format. If it is a preset format, it is determined to match the preset parameter information. And / or, The system identifies whether the operation type identifier in the parameters of the instruction information is a preset operation type. If it is a preset operation type, it is determined that it matches the preset parameter information.

8. The eSIM card management method according to claim 1, characterized in that, After switching the state of the system-level plugin to the circuit breaker state, the method further includes: After the circuit breaker duration is reached, receive the test command issued by the eSIM card management platform; If the test command is executed successfully, the status of the system-level plugin will be switched to the normal state. If the execution result of the test instruction is failure, then the circuit breaker will enter the next state.

9. The eSIM card management method according to claim 1, characterized in that, The system-level plugin listens for instruction information issued to the eSIM card, including: The system-level plugin listens for instruction information sent by the eSIM card management platform through the BIP channel.

10. A method for managing an eSIM card, characterized in that, The method is executed by the eSIM card management platform, and the method includes: If there is an instruction to be issued, then identify whether the instruction to be issued is a preset subscription instruction; If so, then determine the key field information to be sent based on the key fields associated with the preset subscription instruction; The instruction information of the instruction to be issued is constructed based on the instruction type of the preset subscription instruction and the key field information; The instruction information is sent to the eSIM card through a preset channel so that the eSIM card can perform the eSIM card management method as described in any one of claims 1-9.

11. The eSIM card management method according to claim 10, characterized in that, The method further includes: Receive the fuse status information reported by the eSIM card; When the circuit breaker duration is reached, a test command is sent to the eSIM card.

12. A management device for an eSIM card, characterized in that, The device is configured on an eSIM card, the eSIM card's chip operating system is configured with a system-level plugin, and the device includes: The instruction information monitoring module is used to monitor the instruction information issued to the eSIM card in the preset channel through the system-level plug-in. The system-level plug-in is a dedicated management and control module deployed on the eSIM card COS layer, and the system-level plug-in has a built-in cache area. The instruction information interception module is used to identify whether the instruction information is a preset subscription instruction through the system-level plugin; if so, the instruction information is intercepted. The instruction information storage module is used to allocate a storage unit independently for each instruction information in the cache area based on the length and type of the instruction information, and the storage unit adopts independent access control; it is also used to store the instruction information in the storage unit. A container building module is used to build an execution management container for the instruction information obtained through the system-level plugin, and to receive instruction information based on the execution management container; The execution module is used to operate on the configuration file in the eSIM card based on the instruction information received by the execution management container, so as to obtain the execution result of the instruction information; The execution result monitoring module is used to monitor the execution result of the execution management container on the instruction information through the system-level plugin; it is also used to switch the state of the system-level plugin to the circuit breaker state if the execution result is an execution error and the number of consecutive execution errors reaches a preset number.

13. A management device for an eSIM card, characterized in that, The device is configured on an eSIM card management platform, and the device includes: The pending instruction identification module is used to identify whether the pending instruction is a preset subscription instruction if there is a pending instruction. The key field information determination module is used to determine the key field information to be sent based on the key fields associated with the preset subscription instruction if it is a preset subscription instruction. The instruction information construction module is used to construct the instruction information of the instruction to be issued based on the instruction type of the preset subscription instruction and the key field information; The instruction information sending module is used to send the instruction information to the eSIM card through a preset channel, so that the eSIM card can perform the eSIM card management method as described in any one of claims 1-9.

14. A management device for an eSIM card, characterized in that, The device includes: a processor and a memory storing computer program instructions; the processor reads and executes the computer program instructions to implement the eSIM card management method as described in any one of claims 1-9 or 10-11.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions that, when executed by a processor, implement the eSIM card management method as described in any one of claims 1-9 or 10-11.

16. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the eSIM card management method as described in any one of claims 1-9 or 10-11.

Images