Autonomous and resilient integrated circuit devices

Abstract

[0003] A Universal Integrated Circuit Card (UICC) is provided for controlling wireless communication over a wireless communication network with a host device in which the UICC is installed, the UICC comprising: a microprocessor for controlling operation of the UICC; a data store for storing data related to operation of the UICC, the data store including a plurality of mobile carrier network profiles, the data store including an operational profile including wireless communication network settings for connecting the host device to a first wireless communication network and a bootstrap profile including wireless communication network settings for connecting the host device to a second wireless communication network; and a program including a plurality of instructions for configuring operation of the UICC, wherein, in use, the microprocessor is configured by the program to connect the host device to the first wireless communication network using the operational profile, detect a loss of operational connectivity with the first wireless communication network, and connect the host device to the second wireless communication network using the bootstrap profile to re-establish wireless communication with the host device. [0004] A host device is further provided, comprising: a processor having a memory, a radio module for connecting the host device to the wireless communication network, and the universal integrated circuit device. Further provided are methods of operating a UICC and computer-implemented methods of re-establishing a wireless communication network connection between a host device and a network platform providing the wireless communication network connection, the host device comprising a UICC.

Description

[Technical Field]

[0001] The present invention relates to an autonomous and resilient Universal Integrated Circuit Device (UICC), and in particular but not exclusively to a UICC for controlling wireless communications over a wireless communications network with a host device in which the UICC is installed in use. [Background technology]

[0002] Alarm signal transmission device and alarm network In the event of an emergency, communications from the location of the emergency, those requiring emergency services, or other entities requiring emergency alerts must be fast, responsive, and accurate. For example, in police and fire response, blue light emergency response, and Telecare personal alarm systems, the speed and reliability of communications are crucial because emergencies can lead to life-threatening situations. However, current systems in this area suffer from connectivity challenges and outages, resulting in unreliable communication channels. This can result in slow and unresponsive signal transmissions to emergency services. When Telecare personal alarm systems are used, slow response or speed of signal transmissions to emergency medical services or nearby caregivers can pose a risk to the health or even the life of the person in need. In the case of an intrusion alarm system, slow response or speed of signal transmissions to police emergency response can result in an intruder or attacker fleeing after committing their crime.

[0003] In remote monitoring of alarm systems, there are several mainstream signaling methods—Redcare, DualCom, and Digicom—that transmit signals between alarm devices and remote alarm receiving centers, which can subsequently alert emergency services or other entities that require emergency alerts. Redcare uses dual-path signaling, which means it communicates with the remote alarm receiving center using both a Global System for Mobile (GSM) wireless network path and a telephone line. Both signaling paths are constantly polled to ensure the communication link is up and to indicate whether the line has a fault or failure. Emizon also employs dual-path signaling, using a GSM wireless network path and an on-site broadband connection. DualCom GPRS, manufactured by CSL DualCom Limited, is also a dual-path signaling device for intrusion alarms that uses GSM wireless networks (GSM wireless networks with general packet radio service (GPRS) and GSM wireless networks without GPRS) and wired telephone and / or Internet paths to transmit intruder, fire, and physical attack signals at high speed. If the first wireless communication path using a GPRS GSM link cannot transmit a signal, a second wireless communication path using a non-GPRS GSM link can be used instead. As another example, if a wired telephone path, e.g., a PSTN line, is cut, the intrusion alarm signal transmission device can communicate via either a GPRS GSM link or a non-GPRS GSM link using a mobile network, e.g., Vodafone PakNet, or a 2G mobile network. Unlike the signal transmission solutions described above, Digicom communicates with a remote alarm receiving center using a single path via a telephone line. A failure of the telephone line can result in a lack of communication capacity. Therefore, a dual-path connectivity solution may be incorporated into the security device to provide resilience against physical attacks and issues caused by service providers, such as mobile network operators (MNOs).

[0004] An alarm network 100 using dual path signaling to communicate between alarm devices 102 and a remote alarm receiving centre 104 is shown in Figure 1 (Prior Art). The alarm network 100 will now be described with illustrative reference to DualCom GPRS, the subject of European patent application published as EP 2124207 entitled "An alarm network".

[0005] The purpose of the alarm network 100 is to improve communication between alarm devices 102, such as intruder or fire alarm units, and a remote alarm receiving center 104. When an alarm condition is met, such as the detection of the presence of an intruder, the alarm devices 102 originate and transmit an alarm signal over the alarm network 100 to the remote alarm receiving center 104. The remote alarm receiving center 104 then takes appropriate action, which may include, for example, notifying the building manager or calling the police.

[0006] The alarm device 102 comprises a radio module 106 configured to transmit and receive over GSM wireless networks (GSM wireless networks with GPRS and GSM wireless networks without GPRS). A radio antenna 108 is connected to the radio module 106 and is configured to operate on GSM network frequencies and for use with GPRS. The alarm device 102 further comprises a SIM card 110. The SIM card 110 stores account and communication details that enable the radio module 106 to operate over the GSM network in accordance with GPRS. It is noted that the SIM card used in this particular example of DualCom GPRS connects to a single MNO, specifically Vodafone. Therefore, the alarm network described below uses a single MNO network, specifically the MNO 1 network 112 as shown in Figure 1. If the SIM contained within the alarm device is connectable to one of multiple MNOs, it is appropriate to use additional MNO networks, such as MNO 2 network 120 and MNO 3 network 124, and corresponding servers, MNO 2 server 122 and MNO 3 server 126. This is explained in more detail below with reference to a roaming SIM.

[0007] The alarm device 102 also includes an input interface (not shown), a microprocessor (not shown), non-volatile memory (not shown), and a telephone line interface (not shown) for providing communication with a public switched telephone network (PSTN) telephone line.

[0008] The alarm network 100 provides several communication paths between the alarm devices 102 and the remote alarm receiving centre 104. These are divided into a first wireless communication path using a GPRS GSM link, a second wireless communication path using a non-GPRS GSM link and a wired communication path using a PSTN line.

[0009] To establish a first wireless communication path using the GPRS GSM link, a GPRS GSM wireless communication link is first provided between the alarm device 102 and a GPRS base station (not shown) 112 of an MNO network (MNO 1 network in FIG. 1 ). A secure fixed line route is provided between the GPRS base station of the MNO network 112 and an MNO server 114 via the Internet 116, and a secure fixed line route is also provided between the MNO server 114 and a base station (not shown) of a wireless communication network 118. Finally, the base station communicates wirelessly with the remote alarm receiving centre 104 over the wireless communication network 118. As a specific example, the secure fixed line used in DualCom GPRS is provided by one or more leased lines or virtual private network (VPN) tunnels, and the wireless communication network 118 is provided by Paknet by Vodafone over an X.25 network such as that provided by Kilostream.

[0010] A second wireless communication path using a non-GPRS GSM link can similarly be established between the alarm device 102 and the remote alarm receiving centre 104. To establish the second wireless communication path using a non-GPRS GSM link, a non-GPRS GSM wireless communication link is first provided between the alarm device 102 and a GSM base station of the MNO network 112 (which may or may not be the same as the GPRS base station used in the first wireless communication path). The GSM base station of the MNO network 112 is in communication with a base station of the wireless communication network 118 over a secure fixed line route via the MNO server 114 and the Internet 116. Finally, the base station then communicates wirelessly with the remote alarm receiving centre 104 over the wireless communication network 118.

[0011] A first wired connection 128 is provided between the alarm device 102 and a telephone exchange 130, for example using a PSTN line or broadband, to establish a wired communication path between the alarm device 102 and the remote alarm receiving centre 104. A second wired connection 132, again using a PSTN line or broadband, is provided between the telephone exchange 130 and the alarm receiving centre 104. The telephone exchange 130 may also be connected to the Internet 116 via a wired connection. In DualCom GPRS, a PSTN line is used to establish a wired communication path between the alarm device 102 and the remote alarm receiving centre 104.

[0012] The DualCom GPRS alarm device has three modes of operation: "standby mode", "alert mode" and "link failure mode". In standby mode, the alarm device 102 periodically sends a polling signal over a first wireless communication path to the MNO server 114 (also known as a polling server) of the alarm network 100. The polling signal indicates to the MNO server 114 that the alarm device 102 is operating normally. If no polling signal is received after a predetermined time limit, the MNO server 114 sends an inquiry signal over a second wireless communication path to the alarm device 102 to check whether the alarm device 102 is operating normally. The inquiry signal Upon receiving the query signal, the alarming device 102 attempts to send a response signal over the second wireless communication path to confirm that the query signal was received and that the alarming device 102 is able to respond accordingly. Upon receiving the response signal, the MNO server 114 thereby confirms that the first wireless communication path is inoperable but the second wireless communication path is operational. In a similar manner, the alarming device 102 can detect whether the wired communication path is operational. Upon detecting that one of the communication paths has failed, the alarming device 102 enters link failure mode and notifies the MNO server 114 and the remote alarm receiving center 104 of the failure.

[0013] If an alarm condition is met, for example, if motion is detected, the alarm device 102 enters alarm mode. The alarm device 102 generates an alarm signal and transmits it to the remote alarm receiving center 104 so that appropriate action can be taken. The alarm device 102 attempts to transmit the alarm signal three times over a first wireless communication channel, then two times over a second wireless communication channel, and then two times over a wired communication channel. This routine ends when an acknowledgement signal is received from the remote alarm receiving center 104. The alarm device 102 then exits alarm mode. The purpose of this routine in alarm mode is to ensure that signal transmission is attempted over an operational path, thereby enabling successful communication with the remote alarm receiving center 104 if one or two of the communication channels become inoperable.

[0014] The prior art described with reference to Figure 1 and exemplified by DualCom GPRS provides multiple communication paths to increase the chances that an alarm signal will be transmitted to a remote alarm receiving center 104 that can continue to operate successfully even if some of these communication paths become inoperable.

[0015] A SIM card used in DualCom GPRS connects to a single MNO, specifically Vodafone. To further improve resilience in the signal transmission device, a roaming SIM can be used, which can connect to and operate on one of multiple MNO networks. For example, if the SIM 110 of the alarm device 102 shown in FIG. 1 is a roaming SIM, the roaming SIM can connect to not only the MNO 1 network 112 but also a second MNO (MNO 2) network 120 and a third MNO (MNO 3) network 124. The roaming SIM stores a first profile, a second profile, and a third profile associated with the MNO 1 network 112, the MNO 2 network 120, and the MNO 3 network 124, respectively. The MNO network with the most stable connection may be selected for the wireless path.

[0016] In typical mobile device applications, such as web browsing on a mobile phone, an "automatic roaming" algorithm is used to select and switch between MNO networks. Automatic roaming typically involves a user entering into a contract with a home MNO, which itself maintains a list of roaming MNOs with which it has roaming contracts. The list of roaming MNOs is then prioritized to provide a preferred list of roaming MNOs, so that if a connection with the home MNO fails, a connection is attempted to one of the roaming MNOs in the prioritized order. However, signal integrity is critical in alarm signal transmission devices, and the roaming MNO selected by automatic roaming may not provide the best signal integrity for a given area.

[0017] Other roaming algorithms have been developed for use in alarm devices that select a roaming MNO which improves signal integrity. For example, in a UK patent application published as UK Patent Application No. 2533853 entitled "Selecting a cellular network for communication of an alarm signal based on reliably of the available cellular networks," a roaming SIM, e.g., Vodafone GDSP, is used as part of the alarm device that selects the MNO network. Key features of an alarm device 202 with a roaming SIM are shown in Figure 2 (Prior Art) and are briefly described below.

