Automated UICC recovery

Deployment of UICCs in IoT and M2M devices requires that the interface between UICC functions reliably in extreme temperature conditions. Extreme conditions may cause communication failures between the UICC and its device. The present application proposes various methods and devices for automatic recovery from UICC failure and UICC communication failures, commonly associated with extreme conditions (e.g., high temperature, low temperature, physical shock). The automatic recovery procedure includes applying one or more increased drive strength to the identity card, and may further include varying voltage and/or clock rate.

BACKGROUND

A wireless communication device may include one (or more) subscriber identity modules (SIMs), which the wireless communication device may use to communicate with one or more cells of a wireless communication network. A SIM is an integrated circuit that is intended to securely store the international mobile subscriber identity (IMSI) number which serves to identify and authenticate subscribers on mobile devices (such as mobile phones and computers). SIM cards are used on GSM phones, and LTE handsets. SIM cards can also be used in satellite phones, smart watches, computers, or cameras.

Embedded SIMs are a typical choice for machine-to-machine (M2M) applications, such as internet-of-things (IoT) environments because they come embedded onto a device's circuit board. Embedded SIMs (eSIM), also referred to as a Universal Integrated Circuit Cards (UICC), have benefits over traditional removable SIMs. The GSMA Embedded SIM Specification provides a standard mechanism for remote provisioning and management of M2M connections. This allows for “over the air” provisioning of the SIM. These SIMs can be remotely provisioned to connect to an initial operator and subsequent operators. Further, embedded SIMs have better reliability in terms of reducing malfunction due to shocks, corrosion and other environmental factors. Additionally, the lifecycle of an embedded SIM is usually 10 years, longer than that of a standard SIM form factor.

SUMMARY

When deploying UICCs in IoT and M2M devices, the interface between UICC and the device should function reliably in extreme conditions (e.g., high temperature, low temperature, physical shock). However, extreme conditions may cause communication failures between the UICC and a device. The present application proposes various methods and apparatus capable of automatically recovering from UICC failure and/or UICC communication failures, commonly associated with extreme conditions.

In one aspect of the disclosure, a method, a computer-readable medium, and an apparatus are provided. The apparatus may be a user equipment, such as a cellular handset, an IoT device, M2M device, MTC device, or other category of communication device. The apparatus may access an identity card (e.g., SIM, eSIM, UICC). The apparatus may detect timeout of an identity card and perform a recovery procedure for the identity card, wherein the recovery procedure comprises applying at least one increased drive strength to the identity card, which may then receive an answer-to-reset (ATR) from the identity card in response to the recovery procedure. The recovery procedure may include applying a plurality of drive strengths to the identity card, including iteratively increasing the drive strength. The drive strength may be a data drive strength. In one example, a clock drive strength is kept constant while the data drive strength is interactively increased. The recovery procedure may further include operating the identity card using a plurality of clock rates or applying a plurality of voltages to the identity card. Finally, the recovery procedure may include iteratively applying, to the identity card, a combination of a drive strength, a voltage, or a clock rate determined from at least two sets from a set of data drive strengths, a set of clock drive strengths, a set of reset line drive strengths, a set of clock rates, or a set of voltages.

DETAILED DESCRIPTION

The term “wireless communication device” is used interchangeably herein to refer to any one or all of cellular telephones, smart phones, personal or mobile multi-media players, personal data assistants (PDAs), laptop computers, tablet computers, smart books, palm-top computers, wireless electronic mail receivers, multimedia Internet enabled cellular telephones, wireless gaming controllers, IoT devices, M2M communication devices, wireless-enabled sensors, wireless-enabled appliances, and similar electronic devices that include a programmable processor and memory and circuitry for establishing wireless communications and transmitting/receiving data via wireless communications. Alternatively, the wireless communication device may be a component of another device for providing access to wireless communications.

A wireless communication device may include connectors for one (or more) SIM cards. A SIM enables the wireless communication device to access one or more communication networks (or one or more subscriber accounts on the same network). A SIM card may identify and authenticate a subscriber using a particular communication device, and the SIM card may be associated with a subscription. In various embodiments, the wireless communication device may also include one or more RF resource chains that may each be used for RF reception and transmission.

