Communication terminal, universal integrated circuit card and method therefor

Abstract

A method for handling temporary proactive command failures between a Universal Integrated Circuit Card (UICC 320) and a communication terminal (310). The method includes, at the UICC: receiving a communication from the terminal; in response thereto, sending a proactive command to the terminal; in response to the proactive command, receiving a notification of a temporary proactive command failure between the UICC and the terminal, wherein the notification includes an expected duration of recovery from the temporary proactive command failure; and implementing a policy for handling the temporary proactive command failure in accordance with the notification, wherein the policy includes one of: waiting for a time period that exceeds the expected duration before resending the proactive command; waiting for an agreed time between the UICC and the terminal before resending the proactive command; resending the proactive command in response to a subsequent event initiated by the terminal; terminating communication with the terminal.

Description

Technical Field

[0001] This technical field generally relates to communication terminals (typically implemented as modems), universal integrated circuit cards (UICCs), and methods for recovering from active commands sent to the communication terminal that have failed due to temporary active command failure. This technical field applies to, but is not limited to, UICCs that have the flexibility to terminate, wait for, or retry active commands based on input from the communication terminal. Background Technology

[0002] A Universal Integrated Circuit Card (UICC) is a smart card used in communication terminals, such as GSM™ and LTE™ communication units, to store subscriber data and other types of information. Typically, a UICC ensures the integrity and security of all types of personal data, and it usually stores several hundred kilobytes of data. With the emergence of more services, it is well known that the storage capacity of UICCs will need to be further expanded. In the context of a UICC, command and response pairs are used to perform information sharing between the communication terminal and the UICC. Typically, the communication terminal acts as the master device, sending commands to the UICC, which then performs the required operation as requested by the command. The UICC then sends a response back to the communication terminal, indicating success, failure, or any additional data applicable to the corresponding command.

[0003] In some situations, the UICC also needs to send commands to the communication terminal to perform certain operations. These commands are called 'active commands'. Therefore, unlike regular commands sent from the communication terminal to the UICC, active commands are known to cause temporary or permanent failures, as defined in ETSI TS 102.223.

[0004] Some examples of temporary errors defined as '2X' in Section 8.12 of ETSI TS 102.223 v17.02 indicate to UICC that it may be worthwhile to retry sending the command later, including: '20' = Terminal cannot currently process the command; '21' = Network cannot currently process the command; '22' = User did not accept the active command; '23' = User cleared the call before the connection or network was released; '24' = Action contradicts the current timer state; '25' = Temporary problem with interaction with call control via NAA; '26' = General error launching browser; '27' = Temporary problem with MMS; '28' = Reserved for 3GPP (for future use); and '29' = Reserved for 3GPP (for future use).

[0005] For example, ETSI TS 102.241 defines a situation where a specific active command (i.e., 'Display Text') fails due to a 'Screen Busy' conflict; here, the UICC can set an event for the communication terminal using, for example, an active command like 'Set Event List'. In the context described herein, an event is intended to contain a command generated by the communication terminal and sent to the UICC when the required conditions are met, which is requested by the UICC in the 'Set Event List'. Later, when the screen is idle, the communication terminal triggers the UICC with the Event_Event_Download_Idle_Screen_Available message, and the UICC (or an applet installed on the UICC) can then send the active command (i.e., 'Display Text') again. The communication terminal then removes the Standby Screen Available event from its current event list. This is to ensure that the communication terminal only reports the event once, i.e., after the UICC has requested the event. Section 6.1 of ETSI TS 102.223 v17.02 identifies a comprehensive list of active commands, such as 'Send Data', 'Timer Management', 'Receive Data', 'Display Text', etc.

[0006] Now for reference Figure 1Figure 100 illustrates a simplified known message sequence of the existing behavior between communication terminal 110 and UICC 120 following an event in response to a failed active command. At 125, communication terminal 110 sends a communication terminal profile with a new event bit set to UICC 120. In response, at 130, UICC 120 sends a list of setup events indicating the new event to communication terminal 110. At 135, communication terminal 110 sends a toolkit event X command to UICC 120, and at 140, UICC 120 processes the command and creates an active command 'Y', which is then sent to communication terminal 110. At 150, communication terminal 110 sends a terminal response (indicating a temporary error) command to UICC 120, and at 155, UICC 120 evaluates a retry counter and begins a wait delay between one or more retries to send the active command 'Y'. At 160, UICC 120 notifies communication terminal 110 that timer management has begun, and communication terminal 110 confirms timer management at 165 using a communication terminal response message. At 170, communication terminal 110 sends the Event_Event_download_timer_expiration command to UICC 120. In response, at 175, UICC 120 processes the command and sends an active command 'Y' to communication terminal 110 at 180. This approach has several drawbacks, such as unnecessary battery consumption (wasted due to repeated and failed retries), uncertainty for UICC regarding when the corresponding active command will succeed, and the need to use critical resources (timers) (which are limited resources on the communication terminal (limited to a total of '8' timers)).

[0007] IN201921009668A describes a scenario where active commands are resumed after an error occurs. US10241845B2 describes a scenario where the event involves a failure to resume active commands. Neither of these methods provides a mechanism that allows communication to be discarded, waited for, or resumed later with a certain probability of success.

[0008] Therefore, there is a need for an improved mechanism for communication terminals, a universal integrated circuit card (UICC), and a method for recovering from a temporary active command failure between the communication terminal and the UICC after an active command is sent from the UICC to the communication terminal, which can provide the UICC with the opportunity to abort, wait for success, or retry later. Summary of the Invention

[0009] According to a first aspect of the present invention, a method is provided for handling a temporary active command failure between a Universal Integrated Circuit Card (UICC) and a communication terminal, the method comprising, at the UICC: receiving communication from the communication terminal; in response to this, sending an active command to the communication terminal; in response to the active command, receiving a notification of a temporary active command failure between the UICC and the communication terminal, wherein the notification includes an expected duration for recovery from the temporary active command failure; and implementing a strategy for handling the temporary active command failure of the communication according to the notification, wherein the strategy includes one of: waiting for a period of time exceeding the expected duration before retransmitting the active command; waiting for a priori time period agreed upon between the UICC and the communication terminal before retransmitting the active command; retransmitting the active command in response to a subsequent event initiated by the communication terminal and notified to the UICC in the notification; and terminating communication between the UICC and the communication terminal.

[0010] In one or more embodiments, the notification of the temporary active command failure includes one or more of the following: the expected duration for which the communication terminal recovers to a state in which it is able to process the active command that failed due to the temporary active command failure; information identifying subsequent events, wherein the events indicate that the communication terminal is in a state in which it can receive the active command; the state of the communication terminal; and the state of the current UICC command executed by the communication terminal.

[0011] In one or more embodiments, the method further includes the UICC retransmitting the active command in a limited number of attempts.

[0012] In one or more embodiments, the finite number of attempts is configurable.