[0018] The alarm device 202 comprises a wireless module 206 and an associated roaming SIM 210. The alarm device 202 further comprises a wireless antenna 208 connected to the wireless module 206 for transmitting and receiving GPRS data. The alarm device 202 also comprises a microcontroller 203 having a memory 205 including flash memory and non-volatile memory. The microcontroller 203 is connected to the wireless module 206. The microcontroller 203 processes data for transmission and data received by the wireless module 206 via the wireless antenna 208. The microcontroller 203 controls the wireless module 206 with respect to the transmission and reception of such data. The microcontroller 203 also controls the wireless link with the MNO network via the roaming SIM 210 associated with the wireless module 206. Thus, the microcontroller 203 controls and determines which MNO network the alarm device 202 is connected to. An algorithm called a connection manager 207 is held in memory 205 which, when executed on the microcontroller 203, enables data to be sent and received between the alarm device 202 and the internet via the MNO network.

[0019] The alarm device 202 also includes the following features associated with the microcontroller 203, but for simplicity these are not shown in Figure 2: a user interface, sensors, power management circuitry, external inputs / outputs, a PSTN interface, and a LAN interface.

[0020] The roaming SIM 210 is connectable to multiple MNO networks, such as an MNO 1 network 212, an MNO 2 network 220, and an MNO 3 network 224. The radio module 206 uses a survey function to provide information about the MNO networks 212, 220, and 224 at the location of the alarm device 202. The alarm device 202 then measures the reliability of communications through each of the available MNO networks 212, 220, and 224 based on signal strength. For each MNO network available at the location, the alarm device 202 instructs the radio module 206 and the roaming SIM 210 to connect to each available MNO network 212, 220, and 224 in turn. The alarm device 202 then instructs the radio module 206 via the radio antenna 208 to transmit a signal packet to a primary polling server (not shown) via the connected MNO network. In response, the primary polling server transmits the signal packet (not shown) back to the alarm device 202. The microcontroller 203 of the alerting device 202 analyzes the signal packets and stores data in memory 205 according to the cell signal quality, signal-to-noise ratio, number of cells within the coverage area of the alerting device 202, and bit error rate. The connection manager 207 then determines when to make a change in the MNO network and to which MNO network a connection should be made based on the data collected for each of the MNO networks 212, 220, 224. The connection manager 207 selects the most reliable MNO network. Through the connection manager 207, the microcontroller 203, radio module 206, and roaming SIM 210 are instructed to register and connect to the selected MNO network.

[0021] Some roaming SIMs are capable of roaming not only between MNO networks in their own country but also between MNO networks in other countries. Such international roaming SIMs are used in alarm devices to provide access to additional MNO networks. As an example, the DualCom Pro manufactured by CSL DualCom Limited uses an international roaming SIM, specifically a multi-network 4G WorldSIM International SIM. An international roaming SIM associated with a home network in its home country can be used in any other country that has a roaming agreement with the home network. For example, if a particular roaming SIM is associated with a home MNO that operates in a home country outside the UK, when powered on in the UK, the roaming SIM is not locked to a single MNO in the UK but can roam with all MNOs available in the UK that have roaming agreements with the home MNO. If one MNO experiences an outage as determined by the network, the SIM simply needs to be instructed to roam to the next available MNO. It provides access to all mobile networks and uses a roaming algorithm that selects the network with the strongest signal, thereby eliminating downtime.

[0022] Dual SIM alarm device Since 2018, an increase in MNO outages has been observed as 4G networks have become more frequent with network updates. To address this concern, alarm devices with multiple SIM slots and multiple associated radio modules, also known as dual-SIM, dual-radio alarm devices, were released in 2019. These devices have two or more SIM slots, allowing two or more SIM cards operating on two independent radio modules to be used within the same alarm device. If an MNO outage is detected by the device while using the primary SIM located in the primary SIM slot, the device can switch from the primary SIM slot to the secondary SIM slot. The secondary SIM located in the secondary SIM slot then connects to its respective MNO. For example, the GradeShift Pro Radio / Radio manufactured by CSL DualCom Limited uses two 4G World SIMs, one as the primary route and the other as the secondary route. Each SIM operates on an independent network and uses its own radio module.

[0023] eUICC SIM: Fallback and Fallback Cancellation Currently, the standard SIM card is the Universal Integrated Circuit Card (UICC) SIM, whose applications and data play a fundamental role in ensuring connectivity and security for alarm devices and networks. Based on existing UICC technology, the GSM Association (GSMA) has established a set of standards for embedded UICC (eUICC) (also known as eSIM) that enables the over-the-air (OTA) provisioning of MNO profiles (subscriptions) to eUICC SIMs. This allows SIM card operators to change the active MNO profile and connect the SIM to a different MNO network.

[0024] When designing the OTA capabilities of the eUICC, the main challenge that GSMA addressed was to make it possible to change the profile of a SIM without having to physically visit the device. For example, if a new MNO profile is sent to the SIM and for some reason the new MNO profile does not work, it is undesirable to lose contact with the SIM. OTA capabilities were intended to avoid the need to physically visit the device to change the SIM, which is expensive. If there is an error in switching to the new profile, the device will lose connectivity and become useless until it can be repaired by a physical visit.

[0025] The GSMA has defined two separate implementations of the eUICC. The first implementation is directed to consumer selection of an MNO network (also known as the "consumer solution"). In the "direct-to-consumer" channel, targeting consumers and businesses, this solution is needed when the end user (or consumer) directly selects the MNO that will provide the network connection. Alternative MNO profiles are pulled to the eUICC and the consumer's device. Because the consumer's device has a keyboard and a screen, the device can present options that allow the consumer to actively select the MNO that will provide the network connection. This is known as a "pull (to device) solution." As an example, an Apple SIM can be configured with different MNO profiles and present the different MNO profiles to the user via the mobile device's user interface. This allows the user to actively pick and select an MNO profile, thereby connecting to the optimal MNO network.

[0026] The second implementation is aimed at business-to-business consumers (also known as M2M solutions). In the "business-to-business" channel, this solution addresses the needs of business-to-business consumers, especially in the Internet of Things (IoT) market. Since the device may not have a screen or keyboard and may be in a remote location, the operator needs the ability to push new MNO profiles and configurations to the eUICC. The standards for this are different from the consumer solutions mentioned above. This is known as a "push (to device) solution."

[0027] In any of the above eUICC implementations, a process is in place to control profile switching between different MNOs (e.g., MNO Y and MNO X) to enable reconnection to the eUICC in the event of an MNO network outage or failure. Such a process is illustrated below with reference to alarm device 302 shown in FIG. 3 (Prior Art). Alarm device 302 comprises a radio module 306 and an associated eUICC 310. Alarm device 302 further comprises a radio antenna 308 and a microcontroller 303 having memory 305 that holds a program 307, which are similar to the corresponding features of alarm device 202 shown in FIG. 2. Program 307, when executed on microcontroller 303, enables transmission and reception of data between alarm device 302 and the Internet via either MNO Y network 312 or MNO X network 320. Similar to the alerting device 202 of FIG. 2, the microcontroller 303 of the alerting device 302 of FIG. 3 controls the radio module 306 for sending and receiving such data and for the radio link with the MNO network via the eUICC 310.

[0028] The eUICC 310 has two profiles (schematically shown in FIG. 3) in its memory (not shown), whereby each profile is associated with a different MNO. Specifically, a first profile 311 (often referred to as the “Operational Profile”) is associated with MNO Y. A second profile 313 (referred to as the “Fallback Profile” or “Bootstrap Profile”) is associated with MNO X. The terms “Fallback Profile” and “Bootstrap Profile” may be used interchangeably. For brevity, the first profile 311 will be referred to hereinafter as the Operational Profile 311 and the second profile 313 will be referred to hereinafter as the Bootstrap Profile 313.

[0029] In this example, operational profile 311 is currently active, which means that eUICC 310 is connected to MNO Y network 312. If MNO Y network 312 or alarming device 302 identify a loss of service, eUICC 310 is notified accordingly. For example, if MNO Y network 312 rejects a connection attempt due to an issue with MNO Y network 312, such as network congestion, a PLMN-specific network failure, or an authentication failure, this network rejection event is provided to UICC 310, which informs microcontroller 303 that service with MNO Y network 312 is unavailable due to the network rejection event. Alternatively, microcontroller 303, in conjunction with radio module 306 of alarming device 302, may identify a loss of service with MNO Y network 312 and then communicate the service loss event to eUICC 310.

[0030] The eUICC 310 receives either a network-generated network rejection event or a device-generated loss of service event, which, once received, triggers a process called the fallback process. The fallback process requests the eUICC 310 to switch from the operational profile associated with MNO Y to a bootstrap profile associated with a different MNO, in this example, MNO X. As a result, the eUICC 210 connects to the MNO X network 320, thereby enabling the alarming device 302 to reconnect and come back online. Importantly, the fallback process is initiated by receiving a command from either the network 312 or the alarming device 302 itself.

[0031] If an outage occurs in the MNO X network 320 while using the bootstrap profile 313, a process called a fallback cancellation process can be used. Fallback cancellation allows the eUICC 310 to cancel the fallback mechanism, thereby switching the eUICC 310 back to the operational profile 311 from the bootstrap profile 313. This was first implemented for the automotive industry, where cars may need to make emergency calls in the event of an accident. If an outage occurs on the bootstrap profile, the car will not be able to make calls. Thus, the fallback cancellation process was designed for switching from the bootstrap profile to the operational profile. Similar to the fallback process, to initiate the fallback cancellation process, the alarm device 302 or the network 320 must instruct the eUICC 310 to perform a fallback cancellation to switch back to the operational profile.

[0032] In summary, current prior art eUICC implementations can only perform fallback and fallback cancellation procedures when the device or network identifies a connectivity problem or loss of service and then instructs the eUICC to switch between the operational profile and the bootstrap profile. Current eUICC implementations cannot perform fallback and fallback cancellation procedures without a command or instruction from the device or network.

[0033] This poses significant connectivity challenges for the eUICC 310. First, in existing solutions, an outage or failure in the MNO network can only be detected by the device or network. The eUICC 310 cannot identify or detect the outage on its own. This can result in a time lag between when the outage occurs, when the outage is detected, and when the eUICC is instructed to switch profiles and connect to a different MNO. Additionally, if the device or network does not detect the outage, the eUICC will lose connectivity and be isolated until the outage issue is resolved. Devices may also not fully comply with the standards, which similarly results in the eUICC or device being isolated.

[0034] Second, once the eUICC 310 switches from the operational profile 311 associated with MNO Y to the bootstrap profile 313 associated with MNO X, an outage or failure may occur in the MNO X network 320. In this situation, a fallback cancellation procedure typically must be performed manually from a remote platform. In rare circumstances, a fallback cancellation procedure may be performed by command from the device. In either case, if an outage occurs in the MNO X network 320 and a fallback cancellation procedure is not performed, the eUICC 310 will lose connectivity as a result.

[0035] In existing systems, the eUICC 310 is essentially a device and network slave and must be instructed to perform certain operations, such as performing fallback and fallback cancellation procedures.

[0036] For example, if eUICC 310 is on operational profile 311 and an outage is detected on MNO Y network 312 by network 312 or device 302, eUICC 310 receives a command from network 312 or device 302 to switch from operational profile 311 to bootstrap profile 313 so that it can connect to MNO X network 320. While on bootstrap profile 313, the issue that caused the outage on MNO Y network 312 is resolved, thereby allowing MNO Y network 312 to function normally again. If an outage occurs on MNO X network 320, eUICC 310 will lose its connection because it is still on bootstrap profile 313, even though MNO Y network 312 is functioning normally. Because eUICC 310 is disconnected and unreachable, it is not possible for a remote platform to initiate a fallback cancellation process to switch back to operational profile 311. The eUICC 310 remains disconnected until the outage in the MNO X network 320 is resolved and the eUICC 310 is manually connected to the MNO Y network 312 .

[0037] It is clear that current implementations of eUICC are still prone to failure under certain circumstances and therefore are not able to respond autonomously and resilient to outages. Mobile networks are ideal conduits for communications for emergency services, but outages in MNO networks, for example due to frequent network updates or network failures, combined with a lack of resilience, can cause serious disruptions to communications and signaling in emergency response systems.

[0038] The present invention aims to overcome or at least partially mitigate one or more of the problems set forth above. Summary of the Invention