A wireless communication device may be capable of communicating over a variety of frequency bands, wireless communication systems (e.g., wide area network (WAN), Wireless Fidelity (Wi-Fi), or Near Field Communication (NFC)), and radio access technologies (RATs) within a WAN (e.g., 3GPP Long Term Evolution (LTE), 5G New Radio (NR), Global System for Mobility (GSM), and Wideband Code Division Multiple Access (WCDMA)). To use different frequency systems and/or radio access technologies, a wireless communication device may include two or more radio transceivers.

Various embodiments may be implemented in wireless communication devices that may operate within a variety of communication systems, particularly systems that include communication networks.FIG. 1illustrates a communication system100suitable for use with various embodiments. A wireless communication device102may communicate with a communication network104. The communication network104may include one or more base stations (e.g., cellular base station106).

The wireless communication device102may communicate with the first communication network104through a communication link108to the base station106. The first base station124may communicate with the first communication network104over a wired or wireless communication link110, which may include fiber optic backhaul links, microwave backhaul links, and other similar communication links. In some embodiments, the communication networks may include mobile telephony communication networks. In another embodiment, the communication network may be a private industrial communication network employed in manufacturing and/or device synchronization or coordination.

While the communication link108is illustrated as a single link, the communication links108may include a plurality of carrier signals, frequencies, or frequency bands, each of which may include a plurality of logical channels. In some embodiments, the communication links108may include cellular communication links using a wireless communication protocol such as 5G NR, LTE, GSM, WCDMA, Worldwide Interoperability for Microwave Access (WiMAX), Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), and other mobile telephony communication technologies.

FIG. 2is a component block diagram of a wireless communication device200suitable for implementing various embodiments. With reference toFIGS. 1 and 2, in various embodiments, the wireless communication device200may be similar to the wireless communication device102. The wireless communication device200may include a subscriber identity module (SIM) interface202, which may receive an identity module SIM204that is associated with a subscription.

A SIM in various embodiments may be a Universal Integrated Circuit Card (UICC) that is configured with SIM and/or USIM (Universal Subscriber Identity Module) applications, enabling access to, for example, wireless communication networks. The UICC may also provide storage for a phone book and other applications. A SIM used in various embodiments may contain user account information, an international mobile subscriber identity (IMSI), a set of SIM application toolkit (SAT) commands and storage space. A SIM card may further store a Home-Public-Land-Mobile-Network (HPLMN) code to indicate the SIM card network operator provider. An Integrated Circuit Card Identity (ICCID) SIM serial number may be printed on the SIM card for identification. The SIM may be an embedded SIM (e.g., a UICC) that is permanently embedded in a communication device.

The wireless communication device200may include at least one controller, such as a general-purpose processor206, which may be coupled to a coder/decoder (CODEC)208. The CODEC208may in turn be coupled to a speaker210and a microphone212. The general-purpose processor206may also be coupled to at least one memory214. The memory214may be a non-transitory computer-readable storage medium that stores processor-executable instructions. For example, the instructions may include routing communication data relating to the first or second subscription through a corresponding baseband-RF resource chain. The memory214may store an operating system, as well as application software and executable instructions. The memory214may also store application data.

The general-purpose processor206may be coupled to a modem230. The modem230may include at least one baseband modem processor216, which may be coupled to a memory222and a modulator/demodulator228. The baseband modem processor216may include physically or logically separate baseband modem processors. The modulator/demodulator228may receive data from the baseband modem processor216and may modulate a carrier signal with encoded data and provide the modulated signal to an RF resource218for transmission. The modulator/demodulator228may also extract an information-bearing signal from a modulated carrier wave received from an RF resource218, and may provide the demodulated signal to the baseband modem processor216. The modulator/demodulator228may be or include a digital signal processor (DSP).

The baseband modem processor216may read and write information to and from the memory222. The memory222may also store instructions associated with a protocol stack, such as a protocol stack. A protocol stack generally includes computer executable instructions to enable communication using a radio access protocol or communication protocol. The protocol stack typically includes network protocol layers structured hierarchically to provide networking capabilities. A protocol stack may be associated with the SIM card204(e.g., a UICC) and/or a subscription. For example, the protocol stack may be associated with the SIM204. The memory222may store one or more protocol stacks (not illustrated).

The SIM204in the wireless communication device200may be coupled to the modem230and may be associated with or permitted to use at least one RF resource chain per RAT. A RAT (e.g., a LTE RAT, 5G NR RAT) may be associated with RF resource218. Wireless communication device200may operate and communicate with SIM204via SIM interface202. The SIM interface202may communicate with SIM204using a plurality of input and output lines matched to pins on SIM204. SIM interface202may operate SIM204using a plurality of input lines including, but not limited to, a voltage line, a reset line, a clock line, a ground line, and a data line. The SIM interface202may also receive output from SIM204via a plurality of output lines including, but not limited to, a voltage line, a clock line, a ground line, and a data line.

