A method for processing UICC application initiative command in a multi-file concurrent activation scenario in an ESIM

Abstract

The application provides a UICC application initiative command processing method in a multiple file concurrent activation scene of an ESIM, comprising defining and allocating independent stack space in memory for each activated port; determining and configuring the maximum number of simultaneously activated ports supported by the system in the compiling stage according to the processing capacity and resource limitation of the used chip; monitoring and analyzing the received MANAGE LSI instruction in real time in the system running process, dynamically switching the port currently interacting with the terminal according to the port identifier specified in the instruction, and switching the execution context to the stack space of the corresponding port to continue executing the UICC application session of the current Profile; using the setjmp / longjmp mechanism to save the session state of the current port when switching the port is needed, and restoring the session state of the target port after jumping to the target port. The application solves the STK session conflict problem in the MEP scene by allocating an independent execution stack for each Profile and combining setjmp / longjmp to realize cross-Profile context saving and restoration.

Description

Technical Field

[0001] This invention relates to the field of smart card technology, specifically to a method for proactive command processing of UICC applications in ESIM multi-file concurrent activation scenarios. This method is designed for multi-operator service scenarios such as IoT devices, mobile terminals, and vehicle networking, as well as other telecommunications service scenarios such as mobile voice services and mobile data communication services. It is used to solve STK (SIM Toolkit) session conflicts, execution stack chaos, and data isolation problems when multiple profiles are concurrent. Background Technology

[0002] eSIM is an embedded universal integrated circuit card that supports dynamic management of multiple operator profiles via over-the-air (OTA) download. MEP (Multiple Enabled Profiles) technology allows multiple profiles to be activated simultaneously on a single eUICC card. Each profile corresponds to an independent logical port and application instance, enabling concurrent operation of multi-operator services. For example, users can simultaneously use mobile networks, IoT connections, or enterprise leased line services on the same device.

[0003] STK (SIM Toolkit) is a protocol stack for interaction between the UICC card and the terminal (such as a mobile phone). It supports proactive commands initiated by the card, such as displaying text, obtaining user input, and sending SMS messages. The STK session flow for a single profile is as follows: The card initiates a command: UICC returns status word 91XX (XX is the length of the data to be acquired), notifying the terminal that it needs to read the response.

[0004] Terminal data acquisition: The terminal sends a FETCH command (INS 0x12) to obtain the card response.

[0005] Card return result: The terminal informs the processing result via TERMINAL RESPONSE (INS 0x14), and the card continues the service or ends the session based on the result.

[0006] like Figure 1 As shown in Note 1: After the UICC returns 91XX (XX represents the length of data that the terminal needs to obtain), during the period between the terminal sending the FETCH command to retrieve the response, other card interaction commands, downlink SMS messages, and triggering Toolkit applications (including HTTPS, Toolkit, etc.) can be interspersed. However, only one STK can exist on the same UICC card at a time. If an application needs to send 91XX during this period, the application will be notified that the ProactiveHandler is busy at this time.

[0007] Note 2: After the terminal obtains a response by acquiring the FETCH command, it needs to inform the UICC of the processing result via TERMINAL RESPONSE. However, before the terminal sends TERMINAL RESPONSE, it can intersperse other card interaction commands and operations such as triggering applications.

[0008] After UICC receives the TERMINAL RESPONSE data, it needs to return the data or result to the application that sent the proactive command. The application continues to process the business. If there is other data that the terminal needs to actively obtain, it continues to send 91XX. If a 9000 response is received, this STK session ends.

[0009] However, when using the MEP card, there are multiple active profiles. At positions 1 and 2, the terminal might send a MANAGE LSI command. Subsequent commands then need to be processed on the newly selected profile (e.g., Port2). In this case, Port2 might also enter an STK session. UICC runtime management needs to ensure that the STK sessions of multiple ports are processed independently and completely, and that the terminal processing result (TERMINAL RESPONSE) is returned to the application, i.e., as shown... Figure 2 The process is shown below.

[0010] Note 11: When the 14 response of the Port1 STK session is received, it is necessary to jump back to position A and return the result of 14 to the Port1 application. The application continues to process the business based on the result of 14.

[0011] Note 12: When the 14 response of the Port2 STK session is received, it is necessary to jump back to position B and return the result of 14 to the Port2 application. The application continues to process the business based on the result of 14.

[0012] Because the execution stack keeps pushing down during program execution, even if Port1 saves stack and register information at position A, and jumps back to position A at note 11, when the terminal responds to Port2 14, since the execution stacks of Port1 and Port2 are mixed together, it cannot be guaranteed that calling back to position B will ensure normal execution when Port2 is in port 2.

[0013] Therefore, in the MEP scenario, existing technologies have the following problems: Single execution stack limitation: Traditional Java or Native cards use a single-threaded model, where all profiles share the same execution stack. When multiple profiles enter the STK session simultaneously, the execution stack can be overwritten, leading to session corruption or data loss.

[0014] Missing context isolation: If Profile A is switched to Profile B in the STK session, the register state and local variables of Profile A are not saved, and the original process cannot continue when restoring.

[0015] Terminal command conflict: The terminal may dynamically switch the current interactive profile through the MANAGE LSI command. If the STK session of the original profile is not completed when switching, it will cause response loss or service interruption. Summary of the Invention

[0016] To address the various shortcomings of existing technologies, this invention provides a method for proactive command processing of UICC applications in ESIM scenarios with concurrent activation of multiple files. By allocating an independent execution stack for each Profile and combining setjmp / longjmp to achieve cross-Profile context saving and restoration, the problem of STK session conflict in MEP scenarios is solved.

[0017] The present invention achieves the above objectives through the following technical solutions: A method for handling proactive commands in UICC applications under concurrent activation scenarios of multiple files in ESIM, including: Each active port is defined and allocated an independent stack space in memory to ensure that each UICC application session has an independent execution environment during execution. Based on the processing power and resource limitations of the chip used, determine and configure the maximum number of ports that the system can simultaneously activate during the compilation phase, i.e., how many configuration files to activate at the same time; During system operation, the received MANAGE LSI instructions are monitored and parsed in real time. Based on the port identifier specified in the instruction, the current port for interaction with the terminal is dynamically switched, and the execution context is switched to the stack space of the corresponding port to continue executing the UICC application session of the current configuration file. Use the setjmp / longjmp mechanism or equivalent assembly jump method to save the session state of the current port when a port switch is needed, and restore its session state after jumping to the target port.

[0018] According to the present invention, a method for handling proactive commands of UICC applications in a multi-file concurrent activation scenario in ESIM is provided. When a terminal command is received, the JCRE performs command parsing and distribution. If the currently activated application is a UICC application, the command is directly dispatched to the UICC session process corresponding to the currently selected port for processing. At the UICC session entry point of each port, the stack pointer, register state and context information of the current UICC session are saved by calling the setjmp(UICC_Main_Env) mechanism. UICC_Main_Env is a UICC jump buffer used to store the state data of the UICC session entry point. During UICC session processing, if a MANAGE LSI instruction is received, the stack space and register state corresponding to the target port are restored through the longjmp(UICC_Main_Env, Port) mechanism according to the new port identifier specified in the instruction, and execution is then jumped to the UICC session entry point of the target port to continue execution; where Port is the port.