[0013] In one or more embodiments, the method further includes the UICC deciding not to resend the active command until the UICC is aware of the state of the communication terminal.

[0014] In one or more embodiments, the method further includes: the UICC determining that the expected duration of recovery from the failure of the provisional active command in the notification is unacceptable to the UICC; and the UICC deciding to send the active command without waiting.

[0015] In one or more embodiments, the method further includes, at the communication terminal: processing the active command; and sending the notification to the UICC, wherein the notification includes an expected duration for recovery from the failure of the provisional active command; and, at the UICC: terminating the communication session in response to sending the notification to the UICC without any subsequent retry attempts when the UICC does not agree to the expected duration for waiting for recovery.

[0016] According to a second aspect of the present invention, a Universal Integrated Circuit Card (UICC) is provided for handling a temporary active command failure between the UICC and a communication terminal, the UICC comprising: a receiver configured to receive communication from the communication terminal; a transmitter configured to send an active command to the communication terminal in response thereto; and a processor operatively coupled to the receiver and the transmitter; wherein the receiver is configured to receive a notification of a temporary active command failure between the UICC and the communication terminal in response to the active command, wherein the processor is configured to: determine that the notification includes an expected duration for recovery from the temporary active command failure; and, based on the notification, implement a strategy for handling the temporary active command failure of the communication, wherein the strategy includes one of: waiting for a period of time exceeding the expected duration before retransmitting the active command; waiting for a priori time period agreed upon between the UICC and the communication terminal before retransmitting the active command; retransmitting the active command in response to a subsequent event initiated by the communication terminal and notified to the UICC in the notification; or terminating the communication between the UICC and the communication terminal.

[0017] In one or more embodiments, the notification of the temporary active command failure includes one or more of the following: the expected duration for which the communication terminal recovers to a state in which it is able to process the active command that failed due to the temporary active command failure; information identifying subsequent events, wherein the events indicate that the communication terminal is in a state in which it can receive the active command; the state of the communication terminal; and the state of the current UICC command executed by the communication terminal.

[0018] In one or more embodiments, the processor is configured to resend the active command a limited number of times.

[0019] In one or more embodiments, the finite number of attempts is configurable.

[0020] In one or more embodiments, the processor is configured to decide not to resend the active command until the UICC is aware of the state of the communication terminal.

[0021] In one or more embodiments, the processor is configured to: determine that the expected duration of recovery from the failure of the provisional active command in the notification is unacceptable for the UICC; and decide to resend the active command without waiting.

[0022] According to a third aspect of the invention, a communication terminal is provided for handling a temporary active command failure between the communication terminal and a Universal Integrated Circuit Card (UICC), the communication terminal comprising: a transmitter configured to transmit communication to the UICC; a receiver configured to receive an active command from the UICC in response thereto; and a processor operatively coupled to the receiver and the transmitter and configured to: process the active command, and determine that a temporary active command failure exists between the UICC and the communication terminal, and accordingly, the transmitter sends a notification of the temporary active command failure, wherein the notification includes an expected duration for recovery from the temporary active command failure.

[0023] In one or more embodiments, the notification of the temporary active command failure includes one or more of the following: the expected duration for which the communication terminal recovers to a state in which it is able to process the active command that failed due to the temporary active command failure; information identifying subsequent events, wherein the events indicate that the communication terminal is in a state in which it can receive the active command; the state of the communication terminal; and the state of the current UICC command executed by the communication terminal.

[0024] These and other aspects of the invention will become apparent from the embodiments described below, and will be illustrated with reference to these embodiments. Attached Figure Description

[0025] Other details, aspects, and embodiments will be described only by way of example and reference to the figures. In the figures, the same reference numerals are used to identify elements that are the same or functionally similar. For simplicity and clarity, the elements in the figures are shown, and these elements are not necessarily drawn to scale.

[0026] Figure 1 A simplified diagram of known message sequences illustrating the existing behavior following an event of a failed active command is shown.

[0027] Figure 2 A block diagram of a wireless communication unit adapted according to some example embodiments is shown.

[0028] Figure 3 An example message sequence diagram is shown according to an example embodiment when the UICC decides to wait for a certain period of time before resending the active command after the temporary active command has failed.

[0029] Figure 4An example message sequence diagram is shown according to an example embodiment when the UICC decides to send an active command without waiting for the requested / suggested time.

[0030] Figure 5 An example message sequence diagram is shown, according to an example embodiment, when UICC decides not to wait for the requested / suggested time and aborts the active session without making any retry attempts.

[0031] Figure 6 An example of a flowchart, such as a startup sequence and a list of setting events for a communication terminal configuration file, is shown according to an example embodiment.

[0032] Figure 7 An example flowchart of an active command that fails due to a temporary error according to an example embodiment is shown, in which the communication terminal sends a temporary error notification of the command to the UICC.

[0033] Figure 8 Another example of a flowchart illustrating an active command that fails due to a temporary error according to an example embodiment is shown, in which the communication terminal sends a temporary error notification of the command to the UICC.

[0034] Figure 9 An example flowchart of an event-based retry or abort command according to an example embodiment is shown.

[0035] Figure 10 An example flowchart of a decision framework according to an example embodiment is shown.

[0036] Figure 11 An example of a use case is shown where UICC communicates with communication terminals and peripheral devices / remote attachment servers, according to an example embodiment. Detailed Implementation

[0037] The inventors have recognized and understand that, for temporary errors, there is an opportunity to better manage retries of active commands; for example, it is worthwhile to retries after waiting for a certain amount of time. To address the technical problem of a UICC sending (and resending) an active command to a communication terminal when a temporary active command failure exists between the communication terminal and the UICC, the example described herein illustrates a scenario where the communication terminal notifies the UICC to delay a retry attempt of the active command for a certain period of time before resending it, said period of time potentially including the expected duration of recovery from the temporary active command failure. In this case, the UICC can wait, terminate, or retry the active command at (or after) the notification time.

[0038] In the following text, it is assumed that the expression 'active command failure' covers one or more of the following:

[0039] (i) Temporary communication failures as defined in Section 8.12 of ETSI TS 102.223 v17.02. The following categories exist (with error codes defined in 102.223). It should be noted that the communication terminal is aware of the error (with error codes (20, 24, 25, 26, 27)); errors with error code (21) are known to the communication terminal, and the communication terminal is then able to estimate the recovery time; and errors (with error codes 22, 23) fall outside the control of the communication terminal. Therefore, the example described herein can be used where the communication terminal is able to know or predict the recovery time, for example, based on the current error codes 20, 21, 24, 25, 26, 27;

[0040] (ii) Faults occurring within the 'communication terminal', such as error code '20' = the terminal is currently unable to process the command; '24' = the action contradicts the current timer state; '26' = general error code for launching a browser, such as the communication terminal being in an environment unrelated to running the command, such as requesting to run an already running timer, or requesting an HTTP session when there is no network connection;