Each baseband-RF resource chain may include the baseband modem processor216to perform baseband/modem functions for communicating with/controlling a RAT, and one or more amplifiers and radios, referred to generally herein as RF resources. In some embodiments, baseband-RF resource chains may share a common baseband modem processor216(i.e., a single device that performs baseband/modem functions for all RATs on the wireless communication device). Alternatively, each baseband-RF resource chain may include the physically or logically separate baseband processors.

The RF resources218may include transceivers associated with one or more RATs and may perform transmit/receive functions for the wireless communication device200on behalf of their respective RATs. The RF resources218may include separate transmit and receive circuitry. The RF resources218may be coupled to a wireless antenna (e.g., a wireless antenna220). The RF resources218may also be coupled to the modem230(e.g., via the modulator/demodulator228, or alternatively via the baseband modem processor216or another component). The term “RF resource chain” may include an RF resource (e.g., the RF resource218), an antenna (e.g., the antenna220), and one or more components of the modem230.

In some embodiments, the general-purpose processor206, memory214, baseband processor(s)216, and RF resource218may be included in the wireless communication device200as a system-on-chip. Conversely, the general-purpose processor206, memory214, baseband processor(s)216, and RF resource218may be the packaged as separate components in a device. SIM204and corresponding interface202may be external to the system-on-chip. Further, various input and output devices may be coupled to components on the system-on-chip, such as interfaces or controllers. The wireless device200may or may not include input components such as, but not limited to, a keypad224, data source232, and/or a touchscreen display226. Data source232may be a sensor, appliance, or any device capable of providing data to the wireless communication device.

In some embodiments, the keypad224, touchscreen display226, data source232, microphone212, or a combination thereof, may perform the function of receiving the request to initiate an outgoing communication. For example, the touchscreen display226, keypad224, or microphone212may function to initiate an outgoing communication. As another example, the request to initiate the outgoing communication may be user driven or device driven (i.e., algorithmically driven). Interfaces may be provided between the various software modules and functions in the wireless communication device200to enable communication between them.

When deploying UICCs in IoT and M2M devices, the interface between the UICC and the device should function reliably in extreme conditions. However, extreme conditions may trigger communication failures between a device and its UICC. It is common for UICCs to timeout in different climatic conditions. In extreme climatic conditions, the eSIM card may need more current to respond to Application Protocol Data Unit (APDU) commands sent to the card. This can be due to a failure at the UICCs interface (e.g., the contacts or touch points between the device a UICCs fail to communicate). The problem is compounded by the fact that a UICC cannot simply be removed and replaced, as it is an embedded component in a device.

Conventionally, when communication with the UICC fails, the user is forced to re-power the device or the device software triggers silent recovery one or more times using the last successful operating configuration for the card. The last successful operating configuration for the card may correspond to a last successful clock rate, voltage, and drive strength(s) used to operate the card before declaring a card error. This can also include specific drive strengths of the various input lines of the card (e.g., reset line, clock line, data line). If there is no response from the card after repeated communication attempts the device gives up and declares failure.

The present application proposes various methods and devices to automatically recover from UICC failure and UICC communication failures, commonly associated with extreme conditions (e.g., high temperature, low temperature, physical shock). In one embodiment, the device may use varied drive strengths, clock rates, and voltages when performing a recovery procedure to improve the likelihood of successful UICC recovery.

FIG. 3illustrates a process300by which a UE302attempts to perform a recovery procedure when detecting a timeout associated with UICC304. The process illustrates communication between UE302and UICC304. While shown as separate devices, as noted above, with reference toFIG. 2, UICC304may be a component of UE302and the communication between the UE302and UICC304may be between the UICC and a baseband processor of the UE302. UE302and UICC304communicate via a UICC interface (not shown).

At305, the UE302communicates an APDU to UICC304.

At310, the UE302detects a timeout associated with UICC304. The timeout may result due to the UICC304failing to respond to the APDU within a predetermined time period. Alternatively, the UE302may detect an error that triggers a recovery procedure (e.g., parity errors in data line communication from the UICC), or the recovery procedure may be manually triggered by the network or a user.