[0019] According to the present invention, a UICC application proactive command processing method in a multi-file concurrent activation scenario in ESIM is provided. When a terminal instruction or internal trigger event is received, the current port status flag is first checked. If the status flag indicates that the current port is in the STK session processing flow, it is determined to be in the STK state; otherwise, it is determined to be in the non-STK state. When it is determined that the current port is in STK state, it indicates that a MANAGE LSI instruction was previously executed to switch to another port, and the STK session context of the original port needs to be restored. At this time, by calling the longjmp(UICC_PortX_STK, PortX) mechanism, execution is directly jumped to the entry point where the current port last issued an active command to continue execution. Here, UICC_PortX_STK is the STK session context snapshot buffer, and PortX is the identifier of the current port. When it is determined that the current port is not in the STK state, the stack management module switches the system execution context from the main stack to the top of the current port's independent stack space; then the UICC instruction flow processing function is called to start processing the currently received terminal instructions or internal events.

[0020] According to the present invention, a method for proactive command processing of UICC applications in a multi-file concurrent activation scenario in ESIM is provided. In UICC session management, an independent UICC application main loop is designed for each port. This main loop adopts a blocking I / O or event-driven mode, continuously listening to and processing terminal commands or internal events until a preset exit condition is met. The exit condition includes: Received an A4 command from the terminal, with the command parameter being the AID of another application; Received a 70 command from the terminal with the command parameter being a request to open a new logical channel; In the main loop of the UICC application, after each execution of the current instruction, it checks whether the exit condition is met; if it is met, it saves the execution context data of the current port to an independent buffer by calling the context switching interface, and jumps to the command dispatch module of JCRE. After receiving a redirect request from the UICC application, JCRE performs the corresponding operation based on the instruction type and parameters: If it is an A4 instruction, the target application is located based on the AID, and the instruction is dispatched to the target application for processing; If it is instruction 70, then the process of opening the new logical channel will be executed, and the operation result will be returned; After the target application or logical channel operation is completed, JCRE returns control to the UICC application main loop entry point of the original port based on the original port identifier and restores its execution context.

[0021] According to the present invention, a method for proactively processing UICC applications in a multi-file concurrent activation scenario in ESIM is provided. In the main loop of the UICC application on each port, the received terminal instructions are parsed to determine whether they conform to the instruction format defined in the specification. If they do, the corresponding instruction processing function is called to perform the operation, which includes at least security access control, file management operation, logical channel management, and Toolkit application triggering. During instruction execution, it checks whether the conditions for generating proactive commands are triggered, including at least SMS sending requests, proactive notifications initiated by the Toolkit application through the UICC API interface, and proactive operations triggered by timers or events. If an active command is detected, a 91XX status word containing the command data is constructed, and the current instruction processing flow is paused, waiting for the terminal to obtain the active command data through the FETCH instruction, where XX is the data length field; If no proactive command is triggered during instruction execution, a standard status word is directly constructed, and response data can be optionally carried and returned to the caller through the terminal interface; After sending the 91XX status word, the UICC instruction processing flow of the current port is frozen until the corresponding FETCH instruction sent by the terminal is received. After the active command data transmission is completed, the terminal processing result is received through the TERMINAL RESPONSE instruction, and the result determines whether to continue executing the original instruction flow or jump to the error handling branch.

[0022] According to the present invention, a method for proactive command processing of UICC applications in a multi-file concurrent activation scenario in ESIM is provided, which allocates an independent context saving area for each port's STK session, and saves the current port's execution state by calling the setjmp mechanism when entering the STK session, including at least: Stack pointer SP, program counter PC, register set; The current intermediate state of the instruction; Proactive commands handle related temporary variables; The saved context data is stored in the UICC_PortX_STK array; If a MANAGE LSI command is received during STK session execution requesting a switch to another port, the following operations are performed: The longjmp mechanism is used to jump to the main processing flow entry point of the target port. Mark the STK context of the current port as suspended and retain its UICC_PortX_STK data; If the STK session is not active on the target port, the command is executed normally; if it is necessary to enter the STK session, the setjmp mechanism is called repeatedly to save the new state. When the terminal returns the TERMINAL RESPONSE command, the system locates the context data of the corresponding UICC_PortX_STK array based on the port identifier carried in the response information, and restores the STK session of the port through the longjmp mechanism, and continues to perform the following operations: Transmit the terminal response data to the application that initiates the proactive command; Update the session state based on the application processing results; If an active command needs to be sent, the 91XX status word is reconstructed and the terminal FETCH instruction is awaited.

[0023] According to the present invention, a method for handling proactive commands in UICC applications during concurrent activation of multiple files in ESIM, if an asynchronous command not directly related to STK is received during the execution of the STK session, the following operations are performed: Interrupt the current STK session processing flow: Save the current STK session context data to the UICC_PortX_STK array by calling the setjmp mechanism; Command dispatch and processing: Dispatch asynchronous instructions to JCRE or other instruction processing modules to perform application selection or logical channel opening operations; Resume STK session: After the asynchronous instruction is processed, the STK context of the original port is restored through the longjmp mechanism to continue the interrupted STK session processing flow; If a MANAGE LSI command is received during STK session execution requesting a switch to another port, the following operations are performed: Save the current STK context: Save the STK session state of the current port to the UICC_PortX_STK array; Jump to UICC entry point: Return to the system's main entry point via the longjmp(UICC_Main_Env, Port) mechanism and switch to the context environment of the target port; If it is necessary to enter the STK session in the target port, the setjmp mechanism is called again to save the new state; if it is not necessary to enter the STK session, the normal UICC instruction flow continues to be executed.

[0024] According to the UICC application proactive command processing method in a multi-file concurrent activation scenario in ESIM provided by the present invention, if a FETCH or TERMINAL RESPONSE instruction sent by the terminal is received during the STK session execution, the following operations are performed: Instruction parsing and matching: Locate the context data of the corresponding UICC_PortX_STK array based on the port identifier in the instruction; FETCH instruction processing: If it is a FETCH instruction, the active command data to be sent is extracted from the context data and returned through the terminal interface; TERMINAL RESPONSE instruction processing: If it is a TERMINAL RESPONSE instruction, the response data is passed to the application that initiated the proactive command, and the status word returned by the application is checked. If the status word is 9000, the current STK session is marked as ended, and the UICC instruction processing flow is restored through the longjmp mechanism; If the status word is not 9000, then the system will decide whether to retry, terminate the session, or jump to the error handling branch based on the error type.

[0025] According to the present invention, a method for handling proactive commands in UICC applications under multi-file concurrent activation scenarios in ESIM is provided. When an asynchronous command is received during STK session execution, the following operations are performed: Channel application type determination steps: Query the application identifier associated with the current logical channel to determine whether the target application is a UICC application; If the target application is a non-UICC application, then perform the non-UICC application processing steps. If the target application is a UICC application, then execute the UICC application processing steps; Non-UICC application processing steps: The asynchronous instruction is encapsulated into a standard APDU format and forwarded to the target non-UICC application through the terminal interface; After dispatching the instruction, start a timeout timer and wait for the application's response; If the application returns the execution result before the timeout, the STC context of the original port is restored through the longjmp mechanism, and the STK session processing flow continues. If the application times out or returns an error status word, the current STK session is terminated, the error log is logged, and the process returns to the UICC instruction handling flow.