[0041] (iii) A failure in the communication link between the communication terminal and one or more other peripheral devices (or remote devices), such as Figure 11 As shown;

[0042] (iv) An error identified in one or more active command parameters, such as when setting up a Hypertext Transfer Protocol (HTTP) session using parameters that are unrelated to the current device / server settings;

[0043] (v) The user rejects the requested command, for example, in cases where the communication terminal user stops the call setup attempt or redial mechanism before receiving a result from the network; and

[0044] (vi) The communication terminal is too 'busy' to process active commands.

[0045] It should be noted that in some cases, the location of an 'active command failure' may depend on the type of active command used. It should also be noted that the description of 'active command failure' does not include a communication link failure between the UICC and the communication terminal, as this would prevent the successful issuance and receipt of the 'temporary error notification' described herein.

[0046] Based on a notification sent from the communication terminal, the UICC may decide to retry sending the active command. If the UICC decides to retry sending the active command, a notification from the communication terminal indicating a temporary active command failure may indicate to the UICC that a subsequent event will indicate that the temporary active command failure has been resolved. In response to this notification, the UICC may retry sending the active command. In some examples, the subsequent event may be a message or command sent from the communication terminal. Therefore, the UICC can determine, in response to a subsequent event received from the communication terminal, that the communication terminal has recovered from the temporary active command failure; and in response to the received subsequent event, when the UICC is aware of the current state of the communication terminal, retry sending the active command. In this way, if the subsequent event is initiated immediately after the communication failure is resolved, the UICC can know the precise timing when the active command can be resent after receiving the subsequent event, without attempting further retries that may fail. In this way, according to the example described herein, the UICC now has the flexibility to terminate, wait for, or retry active commands based on input from the communication terminal. In this way, after a temporary active command fails, the UICC no longer risks never knowing when the communication terminal will successfully process its active command request. Furthermore, this method allows the UICC to control how retries should occur, making the entire process more flexible and controllable. Additionally, this method avoids unnecessary consumption or waste of resources, such as battery power, due to repeated and failed retries.

[0047] In some cases, it is envisioned that UICC can receive multiple instances of the same command (i.e., temporary error notifications) after waiting for the specified amount of time.

[0048] It should be recognized that prior to adopting the concepts described in this article, retries were based on a counter value and a timer value (with a set wait delay), each of which could be configurable. The configurable factors could depend on how the manufacturer views the overall environment in which UICC will be deployed. However, after adopting some of the concepts described in this article, three new approaches (including two recovery modes) are supported:

[0049] 1. UICC may decide (or in some cases, agree a priori with the communication terminal) to wait a longer period of time for the communication terminal (e.g., modem) to recover from a temporary active command failure: in some examples, the duration of recovery may be received in the proposed (new) command, such as in a 'temporary error notification'. In this case, the communication terminal (e.g., modem) is expected to send a successful communication terminal response (e.g., a command notifying UICC that it is now able to receive active commands) after the expected communication recovery time has elapsed (see reference). Figure 3 (as described).

[0050] 2. The UICC may decide not to wait and may decide to retry later at the time determined by the UICC or in response to an event provided by the communication terminal in a temporary active command failure notification: In this case, the communication terminal (e.g., a modem) may issue a Failed Terminal Response (TR) and subsequently send a command or message indicating that the failed active command can be retransmitted (as per reference). Figure 4 (as described).

[0051] 3. The UICC may request the termination of the session, where the decision to terminate the session depends on the duration of recovery shared by the communicating terminals in the temporary error notification: in this case, the UICC may not want to wait or retry, where it is envisioned that the communicating terminal (e.g., a modem) could simply send a failed TR and delete all cached data (as per reference). Figure 5 (as described).

[0052] For cases (1) and (2), it is envisioned that the waiting time can be provided by the communication terminal (e.g., modem) in a dedicated command (e.g., temporary error notification). The UICC then decides whether to accept the instruction / request in the dedicated command.

[0053] If the UICC accepts this duration (case (1)), and if communication may still fail to resume even after the recovery duration has elapsed, it is envisioned that the communication terminal (e.g., modem) may resend the same command (e.g., temporary error notification) again for a new expected recovery duration. In some cases, it is envisioned that this resentment of the command (e.g., resentment of the temporary error notification) may continue until the case falls under case (2) or (3) above. In some cases, it is envisioned that the number of times this resentment operation may occur may be configurable by the manufacturer, for example, depending on the environmental conditions under which the UICC can operate. In some cases, it is envisioned that this method may prevent the UICC from entering a race condition in case (1). It should be noted that for cases (2) and (3), there is no concept of a counter (or number of retries) as used in the examples described herein, because the UICC will reject the delay request upon the first notification from the communication terminal (e.g., modem).

[0054] In some examples, the information expected from the communication terminal may include one or more of the following: (i) the expected duration of recovery from a temporary active command failure to a state where the communication terminal is able to process an active command that failed due to such a temporary error; and (ii) an event whenever the communication terminal recovers from a temporary situation that may have caused the active command to fail. In some examples, the information expected to be received from the communication terminal at the UICC may include one or more of the following: (i) a command indicating the duration of recovery, whereby the UICC may be configured to determine whether such a recovery duration is acceptable; and (ii) a new envelope event to be sent from the communication terminal to the UICC when the communication terminal is in a state of servicing an active command, whereby the UICC may resend the same active command upon receiving the event. In some examples, the temporary problem is expected to be transient, and the communication terminal recovers from the temporary problem after a certain period of time. One such envisioned temporary error / failure is a situation where the communication terminal is currently unable to process a command (as defined in ETSI TS 102.223). In some examples, events requested on the communication terminal in the setup event list may remain set until the UICC explicitly sends a setup event list without the 'communication terminal available' byte. This means that the event will remain in the communication terminal.

[0055] In some examples, it is also envisioned that the information anticipated from the communication terminal is not limited to the expected duration for restoring the communication terminal to a state where it can handle an active command that failed due to a temporary error. In some examples, it is envisioned that the information anticipated from the communication terminal could be information that leads to better synchronization between the UICC and the communication terminal, such as the terminal state (waiting / processing), the state of the current UICC command, etc. Since active commands are exchanged between the UICC and the communication terminal (e.g., a modem), the most specific use cases are relevant to these devices. However, it is envisioned that the concepts described herein apply to any device where a handshake procedure may be in place without a retry.

[0056] In some instances, the concepts described herein are envisioned to be applicable to all types of active commands, such as those identified in ETSI TS102.241. In some instances, the concepts described herein are envisioned to be applicable to all types of temporary errors / failures on communication terminals. In some instances, the concepts described herein are envisioned to be applicable to other situations where retries from a host device, such as a UICC, to a server / device, such as a communication terminal, are not event-dependent but can be latency-dependent.

[0057] Active commands are handled entirely by the communication terminal. In the example described herein, the communication terminal has been adapted and is now configured to play a crucial role in providing relevant information to the UICC, enabling the UICC to determine when to retry sending the active command due to a temporary error identified at the communication terminal.