[0039] The present invention relates to an improved resilient and autonomous SIM card that provides an improved way to handle outages in MNOs due to, for example, frequent network updates or network failures. The improved resilient and autonomous SIM card significantly reduces disruptions to communications over the mobile network. This in turn has positive consequences for signal transmission in emergency response systems, leading to faster and more responsive alerts to emergency services.

[0040] The improved resilient and autonomous SIM card includes an applet installed on the SIM that is configured to detect loss of connectivity in an MNO network and manage profiles associated with different MNOs to ensure connectivity is maintained whenever an outage occurs with the active MNO providing connectivity services. This makes the SIM of the present invention "outage-proof."

[0041] It is important to note that in embodiments of the present invention, the operational logic for identifying possible MNO network outages resides in an applet running on the SIM. This differs from prior art systems, where only the device or network can identify possible outages. Additionally, the operational logic for initiating fallback and fallback cancellation processes resides in the applet, whereas in prior art systems, the device or network must instruct the SIM to perform these processes.

[0042] The SIM utilizes two or more independent MNOs and operates autonomously so that no human, platform, or device interaction is required to maintain uptime and continuity of service. Additionally, the SIM provides this functionality without requiring any modifications to the device in which it is installed.

[0043] Additionally, a key advantage of the eUICC SIM of the present invention is that it can be retrofitted into any device compatible with eUICC SIM cards. For example, legacy devices designed and built before the implementation or approval of the GSMA standard are unable to mimic the fallback and fallback cancellation procedures used with standard SIMs. To address this issue, the SIM applet of the present invention provides the required standards for the SIM and enables commands to trigger fallback and fallback cancellation procedures from within the SIM. As a result, the SIM can be used in any device compatible with eUICC SIMs, including legacy devices that were previously unable to mimic such procedures.

[0044] According to a first aspect of the present invention, there is provided a Universal Integrated Circuit Card (UICC) for controlling wireless communication over a wireless communication network with a host device in which the UICC is installed, in use, the UICC comprising: a microprocessor for controlling operation of the UICC; and a data store for storing data relating to operation of the UICC, the data store including a plurality of mobile carrier network profiles including an operational profile containing wireless communication network settings for connecting the host device to a first wireless communication network and a bootstrap profile containing wireless communication network settings for connecting the host device to a second wireless communication network; and a program containing a plurality of instructions for configuring operation of the UICC, wherein in use the microprocessor is configured by the program to connect the host device to the first wireless communication network using the operational profile, detect loss of operational connectivity with the first wireless communication network, and connect the host device to the second wireless communication network using the bootstrap profile to re-establish wireless communication with the host device.

[0045] The UICC may be an embedded UICC (eUICC) that allows the programs and profiles to be remotely configured and / or updated.

[0046] The programs may include applets that have relatively small size and dedicated functionality.

[0047] The data store may be located in a secure transversal domain of the UICC, and the operational profile or the bootstrap profile may securely provide access to the secure transversal domain of the UICC to enable an external server to make changes to the programs stored in the data store.

[0048] The system may further include a set of variable parameters stored as a file in the data store for configuring the operational profile and bootstrap profile and their use in controlling wireless communications with the host device over the wireless communications network. The parameters may be stored in a separate configuration file, allowing the configuration file to be replaced by an update process. One example of a parameter stored in a configuration file is the address of a ping server.

[0049] The program may include instructions for configuring the microprocessor, when in use, to perform a first wireless communication network connectivity test to test the wireless communication network connectivity between the host device and the first wireless communication network; return a first connectivity test result based on the wireless communication network connectivity test; determine whether a loss of wireless communication network connectivity has occurred between the host device and the first wireless communication network based on the first connectivity test result; and if such a loss of connectivity has been determined, deselect the operational profile and select the bootstrap profile; and connect to the second wireless communication network based on the network settings of the bootstrap profile using the bootstrap profile to re-establish wireless communication network connectivity of the host device.

[0050] The program may include instructions for configuring the microprocessor, in use, to start a cancel timer of a predetermined duration when a loss of connectivity is detected on the first network, and once the cancel timer expires, to deselect the bootstrap profile, reselect the operational profile, and reconnect to the first wireless communications network using the operational profile to re-establish wireless communications network connectivity between the host device and the first wireless communications network.

[0051] The program may include instructions for configuring the microprocessor, when in use, to: after connecting the host device to the second wireless communication network using the bootstrap profile, perform a second wireless communication network connectivity test to test the wireless communication network connectivity between the host device and the second wireless communication network; return a second connectivity test result based on the wireless communication network connectivity test; determine whether a loss of wireless communication network connectivity has occurred between the host device and the second wireless communication network based on the second connectivity test result; and if such a loss of connectivity has been determined, deselect the bootstrap profile and reselect the operational profile; and connect to the first wireless communication network using the operational profile based on the network settings of the operational profile to re-establish wireless communication network connectivity of the host device.

[0052] In an embodiment, the program includes instructions for configuring the microprocessor, when in use, to determine a time slot for using the reselected operational profile and to delay disconnecting from the second wireless communication network and connecting to the first wireless communication network using the reselected operational profile until the time slot is reached.

[0053] Preferably, the time slot is determined using a random number or a number from the ICCID, IMEI or MISDIN associated with the UICC or host device, although the time slot may be determined by other means.

[0054] In an embodiment, the program includes instructions for configuring the microprocessor, in use, to perform the first or second wireless communication network connectivity test by testing the wireless communication network connectivity between the host device and one or more test servers within the wireless communication network being tested.

[0055] Preferably, the program includes instructions for configuring the microprocessor, when in use, to perform the first or second wireless communication network connectivity test by performing a ping test, the ping test including sending a forwarded data packet to at least one test server of the one or more test servers, determining whether a response data packet is received from the test server, and returning a negative first or second wireless communication network connectivity test result if the response data packet is not received from the test server within a predetermined period of time after sending the forwarded data packet.

[0056] The program may include instructions for configuring the microprocessor, when in use, to perform the first or second wireless communication network connectivity test by performing a ping sequence test, the ping sequence test including: sending a first forwarded data packet to a first test server of the one or more test servers; determining whether a first response data packet is received from the first test server within a first predetermined period of time; if it is determined that the first response data packet has not been received within the first predetermined period of time, sending a second forwarded data packet to a second test server of the one or more test servers within a second predetermined period of time. determining whether a second response data packet has been received from the second test server; if it is determined that the second response data packet has not been received within the second predetermined period, sending a third forwarded data packet to a third test server among the one or more test servers; determining whether the third response data packet has been received from the third test server within a third predetermined period; if it is determined that the third response data packet has not been received within the third predetermined period, returning a negative ping sequence test result; and if a negative sequence ping result is returned, returning a negative first or second wireless communication network connectivity test result.

[0057] The program may include instructions for configuring the microprocessor, in use, to perform the first or second wireless communication network connectivity test by repeating the ping sequence test one or more times, and wherein the negative wireless communication network connectivity test result is returned only if the number of consecutive negative ping sequence test results exceeds a predetermined threshold.

[0058] In an embodiment, the program includes instructions for configuring the microprocessor, when in use, to perform the first or second wireless communication network connectivity test by executing a data test, the data test including sending a predetermined amount of data to a test server, determining whether the predetermined amount of data has been delivered to the test server, and returning a negative first or second wireless communication network connectivity test result if the predetermined amount of data has not been delivered to the test server.

[0059] The program may include instructions for configuring the microprocessor, when used, to perform a connectivity test of the first or second wireless communication network by performing a network layer test, the network layer test including testing different network layers of the first or second wireless communication network.

[0060] In an embodiment, the data store includes a roaming profile including wireless communication network settings for connecting the host device to a roaming wireless communication network, and the program includes instructions for configuring the microprocessor, in use, to connect the host device to the roaming wireless communication network based on the network settings of the roaming profile using the roaming profile to re-establish wireless communication with the host device after detecting a loss of operational connectivity with the first communication network.

[0061] The data store may include a plurality of wireless network profiles, each comprising a wireless communication network setting for connecting the host device to a respective wireless communication network, and the UICC may be configured to enable remote selection of the operational profile and the bootstrap profile from the plurality of profiles.

[0062] The data store may include a plurality of wireless network profiles, each comprising a wireless communication network setting for connecting the host device to a respective wireless communication network, and the UICC may be configured to enable a local user to select the operational profile and the bootstrap profile from the plurality of profiles.

[0063] Preferably, each wireless network profile in the plurality of wireless network profiles is associated with a different independent wireless communication network.

[0064] In an embodiment, each network profile in the plurality of network profiles is associated with an independent wireless communication network platform or a different instance of the same wireless communication network platform.

[0065] The UICC may include an eUICC, a mini SIM, a micro SIM, a nano SIM, or a solderable SIM.

[0066] According to a second aspect of the present invention, there is provided a host device comprising a processor having a memory, a wireless module for connecting the host device to a wireless communication network, and a general purpose integrated circuit device as described above with reference to the first aspect of the present invention.

[0067] The host device may include an alarm device, a smartphone, a tablet computer, a dongle, a router, a GPS tracking device, an M2M device, an IoT device, a vehicle, a telemedicine device or a telecare device.

[0068] According to a third aspect of the present invention, there is provided a method of operating a Universal Integrated Circuit Card (UICC) to control wireless communication over a wireless communication network with a host device in which the UICC is installed when in use, the method comprising the steps of: providing access to data relating to the operation of the UICC stored in a data store of the UICC, the data including a plurality of mobile carrier network profiles including an operational profile including wireless communication network settings for connecting the host device to a first wireless communication network, and a bootstrap profile including wireless communication network settings for connecting the host device to a second wireless communication network; and controlling the operation of the UICC using a microprocessor of the UICC and a program including a plurality of instructions for configuring the operation of the UICC, the control step including connecting the host device to the first wireless communication network using the operational profile, detecting loss of operational connectivity with the first wireless communication network, and connecting the host device to the second wireless communication network using the bootstrap profile to re-establish wireless communication with the host device.

[0069] According to a fourth aspect of the present invention, there is provided a computer program product or computer readable storage medium comprising instructions which, when executed by a computer, cause the computer to perform the method described above with reference to the third aspect of the present invention.

[0070] According to a fifth aspect of the present invention, there is provided a computer-implemented method for re-establishing a wireless communication network connection between a host device and a network platform providing a wireless communication network connection, the host device comprising a Universal Integrated Circuit Card (UICC) having a mobile operator network profile for controlling the wireless communication network connection, the computer-implemented method comprising the steps of receiving a first data packet from the UICC via the wireless communication network connection; receiving a second data packet from the UICC via the wireless communication network connection; determining first time data indicative of an elapsed time between receipt of the first data packet and receipt of the second data packet; comparing the first time data with a predetermined time threshold; and, if the first time data is greater than the predetermined time threshold, sending a reset request to the wireless communication network platform to reset the wireless communication network connection for the host device.

[0071] The computer-implemented method may further include, after the comparing step, if the first time data is greater than the predetermined time threshold, starting a reset timer and comparing the value of the reset timer with a predetermined reset timer threshold, and the transmitting step is delayed until the value of the reset timer is greater than the predetermined reset timer threshold.

[0072] The predetermined reset timer threshold may be configurable for different time periods.

[0073] Within the scope of this application, it is expressly intended that the various aspects, embodiments, examples, and alternatives, and in particular individual features, set forth in the preceding paragraphs, claims, and / or the following description and drawings may be construed independently or in any combination. That is, all embodiments and / or features of any embodiment may be combined in any manner and / or combination, provided such features are not inconsistent. The applicant reserves the right to modify the originally filed claims or to file new claims as appropriate, including the right to amend the originally filed claims to depend on and / or incorporate features of any other claim, even if not originally claimed as such. [Brief explanation of the drawings]