[0026] UICC application processing steps: If the target application is a UICC application, then the instruction processing function conforming to the ts_102221 / ts_102222 / ts_102223 specification is called directly; If a new proactive command is triggered during instruction execution, update the 91XX status word and the data to be sent in the UICC_PortX_STK array; If the command requires a terminal response, the current STK session state is preserved and the system waits for terminal interaction. If the instruction is executed and no further terminal interaction is required, the current STK session is marked as ready to exit. Upon receiving the TERMINAL RESPONSE instruction, the UICC instruction processing flow is returned via the longjmp mechanism. If the command requires continuous interaction, keep the STK session active.

[0027] According to the present invention, in the scenario of concurrent activation of multiple files in ESIM, the UICC application proactive command processing method is provided. When an A4 instruction or a 70 instruction is received during the execution of the STK session, the system determines that the current STK session processing flow is asynchronously interrupted. At this time, the complete execution context data of the current port is saved to the corresponding UICC_PortX_STK array through the setjmp mechanism, and the current port is marked as being in the STK suspended-waiting dispatch state. Based on the judgment logic of the channel application type determination step, the received instructions are dispatched to the target application for processing; during the dispatching period, the STK session logic of the current port is frozen, and the system switches to the execution environment of the target application or the scheduling environment of JCRE to execute the instructions. After the target application finishes execution and returns a result, the system restores the context data stored in the UICC_PortX_STK array using the longjmp mechanism and identifies the STK suspended-waiting-for-dispatch status flag. At this point, instead of exiting the STK session, the system jumps directly back to the instruction receive loop entry point of the STK session and performs the following operations: Reset APDU receive buffer: Clear the temporary data area and prepare to receive new terminal commands; Restore terminal interaction state: If the current state is waiting for FETCH or TERMINAL RESPONSE instruction, re-enable the corresponding interaction timeout timer. Continuous listening and processing: The instruction processing loop that re-enters the STK session continues to wait for and parse the next APDU instruction sent by the terminal until an explicit STK end instruction is received or the defined exit conditions are met. Therefore, compared with the prior art, the UICC application proactive command processing method proposed in this invention for multi-file concurrent activation scenarios in ESIM has the following beneficial effects: 1. In traditional solutions, multiple profiles share the same execution stack. When the STK session of Profile A is interrupted by a terminal instruction and switched to Profile B, the stack data of Profile A will be overwritten, resulting in unrecoverable sessions or data loss. This invention provides each Profile with its own independent stack space, avoiding data overwriting between multiple sessions. By using `setjmp` to save the register state and stack pointer at the STK session entry point, even if the session is interrupted, `longjmp` can restore it to its precise state before the interruption. When the terminal switches profiles via MANAGE LSI, the system uses `longjmp` to freeze the current Profile's context and load the target Profile's stack and register state, achieving seamless switching.

[0028] 2. In an STK session, the terminal may insert other commands. Traditional solutions require forcibly ending the current STK session to handle asynchronous commands, resulting in a poor user experience. This invention, upon receiving an asynchronous command, saves the current STK session context using `setjmp`, and restores the original session using `longjmp` after processing the asynchronous command, without the user noticing. This invention allows STK sessions and asynchronous commands (such as downstream SMS messages and HTTPS requests) to execute in parallel, improving device response speed.

[0029] 3. Traditional solutions rely on the terminal to send instructions strictly in sequence. If the terminal behaves abnormally, it can easily lead to card crashes. This invention uses an independent execution stack and context snapshot. Even if the terminal instructions are out of order, the card can still distinguish the source of the instructions through status codes and drive the JCRE to perform differentiated processing. This invention complies with the requirements of international standards such as TS 102 221 for MANAGE LSI and STK sessions and does not require terminal adaptation.

[0030] 4. Traditional solutions require a fixed stack size during compilation, making it impossible to dynamically adjust the number of supported profiles, thus limiting device flexibility. This invention defines the maximum number of ports (e.g., supporting 4 profiles) during the compilation phase based on chip capabilities, with each port's stack space allocated independently. Profiles are dynamically activated / deactivated through a port manager; unused profiles do not occupy stack resources, optimizing memory utilization.

[0031] 5. Existing shared stacks can easily lead to malicious applications overwriting data (such as return addresses) of other profiles via stack overflows, causing security vulnerabilities. This invention allocates stacks independently for each profile, preventing malicious applications from tampering with data across profiles. `setjmp` / `longjmp` are implemented through hardware register operations, avoiding the risk of stack pointer tampering at the software level.

[0032] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments. Attached Figure Description

[0033] Figure 1 This is the STK interaction flowchart for a single UICC in the existing technology.

[0034] Figure 2 This is a flowchart of UICC operation and management for multiple ports in existing technologies.

[0035] Figure 3 This is a flowchart of an embodiment of the UICC application proactive command processing method in a multi-file concurrent activation scenario in ESIM according to the present invention.

[0036] Figure 4 This is a diagram illustrating the implementation steps of an embodiment of the UICC application proactive command processing method in a multi-file concurrent activation scenario in ESIM according to the present invention.

[0037] Figure 5 This is a flowchart illustrating the UICC instruction processing flow and STK instruction processing flow in an embodiment of the UICC application proactive command processing method in a multi-file concurrent activation scenario of the present invention.

[0038] Figure 6 This is a schematic diagram illustrating the JCRE instruction parsing and distribution, as well as the port switching mechanism of setjmp / longjmp, in an embodiment of the UICC application proactive command processing method in a multi-file concurrent activation scenario of the present invention.

[0039] Figure 7 This is a schematic diagram of the port main loop in UICC session management in an embodiment of the UICC application proactive command processing method in a multi-file concurrent activation scenario of the present invention.

[0040] Figure 8 This is a schematic diagram illustrating the principle of context saving and restoration in STK session management in an embodiment of the UICC application proactive command processing method in a multi-file concurrent activation scenario of the present invention.

[0041] Figure 9This is a schematic diagram of an embodiment of the device for processing UICC application proactive commands when multiple ESIM profiles are activated simultaneously, according to the present invention. Detailed Implementation

[0042] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0043] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0044] ESIM (Embedded SIM): An embedded SIM card (eSIM) is a technology that integrates a traditional pluggable SIM card chip directly into the device's motherboard. It supports dynamic writing of operator profiles via over-the-air (OTA) updates, enabling network switching without physically replacing the SIM card. The core scenario in this embodiment is a multi-profile concurrently active eSIM, i.e., a MEP device, which resolves STK session conflicts between multiple profiles through independent execution stacks. Compared to traditional single-profile eSIMs, this embodiment supports running multiple independent operator profiles simultaneously on a single eUICC card, such as for mobile networks and IoT networks.

[0045] Profile: A profile is a collection of operator data stored in the eSIM, containing network parameters such as IMSI, key, and APN, defining the device's identity and permissions for accessing a specific network. This embodiment allows multiple profiles (such as Profile A and Profile B) to be active simultaneously on a single eUICC card, with each profile running an independent STK session. By allocating an independent execution stack (such as G_Stack_Port1, G_Stack_Port2) to each profile, data cross-contamination is avoided, ensuring service continuity during network switching.