[0058] In some examples, an envelope command event triggers the UICC when the communication terminal (e.g., modem) recovers from a temporary error. Those skilled in the art will recognize that the terms 'envelope command event' and 'event' are used interchangeably herein, especially since the event arrives at the UICC from the communication terminal (e.g., modem) in the form of an envelope command (i.e., the event is one type of command among many supported by the UICC). Any event is generated when a specific condition requested by the UICC is met. For example, when the UICC requests a 10-second timer, a timer expiration event will be generated in the modem after 10 seconds, and this event will be sent to the UICC using an envelope command. Those skilled in the art will recognize that events sent in a set event list can notify the communication terminal (e.g., modem) that the UICC supports the feature. Therefore, a set event list is an active command sent by the UICC to the communication terminal (e.g., modem) containing a list of events that the UICC requires the communication terminal (e.g., modem) to notify the UICC. In this example, the envelope event sent by the communication terminal will notify the UICC, and the UICC mechanism will retry the active command upon receiving the envelope. UICC retryes active commands on events. Therefore, UICC will not retry active commands if it is unaware of the state of the communication terminal.

[0059] In a first aspect, the examples described herein provide a method for handling a temporary active command failure between a general-purpose integrated circuit card (UICC) and a communication terminal, the method comprising, at the UICC: receiving communication from the communication terminal; in response, sending an active command to the communication terminal; in response to the active command, receiving a notification of a temporary active command failure between the UICC and the communication terminal, wherein the notification includes an expected duration for recovery from the temporary active command failure; and implementing a strategy for handling the temporary active command failure according to the notification, wherein the strategy includes one of: waiting for a period of time exceeding the expected duration before retransmitting the active command; waiting for a priori time period agreed upon between the UICC and the communication terminal before retransmitting the active command; retransmitting the active command in response to a subsequent event initiated by the communication terminal and notified to the UICC in the notification; or terminating communication between the UICC and the communication terminal.

[0060] In a second aspect, this document describes an example of a general-purpose integrated circuit card (UICC) for handling temporary active command failures between the UICC and a communication terminal. The UICC includes: a receiver configured to receive communication from the communication terminal; a transmitter configured to send an active command to the communication terminal in response; and a processor operatively coupled to the receiver and the transmitter. The receiver is configured to receive a notification of a temporary active command failure between the UICC and the communication terminal in response to the active command. The processor is configured to: determine that the notification includes an expected duration for recovery from the temporary active command failure; and, based on the notification, implement a strategy for handling the temporary active command failure. The strategy includes one of the following: waiting for a period exceeding the expected duration before retransmitting the active command; waiting for a priori time period agreed upon between the UICC and the communication terminal before retransmitting the active command; retransmitting the active command in response to a subsequent event initiated by the communication terminal and notified to the UICC in the notification; or terminating communication between the UICC and the communication terminal.

[0061] In a third aspect, the examples described herein provide a communication terminal for handling a temporary active command failure between the communication terminal and a Universal Integrated Circuit Card (UICC), the communication terminal comprising: a transmitter configured to send communication to the UICC; a receiver configured to receive an active command from the UICC in response thereto; and a processor operatively coupled to the receiver and the transmitter and configured to process the active command, determine that a temporary active command failure exists between the UICC and the communication terminal, and thereby, the transmitter sends a notification of the temporary active command failure, wherein the notification includes an expected duration for recovery from the temporary active command failure.

[0062] refer to Figure 2 A block diagram of a communication terminal 225 and a UICC 250 adapted according to some example embodiments is shown. In fact, for purely illustrative purposes, the communication terminal 225 is described in terms of a wireless communication unit such as a user equipment (UE) or a wireless modem. The communication terminal 225 includes an antenna 202 for radiating transmitted signals and for transmitting signals from, for example... Figure 2 Another communication unit, such as the UICC, receives transmission 221. Antenna 202 is coupled to an antenna switch or duplexer 204, which provides isolation between the receive chain and the transmit chain within the communication terminal 225. As is known in the art, one or more receiver chains include a receiver front-end circuitry system 206 (effectively providing reception, filtering, and intermediate frequency conversion or baseband conversion). The receiver front-end circuitry system 206 is coupled to a signal processor 208 (typically implemented by a digital signal processor (DSP)). Those skilled in the art will understand that the level of integration of receiver circuitry or components may vary depending on the implementation scheme in some cases.

[0063] Controller 214 maintains overall operational control of communication terminal 225. Controller 214 is also coupled to receiver front-end circuitry 206 and signal processor 208. In some examples, controller 214 is also coupled to buffer module 217 and memory device 216 for selectively storing operational schemes, such as decoding / encoding functions, synchronization modes, code sequences, etc. Timer 218 is operatively coupled to controller 214 to control the timing of operations within communication terminal 225 (e.g., transmission or reception of time-related signals). In this example, controller 214 and / or signal processor 208 are also coupled to circuitry 259 for communication with UICC.

[0064] Regarding the transmit chain, this essentially comprises an input interface 220 of antenna 202, antenna array, or multiple antennas, coupled in series through transmitter / modulation circuitry 222 and power amplifier 224. Transmitter / modulation circuitry 222 and power amplifier 224 are operatively responsive to controller 214.

[0065] The signal processor 208 in the transmitting chain may be implemented differently from the signal processor in the receiving chain. Alternatively, as Figure 2 As shown, a single processor can be used to process both the transmitted and received signals. Clearly, the various components within the communication terminal 225 can be implemented as discrete or integrated components, and therefore the final structure is either custom-designed or a matter of choice.

[0066] Figure 2 It also includes a UICC 250 that communicates with communication terminal 225. Those skilled in the art will recognize that the UICC 250 has functions similar to a microcontroller. Therefore, the UICC 250 includes (but is not limited to) the following interconnect circuitry / functions: a processor (e.g., a central processing unit (CPU)) 252, which is arranged to run at least a small program stored on memory 254. Memory 254 may include one or more of read-only memory (ROM), random access memory (RAM), and non-volatile memory (NVM). Input-output (I / O) ports (256) provide interfaces to / from the UICC 250. The processor 252 uses clock 258 to organize and control the timing of actions performed by the UICC 250.

[0067] As is well known, retransmission of an active command represents the current approach, which employs timers and counters to perform multiple (determined by the counter) retries of the active command after a certain amount of time (determined by the timer). However, in the example described herein, a different approach is employed, whereby, in response to an active command, the processor processes a received notification of a temporary active command failure between the UICC and the communication terminal. The processor is configured to: determine that the notification includes an expected duration for recovery from the temporary active command failure; and implement a strategy for handling the temporary active command failure according to the notification. The strategy includes one of the following: waiting for a period exceeding the expected duration before retransmitting the active command; waiting for a priori time period agreed upon between the UICC and the communication terminal before retransmitting the active command; retransmitting the active command in response to a subsequent event initiated by the communication terminal and notified to the UICC in the notification; or terminating communication between the UICC and the communication terminal.