[0074] The invention will now be described, by way of example only, with reference to the accompanying drawings, in which: [Figure 1] 1 is a schematic diagram illustrating a known alarm network using dual path signaling for communication between alarm devices and a remote alarm receiving center; [Figure 2] 1 is a schematic diagram showing a prior art alarm device with a roaming SIM; [Figure 3] 1 is a schematic diagram illustrating another prior art alarm device comprising an eUICC; [Figure 4] 1 is a schematic diagram illustrating an eUICC in an alarm device and an alarm network for communication between the alarm device and a remote alarm receiving center according to a first embodiment of the present invention; FIG. [Figure 5] FIG. 5 is a schematic diagram illustrating the components of the eUICC and alarm device shown in FIG. 4 in more detail. [Figure 6] FIG. 5 is a schematic diagram showing in more detail the components of the alarm network shown in FIG. 4. [Figure 7] 4 is a flowchart illustrating a process for maintaining eUICC connectivity when an outage occurs in an active MNO network according to the first embodiment. [Figure 8]8 is a flowchart showing in more detail the process of testing eUICC connectivity in FIG. 7. [Figure 9] 8 is a flowchart showing in more detail the process of executing the fallback process of FIG. 7 according to the first embodiment. [Figure 10] 8 is a flowchart showing in more detail the process of executing the fallback cancellation process of FIG. 7 according to the first embodiment. [Figure 11a] FIG. 10 is a schematic diagram illustrating an eUICC provided in an alarm device before an optional profile is selected according to a second embodiment of the present invention. [Figure 11b] FIG. 11b is a schematic diagram illustrating the eUICC of FIG. 11a after an optional profile has been selected according to a second embodiment of the present invention. [Figure 12a] FIG. 3 is a schematic diagram illustrating an eUICC provided in an alarm device before an optional profile is selected, according to a third embodiment of the present invention, the eUICC including a profile associated with a virtual mobile operator under contract with the mobile operator. [Figure 12b] FIG. 12b is a schematic diagram illustrating the eUICC of FIG. 12a after an optional profile has been selected according to a third embodiment of the present invention; [Figure 13] FIG. 10 is a schematic diagram illustrating a national profile and a roaming profile that may be provided in an eUICC according to a fourth embodiment of the present invention. [Figure 14] 10 is a flowchart illustrating a process for maintaining eUICC connectivity in the event of an outage in an active MNO network where both a home profile and a roaming profile are available, according to a fourth embodiment. [Figure 15] FIG. 9 is another schematic diagram illustrating the process of testing the connectivity of the eUICC in FIG. 8 . [Figure 16] 16 is a flowchart illustrating the ping connectivity test of FIG. 15 in more detail. [Figure 17]FIG. 17 is a schematic diagram of the state machine of the eUICC in a state in which the ping connectivity tests of FIGS. 15 and 16 are performed and fallback processing and fallback cancellation processing are initiated. [Figure 18] 11 is a flowchart illustrating in more detail the steps performed during the fallback and fallback cancel processes of FIGS. 9 and 10; [Figure 19] 10 is a table showing timings used in ping connectivity tests for domestic profiles and roaming profiles, as well as fallback processing and fallback cancellation processing in each embodiment of the present invention. [Figure 20] 10 is a table illustrating possible time slot determinations using random digits of an ICCID number, as used in one embodiment of the present invention. [Figure 21] 6 is a table showing configurable elements of the applet of the eUICC shown in FIG. 5. [Figure 22] 10 is a flow chart illustrating processing for Applet and Platform Synchronisation and triggering of location cancellation requests according to a further embodiment; [Figure 23] FIG. 1 is a schematic diagram illustrating an example of a SIM compatible with embodiments of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0075] Embodiments of the present invention relate to an improved resilient and autonomous SIM card that provides an improved way to address outages or connectivity issues in MNO networks, for example, due to frequent network updates or network failures. The improved resilient and autonomous SIM card significantly reduces disruptions to communications over the mobile network. This, in turn, has positive consequences for signal transmission in emergency response systems, leading to faster and more responsive alerts to emergency services.

[0076] An eUICC according to a first embodiment of the present invention will be described below with reference to FIGS. 4 to 6, and then each related process will be described with reference to FIGS.

[0077] 4 shows an alarm network 400 that provides a communication channel between an alarm device 402 and a remote alarm receiving center 404. The alarm device 402 originates and transmits an alarm signal over the alarm network 400 to the alarm receiving center 404, which then takes appropriate action, including, for example, notifying the building manager or notifying the police.

[0078] The alerting device 402 comprises an eUICC 410 which stores account and communication details that enable a radio module (not shown) within the alerting device 402 to operate on a mobile telecommunications network, thereby enabling the alerting device 402 to connect to one or more MNO networks 412. By way of example, MNO X and MNO Y are shown in Figure 4 as available MNO network 412 operators.

[0079] The alarm network 400 provides a wireless communication path between the alarm device 402 and the alarm receiving center 404. First, a wireless communication link is provided between the alarm device 402 and the MNO network 412. The wireless communication link may be provided by the 4G communication standard Long Term Evolution (LTE), GS using 3G or 2G networks, Code Division Multiple Access (CDMA) using 3G or 2G, or a 5G network. A secure fixed line route is provided between the MNO network 412 and the MNO server 414 via the Internet 416, and also between the MNO server 414 and the wireless communication network 418. Finally, the wireless communication network 418 has a wireless communication link with the alarm receiving center 404. In this embodiment, the secure fixed line is provided by one or more leased lines or virtual private network (VPN) tunnels, and the wireless communication network 418 is provided by, for example, BT or Virgin Media. In some embodiments, several communication paths may be provided by the alarm network 400 between the alarm devices 402 and the alarm receiving center 404, including wireless and wired communication paths.

[0080] 5 illustrates the components of the alarm device 402 and the eUICC 410 in greater detail. The alarm device 402 includes a radio module 406 configured to transmit and receive over a wireless network (e.g., 5G / 4G / 3G / 2G). A radio antenna 408 is connected to the radio module 406 and configured to operate on the frequencies of the wireless network. The alarm device 402 further includes a microcontroller 403 connected to the radio module 406 and having memory (not shown), including flash memory and non-volatile memory. The microcontroller 403 processes data for transmission and data received by the radio module 406 via the radio antenna 408. The microcontroller 403 controls the radio module 406 with respect to the transmission and reception of such data. In some other embodiments, the alarm device 402 also includes an input interface (not shown).

[0081] The eUICC 410 includes a processor 434 having a secure memory 436. The secure memory 436 holds a set of profiles, each associated with a different MNO network. To make the eUICC resilient, each profile is associated with an MNO operating an independent network. Within a single MNO network, there are many points where connectivity issues can occur. Using independently configured MNO networks has the advantage of reducing the probability of a connectivity issue occurring simultaneously in both MNO networks, making the eUICC more resilient. For example, each MNO network may use different masts and radio antennas. To further improve resilience, each profile may be associated with an MNO operating a core network that is independent from the core networks operated by the MNOs associated with other profiles. For example, in a 4G LTE network, the Evolved Packet Core (EPC) is a representative example of the core of an LTE network. The EPC consists of multiple nodes, including a Home Subscriber Server (HSS) used to store subscriber information, current location, SIM details, and authentication keys. The MNOs associated with the profiles are each associated with a separate EPC in the LTE network so that an outage at an MNO using a first EPC can be avoided by switching to an MNO using a different second EPC. MNOs may have roaming agreements with other MNOs, which may be direct roaming relationships or indirect roaming relationships via a GPRS roaming exchange (GRX) hub. As an example, MNO X may have a direct roaming relationship with MNO Z, while MNO Y may connect to MNO Z via a GRX hub.Independent MNO networks (e.g., MNO X and MNO Y) may each connect to a roaming MNO (MNO Z) using independent GRX hubs, or may use the same GRX hubs with independent configurations and independent interconnections to these hubs.

[0082] These different MNOs may operate the same platform on different instances, including physical infrastructure separation (e.g., Ericsson DCP, Jasper). For example, even if these two networks use different virtual machines, it would not be acceptable for them to share the same physical hardware. Because the selected MNOs operate either independent networks and independent platforms or different instances of the same platform, an outage in one MNO network can be avoided by switching to another MNO operating a different, independent network.

[0083] In this embodiment, eUICC 410 has two profiles: (i) an "operational profile" associated with MNO Y, and (ii) a "bootstrap profile" associated with MNO X. Using these profiles, eUICC 410 can connect to either the MNO Y network or the MNO X network. In this embodiment, operational profile 440 is currently active, which means that eUICC 410 is connected to the MNO Y network.

[0084] In some embodiments, the set of profiles may include three or more profiles, thereby enabling the eUICC to connect to three or more MNO networks, as described later in this specification with reference to Figures 11a, 11b, 12a, 12b and 13.

[0085] A small utility program containing algorithms, referred to herein as an "applet" 438, is held in secure memory 436 (also referred to herein as the secure transversal domain) and is executable on processor 434. Applet 438 is responsible for performing connectivity tests for the MNO Y network. If applet 438 identifies a connectivity outage in the MNO Y network, the applet initiates a fallback process that requests eUICC 410 to switch from an operational profile 440 associated with the MNO Y network to a bootstrap profile 442 associated with the MNO X network. This re-establishes connectivity for eUICC 410 in alarm network 400. After a predetermined time frame for initiating the fallback process has elapsed, applet 438 initiates a fallback cancellation process, which causes eUICC 410 to cancel the fallback mechanism, thereby allowing eUICC 410 to switch back from bootstrap profile 442 to operational profile 440. Once this switch has occurred, eUICC 410 can reconnect to MNO Y's network via operational profile 440. Switching logic that enables the eUICC to switch between the operational profile and the bootstrap profile is installed on the eUICC. Bootstrap profile 442 is installed during eUICC manufacture and can be changed to associate with different MNOs via an over-the-air (OTA) update (see OTA update description below). The process performed by applet 438 is described in more detail below with reference to Figures 7 through 10.

[0086] The applet 438 is configurable over the air (OTA) to provide updated MNO profiles and credentials and configuration settings to the eUICC 410. Each MNO profile resides in a secure area within the secure transversal domain on the eUICC SIM. Therefore, to configure the applet 438 over the air, the applet 438 itself resides in the secure transversal domain on the eUICC 410, providing a secure connection to the SIM card. The applet 438 itself can also be installed and updated over the air. Because both the applet and the switching logic reside on the eUICC, any device can be retrofitted with an eUICC. The applet operates according to the required 3GPP / ETSI / GSMA standards and was developed using the SIM Application Toolkit.

[0087] Elements of the alarm network 400 that enable OTA updates are shown in Figure 6. The eUICC 410 manufacturer and hosted platform provider 444 is in communication with the eUICC 410 installed in the alarm device 402 using one of the available MNO networks 412. An available mobile operator 446 is in communication with the manufacturer and hosted platform provider 444. The manufacturer and hosted platform provider 444 enables the eUICC 410 to be remotely configured using information from the mobile operator 446. The available mobile operators 446 and the manufacturer and hosted platform provider 444 are collectively in communication with a machine-to-machine (M2M) management system 448 that enables remote configuration and management of the alarm device 402.

[0088] The manufacturer and hosted platform provider 444 has a subscription manager data preparation element (SM-DP) 450 and a subscription manager secure routing element (SM-SR) 452. The SM-DP 450 and the SM-SR 452 are two key network elements used by available mobile operators 446 to remotely manage the eUICC 410. In this embodiment, the available mobile operators 446 include MNO X 454 and MNO Y 456, which use the SM-DP 450 to securely encrypt and install their operator profiles over-the-air into the eUICC 410. The SM-DP 450 sends the securely encrypted profile to the SM-SR 452. The SM-SR 452 then receives the encrypted profile and securely delivers it to the eUICC 410 over the air. The eUICC 410 receives and installs the profile, and once the profile is installed, the SM-SR remotely manages the eUICC 410.