[0046] Port: A port is a logical concept that refers to the execution context corresponding to an independently running profile, including stack space, register state, etc. Each port corresponds to an active profile and is the basic unit of system scheduling and resource allocation. One port is equivalent to one active profile and one independent execution stack. For example, Port1 corresponds to the stack of ProfileA. The MANAGE LSI instruction switches the currently interacting port, that is, switches which profile the terminal is communicating with.

[0047] The setjmp mechanism saves the current program execution environment (such as program counter PC, stack pointer SP, register state, etc.) to a buffer (jmp_buf).

[0048] The longjmp mechanism restores the previously saved execution environment from the buffer, jumps back to the setjmp call point, and continues execution.

[0049] UICC (Universal Integrated Circuit Card): A universal integrated circuit card, also known as a physical SIM card or an embedded eSIM chip, is a carrier for storing User Identity Module (USIM) application and operator data.

[0050] STK (SIM Toolkit): The SIM toolkit is a set of instructions stored in the UICC that allows operators to proactively push services to users via SMS or menus, such as bank transaction confirmations and menu navigation.

[0051] See Figure 3 and Figure 4 This embodiment provides a method for handling proactive commands of UICC applications in a multi-file concurrent activation scenario in ESIM, including the following steps: Step S1: Define and allocate an independent stack space in memory for each activated port to ensure that each UICC application session has an independent execution environment during execution and avoid session interference between different profiles; Step S2: Based on the processing power and resource limitations of the chip used, determine and configure the maximum number of ports that the system can simultaneously activate during the compilation stage, i.e. how many profiles can be activated at the same time. Step S3: During system operation, monitor and parse the received MANAGE LSI instructions in real time, dynamically switch the port currently interacting with the terminal according to the port identifier specified in the instructions, and switch the execution context to the independent stack space of the corresponding port to continue executing the UICC application session of the current profile. Step S4: Use the setjmp / longjmp mechanism or an equivalent assembly jump method to save the session state of the current port when a port switch is required, and restore its session state after jumping to the target port, thereby achieving fast and safe jump between ports and ensuring the independence and integrity of each profile session.

[0052] like Figure 6 As shown, when a terminal instruction is received, the JCRE (Java Card Runtime Environment) parses and distributes the instruction; if the currently active application is a UICC application, the instruction is directly dispatched to the UICC session process corresponding to the currently selected port for processing. At the UICC session entry point of each port, the stack pointer, register state and context information of the current UICC session are saved by calling the setjmp(UICC_Main_Env) mechanism. UICC_Main_Env is a predefined UICC jump buffer used to store the state data of the UICC session entry point. During UICC session processing, if a MANAGE LSI instruction is received, the stack space and register state corresponding to the target port are restored using the longjmp(UICC_Main_Env, Port) mechanism according to the new port identifier specified in the instruction, and execution is then redirected to the UICC session entry point of the target port to continue execution; at the same time, the session state of the current port is fully saved for subsequent recovery processing. By allocating independent stack space and state saving buffers to each port, it is ensured that when switching ports, the UICC session context of the original port (including stack pointer, register values, temporary variables, etc.) will not be overwritten or interfered with by the session operations of the new port, thereby maintaining the independence of sessions and data security between ports.

[0053] As can be seen, this embodiment further optimizes the JCRE instruction dispatch logic, the UICC entry state saving mechanism, and the Port dynamic switching method based on setjmp / longjmp, strengthening the technical protection of context isolation when multiple profiles are executed concurrently.

[0054] Upon receiving a terminal command or an internal trigger event, the current port's status flag is checked first. If the status flag indicates that the current port is in the STK (SIM Toolkit) session processing flow, it is determined to be in the STK state; otherwise, it is determined to be in the non-STK state. When it is determined that the current port is in STK state, it indicates that a MANAGE LSI instruction was previously executed to switch to another port, and the STK session context of the original port needs to be restored. At this time, by calling the longjmp(UICC_PortX_STK, PortX) mechanism, execution is directly jumped to the entry point where the current port last issued an active command to continue execution. Here, UICC_PortX_STK is the STK session context snapshot buffer, and PortX is the identifier of the current port. At the same time, it is ensured that the stack pointer, register state, and temporary data of the original port are completely restored during the jump process. When it is determined that the current port is not in the STK state, the stack management module switches the system execution context from the main stack to the top of the current port's independent stack space; then the UICC instruction flow processing function is called to start processing the currently received terminal instructions or internal events; When the port status changes, such as entering or exiting an STK session, or executing the MANAGE LSI command to switch ports, the status flag of the current port is updated synchronously; this ensures the accuracy of status judgment during subsequent command processing, thereby guaranteeing session independence and context continuity when multiple ports are executed concurrently.

[0055] As can be seen, by dynamically updating the status flag, the system can accurately respond to MANAGE LSI commands or proactive command events, thus achieving efficient and secure switching between ports.

[0056] like Figure 7 As shown, in UICC session management, an independent UICC application main loop is designed for each port. This main loop adopts a blocking I / O or event-driven mode, continuously listening for and processing terminal commands or internal events until a preset exit condition is met. The exit condition includes: Received an A4 command sent by the terminal, with the command parameter being the AID (ApplicationIdentifier) ​​of another application. Received a 70 command from the terminal with the command parameter being a request to open a new logical channel; In the main loop of the UICC application, after each instruction is executed, it checks whether the exit condition is met. If it is met, the execution context of the current port (including stack pointer, register state, temporary variables, etc.) is saved to an independent buffer by calling the context switching interface, and then the execution context of the current port is jumped to the command dispatch module of JCRE. After receiving a redirect request from the UICC application, JCRE performs the corresponding operation based on the instruction type (A4 or 70) and parameters: If it is an A4 instruction, the target application is located based on the AID, and the instruction is dispatched to the target application for processing; If it is instruction 70, then the process of opening the new logical channel will be executed, and the operation result will be returned; After the target application or logical channel operation is completed, JCRE returns control to the UICC application main loop entry point of the original port based on the original port identifier and restores its execution context. When jumping to JCRE or returning to the UICC instruction processing flow, the stack space and register state of the current port are not modified by other ports or system processes through hardware-supported stack isolation mechanisms or software-implemented context save / restore protocols, thereby maintaining data security and session continuity when multiple profiles are executed concurrently.

[0057] It is evident that the context saving and restoration design ensures that the session state of multiple profiles is not disrupted when processing A4 or 70 instructions, while simultaneously meeting the functional requirements of smart card systems for application switching and logical channel management.