[0068] In some cases, subsequent events can be dedicated events that are not subject to time constraints, and the communication terminal (e.g., modem) is the entity that determines when the UICC should resend the active command after the communication terminal recovers from the current problem / temporary active command failure.

[0069] Now for reference Figure 3 According to an example embodiment, an example of message sequence diagram 300 for communication between communication terminal 310 and UICC 320 illustrates when, in this example, UICC 320 decides to wait for a certain 'time period' before retransmitting the active command after a temporary active command failure. In the example described herein, the amount of time UICC 320 is to wait is provided, for example, in a temporary error notification, and is referred to hereinafter as the 'time period'. In this case, the 'time period' is determined to be sufficient for communication terminal 310 to recover from the temporary active command failure. In the example described herein, UICC 320 does not retransmit the active command until the 'time period' expires, which is the expected duration of recovery from the temporary active command failure. When UICC 320 accepts a 'time period' for recovery in its response to a temporary error notification and requests a retry later, once the 'time period' has expired, communication terminal 310 has two options: (i) send a successful communication terminal 310 response (if communication terminal 310 was able to successfully execute the command within that duration); or (ii) if communication terminal 310 cannot recover, resend the temporary error notification with a new duration and any other information based on the determined relevance. Therefore, in the examples described herein, any reference to the 'time period' is intended to cover the aforementioned assigned delay prior to the resending of the active command.

[0070] At 325, communication terminal 310 sends a communication terminal configuration file with a new event to UICC 320, the new event being referred to as having the 'Terminal Available' bit set. In response, at 330, UICC 320 sends a list of settings events indicating the new event to communication terminal 310. At 335, communication terminal 310 sends a toolkit event 'X' command to UICC 320, and at 340, UICC 320 processes the command and creates an active command 'Y', and at 345, UICC 320 sends the active command 'Y' to communication terminal 310. Here, those skilled in the art will recognize that 'X' and 'Y' are specification references to toolkit events and the corresponding active commands generated by a specific toolkit event. As an example, if the toolkit event is Event_Event_Download_Data_AVAILABLE (here 'X'), then the corresponding active command could be Receive Data (here 'Y'). At 350, communication terminal 310 processes the active command 'Y', and at 355 sends a terminal response with a temporary error to UICC 320, specifically with an expected duration for recovery from the temporary error. It is conceivable that there could be various reasons why the communication terminal might enter a temporary error state. For example, the error code could be one or more error codes defined in Section 8.12 of ETS TS 102.223v17.02. It is conceivable that in some instances, the recovery duration could be determined by the communication terminal based on its own situation. At 360, in response to this, UICC 320 decides to wait for a period of time exceeding the expected recovery time of communication terminal 310, as shown at 365. In some instances, it is conceivable that if communication terminal 310 fails to recover within the expected time after the notified duration, i.e., after at least one (and up to 'n-1' times) re-issuance of the active command at 355, this decision to wait (suggested) time period could occur 'n' times.

[0071] In this example, at 370, communication terminal 310 recovers from the temporary error and continues processing the active command 'Y'; or communication terminal 310 recognizes and acknowledges that it cannot perceive the possibility of successfully receiving the active command 'Y'. Then, communication terminal 310 sends a terminal response (e.g., success or failure) to UICC 320 at 375 and receives an acknowledgment from UICC 320 at 380.

[0072] Now for reference Figure 4This diagram illustrates an example of a message sequence diagram 400 between a communication terminal 410 and a UICC 420 according to an example embodiment. In this example, the UICC 420 decides to send an active command without waiting for the requested / suggested time. At 425, the communication terminal 410 sends a communication terminal profile to the UICC 420 with the new event 'Terminal Available' bit set. In response, at 430, the UICC 420 sends a list of setting events indicating the 'Terminal Available' event to the communication terminal 410. At 435, the communication terminal 410 sends a toolkit event 'X' command to the UICC 420, and at 440, the UICC 420 processes the command and creates an active command 'Y', which is then sent to the communication terminal 410 at 445. At 450, communication terminal 410 processes the active command 'Y', and at 455 sends a terminal response to UICC 420 with a temporary active command failure / error notification, specifically with an expected duration for recovery from the temporary error (as previously described). At 460, in response to this, UICC 420 decides to abort the session and may retry later, for example, at an indeterminate time. At 465, this UICC decision is sent to communication terminal 410. In this example, communication terminal 410 then registers a retry request later. At 475, communication terminal 410 sends a terminal response to UICC 420 after confirming the temporary active command failure / error notification, and UICC 420 sends an acknowledgment to communication terminal 410 at 480. In this example, at 485, communication terminal 410 recovers from the temporary active command failure / error notification, checks whether any retry requests have been registered, and whether the event 'terminal available' has been registered. If 485 occurs, then at 490, communication terminal 410 sends the Event_Event_download_'terminal available' command to UICC 420. At 495, UICC invokes or re-prepares the failed active command 'Y'. At 497, UICC 420 then sends the active command 'Y' to communication terminal 410.

[0073] Now for reference Figure 5This illustrates an example of a message sequence diagram 500 between a communication terminal 510 and a UICC 520 according to some example embodiments. In this example, the UICC 520 decides not to wait for the requested / suggested time and aborts the active session without making any retry attempts. At 525, the communication terminal 510 sends a communication terminal profile to the UICC 520 with the new event 'terminal available' bit set. Thus, in this manner and in the example described herein, the communication terminal 510 uses terminal profile commands to inform the UICC 520 of each feature supported by the communication terminal 510. The various features supported by the communication terminal 510 are encoded in the respective bits. When the UICC 520 receives the terminal profile command, the UICC 520 buffers its data (e.g., in...). Figure 2 The UICC 520 (located in memory 254 of the UICC 250) checks the required bits and performs the relevant operations as needed. Since the communication terminal 510 has a new feature requested in this instance, new bits need to be added. In response, at 530, the UICC 520 sends a list of setting events indicating the 'terminal available' event to the communication terminal 510. At 535, the communication terminal 510 sends a toolkit event 'X' command to the UICC 520, and at 540, the UICC 520 processes the command and creates an active command 'Y', which is then sent to the communication terminal 510 at 545. At 550, the communication terminal 510 processes the active command 'Y' and at 555 sends a terminal response with a temporary error notification to the UICC 520, specifically with the expected duration of recovery from the temporary error in this example. At 560, in response to this, the UICC 520 decides to abort the session without making any subsequent retry attempts. At 565, this UICC decision is sent to communication terminal 510. Then, at 570, communication terminal 510 clears the active stack and discards the active session. At 575, communication terminal 510 sends a 'failure' terminal response to UICC 520. At 580, UICC 520 then also clears the active stack held in UICC and discards the active session, and at 585, UICC 520 then confirms this to communication terminal 510.