[0089] In other words, the SM-DP 450 is responsible for securely packaging and managing MNO profiles on the eUICC 410 and for effectively establishing a communications link between the eUICC 410 and the SM-DP 450 to deliver the MNO profiles. The SM-SR 452 is responsible for securely transporting commands to the eUICC 410 to load, enable, disable, or delete profiles on the eUICC 410 as needed, and for managing the status of profiles on the eUICC 410. The SM-SR 452 also includes a configuration area (not shown) created specifically for the applet 438 on the eUICC 410. The configuration area allows OTA updates to be performed from the SM-SR 452 even when the applet 438 is in the secure transversal area of the eUICC 410. Alternatively, OTA updates may be performed via the SIM's OTA platform. In most current systems, the OTA server does not have access to the eUICC's transversal area and cannot modify the applet on the eUICC, so some modification to the OTA server is required. To address this, the eUICC 410 may use a profile, such as an operational profile or a bootstrap profile, or a different profile, such as a maintenance profile. The OTA server only needs to be modified once, and since it is granted access to the secure transversal domain of the eUICC 410, the profile selected (operational profile, bootstrap profile, or maintenance profile) to address this issue allows the modification to be made to the applet 438.

[0090] The process performed by applet 438 will now be described with reference to Figures 7 to 10. In this embodiment, operational profile 440 is currently active, which means that eUICC 410 is connected to the MNO Y network. Applet 438 performs its process in three major steps. First, in step 700, applet 438 tests MNO Y network connectivity to determine whether an outage has occurred. If applet 438 determines a complete connectivity outage in the MNO Y network, applet 438 initiates a fallback process in step 900. The fallback process requests eUICC 410 to switch from operational profile 440 associated with the MNO Y network to bootstrap profile 442 associated with the MNO X network. This reestablishes eUICC 410 connectivity in the alarm network 400 with the MNO X network. Next, in step 1000, the applet 438 initiates a fallback cancellation process after a predetermined time frame has elapsed. The fallback cancellation process allows the eUICC 410 to cancel the fallback mechanism, thereby switching the eUICC 410 back from the bootstrap profile 442 to the operational profile 440. Once this switch has occurred, the eUICC 410 can reconnect to the MNO Y network via the operational profile 440.

[0091] As described above, applet 438 is responsible for testing MNO Y network connectivity. As part of stage 700, applet 438 first tests MNO Y network connectivity a predetermined number of times in step 702. Applet 438 then checks whether the connectivity test was successful in step 704. If the test is successful, applet 438 loops back and continues to test MNO Y network connectivity in step 702. However, if the test is not successful, applet 438 proceeds to step 706 to check whether a complete connectivity outage has occurred in the MNO Y network. If, based on this check, applet 438 determines that a complete connectivity outage has occurred in the MNO Y network, applet 438 proceeds to stage 900, which is the process of initiating fallback processing. On the other hand, if applet 438 determines that a complete connectivity outage has not occurred in the MNO Y network, applet 438 loops back and continues to test connectivity in the MNO Y network in step 702 .

[0092] In this embodiment, as shown in Figure 8, applet 438 tests the connectivity of the eUICC to the MNO Y network using a ping test. The ping test determines whether the alarm device 402 in which the eUICC 410 is installed can communicate with a server through the alarm network 400. The ping test does this by sending a data packet to the server and waiting for a data packet to be sent back in response. If network communication is successfully established, the ping test also determines the connection latency between the alarm device 402 and the server (the time it takes for a ping (data packet) to be returned to the device 402). In this embodiment, applet 438 performs a series of pings to different servers in the alarm network 400, specifically Server X, Server Y, and Server Z (not shown). These servers are independent and geographically distributed.

[0093] Applet 438 begins a ping test in step 802 by sending a ping, or "pinging," to server X. Applet 438 then checks in step 804 whether a response to the ping has been received from server X. Applet 438 begins checking for a response immediately after the ping is sent to server X. If a response to the ping is received from server X, applet 438 loops back and pings server X again in step 802. When a response is always received from server X after a ping is sent, this is a connectivity heartbeat indicating normal operation and connectivity between server X and MNO Y's network. If a response to the ping is not received from server X within a configurable period of time, e.g., four seconds, applet 438 proceeds to step 806 and sends a ping to server Y. Applet 438 then checks in step 808 whether a response to the ping has been received from server Y. If a response to the ping is received from server Y, applet 438 loops back and restarts the ping test in step 802 by pinging server X again. If a response to the ping is not received from server Y within a configurable period of time, e.g., four seconds, applet 438 proceeds to step 810 and sends a ping to server Z. Applet 438 then checks in step 812 whether a response to the ping was received from server Z. If a response to the ping is received from server Z, applet 438 loops back and restarts the ping test in step 802 by pinging server X again. If a response to the ping is not received from server Z within a configurable period of time, e.g., four seconds, this indicates that three consecutive ping tests (i.e., the ping sequence) were unsuccessful. Following the first unsuccessful ping sequence, applet 438 then repeats steps 802 through 812 two more times to perform the ping sequence twice.If no response to the ping is received from Server Z on the third and final ping sequence, the applet determines whether a complete connection outage has occurred in step 706 shown in FIG.

[0094] In step 706, applet 438 determines whether a complete connection loss or "connection outage" has occurred between eUICC 410 and the MNO Y network based on the occurrence of three consecutive failed ping sequences. If applet 438 determines that a complete connection loss to the MNO Y network has occurred, applet 438 loops back and retests eUICC 410 connectivity with the MNO Y network in step 702. On the other hand, if applet 438 determines that a complete connection loss has not occurred, applet 438 proceeds to stage 900 and begins fallback processing.

[0095] 9, the fallback process initiated by applet 438 in step 900 will be described in more detail below. First, in step 902, applet 438 issues a request to processor 434 of eUICC 410 to switch from operational profile 440 associated with MNO Y network to bootstrap profile 442 associated with MNO X network. At the same time, in step 904, applet 438 issues a request to processor 434 of eUICC 410 to start a timer.

[0096] As part of the fallback process, the network configuration of the radio module 406 of the alarm device 402 needs to be refreshed in order for the radio module 406 to connect to the MNO X network. Therefore, the eUICC sends a refresh command to the radio module 406 in step 906 to initiate a network configuration refresh as part of the fallback process, which allows the network configuration of the radio module to be updated to the MNO X network.

[0097] The applet then sends a command to processor 434 of eUICC 410 to check the timer against a predetermined threshold in step 912. This check is performed in step 914, and if the timer has reached the predetermined threshold, processing proceeds to stage 1000, where a fallback cancellation process is initiated, thereby reconnecting to the MNO Y network. On the other hand, if the result of the check in step 914 indicates that the timer has not reached the predetermined threshold, processing loops back, and applet 438 resends the command to processor 434 in step 912 to check the timer against the predetermined threshold.

[0098] The fallback cancellation process initiated by applet 438 in step 1000 will be described in more detail below with reference to FIG. 10 . As described above, the fallback cancellation process allows eUICC 410 to cancel the fallback mechanism, causing eUICC 410 to switch back to operational profile 440 from bootstrap profile 442. In step 1002, applet 438 determines a time slot (period) for initiating the fallback cancellation process. For example, after a predetermined period of time has elapsed, e.g., every 30 seconds, applet 438 receives an input from device 402 indicating that the predetermined period has elapsed. Each time applet 438 receives an input, applet 438 increments a counter by one. Once the counter reaches a predetermined number of times, e.g., three times, applet 438 initiates the fallback cancellation process. The alarm network 400 may include multiple alarming devices 402, and the eUICC in each of the alarming devices 402 may perform the process described herein. If multiple eUICCs simultaneously switch back to the operational profile, this may result in a so-called "signaling storm," overloading MNO Y's network. This may result in further MNO outages. The applet 438 includes a built-in mechanism for distributing the re-switching of the eUICCs 410 back to the operational profile 440 over time after the fallback cancellation process is initiated. This solves the technical problem of preventing signaling storms with the MNO associated with the operational profile 440, i.e., MNO Y in this embodiment. The time slot may be determined, for example, by using the last digit of the eUICC's IMEI code, ICCID code, EID code, or MISDEN code. The time slot may be determined in other ways, for example, by randomizing the time before the switch from the bootstrap profile 442 to the operational profile 440 occurs.

[0099] Once the time slot at which fallback cancellation is initiated has been determined, applet 438 sends a command to processor 434 in step 1004 to determine whether the time slot has been reached. Applet 438 accordingly proceeds to step 1006 and checks the current time against the time slot. If the time slot has not been reached, processing loops back and applet 438 resends a command to processor 434 in step 1004 to check whether the time slot has been reached. If the time slot has been reached, processing continues and applet 438 issues a request to processor 434 of eUICC 410 in step 1008 to switch from bootstrap profile 442 associated with MNO X network to operational profile 440 associated with MNO Y network. Applet 438 then checks in step 1010 whether connectivity has been established with MNO Y network. If connectivity with the MNO Y network is not established, the applet 438 initiates a fallback process to switch the eUICC 410 back from the operational profile 440 to the bootstrap profile 442 in order to establish connectivity with the MNO X network. That is, the process loops back to the beginning of stage 900 to perform the fallback process in step 1012. On the other hand, if connectivity with the MNO Y network is established in step 1010, the eUICC 410 has successfully connected to the MNO Y network and the process ends.

[0100] In this embodiment, to determine the time slot for initiating fallback cancellation, time, specifically the period between two points in time, is measured and compared with a threshold as the reference point for initiating fallback cancellation processing. However, it should be noted that other means are also possible. For example, the applet may count the number of interactions or event triggers between the eUICC and the device and / or network, and start fallback cancellation processing after a predetermined number of such interactions or events have occurred. Alternatively, the applet may use any combination of time, interactions, and events to determine the point in time for initiating fallback cancellation processing.

[0101] In each of the embodiments described above with reference to Figures 4 to 10, the eUICC 410 comprises two profiles: (i) an operational profile 440 associated with MNO Y and (ii) a bootstrap profile 442 associated with MNO X. Below, with reference to Figures 11a, 11b, 12a, 12b and 13, embodiments are described in which the set of profiles includes three or more profiles, thereby enabling the eUICC to connect to three or more MNO networks.

[0102] 11a and 11b show an eUICC 1110 according to a second embodiment of the present invention. The second embodiment is similar to the first embodiment, and therefore the following description will focus on the differences between these embodiments.

[0103] The eUICC 1110 is installed in an alarm device 1102 that provides an M2M solution. The alarm device 1102 is part of the alarm network described above with reference to FIG. 4, which provides a communication channel between the alarm device 1102 and a remote alarm receiving center. The alarm device 1102 and the eUICC 1110 have the features of the alarm device 402 and the eUICC 410, respectively, shown in FIG. 5, although these features are not shown in FIG. 11a. The difference between the first and second embodiments lies in the profiles stored on the eUICC 1110. The eUICC 1110 has four profiles: (i) a bootstrap profile 1142a associated with MNO 1, (ii) an operational profile 1140a associated with MNO 2, (iii) an optional profile A 1143a associated with MNO 3, and (iv) an optional profile B 1144a associated with MNO 4. It should be noted that the profile provided in the eUICC 1110 is a national profile associated with an MNO that provides connectivity in the country in which it operates its physical network. The national profile is therefore associated with an MNO that provides connectivity in the same country in which the eUICC 1110 and alerting device are operating. In addition to the national profile, the eUICC may also include a roaming profile, which will be described in more detail with reference to Figure 13 in connection with the fourth embodiment.

[0104] Using the national profile shown in FIG. 11a, the eUICC 1110 can connect to the MNO 1 network, the MNO 2 network, the MNO 3 network, or the MNO 4 network. As shown in FIG. 11a, in this embodiment, the operational profile 1140a is currently active, which means that the eUICC 1110 is connected to the MNO 2 network. The MNO network that provides network connectivity, i.e., that is associated with the operational profile, can be selected from the alarm server in the alarm network. Optional profile A 1143a and optional profile B 1144a will be presented in the server as options that allow control over which MNO provides network connectivity.