[0058] In the main loop of the UICC application on each port, the received terminal instructions are parsed to determine whether they conform to the instruction formats defined by ETSI TS 102 221, TS 102 222, TS 102 223, etc. If they conform, the corresponding instruction processing function is called to perform the operation, including but not limited to: Secure access control, such as VERIFY PIN and CHANGE PIN; File management operations, such as SELECT FILE, READ BINARY, UPDATE BINARY; Logical channel management, such as OPEN CHANNEL and CLOSE CHANNEL; Toolkit applications trigger commands such as ENVELOPE, FETCH, and TERMINAL RESPONSE. During instruction execution, it checks whether the conditions for generating a proactive command are triggered, including but not limited to: SMS sending request, such as SEND SMS; Toolkit applications initiate proactive notifications through the UICC API interface, such as Display Text and Get Inkey; Active operations triggered by timers or events; If an active command is detected, a 91XX status word containing command data is constructed, where XX is the length field of subsequent data, and the current instruction processing flow is paused, waiting for the terminal to obtain the active command data through the FETCH instruction; If no active command is triggered during the execution of the instruction, a standard status word is directly constructed, such as 9000 to indicate success, or an error code such as 6XXX to indicate failure. Response data, such as file read results or logical channel identifiers, can be carried and returned to the caller through the terminal interface. After sending the 91XX status word, the UICC instruction processing flow of the current port is frozen until the corresponding FETCH instruction sent by the terminal is received; after the active command data transmission is completed, the terminal processing result is received through the TERMINAL RESPONSE instruction, and the result determines whether to continue executing the original instruction flow or jump to the error handling branch. By designing instruction processing functions in a modular fashion, it supports dynamic expansion of instructions defined by different ETSI specifications (such as TS 102 221 / 222 / 223); at the same time, it ensures that the generation logic of proactive commands and the terminal interaction process comply with the technical requirements of standards organizations such as 3GPP and GSMA.

[0059] As can be seen, this embodiment ensures that the present invention is compatible with various terminals and application scenarios in the existing smart card ecosystem by supporting multiple standard instruction sets and standardized status word feedback, while also meeting the proactive notification requirements when multiple profiles are executed concurrently.

[0060] In this embodiment, as Figure 8 As shown, an independent context saving area is allocated for each port's STK session. Upon entering an STK session, the execution state of the current port is saved by calling the setjmp mechanism (or an equivalent hardware / software context saving interface), including but not limited to: Stack pointer SP, program counter PC, register set (such as R0-R15); The intermediate state of the current instruction, such as buffer data and loop counter; Temporary variables related to proactive command processing, such as the 91XX status word to be sent and the terminal response wait flag; The saved context data is stored in a pre-allocated UICC_PortX_STK array, where X is the port identifier, and the number of arrays is consistent with the maximum number of ports supported by the system. If a MANAGE LSI command is received during STK session execution requesting a switch to another port, the following operations are performed: Jump to the main processing flow entry point of the target port using the longjmp mechanism (or an equivalent context recovery interface); Mark the STK context of the current port as suspended and retain its UICC_PortX_STK data; If the STK session is not active on the target port, the command is executed normally; if it is necessary to enter the STK session, the setjmp mechanism is called repeatedly to save the new state. When the terminal returns the TERMINAL RESPONSE instruction (instruction 0x14), the system locates the context data of the corresponding UICC_PortX_STK array based on the port identifier carried in the response information, and restores the STK session of the port through the longjmp mechanism, and continues to perform the following operations: Transmit the terminal response data to the application that initiates the proactive command; Update the session state based on the application processing results (e.g., end the STK session or continue waiting for new instructions). If a subsequent proactive command needs to be sent, the 91XX status word is reconstructed and the terminal FETCH command is awaited. The following measures are taken to ensure the security of STK context switching: Hardware-level stack isolation: Utilize the chip's memory protection unit (MPU) or secure enclave to allocate independent storage space for the STK context of each port; Software locking mechanism: Locking is applied when accessing the UICC_PortX_STK array to prevent data races caused by concurrent modifications from multiple ports; State consistency verification: Before restoring the context, verify the validity of critical data such as stack pointers and registers to avoid execution flow abnormalities due to data corruption.

[0061] As can be seen, by using setjmp / longjmp to save and restore the state during cross-port jumps, and by introducing security measures such as hardware isolation and software locks, the independence of the STK session, the accuracy of terminal response, and the overall robustness of the system are ensured when multiple profiles are executed concurrently. This can effectively solve the session chaos problem caused by multiple profile switching under the traditional single-stack architecture and meet the high reliability requirements of smart cards in complex communication scenarios.

[0062] During STK session execution, if an asynchronous instruction not directly related to STK is received, such as A4 selecting another application's AID or 70 opening a new logical channel, the following operations are performed: Interrupt the current STK session processing flow: Save the current STK session's context data (including stack pointer, register state, and proactive command processing progress) to the UICC_PortX_STK array by calling the setjmp mechanism; Command dispatch and processing: Dispatch asynchronous instructions to JCRE or other instruction processing modules to perform application selection or logical channel opening operations; Resume STK session: After the asynchronous instruction is processed, the STK context of the original port is restored through the longjmp mechanism to continue the interrupted STK session processing flow, such as waiting for the terminal FETCH instruction or sending subsequent proactive commands.

[0063] If a MANAGE LSI command is received during STK session execution requesting a switch to another port, the following operations are performed: Save the current STK context: Save the STK session state of the current port (including incomplete proactive commands and terminal response wait flags) to the UICC_PortX_STK array; Jump to UICC entry point: Return to the system's main entry point via the longjmp(UICC_Main_Env, Port) mechanism and switch to the context environment of the target port; If it is necessary to enter the STK session in the target port, the setjmp mechanism is called again to save the new state; if it is not necessary to enter the STK session, the normal UICC instruction flow continues to be executed.

[0064] If a FETCH (0x12) or TERMINAL RESPONSE instruction (0x14) is received from the terminal during STK session execution, the following operations are performed: Instruction parsing and matching: Locate the context data of the corresponding UICC_PortX_STK array based on the port identifier in the instruction; FETCH instruction processing: If it is a FETCH instruction, the active command data to be sent is extracted from the context data and returned through the terminal interface; TERMINAL RESPONSE instruction processing: If it is a TERMINAL RESPONSE instruction, the response data is passed to the application that initiated the proactive command, and the status word returned by the application is checked. If the status word is 9000 (success), the current STK session is marked as ended, and the UICC instruction processing flow is restored through the longjmp mechanism; If the status word is not 9000 (error), then the system will decide whether to retry, terminate the session, or jump to the error handling branch based on the error type.

[0065] If the received instruction is neither MANAGE LSI nor 12 / 14, then perform the following operation: Command classification and judgment: Call the corresponding processing function according to the command type (such as secure access, file management, toolkit trigger, etc.); STK session state synchronization: If a new proactive command (such as SEND SMS) is triggered during the execution of the instruction, the 91XX status word and the data to be sent in the context data of the UICC_PortX_STK array are updated; Continue or exit STK: The decision to remain in the STK session (e.g., waiting for a terminal response) or exit directly (e.g., when a normal file has been read) is based on the result of the command execution.

[0066] It is evident that by using setjmp / longjmp to flexibly save and restore the context, and defining standardized processing procedures for different instruction types, the continuity of STK sessions, the accuracy of terminal responses, and the effective utilization of system resources in multi-profile concurrent environments can be ensured, which can significantly improve the interaction efficiency and reliability of smart cards in complex communication scenarios.