[0074] For reference Figure 6 The diagram illustrates an example of a flowchart 600, based on some example embodiments, for example, a startup sequence and a list of setup events for a terminal profile. In this example, the communication terminal profile is provided with dedicated bits to indicate support for a new event referred to herein as "terminal available". When the UICC receives a communication terminal profile indicating support for the "terminal available" feature, the UICC adds the dedicated event to the setup event list active command to indicate that the UICC also supports the "terminal available" feature.

[0075] At 625, the startup sequence begins in communication terminal 610. At 630, it is determined whether the 'Terminal Available' feature is supported. If the 'Terminal Available' feature is supported at 630, it is added to the communication terminal profile to enable the terminal to send a single bit to indicate an event and to inform UICC 620 that communication terminal 610 supports the temporary active command failure feature. The flowchart then transitions to 640. If the 'Terminal Available' feature is not supported at 630, the flowchart transitions to 640, where the communication terminal profile is sent to UICC 620. Flowchart 600 then transitions from communication terminal 610 to UICC 620, and at 645, UICC 620 saves the communication terminal profile. At 650, UICC 620 determines whether the 'Terminal Available' feature is supported in the communication terminal profile. If the 'Terminal Available' feature is supported at 650, it is added to the event list at 655. Essentially, this resembles a handshake between UICC 620 and communication terminal 610. Communication terminal 610 sends its terminal profile (indicating supported features) to UICC 620, and UICC 620 sends a set event list command to communication terminal 610, instructing UICC 620 to require communication terminal 610 to trigger all events of UICC 620. The flowchart then transitions to 660. If the 'terminal available' feature is not supported at 650, the flowchart transitions to 660, where the set event list is sent to communication terminal 610.

[0076] Now for reference Figure 7This illustrates an example of a flowchart 700 of a notification of a new active command 730 that failed due to a temporary error according to an example embodiment, wherein the communication terminal 710 sends a temporary error notification to the UICC 720. At 728, processing in the communication terminal 710 begins with the input of a new active command 730 and / or a queuing request at 725. At 735, it is determined whether the required resource is available. If the required resource is available at 735, then at 745, the operation requested in the active command is performed. Next, at 748, a communication terminal response is sent to the UICC 720. If the required resource is unavailable at 735, then at 738, the cause of the failure is analyzed (and determined). If the cause determined at 738 is identified as a temporary problem at 740, then at 750, the communication terminal 710 prepares a temporary error notification and sends the temporary error notification to the UICC 720. Temporary errors are defined in ETSI TS 102.223, with examples including 'Screen busy', 'User busy during call', etc. However, if the cause identified at 738 is identified as not a temporary problem at 740, flowchart 700 moves to 748. At UICC 720, after sending the communication terminal response at 748, UICC processes the response according to the general terminal response at 755, and the process stops at 758. At UICC 720, after communication terminal 710 sends a temporary error notification at 750, at 760, UICC 720 determines whether the duration before recovery is within an acceptable time range. If it is determined at 760 that the duration before recovery is not within an acceptable time range, the process stops at 758. If it is determined at 760 that the duration before recovery is within an acceptable time range, UICC 720 prepares to accept a response for the notified duration at 765 and sends the response to communication terminal 710, where the request was queued at 725. In the event that queued request 725 cannot be served, even after the recovery time has passed and communication terminal 710 needs more time to recover at 732, communication terminal 710 can still send a temporary error notification to UICC 720 at 750.

[0077] Imagine this process can run multiple times until multiple configurable counters (which limit the number of retries) are exhausted to prevent the process from entering a 'race' condition. Once the counters are exhausted, communication terminal 710 will discard the request and enter a processing state at 728, and a permanent failure will occur at 738 because not enough resources were found at 735. Then, at 748-740, the response from communication terminal 710 will be sent to UICC 720, thus terminating the program in the worst-case scenario.

[0078] Now for reference Figure 8This illustrates another example of a flowchart 800 of an active command that failed due to a temporary error according to some example embodiments, where communication terminal 810 sends a temporary command error notification to UICC 820. At 825, communication terminal 810 has recovered from its temporary active command failure. At 830, it is determined whether communication terminal 810 requested a retry. If the determination at 830 is that communication terminal 810 did not request a retry, then communication terminal 810 discards the active session at 835 and decides not to continue. If the determination at 830 is that communication terminal 810 requested a retry, then an envelope event is prepared at 840 and then sent to UICC 820, which receives the event at 845 and evaluates its validity. At UICC 820, it is determined at 850 whether any applets have been registered. If it is determined at 850 that no applets have been registered, then nothing further happens at 865. However, if the determination made at 850 indicates that an applet is registered, the applet is triggered at 855, and at 860, the applet will resend the active command (if the active command is still needed). In the example described herein, an applet existing in UICC 820 can use active commands to perform various tasks for which the applet is designed. Several events discussed herein can be registered through an applet, and these events are forwarded to the applet when they are sent to UICC 820. Whenever the applet receives an event, if the applet still wishes to obtain the corresponding service, it is expected to retry the active command last sent by the applet based on the event. Then, nothing further happens at 865.

[0079] Now for reference Figure 9 Two example flowcharts 900 and 968 illustrate actions performed by a communication terminal 910 based on events using retry or abort commands, according to some example embodiments. The first example flowchart 900 begins with the communication terminal 910 sending a terminal response 925 to the Card Application Kit Runtime Environment (CATRE) 930. Those skilled in the art will recognize that CATRE is the runtime environment that manages the toolkit applets within the UICC.

[0080] Toolkit applets are a specific form of Java™ card applet, designed to perform certain toolkit operations of UICC. CATRE manages all these applets and their corresponding operations. In the context described herein, the term 'manage' encompasses events, states, operations, services, etc. CATRE 930 responds to communication terminal 910 with a 'retry event if possible' command 935 or an active retry command 940. The first example flowchart 900 continues with CATRE 930 sending a terminal response 950 to decision framework 955. Decision framework 955 responds to CATRE 930 by sending a retry session command 960 or an abort session command 965.

[0081] The second example flowchart 968 begins with communication terminal 910 sending event 970 to Card Application Kit Runtime Environment (CATRE) 975. CATRE 975 responds to communication terminal 910 with an active command retry 995. The second example flowchart 968 continues with CATRE 975 sending event 980 to applet 985 (registered to the event). Applet 985 responds to CATRE 975 by sending an active command retry command 990.

[0082] For reference Figure 10 An example of a flowchart 1000 of a decision-making framework according to an example embodiment is shown. Flowchart 1000 begins at communication terminal 1010 and UICC 1065, where at 1025, UICC 1065 receives a temporary error / failure notification. Then at 1030, it is determined whether the recovery duration is acceptable for UICC 1065. In some examples, this duration may depend on several factors regarding the ease with which communication terminal 1010 can recover from the temporary error. In one example, communication terminal 1010 may determine that the duration needs to be evaluated by communication terminal 1010 whenever an error occurs. In one example, if the recovery duration cannot be determined, a pre-programmed value may be used.