[0105] An applet (not shown in FIGS. 11a and 11b) within the eUICC 1110 can perform the processes detailed above with reference to the flowcharts of FIGS. 7-10. That is, the applet tests connectivity with the MNO 2 network associated with the operational profile 1140a (step 700, FIG. 7), and if a loss of connectivity to the MNO 2 network occurs, the applet initiates a fallback process to re-establish connectivity with the MNO 1 network associated with the bootstrap profile 1142a (step 900, FIG. 7). After a predetermined time frame has elapsed, the applet initiates a fallback cancellation process to reconnect to the MNO 2 network (step 1000, FIG. 7).

[0106] FIG. 11b shows the profiles in the eUICC 1110 after optional profile A 1143a has been selected to allow MNO 3 to provide network connectivity. Thus, operational profile 1140b in FIG. 11b is associated with the MNO 3 network. Bootstrap profile 1142b remains associated with the MNO 1 network. Optional profile A 1143b is associated with the MNO 2 network, and can be switched back to the MNO 2 network if desired. Optional profile B 1144b remains associated with the MNO 4 network.

[0107] Alternatively, the eUICC 1110 shown in Figures 11a and 11b may be installed in a consumer device such as a smartphone. In this case, the MNO network providing network connectivity, i.e., the MNO network associated with the operational profile, may be selected by a user of the device. Via an input device such as a touchscreen, the consumer device may present optional profile A 1143a and optional profile B 1144a as options that allow the user to actively select the MNO providing network connectivity. After switching to one of optional profiles 1143a and 1144a, the user has the option to switch back to the MNO 2 network, if desired, by selecting optional profile A 1143b.

[0108] 12a and 12b show an eUICC 1210 according to a third embodiment of the present invention. The third embodiment is similar to the second embodiment, and therefore, the following description will focus on the differences between the second and third embodiments.

[0109] The eUICC 1210 has profiles associated with virtual mobile network operators (MVNOs), each of which has a contract with an MNO to provide services to its customers using the MNO's network infrastructure.

[0110] Therefore, the eUICC 1210 includes a bootstrap profile 1242a associated with MVNO X1. MVNO X1 has concluded a contract with MNO X to use MNO X's network infrastructure.

[0111] The eUICC 1210 further includes an operational profile 1240a associated with the MVNO Y1. The MVNO Y1 has signed a contract with the MNO Y to use the MNO Y's network infrastructure.

[0112] The eUICC 1210 includes two additional profiles 1241a, 1243a. The first additional profile 1241a is associated with MVNO X2, which has an agreement with MNO X. The second additional profile 1243a (hereinafter and in FIG. 12a referred to as "Optional Profile A" 1243a) is associated with MVNO Y2, which has an agreement with MNO Y.

[0113] Using these profiles, the eUICC 1210 can connect to the MNO X network or the MNO Y network through one of the associated MVNOs. As shown in FIG. 12a, in this embodiment, operational profile 1240a is currently active, and thus the eUICC 1210 is connected to the MNO Y network. The MNO network providing network connectivity may be selected at a server (not shown) if the device 1202 is an M2M device, or may be selected by a user via an input device (not shown), such as a touchscreen, if the device 1202 is a consumer device. For fallback and fallback cancellation to be effective, the operational profile and bootstrap profile must be associated with different MNOs. Because bootstrap profile 1242a is associated with MNO X, optional profile A 1243a, associated with MNO Y through MVNO Y2, is presented as the only other option if an alternative profile is desired. A first additional profile 1241a associated with MVNO X2 is currently unavailable for selection.

[0114] An applet (not shown in either Figures 12a or 12b) within the eUICC 1210 may perform the processing detailed above with reference to the flowcharts of Figures 7 to 10.

[0115] FIG. 12b shows the profiles in the eUICC 2110 after optional profile A 1243a has been selected to enable MNO Y to provide network connectivity through MVNO Y2. Thus, operational profile 1240b in FIG. 12b is associated with MVNO Y2. The server (if the device 1202 is an M2M device) or the user (if the device 1202 is a consumer device) can switch back to MVNO Y1 using optional profile B 1243b, if desired. Bootstrap profile 1242b remains associated with MVNO X1. However, because bootstrap profile 1242b is configurable over-the-air, it can be changed to be associated with another profile, but on a different MNO than the operational profile, for example, using additional profile 1241b associated with MVNO X2.

[0116] Figure 13 shows profiles provided in an eUICC according to a fourth embodiment of the present invention. The fourth embodiment is similar to the second embodiment, and therefore the following description will focus on the differences between the second and fourth embodiments. The eUICC of the second embodiment has national profiles associated with MNOs that each provide connectivity in the country in which they operate their physical networks. Thus, the national profiles are associated with MNOs that provide connectivity in the same country in which the eUICC and alerting device are operating.

[0117] In contrast, the eUICC of this embodiment includes a roaming profile in addition to a domestic profile. The roaming profile enables an eUICC operating in a first country to access an MNO network operating in a second country. Thus, the eUICC is provided with roaming network access in addition to domestic network access. Thus, via the roaming profile, the eUICC has access to available networks with which the MNO providing the profile has a roaming agreement.

[0118] As shown in Figure 13, the eUICC has four domestic profiles 1302, 1304, 1306, and 1308 and four roaming profiles 1310, 1312, 1314, and 1316. Each of these profiles is associated with a different MNO. Specifically, the domestic profiles are associated with MNO 1, MNO 2, MNO 3, and MNO 4, respectively, which operate in the same country as the eUICC. The roaming profiles are associated with MNO A, MNO B, MNO C, and MNO D, respectively, which operate in a different country from the eUICC. For the domestic profiles, the domestic operational profile 1304 is associated with MNO 2, and the domestic bootstrap profile 1302 is associated with MNO 1.

[0119] As in the previous embodiment, one of the optional national profiles 1306, 1308, each associated with a different MNO than the current operational profile and the bootstrap profile, may be selected to serve as the national operational profile.

[0120] FIG. 14 illustrates a process in which the home profile and the roaming profile are utilized by the applet of this embodiment. First, the applet tests connectivity with the home operational profile 1304, i.e., the MNO network associated with MNO 2, in step 1402. Next, the applet checks whether the connectivity test was successful in step 1404. If the connectivity test was successful, the process loops back to continue testing connectivity in step 1402. If the connectivity test was not successful, the process continues to check whether a complete loss of connectivity with the MNO 2 network occurred in step 1406. If the applet determines that a loss of connectivity has not occurred, the process loops back to continue testing connectivity in step 1402. On the other hand, if it is determined that a loss of connectivity with the MNO 2 network has occurred, the device notifies the eUICC of this. After this notification, the applet allocates a predetermined time for the eUICC to search for an available roaming operator to find connectivity. In one embodiment, the applet allocates enough time for the SIM / device to roam across several networks, typically three, and if the eUICC does not find connectivity through a roaming operator within a predetermined time, the applet triggers a fallback and fallback cancellation process.

[0121] Once notified of the loss of connectivity, the eUICC or device checks whether there is an available roaming operator in step 1408. If the eUICC determines that there is an available roaming operator, the eUICC switches to the available roaming operator in step 1414. Once connected to the available roaming operator, the applet also tests connectivity with the MNO associated with the roaming operator in step 1414. The connectivity tests performed by the applet are similar to those performed in steps 1402, 1404, and 1406.

[0122] The roaming process effectively allows the eUICC to roam between available roaming operators to find connectivity. If no roaming operators are available, the applet proceeds to initiate the fallback and fallback cancellation processes according to steps 1410 and 1412, as in the embodiment described above.

[0123] This process allows the eUICC to switch between MNOs and thus quickly identify a roaming operator that can provide connectivity when connectivity is initially lost, which advantageously provides a first layer of resilience.

[0124] The connectivity tests performed by the applet are described in more detail below with reference to Figures 15-17. Figure 15 illustrates a process for using ping as a connectivity test and then initiating the fallback process described above with reference to Figures 7-9. Specifically, these figures illustrate a series of ping tests being performed, each pinging Server X, Server Y, and Server Z, and the results of each test. The first ping test 1502 results in ping responses being received from all three servers, while the second ping test 1504 results in no ping responses being received. The connectivity test proceeds to a third ping test 1506 and then a fourth ping test 1508, neither of which results in a ping response being received from any of the servers. Three consecutive failed ping tests will trigger the fallback process in step 902 and start a fallback timer in step 904.

[0125] FIG. 16 illustrates the ping connectivity test in more detail. The ping connectivity test begins in step 1602, with the operational profile active. In step 1604, an applet (not shown) sets a counter to 0. The applet then pings server X in step 1606. If the applet receives a ping response from server X, processing transitions to a wait state in step 1608 where the applet waits for [X] seconds (where [X] is a predetermined number of seconds representing the number of seconds between repeated attempts to ping server X). However, if the applet does not receive a ping response from server X, processing continues and the applet proceeds to ping server Y in step 1610. If the applet receives a ping response from server Y, processing transitions to a wait state in step 1612 where the applet waits for [X] seconds before retrying ping server X in step 1606, thereby restarting the ping sequence. On the other hand, if the applet does not receive a ping response from server Y, processing continues and the applet proceeds to ping server Z in step 1614. Finally, if the applet receives a ping response from server Z, processing transitions to a wait state in step 1616 where the applet waits for [X] seconds before pinging server X again in step 1606, thereby starting the ping sequence again. On the other hand, if the applet does not receive a ping response from server Z, processing continues and the counter is incremented by 1 in step 1618.

[0126] Next, in step 1620, the applet checks the value of the counter to determine whether there have been more than [N] failed ping sequences (where [N] is a predetermined value representing the number of failed ping sequences required for the applet to trigger fallback processing). That is, the applet checks whether the counter is greater than or equal to N. If the result of this check is negative, the applet waits for [Z] seconds (where [Z] is a predetermined number representing the number of seconds to wait before restarting the ping sequence) in step 1622. After [Z] seconds have elapsed, the applet restarts the ping sequence by pinging server X in step 1606. If the result of the above check in step 1620 is positive, that is, if the counter is greater than or equal to N, the applet starts fallback processing in step 1624 and simultaneously starts a fallback cancel timer in step 1626. Steps 1624 and 1626 are understood to be similar to steps 902 and 904, respectively, of FIG. 9 . Therefore, the subsequent steps in Figures 9 and 10 also apply to this embodiment. Note that in the process flow of Figure 16, the operational profile of the eUICC is currently active. The ping connectivity test can also be performed when the bootstrap profile is active instead of the operational profile, for example, when the fallback process has already been performed and switching to the bootstrap profile has been performed. The process flow in this case will be described below with reference to Figure 17.

[0127] The applet maintains a state machine while performing a ping connectivity test and initiating fallback and fallback cancellation procedures, as illustrated in FIG. 17. The various states of the state machine ensure that the eUICC remains connected. Note that the states and process flow illustrated in FIG. 17 are for illustrative purposes only. At the start of the process, the eUICC uses the operational profile (Profile 1) associated with the first MNO network, MNO 1. Because Profile 1 provides connectivity for the eUICC, in state 1702 the applet records Profile 1 as "good." The applet tests connectivity with the MNO 1 network by pinging servers X, Y, and Z to create a ping sequence. In state 1704, the applet records a positive ping sequence, i.e., ping responses were received from all three servers. The applet then repeats the ping test. In state 1706, the applet records a negative ping sequence, i.e., no ping response was received from the server. The applet repeats the ping test two more times in state 1708, recording the second and third negative ping sequences, respectively, in state 1710. The applet determines that there have been three consecutive negative ping sequences, and as a result, initiates a fallback process. The fallback process switches the currently active profile from the operational profile to the bootstrap profile (profile 2) associated with the second MNO network, MNO 2. At the same time, a fallback cancel timer is started.