At315, in response to the timeout310, the UE302may perform a recovery procedure to reset the UICC304. This recovery procedure may include attempting to communicate a reset command to the UICC using the last successful operating configuration associated with the UICC304. For example, the UE302may use the last successful operating configuration associated with the UICC304. Thereafter, UE302may monitor for an ATR response from UICC304. If the UE302does not receive an ATR response from the UICC304within a specified period of time, the UE302may again send the reset command to the UICC304and await an ATR response. This process may of sending a reset request and awaiting an ATR response may be repeated a specified number of times. If no ATR response is received after the process is repeated the specified number of time (e.g., 3), the UE302may declare a UICC recovery failure.

At320, the UE302detects a recovery failure associated with UICC304. This may be, for example, a timeout resulting from a failure of the UICC304to provide an answer-to-reset (ATR) response or detection of signaling errors in the UICC response (e.g., parity errors in the data provided by the UICC to the UE302).

Following320, the UE302may perform a dynamic recovery procedure to reset the UICC304. This dynamic recovery procedure may include attempting to communicate a reset command to the UICC using different drive strengths, clock rates, or voltages. At325ato325n, the UE302may attempt to iteratively send UICC304a reset command using different drive strengths, clock rates, or voltages (and monitor for an ATR) until, at335, the UICC successfully returns an ATR response. Alternatively, the UE302may determine, after sending a plurality of reset commands, that the UICC is not recoverable.

At340, after receiving an ATR from UICC304, the UE302may perform UICC initialization.

As noted above, the dynamic recovery procedure may include attempting to communicate a reset command to the UICC using different drive strength, clock rates, or voltages. Drive strength refers to the current that can be drawn by the UICC on a given input line, while maintaining the appropriate voltages for logic level inputs. Increasing the drive strength of a line increases a corresponding output current from the UICC, and so affects the voltage received by the UICC. Drive strength may be increased for various input lines from the UE to the UICC. For example, at a previously drive strength on a given line, a voltage at UICC input may be 1.2V. By increasing the current on the given line, the voltage at UICC input may rise to 1.8V. Drive strength can be different for the data line, clock line, and reset line. Accordingly, it is possible to vary or increase the line strengths for the data line, clock line, and reset line. Increasing the drive strength from a line, while maintaining the same voltage, allows more amps to be drawn from the output of the UICC.

Furthermore, increasing the drive strength for a given line, makes that line more robust to climate conditions. For example, if there is hardware interference or climatic conditions, an input line signal (e.g., a clock line signal) may not reach the UICC or the UICC may experience some distortions. Increasing the drive strength may eliminate or reduce the interference, allowing the signal to pass to the UICC.

For example, the UE may initially send a reset command using a low drive strength (e.g., 2 mA) to the reset line. If no response is detected, the UE may then incrementally increase the drive strength of the line and retry sending the reset command to the UICC until it reaches a maximum drive strength (e.g., 16 mA). By example, the UE302may iterate through reset commands using drive strengths of 2 mA, 4 mA, 6 mA, 8 mA, and 16 mA.

Serial communication with the UICC is based on a clock rate that is driven by a clock pin at the UICC via the clock line. Conventional UICCs may support two clock rates: 3.8 Mhz and 4.8 MHz (also referred to as 4 Mhz and 5 Mhz). If a UICC was last operated at 4.8 MHz, the UE302may attempt to change the clock rate to a lower clock rate to improve the likelihood of a UICC response. For example, the UE may attempt to reduce the clock rate from 4.8 Mhz to 3.8 Mhz when performing the dynamic recovery procedure.

Additionally, the UE302may attempt to change the input voltage to the UICC. UE302may support operating the UICC at different voltages and may attempt varying the input voltage provided to the UICC. For example, the UICC304may support voltages of 3V and 1.8V (which may correspond to class B and class C devices). UICC304may also support 5V (corresponding to class E devices).

In a further example, the UE302may iteratively vary all three variables (e.g., drive strength, clock rate, and voltage). The UE302may also vary drive strengths between the data line, clock line, and reset line. In one example, an implementation of the dynamic recovery procedure may employ three nested loops, varying drive strength in an inner loop, varying voltage in a middle loop, then varying clock rate in the outer loop. Alternatively, the different combinations of drive strengths, clock rates, and voltages may be placed into a set of all possible value combinations, and the UE302may iterate through the different combinations of elements of the set (each element corresponding to a different combination of drive strength, clock rate, and voltage). Furthermore, the implementation may include variation of the drive strengths for the data line, clock line, and reset line.