[0083] If the recovery duration is acceptable to UICC 1065 at 1030, then UICC 1065 decides to wait at 1035. Relevant information is sent from UICC 1065 to communication device 1010 (e.g., to 1025). If the recovery duration is unacceptable to UICC 1065 at 1030, then UICC 1065 determines whether a retry is expected at 1040. If a retry is not expected at 1040, then UICC requests session termination at 1045. UICC 1065 queries communication device 1010 (e.g., to 1025). If a retry is expected at 1040, then at 1050, UICC 1065 determines whether the applet requested a communication terminal availability event. If the applet requests a communication terminal available event at 1050, then at 1060, a retry request using that event is executed, and relevant information is sent from UICC 1065 to communication device 1010. If the applet does not request a communication terminal available event at 1050, then at 1055, UICC 1065 requests the termination of the session. Relevant information is sent from UICC 1065 to communication device 1010 (e.g., up to 1025).

[0084] It should also be understood that, for clarity, the embodiments described with reference to different functional units and processors may be modified or reconfigured without departing from the concepts described herein, wherein any suitable functional distribution among the different functional units or processors is possible. For example, the illustrated functions to be performed by a separate processor or controller may be performed by the same processor or controller. Therefore, references to specific functional units are to be regarded only as references to suitable means for providing the described functions, and not as indications of a strict logical or physical structure or organization.

[0085] The examples described herein are envisioned for use in initiating a notification between the mobile terminal and the UICC after a temporary active command fails during the execution of an active command. Following the notification of the active command's failure due to the temporary active command failure (e.g., "The terminal is currently unable to process the command"), it is envisioned that the temporary active command failure can be handled effectively and in accordance with the prior protocols agreed upon by both the mobile terminal and the UICC regarding processing. The examples described herein are envisioned for use in many applications, some of which are described below.

[0086] Now for reference Figure 11This document illustrates an example 1100 of a use case in which a UICC 1120 receives communication from a communication terminal 1110 via path 1115, and the communication terminal 1110 receives communication from a peripheral device / remote attachment server 1130, etc., via path 1135, according to some example embodiments. In the examples described herein, it should be noted that any communication failures occurring in communication path 1115 or communication path 1155 from the UICC 1120 to the communication terminal 1110 cannot be resolved, especially since these communication paths are critical for further communication between the communication terminal 1110 and the UICC 1120.

[0087] Example 1100 illustrates various use cases for temporary active command failures. For example, in some cases, it is envisioned that the failure can be identified within the communication terminal 1110 itself. For instance, the communication terminal 1110 may be too busy performing other functions or tasks, such as those with higher priority. Another example could be that the user of the communication terminal 1110 is not allowed to process or receive the requested active command. Yet another example could be that one or more parameters of the active command may be processed and determined to be unexpected. Yet another example could be that the communication terminal 1110 determines that its operating environment may not be relevant to or available for running the requested active command. Example 1100 also illustrates various other use cases for temporary active command failures unrelated to the active command (and / or the ability or expectation to process the active command). Such temporary active command failures include communication link failures in path 1135, where communication terminal 1110 receives communication from a peripheral device (embedded within or outside the communication terminal) / remote attachment server 1130, or communication link failures in path 1145, where UICC 1120 sends communication to the peripheral device / remote attachment server 1130. Such temporary active command failures also include situations where the connected device (e.g., peripheral / remote attachment server 1130) does not respond to communication terminal 1110 in the expected manner.

[0088] Those skilled in the art will recognize that active commands are crucial during UICC data updates. Essentially, in the first example, UICC activation is analogous to updating the relevant MNO data within the UICC, causing the UICC to function in the specific way the MNO expects. This data update is typically performed remotely, and two protocols are defined for this type of data transfer: SCP80 and SCP81. Therefore, the fundamental building blocks of these protocols are active commands, such as: for SCP81, 'Open Channel,' 'Timer Management,' 'Send Data,' 'Receive Data,' 'Close Channel'; and for SCP80, 'Send Short Message'. It should be noted that several other active commands may occur during this data update, depending on the applet (if any) targeted during the data update.

[0089] In the second example, to refresh the UICC content on the communication terminal side, a refresh (REFRESH) active command is primarily used. This refresh active command is typically used by a small program whenever any data on the UICC changes, and this needs to be notified to the communication terminal. Once a refresh is performed, the communication terminal must reread the data (depending on the refresh mode described in Section 8.6 of ETSI TS 102.223v17.02). Whenever the refresh fails, the communication terminal will not be able to reread the data, and therefore retaining outdated data may cause the UICC to malfunction.

[0090] Therefore, the example described herein eliminates the scenario where the use of active commands is entirely controlled by the communication terminal. In practice, the communication terminal is positioned to play a primary role in providing relevant information to the UICC (e.g., notifying the UICC of temporary active command failures and when the UICC can retry sending the active command). Thus, based on suggestions from the communication terminal, the UICC controls what to do after a temporary active command failure, such as waiting for the failure to be corrected or attempting to complete the sending of the active command at a later time, regarding when the UICC can retry sending the active command due to a temporary communication error on the communication terminal side or a temporary communication error identified by the communication terminal in the communication between the communication terminal and the UICC, or whether to completely discard the active session.

[0091] In the foregoing description, examples have been described with reference to specific examples of potential embodiments or applications. However, it should be understood that various modifications and changes may be made herein without departing from the scope set forth in the appended claims, and the claims are not limited to the specific examples described above.

[0092] The connections discussed herein can be of any type suitable for transmitting signals to or from a corresponding node, unit, or device, for example, via an intermediate means. Therefore, unless otherwise implied or stated, the connections can be, for example, direct or indirect connections. The connections can be shown or described as a single connection, multiple connections, unidirectional connections, or bidirectional connections. However, different embodiments may vary the implementation of the connections. For example, a single unidirectional connection may be used instead of a bidirectional connection, and vice versa. Furthermore, multiple connections may be replaced by a single connection that transmits multiple signals serially or in a time-division multiplexing manner. Similarly, a single connection carrying multiple signals may be divided into various different connections carrying subsets of these signals. Therefore, many options exist for transmitting signals. Those skilled in the art will recognize that the architectures depicted herein are merely exemplary, and in practice, many other architectures can be implemented to achieve the same functionality.

[0093] Any arrangement of components that perform the same function is effectively 'associated' in order to achieve the desired functionality. Therefore, any two components combined in this paper to achieve a particular function can be considered 'associated' with each other to enable the desired functionality, regardless of the architecture or intermediate components. Similarly, any two such associated components can also be considered 'operably connected' or 'operably coupled' with each other to achieve the desired functionality.