[0067] When an asynchronous instruction is received during STK session execution (such as A4 selecting another application's AID or 70 opening a new logical channel), perform the following operations: Channel application type determination steps: Query the application identifier (AID) associated with the current logical channel to determine whether the target application is a UICC application, such as a SIM Toolkit application that conforms to the ts_102221 / ts_102222 / ts_102223 specification definition. If the target application is a non-UICC application, such as a third-party Java Card application or a payment application, then the non-UICC application processing steps will be executed. If the target application is a UICC application, then the UICC application processing steps are executed.

[0068] Non-UICC application processing steps: The asynchronous instructions are encapsulated in the standard APDU (Application Protocol Data Unit) format and forwarded to the target non-UICC application through the terminal interface; After dispatching the instruction, start a timeout timer and wait for the application's response; If the application returns an execution result (such as status word 9000) before the timeout, the original port's STC context is restored through the longjmp mechanism, loaded from the UICC_PortX_STK array, and the STK session processing flow continues, such as waiting for the terminal FETCH command. If the application times out or returns an error status word (other than 9000), the current STK session is terminated, the error log is logged, and the process returns to the UICC instruction handling flow.

[0069] UICC application processing steps: If the target application is a UICC application, then the instruction processing function conforming to the ts_102221 / ts_102222 / ts_102223 specification is called directly, such as PROCESS TOOLKIT and SEND DATA; If a new proactive command is triggered during the execution of the instruction, such as DISPLAY TEXT or GET INPUT, then update the 91XX status word and the data to be sent in the UICC_PortX_STK array. If the command requires a terminal response (such as FETCH), then retain the current STK session state and wait for terminal interaction; If the instruction is executed and no further terminal interaction is required (such as ordinary file operation), the current STK session is marked as ready to exit. After receiving the TERMINAL RESPONSE instruction (0x14), the UICC instruction processing flow is returned through the longjmp mechanism. If the command requires continuous interaction (such as multiple rounds of GET INPUT), then keep the STK session active.

[0070] As can be seen, this embodiment achieves precise instruction dispatch and secure context switching by distinguishing between target application types (UICC and non-UICC). Non-UICC application scenarios: Ensure that STK session state is not lost during the execution of third-party applications, and ensure system robustness through timeout control and state recovery mechanisms; UICC application scenarios: Directly invoke standardized instruction processing flow and dynamically update STK context to avoid proactive command interruption or data inconsistency caused by application switching.

[0071] Furthermore, this embodiment is strictly compatible with international standards such as TS_102221 / TS_102222 / TS_102223, and can effectively support the complex business logic of smart cards in multi-profile concurrent environments.

[0072] When an A4 instruction (select application) or a 70 instruction (open logical channel) is received during the execution of an STK session, the system determines that the current STK session processing flow has been asynchronously interrupted. At this time, the complete execution context data of the current port (including program counter PC, stack pointer SP, register set R0-R15, command progress flag of the current STK session, and the constructed 91XX status word buffer) is saved to the corresponding UICC_PortX_STK array through the setjmp mechanism, and the current port is marked as being in the STK suspended-waiting-for-dispatch state. Based on the judgment logic of the channel application type determination step, the received instructions are dispatched to the target application (UICC application or non-UICC application) for processing; during the dispatching period, the STK session logic of the current port is frozen, and the system switches to the execution environment of the target application or the scheduling environment of JCRE to execute the instructions. After the target application finishes execution and returns a result, the system restores the context data stored in the UICC_PortX_STK array using the longjmp mechanism and identifies the STK suspended-waiting-for-dispatch status flag. At this point, instead of exiting the STK session, the system jumps directly back to the instruction receive loop entry point of the STK session and performs the following operations: Reset APDU receive buffer: Clear the temporary data area and prepare to receive new terminal commands; Restore terminal interaction state: If the current state is waiting for FETCH or TERMINAL RESPONSE instruction, re-enable the corresponding interaction timeout timer. Continuous listening and processing: The instruction processing loop that re-enters the STK session continues to wait for and parse the next APDU instruction sent by the terminal until an explicit STK end instruction is received or the exit conditions defined above are met (such as receiving instruction 14 and the status word is 9000).

[0073] After restoring the STK session, the system maintains the original logical channel connection state and proactive command context to ensure that subsequent received APDU commands can continue to be executed based on the STK business logic before the interruption, thus avoiding abnormal termination of the STK session or disconnection of the data link due to asynchronous command dispatch.

[0074] It is evident that by accurately marking the state and restoring the context, the technical problem that traditional smart cards often cause the STK session to be forcibly terminated after processing asynchronous instructions during the STK process has been solved. This enables seamless interleaving and continuous execution of the STK session and the ordinary APDU instruction processing flow, greatly improving the business processing capabilities and user experience in multi-profile concurrent scenarios.

[0075] In practical applications, the code for UICC instruction processing flow and STK instruction processing flow is the same, such as... Figure 5 As shown, Figure 5 To demonstrate the simultaneous activation of two ports in the call relationship, the port will be referred to as "Port" below. This indicates that Port is the specific implementation carrier of Profile in the system. Port directly corresponds to the independent execution environment of Profile, and the specific implementation includes the following steps: Step S10: JCRE command dispatch. If the current application is UICC, the command is dispatched to the UICC application for processing.

[0076] Step S11: Save information such as the UICC entry point stack and registers. In order to handle the newly selected Port when the STK session is initiated by the MANAGE LSI instruction, such as by saving the entry point state through setjmp(UICC_Main_Env).

[0077] Step S12: The currently selected port, subsequent instructions need to be dispatched to this selected port, i.e., UICC.

[0078] Step S13: Port status determination. If it is in STK, it means that the MANAGE LSI instruction was executed in STK last time and switched to another port. When entering again, it is necessary to jump directly to the entry point where the active command was issued last time, such as longjmp(UICC_Port1_STK, Port1); if it is not in STK, it is directly switched from the main stack to the top of the Port1 stack and the UICC instruction flow processing function is called.

[0079] Step S14: UICC processing flow is an infinite loop process (the exit condition is A4 selecting another application or 70 opening a new logical channel). If the AID of A4 selecting another application or 70 opening a new logical channel is received during this process, it is necessary to jump back to JCRE to dispatch commands.

[0080] Step S15: UICC instruction processing, including instructions defined by the specification such as ts_102221 / ts_102222 / ts_102223, including triggering Toolkit applications.

[0081] Step S16: During the processing of step S15, was any proactive command generated, including SMS messages, application calls to the UICC API, etc., requiring a 91XX status word response to the terminal? If not, the instruction processing is complete, and a status word is directly returned to the terminal.

[0082] Step S17: Save the Port STK entry state. For example, for Port1, use `setjmp(UICC_Port1_STK)`, and for Port2, use `setjmp(UICC_Port2_STK)`. The number of STK state saving arrays corresponds to the number of supported Ports. This is to ensure that after receiving a Port switching command in the STK and exiting the STK, the process can jump back to continue. It also ensures that after the proactive command is processed, the terminal 14 response can correctly return to the application, and then proceed with subsequent business operations.

[0083] Step S18: Since STK is a process, other instructions can be interspersed in between. If A4 selects another application's AID or 70 opens a new logical channel at this time, command dispatch needs to be invoked. After dispatch processing is completed, the process continues back to STK.

[0084] Step S19: If it's a MANAGE LSI switch to a new Port, then it needs to jump back to the UICC entry point, return via longjmp(UICC_Main_Env, Port), and enter the new Port to process subsequent instructions. If the received instruction is 12 / 14, perform FETCH and TERMINAL RESPONSE processing. If it's neither an LSI nor a 12 / 14 instruction, further judgment and processing are required.

[0085] Step S110: If 12 / 14 has been completed, that is, the application returns a status word of 9000 after UICC receives TERMINAL RESPONSE, then exit STK and fall back to UICC instruction flow processing.

[0086] Step S111: Because the process in step S18 may involve selecting other applications, it is necessary to determine whether the current channel's application is UICC. If it is not UICC, the instruction is dispatched to the application. After the application executes the instruction, it returns to the STK processing flow. If the current channel is UICC, the UICC instruction is called for processing. That is, the instructions defined in the specifications such as ts_102221 / ts_102222 / ts_102223 are used.

[0087] Step S112: When in STK, if A4 is received to select another application's AID or 70 to open a new logical channel, command dispatch is performed. After processing, it is necessary to return to the STK processing flow to continue receiving and processing APDU instructions.

[0088] Stack switching and function call examples / / Define the stack space for each Port (must be aligned and the space must be large enough) unsigned int G_Stack_Port1

[1024] ; unsigned int G_Stack_Port2

[1024] ; / / Define the stack top pointer (stacks typically grow downwards, so the stack top is the end of the array). unsigned int G_SP_Port1 =&G_Stack_Port1

[1023] ; unsigned int G_SP_Port2 =&G_Stack_Port2

[1023] ; / / Main processing function of Port1 void UICC_Main_1(void) { / / ... Logic for processing Profile 1... / / When it is necessary to switch to Port2: switch_stack_pointer(G_SP_Port2, UICC_Main_2); / / Note: Normally, the code will stop executing here. / / Because the stack has been swapped, unless we return from UICC_Main_2.

[0089] } / / Main processing function of Port2 void UICC_Main_2(void) { / / ... Logic for processing Profile 2... / / When it is necessary to switch back to Port1: switch_stack_pointer(G_SP_Port1, UICC_Main_1); } / / Example of calling void trigger_switch_to_port2(void) { / / R0 =&G_SP (Here it is assumed that G_SP currently points to the top of the stack of Port2) / / R1 = UICC_Main_2 switch_stack_pointer(&G_SP_Port2, UICC_Main_2); } The function example is as follows: It retrieves the stack address corresponding to the Port indicated by parameter R0, assigns it to SP, performs a stack switch, and then jumps to the address indicated by function entry (at this time, register R1 is the function address). That is, in step S13, stack switching and function calls are required to assign a separate stack to the currently selected Port. A new execution stack top is set for the current UICC_Main_2.

[0090] Therefore, this embodiment solves the STK session conflict problem when multiple profiles are concurrent by using the Port as a logical isolation unit and combining an independent execution stack and setjmp / longjmp context snapshots, which significantly improves the reliability and flexibility of eSIM in high-concurrency scenarios.

[0091] like Figure 9 As shown, this embodiment also provides an apparatus for processing UICC application proactive commands when multiple ESIM profiles are activated simultaneously, including: The stack management module is used to allocate and manage independent stack space for each active port; The instruction parsing module is used to parse received instructions, including MANAGE LSI instructions and other UICC-related instructions; The jump control module uses the setjmp / longjmp mechanism or equivalent assembly jump methods to achieve fast jumps between ports; The session processing module is used to execute UICC session flows in an independent stack space for each port, including handling proactive commands and interactions with other modules.

[0092] Furthermore, the stack management module is also responsible for allocating an independent memory region as its execution stack for each Profile that may be activated simultaneously during the system initialization phase, and saving the stack pointer and related register states of each Profile.

[0093] Furthermore, when implementing Profile jumps, the jump control module ensures that the session state of other Profiles is not disrupted during the jump process, thus maintaining the independence between sessions.

[0094] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0095] The above embodiments are merely preferred embodiments of the present invention and should not be construed as limiting the scope of protection of the present invention. Any non-substantial changes and substitutions made by those skilled in the art based on the present invention shall fall within the scope of protection claimed by the present invention.