FIG. 4illustrates an example of a procedure for performing a UICC recovery procedure. The procedure employs three nested loops, varying drive strength in an inner loop, varying voltage in a middle loop, and varying clock rate in the outer loop.

At402, the UE communicated an APDU to UICC. At404, the UE detects an error associated with UICC. The error may be a timeout (e.g., if the UICC fails to respond to the APDU within a predetermined time period), detection of an error that triggers a recovery procedure (e.g., parity errors in communications from the UICC), or the recovery procedure may be triggered by the network or a user.

At406, the UE406may perform a simple recovery procedure to reset the UICC. This recovery procedure may include attempting to send a reset command to the UICC on the reset line using the last successful operating configuration associated with the UICC. Thereafter, UE may monitor for an ATR response from UICC. The UE may attempt to send a reset command to the UICC using the last successful operating configuration a predetermined number of times (e.g., 3).

At408, the UE initializes the clock rate, the voltage, and the drive strength to an initial set of values. The initial values may be based on the last known UICC operating configuration, or may correspond to a minimal or power optimal set of values. For example, or alternatively, the clock rate may be set to 4.8 Mhz, the voltage may be set to 1.8V, and the drive strength may be set to 2 mA.

At410, the UE determines if recovery has been attempted with all clock rates. Alternatively, the UE may check if the last recovery attempt used the lowest clock rate (e.g., 3.8 MHz). If all clock rates have been attempted or the maximum clock rate has been attempted, the UE may indicate an UICC failure at426. If recovery should be attempted with further clock rates, the process proceeds to412.

At412, the UE determines if recovery has been attempted with all voltages. Alternatively, the UE may check if the last recovery attempt used the maximum voltage (e.g., 3V or 5V). If all voltages have been attempted or the maximum voltage has been attempted, then the UE, at424, may iterate to the next clock rate, reset the voltage, and return to410. If recovery should be attempted with further voltages, then the process proceeds to414.

At414, the UE determines if recovery has been attempted with all drive strengths. Alternatively, the UE may check if the last recovery attempt used the maximum drive strength (e.g., 16 mA). If all drive strengths have been attempted or the maximum drive strength has been attempted, then the UE, at422, may iterate to the next voltage, reset the drive strength, and return to412. If recovery should be attempted, then the process proceeds to416.

At416, the UE attempts to transmit a reset command to the UICC using a clock rate, voltage, and drive strength. At418, if the UE receives an ATR from the UICC, then the UE can begin UICC initialization, at420. If the UE does not receive an ATR within a timeout period, then the UE iterates to the next drive strength (e.g., increases the drive strength), at424, and proceeds to414.

WhileFIG. 3illustrates an example of a UICC recovery procedure using nested loops, other implementations would fall within coverage of the present invention. Alternative examples could iterate over combinatorial sets of clock rates, voltages, and drive strength values. Furthermore, the nested loops of method300may be restructured in different arrangements.

FIG. 5illustrates a method500of performing UICC recovery. The method automatically recovers from UICC failure and UICC communication failures, commonly associated with extreme conditions. The method may be performed by a UE. The UE may be an IoT device, MTC device, or any network device employing an identity card, such as a SIM, eSIM, or UICC. Optional steps or implementations are illustrated using dashed lines.

At step502, UE may detect a timeout of an identity card. The timeout may result when the identity card fails to respond to a data line communication within a predetermined time period. Alternatively, the UE302may detect an error that triggers a recovery procedure (e.g., parity errors in communications from the UICC), or the recovery procedure may be triggered by the network or a user

At step504, UE may perform a recovery procedure. Step504may be implemented using one or a combination of sub-step506,508,510, and/or512. The recovery procedure may apply a plurality of drive strengths to at least one input line associated with the identity card506. The recovery procedure may include applying at least one increased drive strength to the at least one input line associated with the identity card, relative to a drive strength associated with a previously known successful operating configuration. This can include iteratively increasing the drive strength. The drive strength may be applied to a data line. In one example, the UE may keep a voltage or a clock rate (applied to the identity card via the respective lines) constant while the data line or reset line drive strength is iteratively increased. The recovery procedure may include operating a clock line associated with the identity card using a plurality of clock rates508or operating a voltage line associated with the identity card using a plurality of voltages510. Furthermore, the recovery procedure may further comprise iteratively applying to the identity card, combinatorial sets of drive strengths, voltages, or clock rates512. The drive strengths, voltages, or clock rates may be selected from a set of data line drive strengths, a set of clock line drive strengths, a set of reset line drive strengths, a set of clock rates, or a set of voltages.