[0128] Once the fallback process is performed, the applet can be in one of two states: a first state in which Profile 2 does not provide connectivity for the eUICC in state 1712, and a second state in which Profile 2 provides connectivity for the eUICC in state 1722. Starting from state 1712 (no connectivity), the applet then tests connectivity to the MNO 2 network via Profile 2 using the ping test described above. In states 1714, 1716, and 1718, the applet records three consecutive negative ping sequences. The applet determines that there have been three consecutive negative ping sequences and therefore initiates a fallback cancellation process. The fallback cancellation process switches the currently active profile from the bootstrap profile (Profile 2) back to the operational profile (Profile 1) associated with the MNO 1 network. Once the fallback cancellation process is performed, the applet can be in one of two states: a first state in which Profile 1 does not provide connectivity for the eUICC in state 1720, and a second state in which Profile 1 provides connectivity for the eUICC in state 1702. If connectivity is not recorded in state 1720, the applet then tests connectivity to the MNO 1 network via Profile 1 using a ping test, and thus states 1706, 1708, and 1710 are repeated. If connectivity to the MNO 1 network via Profile 1 is recorded in state 1702, the applet then tests connectivity to the MNO 1 network via Profile 1 using a ping test, and state 1704 is repeated.

[0129] Moving to state 1722, once the fallback process is performed, Profile 2 provides connectivity to the eUICC. The applet then tests connectivity to the MNO 2 network via Profile 2 using a ping test, as described above. In state 1724, the applet records a positive ping sequence. At this stage, the applet is checking whether the fallback cancel timer has expired. If so, in state 1732, the applet records the expiration of the fallback cancel timer and initiates the fallback cancel process. Alternatively, if the fallback cancel timer has not expired, the applet repeats the ping test. In states 1726, 1728, and 1730, the applet records three consecutive negative ping sequences. The applet determines that there have been three consecutive negative ping sequences and therefore initiates the fallback cancel process.

[0130] The fallback cancellation process switches the currently active profile from the bootstrap profile (Profile 2) back to the operational profile (Profile 1) associated with the MNO 1 network. Once the fallback cancellation process is performed, the applet can be in one of two states: a first state in which Profile 1 does not provide connectivity for the eUICC, in state 1734, and a second state in which Profile 1 provides connectivity for the eUICC, in state 1702. If connectivity is not recorded in state 1734, the applet then tests connectivity to the MNO 1 network via Profile 1 using a ping test, and states 1706, 1708, and 1710 are repeated. If connectivity to the MNO 1 network via Profile 1 is recorded in state 1702, the applet then tests connectivity to the MNO 1 network via Profile 1 using a ping test, and state 1704 is repeated.

[0131] Referring now to FIG. 18, the steps performed by the applet during fallback and fallback cancellation are shown in more detail. The process flow of FIG. 18 continues from the positive result of the check in step 1618 of the process flow of FIG. 16. Specifically, if the result of the check in step 1620 (FIG. 16) is positive, i.e., if the counter is greater than or equal to N, the process continues in step 1802 (FIG. 18) to check the Profile Loaded Flag, which indicates which profile is currently active on the eUICC. If the Profile Loaded Flag indicates that the operational profile is currently active, the process continues in step 1804 to trigger fallback processing and simultaneously start the fallback cancellation timer in step 1806. Thus, steps 1804 and 1806 shown in FIG. 18 are similar to steps 1624 and 1626 shown in FIG. 16.

[0132] After triggering the fallback process, the applet disconnects from the operational profile in step 1808 and then connects to the bootstrap profile in step 1810. After the applet connects to the bootstrap profile, the applet updates the profile loaded flag to the bootstrap profile and loads the context settings of the bootstrap profile in step 1812.

[0133] The fallback cancel timer started by the applet in step 1806 is set to a predetermined time, i.e., [H] hours. Thus, the applet waits for [H] hours in step 1814, and once the time limit is reached, the applet triggers the fallback cancel process in step 1816. Once the fallback cancel process is triggered, the applet cancels the fallback cancel timer in step 1818. The fallback cancel process itself involves the applet disconnecting from the bootstrap profile in step 1820 and connecting to the operational profile in step 1822. Next, the applet starts a SIM trigger timer of a predetermined time, i.e., [T] minutes, in step 1824. The SIM trigger timer ensures that the eUICC waits a period of time after the fallback cancel timer expires and the fallback cancel process is complete. This staggers (e.g., by random delay periods) the return of the eUICC to the operational profile and corresponding MNO network to avoid signaling storms as described above in other embodiments. In step 1826, the applet checks whether [T] minutes has been reached, then in step 1812, it updates the profile loaded flag to the operational profile and loads the context settings of the operational profile, also in step 1812.

[0134] If in step 1802 the profile loaded flag indicates that the bootstrap profile is currently active on the eUICC, then processing proceeds directly to step 1816, which triggers a fallback cancellation procedure and switches to the operational profile.

[0135] Figure 19 shows a table summarizing the timing used by the applet in the ping connectivity test and fallback and fallback cancellation processes for the domestic and roaming profiles. First, [N] 1902 is the number of failed ping sequence attempts required for the applet to trigger fallback processing. As shown in Figure 16, the applet checks whether fallback processing needs to be triggered by checking whether the counter is greater than or equal to [N] (see step 1620).

[0136] Second, [X] 1904 is the number of seconds the applet will wait between ping attempts during a connectivity test. As shown in Figure 16, after pinging each of servers X, Y, and Z, the applet will wait [X] seconds before pinging server X again (see steps 1608, 1612, and 1616).

[0137] Third, [Z] 1906 is the number of seconds the applet will wait before starting the ping sequence again. As shown in Figure 16, after one ping sequence is completed, if the check in step 1620 is negative, the applet will increment the counter by 1, and then in step 1622 will wait [Z] seconds before starting the ping sequence again by pinging server X again.

[0138] Fourth, [H] 1908 is the amount of time the applet waits before canceling the fallback. As shown in Figure 18, the fallback cancel timer is started in step 1806, the applet waits [H] using a timer that monitors the elapsed time in step 1814, and then triggers the fallback cancel in step 1816.

[0139] Fifth, [T] 1910 is the number of minutes the applet waits after the fallback cancel timer expires and performs the fallback cancel process. As shown in Figure 18, a SIM trigger timer is used to monitor [T] in step 1824. This delays the transition of the eUICC back to its operational profile and the corresponding MNO network to avoid signaling storms.

[0140] Finally, the expected total time before the applet triggers the fallback process is approximately 3 to 5 minutes if only a domestic profile is used, and approximately 6 to 15 minutes if both a domestic profile and a roaming profile are used. If a roaming profile is used on the eUICC, the applet does not interfere with the inter-MNO roaming process and ensures that the eUICC is allocated sufficient time to disconnect from one MNO and roam to connect to another before triggering the fallback process. Typically, there are three or four MNOs in a given country. Therefore, the applet allocates a configurable time of 3 to 15 minutes for the device and eUICC to cycle through roaming MNOs. The allocated time depends on the importance of the services provided using the eUICC.

[0141] As previously mentioned, returning the eUICC to its operational profile over time after triggering a fallback cancellation helps to avoid signaling storms and further outages. In some embodiments, the applet uses a random number (which may be derived from, for example, the Integrated Circuit Card Identifier (ICCID), the International Mobile Equipment Identity (IMEI) of the host device, or the Mobile Station International Subscriber Directory Number (MISDIN) assigned to the device by the network) and an associated time slot. The applet ensures that the fallback cancellation process does not occur until the specific time slot associated with the random number is reached. That is, the applet delays the fallback cancellation process. As an example, if the ICCID number ends in 2, the assigned time slot is 12 to 18 minutes after the expiration of the first fallback cancellation timer. Therefore, the applet on the eUICC waits 12 minutes after the expiration of the first fallback cancellation timer before performing the fallback cancellation process.

[0142] Figure 20 shows an example of another possible time slot determination using the last digit of the ICCID number. For example, if the last digit of the ICCID number is 4 (see 2002 in Figure 20), the assigned time slot is 24 to 30 minutes after the fallback cancel timer expires (see 2004 in Figure 20). In other embodiments, a random digit of the ICCID number may be used instead.

[0143] Elements of an applet can be configured through context settings. These context settings provide the applet with information about the environment, how the applet should operate, and how it should test and trigger events. The applet can be configured based on whether a domestic or roaming profile is being used. Figure 21 shows a table summarizing the configurable elements of an applet.

[0144] The total time 2102 allotted to the applet to complete the ping sequence is configurable. In this embodiment, this is set to 6 to 15 minutes for a roaming profile and 3 to 5 minutes for a domestic profile. Other configurable elements of the applet include the ping sequence number 2104 used in the connectivity ping test and the Internet address of the corresponding ping server 2106. These elements are particularly important when an MNO blacklists IP addresses to prevent certain servers from being pinged, or when a server is shut down and needs to be replaced with another server. Additionally, the ping test may have latency issues if the server is located in Europe and an eUICC is used in Australia, accidentally triggering a fallback process.

[0145] Additionally, parameters used by the applet can be configured such as the timing between ping sequences 2108 (corresponding to [X]), the number of failed ping sequence attempts before triggering fallback processing 2110 (corresponding to [N]), and the wait time for a ping 2112, i.e., the time it takes for a ping to return before being considered a failed ping.

[0146] "Applet-Platform Synchronization" provides real-time information directly from the applet to the MNO platform. If the MNO platform fails to receive a ping from the applet, the MNO platform can automate a request to the MNO network's Visitor Location Record (VLR) to reset the connection to the eUICC. This request is referred to herein as a "Location Cancellation" request. Figure 22 shows the process for Applet-Platform Synchronization and triggering a Location Cancellation request.

[0147] First, the applet pings the server on the MNO platform in step 2202. The server then records the received ping in step 2204, after which the server starts Timer A in step 2206. The applet then pings the server again in step 2208, and the server records this second ping in step 2210. Once the second ping has been recorded, the server stops Timer A in step 2212 and starts Timer B in step 2216. The server stores the time from Timer A in a database associated with the server in step 2214. The stored time from Timer A therefore represents the time between the first and second pings recorded by the server. Next, the applet pings the server a third time in step 2218, and the server records this third ping in step 2220. Once the third ping has been recorded, the server restarts Timer A in step 2222 and simultaneously stops Timer B in step 2224. The server stores the time from Timer B in a database associated with the server in step 2226. The stored time from Timer B thus represents the time between the second and third pings recorded by the server.

[0148] The process continues in step 2228, where the server checks the time between pings against a predetermined time threshold. That is, the server checks the time from stored Timer A for the time between the first and second pings, and the time from stored Timer B for the time between the second and third pings. If Timer A and Timer B are both below the predetermined threshold, this check passes and the process loops back from the second ping, i.e., without server intervention, to ping the server again in step 2208. On the other hand, if the time between pings fails this check, this indicates that the pings did not reach the server in time (i.e., the time between pings exceeds the predetermined time threshold), and the server checks in step 2230 whether Timer Y has been started.

[0149] If not already started, the server starts timer Y in step 2232. If timer Y has been started, the server checks in step 2234 whether timer Y is greater than or equal to 20 minutes. If the result of this check is negative, i.e. timer Y is less than 20 minutes, the process loops back from the second ping and pings the server again in step 2208. If the result of the check in step 2234 is positive, i.e. timer Y is greater than or equal to 20 minutes, the server calls the API of the MNO platform in step 2236 to send a location cancellation request to the VLR of the MNO network to cancel the connection to the eUICC.

[0150] The location cancel request is a request to the MNO network to disconnect the eUICC from the MNO network. This forces the eUICC to re-initiate a connection to the MNO, effectively resetting the connection to the eUICC. The server then waits for an incoming ping in step 2238 and then starts the process again from step 2202. The time the server waits in this step is configurable, but is typically around 10 minutes. If the server does not receive an incoming ping, this may indicate that the device and / or eUICC has powered down and / or failed.