Claims

1. A method for handling proactive commands in UICC applications under multi-file concurrent activation scenarios in ESIM, characterized in that, Includes the following steps: Each active port is defined and allocated an independent stack space in memory to ensure that each UICC application session has an independent execution environment during execution. Based on the processing power and resource limitations of the chip used, determine and configure the maximum number of ports that the system can simultaneously activate during the compilation phase, i.e., how many configuration files to activate at the same time; During system operation, the received MANAGE LSI instructions are monitored and parsed in real time. Based on the port identifier specified in the instruction, the current port for interaction with the terminal is dynamically switched, and the execution context is switched to the stack space of the corresponding port to continue executing the UICC application session of the current configuration file. Use the setjmp / longjmp mechanism or equivalent assembly jump method to save the session state of the current port when a port switch is needed, and restore the session state after jumping to the target port.

2. The method according to claim 1, characterized in that: Upon receiving a terminal instruction, the JCRE parses and distributes the instruction; if the currently active application is a UICC application, the instruction is directly dispatched to the UICC session process corresponding to the currently selected port for processing. At the UICC session entry point of each port, the stack pointer, register state and context information of the current UICC session are saved by calling the setjmp(UICC_Main_Env) mechanism. UICC_Main_Env is a UICC jump buffer used to store the state data of the UICC session entry point. During UICC session processing, if a MANAGE LSI instruction is received, the stack space and register state corresponding to the target port are restored through the longjmp(UICC_Main_Env, Port) mechanism according to the new port identifier specified in the instruction, and execution is then jumped to the UICC session entry point of the target port to continue execution; where Port is the port.

3. The method according to claim 1, characterized in that: Upon receiving a terminal command or an internal trigger event, the current port's status flag is checked first. If the status flag indicates that the current port is in the STK session processing flow, it is determined to be in the STK state; otherwise, it is determined to be in the non-STK state. When it is determined that the current port is in STK state, it indicates that a MANAGE LSI instruction was previously executed to switch to another port, and the STK session context of the original port needs to be restored. At this time, by calling the longjmp(UICC_PortX_STK, PortX) mechanism, execution is directly jumped to the entry point where the current port last issued an active command to continue execution. Here, UICC_PortX_STK is the STK session context snapshot buffer, and PortX is the identifier of the current port. When it is determined that the current port is not in the STK state, the stack management module switches the system execution context from the main stack to the top of the current port's independent stack space; then the UICC instruction flow processing function is called to start processing the currently received terminal instructions or internal events.

4. The method according to claim 3, characterized in that: In UICC session management, an independent UICC application main loop is designed for each port. This main loop adopts blocking I / O or event-driven mode, continuously listening to and processing terminal commands or internal events until the preset exit condition is met. Exit conditions include: Received an A4 command from the terminal, with the command parameter being the AID of another application; Received a 70 command from the terminal with the command parameter being a request to open a new logical channel; In the main loop of the UICC application, after each execution of the current instruction, it checks whether the exit condition is met; if it is met, it saves the execution context data of the current port to an independent buffer by calling the context switching interface, and jumps to the command dispatch module of JCRE. After receiving a redirect request from the UICC application, JCRE performs the corresponding operation based on the instruction type and parameters: If it is an A4 instruction, the target application is located based on the AID, and the instruction is dispatched to the target application for processing; If it is instruction 70, then the process of opening the new logical channel will be executed, and the operation result will be returned; After the target application or logical channel operation is completed, JCRE returns control to the UICC application main loop entry point of the original port based on the original port identifier and restores its execution context.