[0094] Furthermore, those skilled in the art will recognize that the boundaries between the operations described above are merely illustrative. Multiple operations may be combined into a single operation, a single operation may be distributed among other operations, and the execution of operations may overlap at least partially in time. Additionally, alternative embodiments may include multiple instances of a particular operation, and in various other embodiments, the order of operations may be changed. Furthermore, for example, in one embodiment, the illustrated example may be implemented as a circuit system located on a single integrated circuit or within the same device.

[0095] In some examples, the various components within the communication terminal and / or UICC can be implemented as discrete or integrated components, and thus the final structure is custom-designed or a matter of choice. Since the illustrated embodiments can be implemented extensively using electronic components and circuitry known to those skilled in the art, details will not be explained to a greater extent than is deemed necessary for understanding and appreciating the underlying concepts described herein and to avoid confusion or distraction from the teachings. Those skilled in the art will understand that, in some cases, the level of integration of the processor and memory circuitry within the communication terminal and / or UICC can be implementation-dependent.

[0096] Additionally, for example, the described examples or portions thereof may be implemented, for instance, as a physical circuit system or a software or code representation that can be converted into a logical representation of a physical circuit system, using any suitable type of hardware description language. Furthermore, the described examples are not limited to physical devices or units implemented in non-programmable hardware, but can also be applied to programmable devices or units capable of performing desired sampling errors and compensations by operating according to suitable program code, such as microcomputers, personal computers, notebooks, personal digital assistants, automotive and other embedded systems, cellular phones and various other wireless devices, collectively referred to in this application as 'computer systems'. However, other modifications, variations, and alternatives are also possible. Therefore, the specification and drawings should be viewed in an illustrative rather than restrictive sense.

[0097] In the claims, any reference numerals placed in parentheses should not be construed as limiting the claims. The word 'comprising' does not exclude the presence of other elements or steps different from those listed in the claims. Furthermore, as used herein, the terms 'a' or 'an' are defined as one or more. Additionally, the use of introductory phrases such as 'at least one' and 'one or more' in the claims should not be construed as implying that another claim element introduced by the indefinite article 'a' limits any particular claim containing such an element to an invention containing only one such element, even when the same claim includes the introductory phrase 'one or more' or 'at least one' and an indefinite article such as 'a'. The same applies to the use of definite articles. Unless otherwise stated, terms such as 'first' and 'second' are used to arbitrarily distinguish the elements described by such terms. Therefore, these terms are not necessarily intended to indicate a temporal or other priority order of such elements. The mere fact that certain measures are recited in claims that differ from one another does not imply that combinations of these measures cannot be used to gain an advantage.

Claims

1. A method for handling temporary active command failures between a general-purpose integrated circuit card (UICC) (320) and a communication terminal (310), characterized in that, The method includes the following at the UICC (320): Receive communication from the communication terminal (310); In response, an active command is sent to the communication terminal (310); In response to the active command, a notification of a temporary active command failure between the general-purpose integrated circuit card UICC (320) and the communication terminal (310) is received, wherein the notification includes the expected duration of recovery from the temporary active command failure; as well as Implement a strategy for handling the failure of the temporary active command in processing the communication according to the notification, wherein the strategy includes one of the following: Before resending the active command, wait for a period of time exceeding the expected duration; Before resending the active command, wait for the prior time period agreed upon between the UICC (320) and the communication terminal (310); The active command is resent in response to a subsequent event initiated by the communication terminal (310) and notified to the UICC (320) in the notification; The communication between the UICC (320) and the communication terminal (310) is terminated.

2. The method according to claim 1, characterized in that, The notification of the failure of the temporary active command includes one or more of the following: The communication terminal (310) is restored to its expected state for the duration during which it is able to process the active command that failed due to the failure of the temporary active command; Information identifying subsequent events, wherein the events indicate that the communication terminal (310) is in a state capable of receiving the active command; The status of the communication terminal; The status of the current UICC command executed by the communication terminal (310).

3. The method according to claim 1 or claim 2, characterized in that, This also includes the UICC resending the active command within a limited number of attempts.

4. The method according to claim 3, characterized in that, The finite number of attempts is configurable.

5. The method according to any one of the preceding claims, characterized in that, Additionally, the UICC decides not to resend the active command until the UICC (320) is aware of the status of the communication terminal (310).

6. The method according to any one of the preceding claims, characterized in that, In addition, including: The UICC (320) determines that the expected duration of recovery from the failure of the temporary active command in the notification is unacceptable to the UICC (320); and The UICC (320) decides to send the active command without waiting.

7. The method according to any one of the preceding claims, characterized in that, Additionally, this includes the communication terminal (510): Processing (550) the active command; and Send the notification (555) to the UICC (520), wherein the notification includes the expected duration of recovery from the failure of the temporary active command; And at UICC(520): When the UICC (520) disagrees with the expected duration of waiting for recovery, the communication session is terminated in response to sending the notification (555) to the UICC (520) without any subsequent retry attempts.

8. A general-purpose integrated circuit card (UICC) (320) for handling temporary active command failures between the UICC (320) and a communication terminal (310), characterized in that, The UICC (320) includes: A receiver is arranged to receive communications from the communication terminal (310); A transmitter is configured to send an active command to the communication terminal (310) in response to this; A processor, which is operatively coupled to the receiver and transmitter; The receiver is configured to receive a notification of a temporary active command failure between the UICC and the communication terminal (310) in response to the active command, wherein the processor is configured to: The notification is determined to include the expected duration of recovery from the failure of the temporary proactive command; and Based on the notification, a strategy is implemented to address the failure of the temporary active command in processing the communication, wherein the strategy includes one of the following: Before resending the active command, wait for a period of time exceeding the expected duration; Before resending the active command, wait for the prior time period agreed upon between the UICC (320) and the communication terminal (310); The active command is resent in response to a subsequent event initiated by the communication terminal (310) and notified to the UICC (320) in the notification; The communication between the UICC (320) and the communication terminal (310) is terminated.

9. The UICC (320) according to claim 8, characterized in that, The notification of the failure of the temporary active command includes one or more of the following: The communication terminal (310) is restored to its expected state for the duration during which it is able to process the active command that failed due to the failure of the temporary active command; Information identifying subsequent events, wherein the events indicate that the communication terminal (310) is in a state capable of receiving the active command; The status of the communication terminal; The status of the current UICC command executed by the communication terminal (310).

10. A communication terminal (310) for handling temporary active command failures between the communication terminal and a general-purpose integrated circuit card (UICC) (320), characterized in that, The communication terminal (310) includes: A transmitter is configured to send communications to the UICC (320); A receiver is configured to receive an active command from the UICC (320) in response to this; A processor, operatively coupled to the receiver and transmitter, is arranged such that: Processing the active command, and A temporary active command failure is determined between the UICC (320) and the communication terminal (310), and accordingly, the transmitter sends a notification of the temporary active command failure, wherein the notification includes the expected duration of recovery from the temporary active command failure.

Images