At step514, UE may receive an ATR response from the identity card in response to the recovery procedure. Following receipt of the ATR response, the UE may perform UICC initialization using the last attempted combination of drive strength, clock rate, and voltage used during the recovery procedure.

Various embodiments illustrated and described are provided merely as examples to illustrate various features of the claims. However, features shown and described with respect to any given embodiment are not necessarily limited to the associated embodiment and may be used or combined with other embodiments that are shown and described. Further, the claims are not intended to be limited by any one example embodiment.

Various embodiments (including, but not limited to, embodiments discussed above with reference toFIGS. 1-5) may be implemented in any of a variety of wireless communication devices, an example of which (e.g., wireless communication device600) is illustrated inFIG. 6. With reference toFIGS. 1-5, in various embodiments, the wireless communication device600(which may correspond, for example, to the wireless communication devices102and200) may include a processor602coupled to a touchscreen controller504and an internal memory606. The processor602may be one or more multi-core integrated circuits designated for general or specific processing tasks. The internal memory606may be volatile or non-volatile memory, and may also be secured and/or encrypted memory, or unsecured and/or unencrypted memory, or any combination thereof. The touchscreen controller604and the processor602may also be coupled to a touchscreen panel612, such as a resistive-sensing touchscreen, capacitive-sensing touchscreen, infrared sensing touchscreen, etc. Additionally, the display of the wireless communication device600need not have touch screen capability.

The wireless communication device600may have two or more radio signal transceivers608(e.g., Peanut, Bluetooth, ZigBee, Wi-Fi, RF radio) and antennae610, for sending and receiving communications, coupled to each other and/or to the processor602. The transceivers608and antennae610may be used with the above-mentioned circuitry to implement the various wireless transmission protocol stacks and interfaces. The wireless communication device600may include one or more cellular network wireless modem chip(s)616coupled to the processor and antennae610that enable communication via two or more cellular networks via two or more radio access technologies.

The wireless communication device600may include a peripheral device connection interface coupled to the processor602. The peripheral device connection interface may be singularly configured to accept one type of connection, or may be configured to accept various types of physical and communication connections, common or proprietary, such as USB, FireWire, Thunderbolt, or PCIe. The peripheral device connection interface may also be coupled to a similarly configured peripheral device connection port (not shown).

In addition, the wireless communication device600may include speakers614for providing audio outputs. The wireless communication device600may also include a housing unit620, constructed of plastic, metal, or a combination of materials, for containing all or some of the components discussed herein. The wireless communication device600may include a power source622coupled to the processor602, such as a disposable or rechargeable battery. The rechargeable battery may also be coupled to the peripheral device connection port to receive a charging current from a source external to the wireless communication device600. The wireless communication device600may include a physical button624for receiving user inputs. The wireless communication device600may also include a power button626for turning the wireless communication device600on and off.

The processor602may be any programmable microprocessor, microcomputer or multiple processor chip or chips that can be configured by software instructions (applications) to perform a variety of functions, including the functions of various embodiments described below. In some wireless communication devices, multiple processors602may be provided, such as one processor dedicated to wireless communication functions and one processor dedicated to running other applications. Typically, software applications may be stored in the internal memory606before they are accessed and loaded into the processor602. The processor602may include internal memory sufficient to store the application software instructions.

Various embodiments may be implemented in any number of single or multi-processor systems. Generally, processes are executed on a processor in short time slices so that it appears that multiple processes are running simultaneously on a single processor. When a process is removed from a processor at the end of a time slice, information pertaining to the current operating state of the process is stored in memory, so the process may seamlessly resume its operations when it returns to execution on the processor. This operational state data may include the process's address space, stack space, virtual address space, register set image (e.g., program counter, stack pointer, instruction register, program status word, etc.), accounting information, permissions, access restrictions, and state information.

A process may spawn other processes, and the spawned process (i.e., a child process) may inherit some of the permissions and access restrictions (i.e., context) of the spawning process (i.e., the parent process). A process may be a heavyweight process that includes multiple lightweight processes or threads, which are processes that share all or portions of their context (e.g., address space, stack, permissions, and/or access restrictions, etc.) with other processes/threads. Thus, a single process may include multiple lightweight processes or threads that share, have access to, and/or operate within a single context (i.e., the processor's context).