5. The method according to claim 4, characterized in that: In the main loop of the UICC application on each port, the received terminal commands are parsed to determine whether they conform to the command format defined in the specification. If they do, the corresponding command processing function is called to perform the operation, which includes at least security access control, file management operations, logical channel management, and Toolkit application triggering. During instruction execution, it checks whether the conditions for generating proactive commands are triggered, including at least SMS sending requests, proactive notifications initiated by the Toolkit application through the UICC API interface, and proactive operations triggered by timers or events. If an active command is detected, a 91XX status word containing the command data is constructed, and the current instruction processing flow is paused, waiting for the terminal to obtain the active command data through the FETCH instruction, where XX is the data length field; If no proactive command is triggered during instruction execution, a standard status word is directly constructed, and response data can be optionally carried and returned to the caller through the terminal interface; After sending the 91XX status word, the UICC instruction processing flow of the current port is frozen until the corresponding FETCH instruction sent by the terminal is received. After the active command data transmission is completed, the terminal processing result is received through the TERMINAL RESPONSE instruction, and the result determines whether to continue executing the original instruction flow or jump to the error handling branch.

6. The method according to claim 5, characterized in that: Each STK session on a given port is allocated a separate context saving area. Upon entering an STK session, the execution state of the current port is saved by calling the setjmp mechanism, including at least: Stack pointer SP, program counter PC, register set; The current intermediate state of the instruction; Proactive commands handle related temporary variables; The saved context data is stored in the UICC_PortX_STK array; If a MANAGE LSI command is received during STK session execution requesting a switch to another port, the following operations are performed: The longjmp mechanism is used to jump to the main processing flow entry point of the target port. Mark the STK context of the current port as suspended and retain its UICC_PortX_STK data; If the STK session is not active on the target port, the command is executed normally; if it is necessary to enter the STK session, the setjmp mechanism is called repeatedly to save the new state. When the terminal returns the TERMINAL RESPONSE command, the system locates the context data of the corresponding UICC_PortX_STK array based on the port identifier carried in the response information, and restores the STK session of the port through the longjmp mechanism, and continues to perform the following operations: Transmit the terminal response data to the application that initiates the proactive command; Update the session state based on the application processing results; If an active command needs to be sent, the 91XX status word is reconstructed and the terminal FETCH instruction is awaited.

7. The method according to claim 6, characterized in that: If an asynchronous instruction not directly related to STK is received during STK session execution, the following operations are performed: Interrupt the current STK session processing flow: Save the current STK session context data to the UICC_PortX_STK array by calling the setjmp mechanism; Command dispatch and processing: Dispatch asynchronous instructions to JCRE or other instruction processing modules to perform application selection or logical channel opening operations; Resume STK session: After the asynchronous instruction is processed, the STK context of the original port is restored through the longjmp mechanism to continue the interrupted STK session processing flow; If a MANAGE LSI command is received during STK session execution requesting a switch to another port, the following operations are performed: Save the current STK context: Save the STK session state of the current port to the UICC_PortX_STK array; Jump to UICC entry point: Return to the system's main entry point via the longjmp(UICC_Main_Env, Port) mechanism and switch to the context environment of the target port; If it is necessary to enter the STK session in the target port, the setjmp mechanism is called again to save the new state; If there is no need to enter the STK session, continue executing the normal UICC instruction flow.

8. The method according to claim 6, characterized in that: If a FETCH or TERMINAL RESPONSE command is received from the terminal during STK session execution, the following operations are performed: Instruction parsing and matching: Locate the context data of the corresponding UICC_PortX_STK array based on the port identifier in the instruction; FETCH instruction processing: If it is a FETCH instruction, the active command data to be sent is extracted from the context data and returned through the terminal interface; TERMINAL RESPONSE instruction processing: If it is a TERMINAL RESPONSE instruction, the response data is passed to the application that initiated the proactive command, and the status word returned by the application is checked. If the status word is 9000, the current STK session is marked as ended, and the UICC instruction processing flow is restored through the longjmp mechanism; If the status word is not 9000, then the system will decide whether to retry, terminate the session, or jump to the error handling branch based on the error type.

9. The method according to claim 6, characterized in that: When an asynchronous instruction is received during STK session execution, perform the following operations: Channel application type determination steps: Query the application identifier associated with the current logical channel to determine whether the target application is a UICC application; If the target application is a non-UICC application, then perform the non-UICC application processing steps. If the target application is a UICC application, then execute the UICC application processing steps; Non-UICC application processing steps: The asynchronous instruction is encapsulated into a standard APDU format and forwarded to the target non-UICC application through the terminal interface; After dispatching the instruction, start a timeout timer and wait for the application's response; If the application returns the execution result before the timeout, the STC context of the original port is restored through the longjmp mechanism, and the STK session processing flow continues. If the application times out or returns an error status word, the current STK session is terminated, the error log is logged, and the process returns to the UICC instruction processing flow. UICC application processing steps: If the target application is a UICC application, then the instruction processing function conforming to the ts_102221 / ts_102222 / ts_102223 specification is called directly; If a new proactive command is triggered during instruction execution, update the 91XX status word and the data to be sent in the UICC_PortX_STK array; If the command requires a terminal response, the current STK session state is preserved and the system waits for terminal interaction. If the instruction is executed and no further terminal interaction is required, the current STK session is marked as ready to exit. Upon receiving the TERMINALRESPONSE instruction, the UICC instruction processing flow is returned via the longjmp mechanism. If the command requires continuous interaction, keep the STK session active.

10. The method according to claim 6, characterized in that: When an A4 or 70 instruction is received during the execution of an STK session, the system determines that the current STK session processing flow has been asynchronously interrupted. At this time, the complete execution context data of the current port is saved to the corresponding UICC_PortX_STK array through the setjmp mechanism, and the current port is marked as being in the STK suspended-waiting-for-dispatch state. Based on the judgment logic of the channel application type determination step, the received instructions are dispatched to the target application for processing; during the dispatching period, the STK session logic of the current port is frozen, and the system switches to the execution environment of the target application or the scheduling environment of JCRE to execute the instructions. After the target application finishes execution and returns a result, the system restores the context data stored in the UICC_PortX_STK array using the longjmp mechanism and identifies the STK suspended-waiting-for-dispatch status flag. At this point, instead of exiting the STK session, the system jumps directly back to the instruction receive loop entry point of the STK session and performs the following operations: Reset APDU receive buffer: Clear the temporary data area and prepare to receive new terminal commands; Restore terminal interaction state: If the current state is waiting for FETCH or TERMINAL RESPONSE instruction, re-enable the corresponding interaction timeout timer. Continuous listening and processing: The instruction processing loop that re-enters the STK session continues to wait for and parse the next APDU instruction sent by the terminal until an explicit STK end instruction is received or the defined exit conditions are met.

Images