[0151] The connection to the eUICC may be reset in this way before the fallback procedure is initiated. For example, the eUICC may experience connectivity issues while in the operational profile. The connectivity issues may be resolved simply by resetting the connection based on the location cancellation request. Alternatively, the connection may be initiated again after the fallback procedure is initiated. For example, after the eUICC switches from the operational profile to the bootstrap profile, the eUICC may remain offline due to issues with the MNO network, such as network congestion, or because the radio module needs to be reset. Resetting the connection to the eUICC after the fallback procedure is initiated may have the effect of resolving the network issues and / or resetting the radio module on a failed or crashed device, thereby allowing the eUICC to reconnect.

[0152] Additionally, applet inter-platform synchronization makes it possible to alert the network operations center to large-scale network issues so that the network operations center can begin to resolve the issue with the MNO before a fallback process kicks in. Applet inter-platform synchronization also makes it possible to automatically alert customers to impending network changes on their eUICC.

[0153] While embodiments of the present invention employ pinging as a connectivity test, it should be noted that other connectivity tests may be used in any embodiment of the present invention to identify potential issues. The applet may use many alternative end-to-end connectivity service testing methods to test connectivity. Alternative testing methods may include, but are not limited to, one or more of the following: Address Resolution Protocol (ARP) pinging; data delivery (e.g., whether the SIM can deliver 10 kb of data to the server); speed testing; and / or testing one or more network layers, such as Layer 1 - Physical; Layer 2 - Data Link; Layer 3 - Network; Layer 4 - Transport; Layer 5 - Session; Layer 6 - Presentation; and Layer 7 - Application.

[0154] It should also be noted that while embodiments of the present invention are described with respect to an applet embodied on an eUICC, the applet may be installed on any compatible SIM (i.e., any UICC) and may use any SIM card format. Examples of compatible SIMs are shown in Figure 23. Specifically, any of the following SIM types may be used: a 2FF mini-SIM (25mm x 15mm x 0.76mm) 2302, a 3FF micro-SIM (15mm x 12mm x 0.76mm) 2304, a 4FF nano-SIM (12.3mm x 8.8mm x 0.67mm) 2306, and a MFF2 solderable SIM 2308, as shown in Figure 23.

[0155] It is further noted that the applet can operate on SIM cards manufactured by any SIM vendor, including but not limited to Gemalto, Thales, Giesecke & Devrient, Idemia (Morpho and Oberthur Technologies), Bluefish, Datang and DZCARD.

[0156] It is further noted that although embodiments of the present invention are described with respect to an eUICC installed in an alarm device, the eUICC may be installed in any device requiring wireless network connectivity. For example, the eUICC may be installed in a smartphone, a tablet, a dongle, a router, a GPS tracking device, an M2M device, an IoT device, a vehicle, or a telemedicine and telecare device.

[0157] It should also be noted that embodiments of the present invention can be used with a variety of MNO platforms, including but not limited to Cisco Jasper, Ericsson DCP, Vodafone GDSP, Nokia Wing, Huawei IoT Connection Management Platform and Orange Platform.

[0158] Features of one embodiment may be used in other embodiments in addition to or as an alternative to the embodiment.

Claims

1. 1. A Universal Integrated Circuit Card (UICC) for controlling wireless communications over a wireless communications network with a host device in which the UICC is installed, in use, comprising: a microprocessor located within the UICC for controlling operation of the UICC; a data store provided within the UICC for storing data relating to the operation of the UICC, an operational profile including wireless communication network settings for connecting the host device to a first wireless communication network; and a plurality of mobile carrier network profiles including a bootstrap profile including wireless communication network settings for connecting the host device to a second wireless communication network; a data store containing a program running on said microprocessor and including a plurality of instructions for configuring operation of said UICC; In use, the microprocessor: connecting the host device to the first wireless communication network using the operational profile; performing a first wireless communication network connectivity test to test first connectivity of the wireless communication network between the host device and the first wireless communication network established by the program using the operational profile, and returning a first connectivity test result based on the first wireless communication network connectivity test; determining whether a loss of wireless communication network connectivity has occurred between the host device and the first wireless communication network based on the first connectivity test result; if such a loss of connectivity is determined, deselecting the operational profile and selecting the bootstrap profile, and connecting to the second wireless communication network using the bootstrap profile based on the network settings of the bootstrap profile to re-establish the connectivity of the wireless communication network with the host device; A Universal Integrated Circuit Card (UICC) configured by said program.

2. The UICC of claim 1 , wherein the UICC is an embedded UICC (eUICC) that allows the programs and profiles to be remotely configured and / or updated.

3. The UICC of claim 1 or 2, wherein the program comprises an applet having a relatively small size and dedicated functionality.

4. 4. The UICC of claim 1, wherein the data store is provided in a secure transversal domain of the UICC, and the operational profile or the bootstrap profile can securely provide access to the secure transversal domain of the UICC to enable an external server to make changes to the programs stored in the data store.

5. 5. The UICC of claim 1, further comprising a set of variable parameters stored as files in the data store for configuring the operational profile and bootstrap profile and their use in controlling wireless communication with the host device over the wireless communication network.

6. The program, when used, starting a cancellation timer of a predetermined duration when a loss of connection is detected on the first wireless communication network; once the cancel timer expires, deselecting the bootstrap profile, reselecting the operational profile, and reconnecting to the first wireless communication network using the operational profile to re-establish wireless communication network connectivity between the host device and the first wireless communication network; A UICC according to any preceding claim, including instructions for configuring said microprocessor.

7. The program, when used, after connecting the host device to the second wireless communication network using the bootstrap profile, performing a second wireless communication network connectivity test to test a second wireless communication network connectivity between the host device and the second wireless communication network, and returning a second connectivity test result based on the second wireless communication network connectivity test; determining whether a loss of wireless communication network connectivity has occurred between the host device and the second wireless communication network based on the second connectivity test result; if such loss of connectivity is determined, deselecting the bootstrap profile and reselecting the operational profile and connecting to the first wireless communication network using the operational profile based on the network settings of the operational profile to re-establish the connectivity of the wireless communication network to the host device; A UICC according to any preceding claim, including instructions for configuring said microprocessor.

8. The program, when used, determining a time slot for using the reselected operational profile; delaying disconnection from the second wireless communication network and connection to the first wireless communication network using the reselected operational profile until the time slot arrives; A UICC according to claim 6 or 7, including instructions for configuring said microprocessor.

9. The UICC of claim 8 , wherein the time slot is determined using a random number or a number from an ICCID, IMEI, or MISDIN associated with the UICC or host device.

10. 10. A UICC as claimed in any one of claims 7 to 9, wherein the program includes instructions for configuring the microprocessor to, in use, perform the first or second wireless communication network connectivity test by testing wireless communication network connectivity between the host device and one or more test servers within the wireless communication network being tested.

11. The program includes instructions for configuring the microprocessor, in use, to perform the first or second wireless communication network connectivity test by performing a ping test, the ping test comprising: sending a forwarded data packet to at least one test server of the one or more test servers; determining whether a response data packet is received from the test server; and The UICC of claim 10, further comprising returning a negative first or second wireless communication network connectivity test result if the response data packet is not received from the test server within a predetermined period of time after sending the forwarding data packet.

12. The program includes instructions for configuring the microprocessor, in use, to perform the first or second wireless communication network connectivity test by performing a ping sequence test, the ping sequence test comprising: sending a first forwarded data packet to a first test server of the one or more test servers; determining whether a first response data packet is received from the first test server within a first predetermined period of time; sending a second forwarded data packet to a second test server of the one or more test servers if it is determined that the first response data packet has not been received within the first predetermined period of time; determining whether a second response data packet is received from the second test server within a second predetermined period of time; sending a third forwarded data packet to a third test server of the one or more test servers when it is determined that the second response data packet has not been received within the second predetermined period of time; determining whether a third response data packet is received from the third test server within a third predetermined period; returning a negative ping sequence test result if it is determined that the third response data packet has not been received within the third predetermined period of time; and The UICC of claim 10, further comprising returning a negative first or second wireless communication network connectivity test result if a negative ping sequence test result is returned.

13. 13. The UICC of claim 12, wherein the program includes instructions for configuring the microprocessor, in use, to perform the first or second wireless communication network connectivity test by repeating the ping sequence test one or more times, and wherein the negative wireless communication network connectivity test result is returned only if a number of consecutive negative ping sequence test results exceeds a predetermined threshold.

14. The program includes instructions for configuring the microprocessor, in use, to perform the first or second wireless communication network connectivity test by performing a data test, the data test comprising: Sending a predetermined amount of data to a test server; determining whether the predetermined amount of data has been delivered to the test server; The UICC of claim 10, further comprising returning a negative first or second wireless communication network connectivity test result if the predetermined amount of data is not delivered to the test server.

15. 11. The UICC of claim 10, wherein the program includes instructions for configuring the microprocessor, when in use, to perform the first or second wireless communication network connectivity test by performing a network layer test, the network layer test including testing different network layers of the first or second wireless communication network.

16. the data store includes a roaming profile including wireless communication network settings for connecting the host device to a roaming wireless communication network; 16. The UICC of any one of claims 1 to 15, wherein the program includes instructions for configuring the microprocessor to, in use, after detecting a loss of operational connectivity with the first wireless communication network, use the roaming profile to connect the host device to the roaming wireless communication network based on the network settings of the roaming profile in order to re-establish wireless communication with the host device.

17. the data store includes a plurality of wireless network profiles, each of the wireless network profiles comprising a wireless communication network setting for connecting the host device to a respective wireless communication network; The UICC of any one of claims 1 to 16, wherein the UICC is configured to enable remote selection of the operational profile and the bootstrap profile from the plurality of profiles.

18. the data store includes a plurality of wireless network profiles, each of the wireless network profiles comprising a wireless communication network setting for connecting the host device to a respective wireless communication network; The UICC of claim 1 , wherein the UICC is configured to enable a local user to select the operational profile and the bootstrap profile from the plurality of profiles.

19. The UICC according to claim 17 or 18, wherein each wireless network profile in the plurality of wireless network profiles is associated with a different independent wireless communication network.

20. The UICC of claim 17 or 18, wherein each network profile in the plurality of network profiles is associated with an independent wireless communication network platform or a different instance of the same wireless communication network platform.

21. The UICC of any one of claims 1 to 20, wherein the UICC comprises an eUICC, a mini SIM, a micro SIM, a nano SIM or a solderable SIM.

22. A host device comprising a processor having a memory, a wireless module for connecting the host device to a wireless communication network, and a general purpose integrated circuit device according to any one of claims 1 to 20.

23. 23. The host device of claim 22, wherein the host device comprises an alarm device, a smartphone, a tablet computer, a dongle, a router, a GPS tracking device, an M2M device, an IoT device, a vehicle, a telemedicine device, or a telecare device.

24. 1. A method of operating a Universal Integrated Circuit Card (UICC) for controlling wireless communication over a wireless communication network with a host device in which the UICC is installed in use, comprising: providing access to data relating to the operation of the UICC stored in a data store within the UICC, the data comprising: an operational profile including wireless communication network settings for connecting the host device to a first wireless communication network; and a plurality of mobile carrier network profiles, including a bootstrap profile including wireless communication network settings for connecting the host device to a second wireless communication network; controlling operation of the UICC using a microprocessor within the UICC and a program running on the microprocessor and including a plurality of instructions for configuring operation of the UICC, connecting the host device to the first wireless communication network using the operational profile; performing a first wireless communication network connectivity test to test first connectivity of the wireless communication network between the host device and the first wireless communication network established by the program using the operational profile, and returning a first connectivity test result based on the first wireless communication network connectivity test; and determining whether a loss of wireless communication network connectivity has occurred between the host device and the first wireless communication network based on the first connectivity test result; a control step of deselecting the operational profile and selecting the bootstrap profile when such a loss of connectivity is determined, and connecting to the second wireless communication network using the bootstrap profile based on the network settings of the bootstrap profile to re-establish the connectivity of the wireless communication network between the host device and the host device; A method comprising:

25. 25. A computer program product or computer readable storage medium comprising instructions that, when executed by a computer, cause the computer to perform the method of claim 24.

Images