[0001] The present application relates to a system and method for synchronising device configuration data of each of a plurality of devices with corresponding device configuration data maintained by a first platform and a second platform configured to remotely control/configure said devices.

BACKGROUND

[0002] The Internet of Things (loT) is the name given to billions of devices that may be deployed and configured to be connected to the Internet and/or networked in one or more communication networks for collecting and sharing data for a plurality of applications and/or services. This is opening up new applications, services, innovation and creativity. For example, a transport service provided may use a large loT deployment of thousands of devices deployed across one or more transport distribution networks for remote tracking of goods and/or shipments and the like. Given the large scale of devices requiring communication and, in particular, wireless communication capabilities and access to communication networks of telecommunication and/or mobile network operators (MNO(s)), manual configuration of such devices for loT deployments is extremely inefficient. Thus, devices are being manufactured with the capability of being deployed and remotely controlled, configured and/or provisioned with the necessary device configuration data enabling the devices to be authenticated and connect to the appropriate communication network(s) of MNO(s) associated with the device configuration data and operating according to customers/third party loT deployment requirements for rapidly providing the necessary applications and/or services.

[0003] There have been systems and/or platforms, so-called remote provisioning systems, developed to enable devices to be rapidly deployed and remotely controlled/configured and/or provisioned with device configuration data enabling devices to securely communicate over one or more communication networks of an MNO. The device configuration data may comprise or represent data for controlling and/or configuring one or more operations of software/hardware of a device. For example, in the above examples, device configuration data may comprise or represent data representative of device, subscription and/or operator profile data that configures and/or enables the operation of software/hardware of a device for, without limitation, authentication and communication on one or more communication network(s) of one or more corresponding MNOs. For example, such systems may be based on the current Global System for Mobile Communications Association (GSMA) standard, so-called remote SIM control/provisioning systems, are configured to remotely provision devices with device configuration data based on SIM technologies used for authenticating subscribers and devices on networks of one or more MNOs. For GSMA, device configuration data may include, without limitation, for example data representative of subscriber identity module (SIM) profile data, integrated-SIM (ISIM), embedded-SIM (eSIM) profile data, and/or embedded universal integrated circuit card (eUlCC) profile data and the like. This enables the eSIM, ISIM or eUlCC of such devices to be remotely provisioned with eSIM/eUICC profiles that enables these devices to be authenticated and communicate over the communication networks of MNOs based on a successfully provisioned profile etc.

[0004] However, device configuration data such as, without limitation, for example eSIM/ISIM profiles can become "broken", corrupted, out-of-date during remote provisioning and/or deployment and operation of the devices that have been remote provisioned. For example a device may be remotely provisioned with one or more eSIM/ISIM profile(s) but, during the provisioning process, may fail to report success of the remote provisioning to the remote provisioning system due to a communication outage and the like. In such cases, the remote provisioning system is unaware the device has been successfully provisioned and may have recorded the device eSIM/ISIM profile(s) as being invalid. Nevertheless, the device may continue to operate and communicate over the communication networks of the MNO associated with the "invalid" eSIM/ISIM profile. Other scenarios include ISIM/eSIM profile(s) becoming corrupted and/or out-of-date during operation of the device in which the device falls back to bootstrap and/or another operational profile when it is supposed to be using the provisioned eSIM/ISIM profiles. Such device inconsistencies may not be detected and these devices may continue to operate on invalid and/or corrupted/out of date eSIM/ISIM profiles which wastes the communication resources of MNOs and/or may significantly increase the cost of operating a plurality of such devices (e.g. Internet of Things devices) for third party service providers using such devices (e.g. loT service providers).

[0005] Even though the above issues have been described with respect to a device, in reality, there are a plethora of devices being updated all the time, especially with large loT deployments in which thousands of loT devices may be required to be remotely controlled, configured and/or provisioned. Thus, it is clear that as the number of devices scale so too does the number of devices with inconsistencies/failures in relation to being provisioned and the like. Even if a few percent of the plethora of devices being provisioned have inconsistencies, resolving such inconsistences manually is problematic for remote provisioning operators and is fast becoming implausible as loT and the number of devices in use skyrockets. It is apparent that conventional or current systems for troubleshooting and/or detecting devices with "broken" SIM/iSIM/eSIM profile(s) is becoming a laborious and time consuming manual task for remote provisioning operators, MNOs, and/or third party providers and often results in the need to perform an audit on all devices to detect, reconfigure, resynchronise, and/or remove the SIM/iSIM/eSIM profile(s) and generate/provision another one for the affected device(s). This may lead to significant delays in, without limitation, for example getting a plurality of devices provisioned loT device deployment.

[0006] Conventionally, in order to determine that a SIM/eSIM/iSIM profile is broken a number of events may need to occur such as, without limitation, for example: 1) third party provider, end user or customer realises one or more devices they are using or have deployed and are operating has no connectivity or is unable to connect to an access point node (APN) or communication network these devices are trying to access; 2) remote provisioning system(s) such as Internet of Things management platform(s) and distribution remote provisioning platforms for generating, distributing and remotely provisioning device configuration data (e.g. data representative of SIM/iSIM/eSIM profile(s)) may only perform infrequent periodic checks on a plurality of devices to determine device status; 4) remote provisioning platforms for generating and distributing device configuration data to those remote provisioning platforms for deploying the device configuration data to a plurality of devices may become unsynchronised due to communication outages and/or delays in reporting successful or unsuccessful provisioning of each device of a plurality of devices being provisioned; 5) the requirement to deploy a wide range of MNO troubleshooting tools such as disconnect I reconnect I refresh functions and the like on the plurality of devices before a problem device with "broken" eSIM/ISIM is detected. There are numerous events/scenarios in which one or more devices of a plurality devices being remotely provisioned with the appropriate device configuration data may be operating using device configuration data that is invalid, out-of-date and/or corrupted. There can be a lengthy delay between one or more of such events occurring and problematic devices being detected, identified and/or reconfigured or taken out of service, where the problematic device has been continuing to use or communicate over one or more networks of one or more MNOs.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Embodiments of the invention will be described, by way of example, with reference to the following drawings, in which:

[0008] Figure 1a is a schematic diagram illustrating a remote provisioning system with device synchronisation apparatus according to the invention;

[0009] Figure 1 b is a flow diagram illustrating an example device synchronisation process for use with a first platform of the remote provisioning system according to the invention;

[0010] Figure 1 c is a flow diagram illustrating an example traffic monitoring process for use with the device synchronisation apparatus of figure 1a according to the invention;

[0011] Figure 2a is a schematic diagram illustrating an example remote provisioning system of figure 1 a modified based on the GSMA standard for remotely provisioning devices according to the invention;

[0012] Figure 2b is a flow diagram illustrating an example device synchronisation process for use with a first platform of the remote provisioning system of figure 2a according to the invention;

[0013] Figure 2c is a flow diagram illustrating another example synchronisation checking process that may be performed by a device synchronisation apparatus or remote provisioning system according to the invention;

[0014] Figure 3 is a schematic diagram illustrating device synchronisation apparatus of figures 2a to 2c according to the invention; and [0015] Figure 4 is a schematic diagram illustrating an example computing system for a remote provisioning system and/or device synchronisation apparatus according to the invention.

[0016] Common reference numerals are used throughout the figures to indicate similar features.

DETAILED DESCRIPTION

[0017] There is a desire for more efficient and rapid detection of problematic devices that have been remotely provisioned by a remote provisioning system and for efficiently rectifying the state of each detected problematic device and the like.

[0018] The embodiments described below are not limited to implementations which solve any or all of the disadvantages of the known approaches described above.

[0019] This following is provided to introduce a selection of concepts in a simplified form that are further described below, and is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to determine the scope of the claimed subject matter; variants and alternative features which facilitate the working of the invention and/or serve to achieve a substantially similar technical effect should be considered as falling into the scope of the invention disclosed herein.

[0020] The present disclosure provides a device synchronisation mechanism or apparatus for detecting whether one or more remote platforms(s), system(s) and/or components thereof and one or more devices of a plurality of devices, which have been remotely controlled and/or configured with device configuration data by said remote platforms for configuring one or more operations of software/hardware of the device (e.g. operations related to communication over one or more communication networks), have come out of synchronisation with one another based on device traffic of each device communicating over one or more communication networks. The device synchronisation mechanism or apparatus is configured to detect and to rapidly update the required device configuration data (e.g. SIM/iSIM/eSIM profiles and the like) of the remote platform(s) and/or components thereof and/or said affected devices.

[0021] In a first aspect, the present disclosure provides a computer-implemented method of synchronising device state information between a first platform, a second platform and a plurality of devices remotely controlled for communication by the first and second platforms, the method comprising: receiving an indication of the status of a device of the plurality of devices based on traffic associated with the device communicating over a communication network; determining whether first device state information of the device stored by the first platform and second device state information of the device stored by the second platform are correlated with the received status indication of the device; and triggering one or more device state update actions for at least one of the corresponding first platform, the second platform and the device when at least one of the first and second device state information is uncorrelated with the received status indication of the device. [0022] As an option, the computer-implemented method according to the first aspect, wherein the device is remotely controlled and configured with device configuration data comprising data representative of controlling or configuring one or more operations of the device; and the device state information for the device comprises data representative of the device configuration data and the status of the device.

[0023] As another option, the computer-implemented method according to the first aspect, wherein the device is remotely controlled and configured with device configuration data comprising data representative of device, subscriber and/or operator profile data for authenticating the device on a communication network of a network operator; and the device state information for the device comprises data representative of the device configuration data and the status of the device.

[0024] As a further option, the computer-implemented method according to the first aspect, further comprising: receiving device traffic associated with the device; and extracting, from the received device traffic, device status data associated with device configuration data based on the device traffic.

[0025] Optionally, the computer-implemented method according to the first aspect, wherein the device state update comprises updating the device configuration data of the first platform when the second device state information of the device correlates with the device status indication of the device and the first device state information of the first platform is decorrelated with the device status indication of the device.

[0026] Optionally, the computer-implemented method according to the first aspect, wherein the device state update comprises updating the device configuration data of the first platform, the second platform and the device when the second device state information is decorrelated with the device status indication of the device.

[0027] Optionally, the computer-implemented method according to the first aspect, wherein the device state update comprises updating the device configuration data of the first platform, the second platform and the device when the first device state information, the second device state information and the device status indication of the device are decorrelated.

[0028] Optionally, the computer-implemented method according to the first aspect, wherein each of the devices includes a subscriber identity module, SIM, component and the device configuration data comprises data representative of one or more from the group of: subscriber identity module, SIM, profile data; integrated-SIM profile data; embedded-SIM profile data; embedded universal integrated circuit card, eUlCC, profile data; and subscriber, device and/or operator profile data.

[0029] As an option, the computer-implemented method according to the first aspect, wherein the one or more device state update actions comprises a Get eUlCC Information Set, EIS, operation associated with the device for retrieving the second device state information of the device from the second platform. As another option, the computer-implemented method according to the first aspect, wherein the one or more device state update actions comprises an Audit operation associated with the device for updating the device configuration data of the first platform, the second platform and the device.

[0030] As a further option, the computer-implemented method according to the first aspect, further comprising: receiving device traffic associated with the device; extracting device data based on device configuration data used to configure the device from the received device traffic; and generating the indication of the status of the device based on the extracted device data.

[0031] Optionally, the computer-implemented method according to the first aspect, further comprising: extracting device configuration data of the device from message traffic associated with the device; generating a first indication of the status of the device based on the extracted device configuration data of the device; retrieving device data associated with device configuration data or device state information of the device from one or more data source(s) accessible by the first platform; generating one or more second indication(s) of the status of the device based on the retrieved device data; and generating a third indication of the status of the device based on device state information of the device accessible by the second platform.

[0032] As an option, the computer-implemented method according to the first aspect, wherein the one or more data source(s) accessible to the first platform include one or more from the group of: Call Data Records (CDRs), associated with each SIM component of each device of the plurality of devices; configuration or profile database(s) configured for maintaining device state information of the device based on device configuration data remotely provisioned on the device; and transaction database(s) configured for maintaining a set of transactions of the device associated with remote provisioning the device.

[0033] Optionally, the computer-implemented method according to the first aspect, wherein an access point of the communication network is configured to receive device traffic associated with the plurality of devices when communicating over the communication network, and send device traffic data associated with each device communicating over the communication network.

[0034] As an option, the computer-implemented method according to the first aspect, wherein the access point uses the RADIUS protocol for counting the traffic packets for each device of the plurality of devices communicating over the communication network, and sends the device traffic data including the traffic packet count for each device communicating over the communication network.

[0035] As a further option, the computer-implemented method according to the first aspect, further comprising auditing the traffic packet count for a device and the CDRs associated with the device for determining whether one or more synchronisation issues exist between the device, the first platform and/or the second platform. [0036] Optionally, the computer-implemented method according to the first aspect, the method further comprising detecting whether a device of the plurality of devices is communicating over a communication network of a network operator according to the device configuration data of the device, by: analysing the CDRs of the device to determine when the device initiates and terminates a communication session; tracking the number of communication sessions for the device; timing the disconnection period between communication sessions for the device; detecting a connection failure for the device when the disconnection period is greater than a predetermined time period indicating a possible connection failure of the device; determining whether there is a synchronisation issue between the device, the first platform and/or the second platform in relation to the device; and triggering one or more device update actions for resolving any synchronisation issues associated with the device, the first platform and/or the second platform in relation to the device.

[0037] Optionally, the computer-implemented method according to the first aspect, wherein a set of synchronisation rules for determining one or more synchronisation issues between the first platform, the second platform and the device, and determining the correlation between the first device state information, second device state information and the indication of device status of the device further comprising: applying the set of synchronisation rules to data representative of the first, second and/or third indications of status of the device for determining said one or more synchronisation issues; and triggering, based on the result of one or more synchronisation rules, one or more device status update actions for resolving the synchronisation issues between the device, the first platform and/or the second platform.

[0038] As an option, the computer-implemented method according to the first aspect, wherein a set of synchronisation rules for determining one or more synchronisation issues further comprises one or more rules from the group of: one or more rule(s) for determining whether the first platform and the device are unsynchronised; one or more rule(s) for determining whether the first platform and second platform are unsynchronised; one or more rule(s) for determining whether the second platform and the device are unsynchronised; and one or more rule(s) for determining whether the first platform, the second platform and the device are unsynchronised; the computer-implemented method further comprising: applying the set of synchronisation rules to data representative of the indication of the status of the device, first device state information, and second device state information; and triggering, based on the result of applying one or more of the synchronisation rules, one or more device status update actions for resolving the one or more synchronisation issues between the device, the first platform and/or the second platform.

[0039] Optionally, the computer-implemented method according to the first aspect, wherein each device comprises a SIM component and said each device is remotely controlled and configured with device configuration data comprising data representative of SIM profile data, wherein the first platform is configured to generate the SIM profile data for the device and distribute the SIM profile data to the second platform, and the second platform is configured to remotely control the SIM profile data of the device to the SIM component of the device, the method further comprising: analysing message traffic associated with the device communicating over a communication network to derive device status data representative of the SIM profile data of the device; determining whether the device status data correlates to first SIM profile data of the device stored by the first platform; retrieving second SIM profile data of the device stored by the second platform using a GetEIS operation associated with the device; determining whether the device status data correlates to the second SIM profile data of the device stored by the second platform; updating the first SIM profile data with the second SIM profile data when the device status data correlates with the second SIM profile data and the device status data is decorrelated with the first SIM profile data; and performing an Audit operation when the second SIM profile data is decorrelated with the device status data.

[0040] As an option, the computer-implemented method according to the first aspect, wherein each device comprises a SIM component and said each device is remotely controlled and configured with device configuration data comprising data representative of SIM profile data, wherein the first platform is configured to generate the SIM profile data for the device and distribute the SIM profile data to the second platform, and the second platform is configured to remotely control the SIM profile data of the device to the SIM component of the device, the method further comprising: analysing message traffic associated with the device communicating over a communication network to derive device status data representative of the SIM profile data of the device; retrieving first and second SIM profile data of the device stored by the first and second platforms; in response to: determining device status data correlates to the first SIM profile data and device status data is decorrelated with the second SIM profile data, or determining device status data is decorrelated to the first and second SIM profile data, performing the steps of: updating the first SIM profile data of first platform with the second SIM profile data and updating the device with second SIM profile data when the second SIM profile data is the most up-to-date data associated with the device, otherwise generating new SIM profile data for the device and updating the first platform, the second platform and the device with the new SIM profile data; in response to determining device status data is decorrelated to the first SIM profile data and device status data correlates with the second SIM profile data: updating the first SIM profile data of first platform with the second SIM profile data when the second SIM profile data is the most up-to-date data associated with the device, otherwise generating new SIM profile data for the device and updating the first platform, the second platform and the device with the new SIM profile data.

[0041] As another option, the computer-implemented method according to the first aspect, wherein each device comprises a SIM component and said each device is remotely controlled with device configuration data comprising data representative of SIM profile data, wherein the first platform is configured to generate the SIM profile data for the device, store first device state information based on the SIM profile data for the device, and distribute the SIM profile data to the second platform, and the second platform is configured to remotely control the SIM profile data of the device to the SIM component of the device and store second device state information based on said SIM profile data, the method further comprising: determining, based on at least device traffic of a device communicating over the communication network, whether the SIM profile data of the device used for communicating over the communication network is decorrelated with data representative of the first device state information of the device maintained by the first platform; triggering a device update action using an EIS operation for retrieving the second device state information of the device maintained by the second platform; determining whether the SIM profile data of the device used for communicating over the communication network is decorrelated with data representative of the second device state information of the device maintained by the second platform; triggering a device update action for updating the first device state information of the device maintained by the first platform with the retrieved second device state information when the SIM profile data of the device used for communicating over the communication network is correlated with data representative of the second device state information of the device maintained by the second platform; triggering a device update action using an Audit operation for updating the device state information and/or the device configuration data of the device in relation to the device, the first platform and/or the second platform when the second device state information of the device maintained by the second platform is decorrelated with the SIM profile data of the device.

[0042] Optionally, the computer-implemented method according to the first aspect, further comprising: detecting a device of the plurality of devices has transited to another communication network; and determining whether the SIM profile data of the device is suitable for the device communicating over the other communication network; and triggering a device update action using an Audit operation for updating the device state information and/or the device configuration data with new SIM profile data associated with the other communication network in relation to the device, the first platform and/or the second platform when the SIM profile data of the device is unsuitable for communicating over the other communication network.

[0043] In a second aspect, the present disclosure provides an apparatus for synchronising device state information between a first platform, a second platform and a plurality of devices remotely controlled for communication by the first and second platforms, the apparatus comprising: a traffic analytics component configured for receiving traffic data associated with the device communicating over a communication network and generating an indication of the status of a device of the plurality of devices based on the received traffic data associated with the device; an automation rules engine configured for determining whether first device state information of the device stored by the first platform and second device state information of the device stored by the second platform are correlated with the generated status indication of the device; and a synchronisation component configured for triggering one or more device state update actions for at least one of the corresponding first platform, the second platform and the device when at least one of the first and second device state information is uncorrelated with the received status indication of the device.

[0044] As an option, the apparatus according to the second aspect, wherein the apparatus is configured to implement the computer-implemented method according to any of the features and/or steps of the first aspect, modifications thereto, combinations thereof, as herein described and/or as the application demands. [0045] In a third aspect, the present disclosure provides an apparatus comprising a processor, a memory and a communication interface, the processor connected to the memory and communication interface, wherein the apparatus is adapted or configured to implement the computer-implemented method according to any of the features and/or steps of the first aspect, and/or the features and/or steps of the second aspect, modifications thereto, combinations thereof, as herein described and/or as the application demands.

[0046] In a fourth aspect, the present disclosure provides a first platform comprising: a device configuration component for receiving or generating device configuration data in relation to remotely controlling one or more devices for communication over a communication network of a network operator; one or more databases configured for storing and maintaining device state information associated with the device configuration data of each device; a transaction component configured for distributing said device configuration data of each device by a second platform, the second platform configured for remotely controlling the device based on said corresponding device configuration data; and a device synchronisation apparatus according to any of the features and/or steps of the second and/or third aspects, modifications thereto, combinations thereof, as disclosed herein, and/or as the application demands.

[0047] In a fifth aspect, the present disclosure provides a system comprising: a first platform configured for generating and distributing device configuration data in relation to remotely control one or more devices for communication over a communication network of a network operator; a second platform configured for receiving the distributed device configuration data for remotely controlling the one or more devices; and a device synchronisation apparatus according to any of the features and/or steps of the second and/or third aspects, modifications thereto, combinations thereof, as disclosed herein, and/or as the application demands.

[0048] Optionally, the computer-implemented method of the first aspect, the apparatus of the second or third aspects, the first platform of the fourth aspect, and/or the system of the fifth aspect, including wherein: the first platform comprises an Internet of Things platform configured to: generate device configuration data for each device of a plurality of devices, the device configuration data including data representative of SIM profile data for distributing to the second platform; store and maintain the first device state information for each associated with the device configuration data generated for each device; distribute the device configuration data for each device to the second platform for remote controlling of said each device for communication; the second platform comprises an Subscription Manager Secure Routing, SM-SR, and Subscription Manager Data Preparation, SM-DP, entities or components configured to: remotely control one or more devices of the plurality of devices based on said corresponding distributed device configuration data for each device; store and maintain second device state information for each device associated with the remotely controlled device configuration data for each device. [0049] In a sixth aspect, the present disclosure provides a computer-readable medium comprising computer readable code or instructions stored thereon, which when executed on a processor, causes the processor to implement the computer-implemented method according to any of the features and/or steps of the first aspect, modifications thereto, combinations thereof, as herein described and/or as the application demands.

[0050] The methods described herein may be performed by software in machine readable form on a tangible storage medium e.g. in the form of a computer program comprising computer program code means adapted to perform all the steps of any of the methods described herein when the program is run on a computer and where the computer program may be embodied on a computer readable medium. Examples of tangible (or non-transitory) storage media include disks, thumb drives, memory cards etc. and do not include propagated signals. The software can be suitable for execution on a parallel processor or a serial processor such that the method steps may be carried out in any suitable order, or simultaneously.

[0051] This application acknowledges that firmware and software can be valuable, separately tradable commodities. It is intended to encompass software, which runs on or controls “dumb” or standard hardware, to carry out the desired functions. It is also intended to encompass software which “describes” or defines the configuration of hardware, such as, without limitation, for example HDL (hardware description language) software and the like, as is used for designing silicon chips, or software which "describes" or defines the configuration of a system/hardware, such as, without limitation, for example system-level modelling language such as SystemC and the like, or for configuring universal programmable chips, to carry out desired functions.

[0052] The preferred features may be combined as appropriate, as would be apparent to a skilled person, and may be combined with any of the aspects of the invention.

[0053] Embodiments of the present disclosure are described below by way of example only. These examples represent the best mode of putting the invention into practice that are currently known to the Applicant although they are not the only ways in which this could be achieved. The description sets forth the functions of the example and the sequence of steps for constructing and operating the example. However, the same or equivalent functions and sequences may be accomplished by different examples.

[0054] The inventors propose a device synchronisation mechanism or apparatus for detecting whether one or more remote platforms(s), system(s) and/or components thereof and one or more devices of a plurality of devices, which have been remotely controlled and/or configured with device configuration data by said remote platforms for configuring one or more operations of software/hardware of the device (e.g. operations related to communication over one or more communication networks), have come out of synchronisation with one another based on device traffic of each device communicating over one or more communication networks. The device synchronisation mechanism or apparatus is configured to detect and to rapidly update the required device configuration data (e.g. SIM/iSIM/eSIM profiles and the like) of the remote platform(s) and/or components thereof and/or said affected devices. The invention enables such systems to rapidly detect those devices that have been remotely controlled and/or configured but may, without limitation, for example have inconsistencies in their device configuration data compared with the original device configuration data that was intended for said devices. For example, these devices may have been incorrectly provisioned, configured, have corrupted and/or out-of-date device configuration data and the like. This detection may be achieved, without limitation, for example by comparing an indication of the device status derived from device traffic of each device communicating over one or more communication network(s) with device state information maintained by the remote platform(s), system(s) and/or component(s) thereof and for identifying whether it is the remote platform(s) system(s) and/or component(s) thereof requiring updating and/or whether it is the affected devices that require updating and/or reconfiguration with the associated device configuration data from the remote platform(s), system(s) and/or components thereof.

[0055] A device may comprise or represent any device capable of communicating over a communications network of a network operator. Examples of devices that may be used in certain examples of the described apparatus, processes, methods and systems may be wired or wireless devices such as device with a SIM component/card, mobile devices, Internet of Things (loT) devices, mobile phones, terminals, smart phones, portable computing devices such as laptops, handheld devices, tablets, tablet computers, netbooks, phablets, personal digital assistants, music players, any device with a SIM component/card, and any other computing devices capable of wired or wireless communications over a communication network of a network operator.

[0056] Examples of communications network that may be used in certain examples of the described apparatus, process(es), methods and systems may be at least one communication network or combination thereof including, but not limited to, one or more wired and/or wireless communication network(s), one or more telecommunication network(s), one or more core network(s), one or more radio access network(s), one or more computer networks, one or more data communication networks), the Internet, the telephone network, wireless networks) such as the WiMAX, WLAN(s) based on, by way of example only, the IEEE 802.11 standards and/or Wi-Fi networks, or Internet Protocol (IP) networks, packet-switched networks or enhanced packet switched networks, IP Multimedia Subsystem (IMS) networks, or communications networks based on wireless, cellular or satellite technologies such as mobile networks, Global System for Mobile Communications (GSM), GPRS networks, Wideband Code Division Multiple Access (W-CDMA), CDMA2000 or Long Term Evolution (LTE)/LTE Advanced networks or any 2 ^nd , 3 ^rd , 4 ^th , 5 ^th or 6 ^th Generation and beyond type communication network and the like.

[0057] The synchronisation apparatus and remote platform(s) are configured to remotely monitor devices throughout the lifetime of the devices, such that the devices may be remotely controlled, remotely configured/re-configured one or more times or multiple times throughout the lifetime of the devices and/or the remote platform(s) and the like, or as the application demands. Remotely controlling a device may include, without limitation, for example remotely controlling the sending of device configuration data or other data for configuring or reconfiguring the device to operate or communicate according to the device configuration data and/or other data. Thus the device is remotely controlled with device configuration data distributed and/or stored by the remote platform and the like. The device configuration data which may include data representative of device configuration data or device communication configuration data (e.g. eSIM, ISIM, profiles and the like) for use by the device in communicating over a specified one or more communication networks and the like. Remote controlling and/or configuration of a device includes remote provisioning and/or provisioning of a device with device configuration data for use by the device in communicating over the appropriate communication networks specified by the device configuration data. The terms "provisioning" or "remote provisioning" may be used herein as meaning that devices may be provided, configured and/or reconfigured with device configuration data and the like one or more times during the lifetime of a device. Although provisioning or remote provisioning a device may be performed the first time a device connects to a communication network, it is to be appreciated by the skilled person that provisioning and/or remote provisioning a device may be performed multiple times throughout the lifetime of the device and/or as the application demands.

[0058] Figure 1a is a schematic diagram illustrating an example remote system 100 with a device synchronisation apparatus 110 according to the invention. The remote system 100 includes a first platform 102 in communication with a second platform 104 that are configured for remotely controlling and/or configuring (e.g. provisioning) a plurality of devices 106a-106n for operating in accordance with device configuration data. For example, remotely controlling and/or configuring a plurality of devices 106a-106n for communication over one or more communication network(s) 108 of one or more network/telecommunication/mobile operators and the like, hereinafter referred to as Mobile Network Operator(s) (MNO(s)). The device synchronisation apparatus 110 is configured for automatically determining whether one or more of the devices of the plurality of devices 106a-106n that have been remotely controlled and/or configured with device configuration data are operating as expected using an indication of device status of each device 106a based on device traffic of each device 106a of the plurality of devices 106a-106n. The indication of device status for each device 106a used by the device synchronisation apparatus 110 to determine whether it correlates or is in line with the device state information of the device 106a maintained in databases 103a and 105a of the first and/or second platforms 102 and 104. The device state information being based on the device configuration information used for remotely controlling and/or configuring (or provisioning) each device 106a and whether this was successfully performed or not. If the indication of the device status of a device 106a does not correlate or is not in line with the device state information of the first platform 102 and/or the second platform 104, then the device synchronisation apparatus 110 triggers a device state update action for at least one of the corresponding first platform 102, second platform, and/or the device 106a and the like for ensuring the device state and/or device configuration data of the device 106a is synchronised across the first and second platforms 102 and 104 and the device 106a, which may include remotely controlling and/or configuring/re-configuring (e.g. remotely provisioning) the device 106a with currently stored and/or new device configuration data and the like.

[0059] The first platform 102 is configured to generate and provide the second platform 104 with device configuration data comprising or representative of device, subscription and/or operator profile data (e.g. data representative of SIM/iSIM or eSIM profiles) for enabling each device 106a of a plurality of devices 106a-106n to communicate over one or more communication networks) 108 of one or more corresponding MNOs. The second platform 104 is configured to receive the device configuration data for each device of the plurality of devices 106a-106n from the first platform 102 and proceed to download and install the corresponding device configuration data on each of the plurality of devices 106a-106n. When remote controlling and/or configuring (e.g. provisioning) a device 106a of the plurality of devices 106a-106n, the second platform 102 downloads the required device configuration data to the device 106a, and on receipt of the device configuration data, the device 106a configures the corresponding hardware/software components of the device 106a based on the device configuration data or loads the device configuration data provided by the second platform 102. The device 106a may then notify the second platform 102 whether said remote controlling and/or configuring (e.g. provisioning) was successful or not. The second platform 102 maintains one or more database(s) 105a for recording and/or storing device state information for each of the plurality of devices 106a-106n, the device state information for a device 106a including data representative of, without limitation, for example the device configuration data downloaded and confirmed to be controlled and/or configured (e.g. provisioned), successfully controlled and/or configured (e.g. provisioned), or unsuccessfully controlled and/or configured (e.g. provisioned) on each device 106a and/or the status of the device 106a and the like. The first platform 102 also maintains one or more database(s) 103a for recording and/or storing data representative of, without limitation, for example data representative of the device configuration data generated for each device 106a, the device state information remotely controlled and/or configured on each device 106a and/or generated and confirmed, by the second platform 102, to be remotely controlled and/or configured on each device 106a and/or the status of the plurality of devices 106a-106n and the like.

[0060] The first platform 102 further includes and/or uses the device synchronisation apparatus 110 according to the invention, which is configured to maintain synchronisation between the at least the database(s) 103a and 105a of the first and second platforms 102 and 104, respectively, and/or the device state of each of the plurality of devices 106a-106n in relation to device status information of each of the plurality of devices 106a-106n. The device status information may be derived from device traffic 114 passing through one or more access points (APs) 112a-112k of said communication network(s) 108 after each device has been targeted for remote controlling/configuring (e.g. remote provisioning) or has been remotely controlled/configured with device configuration data. For example, provisioned for communications over the communication network(s) 108 of the one or more MNO(s). This enables timely and pro-active detection of synchronisation errors in the database(s) 103a and 105a between the first platform 102 (e.g. Mobile Virtual Network Operator (MN O)/lnternet of Things (loT) platforms) and the second platform 104 (e.g. GSMA remote provisioning platforms that include Subscription Manager Data Preparation (SM-DP) and/or Subscription Manager Secure Routing (SM- SR) entities or components), and/or between the first and second platforms 102 and 104 and the device, enabling rapid detection of device status errors and/or automatic alerting or triggering of corrective actions such as updates of device configuration data onto the device and/or device status updates and the like (e.g. Get eUlCC Information Set (GetEIS)/EIS actions and/or GetAudit/Audit actions and the like).

[0061 ] For example, the first and second platforms 102 and 104 are used to remotely control and/or configure the plurality of devices 106a-106n for communications over the appropriate communication network(s) 108 of MNOs and the like. For example, the device configuration data for each device of a group of devices 106a-106m may be generated, configured and/or stored by the first platform 102 and then remotely controlled/configured by the second platform 102 to a group of devices 106a-106m on behalf of a third party service provider (not shown) to enable and/or authorise the group of devices 106a-106m to communicate over a communication network of a MNO. This may allow the third party service provider to provide, without limitation, for example Internet of Things services/solutions and the like, where the group of devices 106a-106m are configured as Internet of Things devices 106a- 106m and authorised, based on the device configuration data, to send/transmit the requisite data over the communication network of the corresponding MNO in relation to the third party provider services/solutions and the like. This enables the MNO to appropriately provide the required communication resources and services in relation to the group of devices 106a-106m of the third party provider.

[0062] Each device 106a of the group of devices 106a-106m receives device configuration data (e.g. device, subscription and/or operator profile data) under control of the second platform 102 that is used by said device to configure how the device 106a operates. For example, the device configuration data for a device 106a may be for controlling and configuring the communication operations of the device 106a to authorise/enable the device 106a to, without limitation, communicate over an appropriate one or more communication network(s). When device configuration data is downloaded to each device 106a of the group of devices 106a-106m under control of the second platform 102, each device 106a uses the received device configuration data to configure itself according to the downloaded device configuration data, in which that device 106a then operates in accordance with the downloaded device configuration data. The device 106a communicates the success and/or failure of the download and/or configuration using the device configuration data to the second platform 104, which updates its database(s) 105a accordingly. The second platform 104 may relay the success and/or failure of each device in downloading and/or configuration using the device configuration data to the first platform 102, which updates its database(s) 103a accordingly. When the device configuration data is for authorising and/or enabling the device to operate by communicating over a specified communication network, e.g. a communications network 108 of an MNO, then when successfully configured with their corresponding device configuration data, each of the devices 106a- 106m are authorised and/or enabled to operate and communicate over the communications network(s) 108 of the MNO. These devices may be used, without limitation, for example as a group of Internet of Things devices 106a-106m for communicating over the specific communication network 108 of the MNO with a third party service provider (not shown), which provides Internet of Things services/solutions and the like.

[0063] The device synchronisation apparatus 110 of the first platform 102 is configured to receive an indication of the status of a device 106a of the plurality of devices 106a-106n that has been remotely controlled and/or configured based on traffic associated with the device communicating over a communication network. The indication of the status of the device 106a is derived from device traffic 114 associated with the device 106a that is filtered/intercepted and/or inspected as it passes through one or more APs 112a-112k of said communication network(s) 108. The device traffic 114 of the device 106a may be analysed to determine the status of the device 106a in which an indication of the status of the device 106a is derived, which may be used to determine the operating state of the device 106a in relation to the recorded device state information in databases 103a of the first platform 102 and/or databases 105a of the second platform 104.

[0064] The device synchronisation apparatus 110 may be configured to receive a status indication for each of those devices of the plurality of devices 106a-106n that has been remotely controlled and/or configured for communication and that are currently communicating over the corresponding communication network(s) 108 generating communication traffic. Traffic monitoring apparatus may be configured to analyse the device traffic 114 to determine device status information for each device. The device traffic or traffic packets 114 associated with each of these devices 106a-106n is filtered/intercepted and/or inspected (e.g. packet filtering and/or Deep Packet Inspection and the like) by the one or more APs 112a-112k in which data from the packet header and/or payload and the like may be extracted, filtered and analysed to derive data representative of an indication of status for each of the devices 106a-106n that are communicating over the communication network(s) 108. The indication of status of each of the devices 106a-106n may include, by way of example only, data representative of the device configuration data remotely controlled and/or configured on the device 106a that may be gleaned from the traffic associated with the device 106a (e.g. SIM/iSIM/eSIM profile in use, MNO the device is subscribed to, device identifiers and the like).

[0065] Alternatively or additionally, a traffic monitoring component (not shown) may be configured to receive or use the data representative of device traffic 114 of the one or more devices 106a-106n filtered/intercepted and/or inspected by the APs 112a-112k to determine an indication of the device status of each of the devices 106a-106n as they communicate, after they have been remotely controlled and/or configured for communications, over the communications network(s) 108 of the MNO(s). Alternatively or additionally to receiving the status indication, the device synchronisation apparatus 110 may include the traffic monitoring component that is configured to receive or use data representative of device traffic 114 of the one or more devices 106a-106n to determine device status of each of the devices 106a-106n as they communicate, after they have been remotely provisioned for communications, over the communications network(s) 108 of the MNO(s).

[0066] The device traffic 114 of the one or more devices 106a-106n may be intercepted/filtered and/or inspected by one or more APs 112a-112k in the communications network(s) 108 of the MNOs, which may extract and/or forward the relevant data representative of the device traffic 114 for each of the devices 106a-106n to the traffic monitoring component. The traffic monitoring component may process or analyse the extracted device traffic data corresponding to the device traffic 114 for each device 106a-106n to determine an indication of device status associated with each device 106a from the corresponding filtered/intercepted and/or inspected device traffic 114. The traffic monitoring component may be configured to determine, based on the received traffic data representative of the traffic 114 of each device 106a-106n, the indication of the device status each of the devices 106a- 106n. The traffic monitoring component may be configured to send the device status indication of each device 106a-106n to the device synchronisation apparatus 110 for determining whether each device 106a-106n is operating and communicating as expected in relation to the state of the database(s) 103a of the first platform 102 and/or the database(s) 105a of the second platform 104.

[0067] The indication of the device status for each device 106a-106n is used by the device synchronisation apparatus 110 for use in determining whether the device status correlates with the device state information maintained for the device 106a by the first and/or second platform(s). Decorrelation of the device state information of the first and/or second platform(s) and/or the detected device status indication may occur due to, without limitation, for example: a) the database(s) 103a of the first platform 102 are out of synchronisation with the database(s) 105a of the second platform 104 in relation to recording device state information during remote controlling and/or configuring (e.g. remote provisioning) of the devices 106a-106n; b) the device 106a may have completed remote controlling and/or configuring (e.g. remote provisioning), but failed or could not (e.g. communications outage) report the successful control/configuration (e.g. provisioning) to the second platform 104 and/or first platform 102; c) the first and second platforms 102 and 104 record the device state information for the device 106a as being successful, but the installation of the device configuration information on the device 106 may have become corrupted during operation for some reason and the like, thus the device 106a does not behave as expected - e.g. no communication traffic from the device 106a; d) the response reporting successful provisioning/configuration/update from the device 106a occurred later than expected; e) the response reporting successful configuration update/provisioning was never delivered, (e.g. response message is lost); f) the device 106a may have moved location (e.g. shipping and/or in transit) between regions and/or communication network(s) and is using device configuration data that requires an update for it to operate with a communication network of another MNO in that region; and/or g) any other indication of the status of the device 106a that requires an update of the device configuration data for the device 106a for it to be able to operate accordingly and/or as requested or required by the third party service provider using the device 106a to provide one or more services and the like. [0068] It is problematic for an MNO and/or third party providers having one or more device(s) 106a operating over a communication network 108 of the MNO using incorrect, corrupt or unauthorised device configuration data because the MNO may be inadvertently providing communication resources to these device(s), which should not be communicating over the MNO's communication network, and/or the third party provider is unaware of having such devices operating, or not as the case may be, which may also inadvertently increase computational and/or operational cost of their service, which relies on the reliable deployment of such devices. Problematic device(s) may not be detected by the MNO for a relatively long time period, which is a major issue for large loT deployments that include thousands or millions of devices. Even if a small fraction of these devices have problematic provisioning there will be a measurable impact on the performance of the MNO's operation and/or communication network and the like, and/or the communication performance and/or cost of operating the devices by the third party provider using such devices over the communication network(s) 108 of one or more MNO(s). Thus, the device synchronisation apparatus 110 of the first platform 102 rapidly detects anomalous device(s) and/or device behaviour(s) and automatically operates to mitigate and minimise the anomalous device status based on device traffic of each device over communications network(s) 108 as quickly as possible based on using the received indication of status for each device 106a. The device synchronisation apparatus 110 is configured to determine whether the first device state information of the device 106a stored by the first platform 102 and second device state information of the device 106a stored by the second platform during remote controlling and/or configuring (e.g. remote provisioning) of the device 106a correlate with or are in line with the received status indication of the device 106a. That is, whether the device 106a is operating in line with the device configuration data that was remotely controlled and/or configured (e.g. remotely provisioned) onto the device 106a by the second platform 104 and/or whether the device state information maintained by the first and second platforms 102 and 104 in relation to the device configuration data that was controlled/configured are in synchronisation with each other and also with the device 106a. If the first device state information, the second device state information, and the received status indication of the device 106a differ, do not correlate, or are not in line with each other and/or the device configuration data assumed to be controlled/configured (e.g. provisioned) on the device 106a, then the device synchronisation apparatus 110 triggers a device state update for the device 106a in relation to at least one of the corresponding first and second platforms 102 and 104 and/or the device 106a.

[0069] Figure 1 b is a flow diagram illustrating an example device state synchronisation process 120 for use with device synchronisation apparatus 110 of system 100 as described with reference to figure 1a. The device synchronisation apparatus 110 is configured to synchronise device state information between the first platform 102, the second platform 104 and each of the plurality of devices 106a- 106n that have been remotely controlled and/or configured/reconfigured by the first and second platforms 102 and 104 for operation based on device configuration data associated with each of the devices 106a-106n. For example, the device configuration data for a device 106a may be associated with enabling the device 106a communication over communication network(s) 108 of one or more MNOs. The device state synchronisation process 120 may include the following steps of:

[0070] In step 122, receiving an indication of the status of a device 106a of the plurality of devices 106a-106n based on traffic associated with the device 106a communicating over a communication network. In step 124, determining whether first device state information of the device 106a stored by the first platform and second device state information of the device 106a stored by the second platform are in line with the received status indication of the device 106a. In step 126, triggering a device state update for at least one of the corresponding first and second platforms 102 and 104 when at least one of the first and second device state information differs to the received status indication of the device 106a. This process may be performed multiple times for each device of the plurality of devices 106a-106n and/or for a particular group of devices 106a-106m of the plurality of devices 106a-106n in a periodic schedule or fashion, aperiodic schedule or fashion, and/or when instructed by an operator or user of the first platform 102 and the like to ensure each of the devices are operating with the correct device configuration data. In an example, when the first device state information, the second device state information and the device status indication of a device are decorrelated or differ, then the device state update may include updating the device configuration data of the first platform, the second platform and the device.

[0071] Figure 1c is a flow diagram illustrating an example device traffic monitoring process 130 for use with device synchronisation apparatus 110 of system 100 as described with reference to figures 1a and 1 b. The device synchronisation apparatus 110 is configured to receive an indication of the status of each device 106a of a plurality of devices 106a-106n in order to determine whether there is a need to synchronise device state information for each device 106a between the first platform 102, the second platform 104 and one or more of the plurality of devices 106a-106n, which have been remotely controlled and/or configured/reconfigured (e.g. provisioned) by the first and second platforms 102 and 104 with device configuration data for operating said devices. For example, the device configuration data for each device may control/configure the device for communication over communication network(s) 108 of one or more MNOs. The device traffic monitoring process 130 may include, for each device 106a of the plurality of devices 106a-106n, the following steps of:

[0072] In step 132, receiving device traffic and/or device traffic data associated with a device 106a of the plurality of devices 106a-106n. The device 106a may be communicating over a communication network 108 of an MNO in which an APN 112a of the communication network 108 inspects device traffic of the device 106a and extracts device traffic data from the device traffic for sending to step 132 of the device traffic monitoring process 130. Alternatively or additionally, device traffic monitoring process 130 may further include a step for receiving device traffic of device 106a, inspecting the device traffic of the device 106a, and extracting device traffic data from the device traffic of device 106a for sending to step 132 of the device traffic monitoring process 130. The device traffic data may comprise or represent data associated with header fields of packets of the device traffic and the like. [0073] In step 134, extracting device data from the received device traffic data, the device data associated with the device configuration data used to control/configure (e.g. provision) the device 106a, device state information of the device 106a, and/or any other device data capable of being used for determining an indication of the status of the device 106a from the device traffic of the device 106a. The device data that may be extracted from the received device traffic data may comprise or represent data based on at least the device identity of the device 106a and/or the MNO identity of the communication network 108 of the MNO that the device traffic of device 106a originates from and/or is detected in using and the like. The extracted device data may be configured and/or compiled as an indication of the status of the device 106a. The indication of status of the device 106a is used by the device state synchronisation process 120, in step 124, for determining whether first device state information of the device 106a stored by the first platform and second device state information of the device 106a stored by the second platform during provisioning of the device 106a are in line with the received status indication of the device 106a.

[0074] In step 136, determining an indication of the status of the device 106a from the extracted device data. The indication of status of the device 106a comprising or representative of data associated with an estimated status of the device 106a based on the extracted device traffic. The indication of status of the device 106a may include bundling and/or compiling selected portions of the extracted device data such as, without limitation, for example the device identity of the device 106a and/or the MNO identity of the communication network 108 being used by the device 106a for communications and the like. The indication of device status is used by the device state synchronisation process 120, in step 124, for determining whether first device state information of the device 106a stored by the first platform and second device state information of the device 106a stored by the second platform during remote controlling/configuring (e.g. provisioning) of the device 106a are in line with the received status indication of the device 106a. In step 138, sending the device status indication of the device 106a to the device state synchronisation process 120.

[0075] The device traffic monitoring process 130 may be implemented for each of the plurality of devices 106a-106n, thus, when a device 106a of the plurality of devices 106a-106n authenticates and/or connects to a communications network 108 of one or more MNOs, the device traffic monitoring process 130 may be performed to monitor the traffic generated of each device 106a for determining an indication of the status of the device 106a based on the device traffic for that device. The determined indication of status of the device 106a is sent to device state synchronisation process 120 for determining whether the indication of the status of the device 106a is as expected based on the device state information of the device 106a maintained by the first and/or second platforms 102 and/or 104. The indication of status of the device 106a may be generated by the device traffic monitoring process 130 for each device 106a of the plurality of devices 106a-106n and/or for a particular group of devices 106a-106m of the plurality of devices 106a-106n based on a periodic schedule, aperiodic schedule, and/or when instructed by an operator or user of the first platform 102 and the like to ensure each of the devices 106a-106n are operating as expected and with the correct device configuration data that has been assumed to have been remotely controlled and/or configured/reconfigured by the system 100 to each device 106a of the plurality of devices 106a-106n and the like.

[0076] The device traffic monitoring process 130 may be implemented as a traffic monitoring component within the device synchronisation apparatus 110 and/or as a traffic monitoring apparatus (not shown) separate to the device synchronisation apparatus 110. In any event, the traffic monitoring component monitors the device traffic of the plurality of devices 106a-106n and sends an indication of device status or a device status indication to the device state synchronisation process 120 of the device synchronisation apparatus 110 for use in determining whether there is a need to synchronise device state information for each device 106a between the first platform 102, the second platform 104 and the device 106a based on the indication of device status, the device state information associated with the device configuration data used for remotely controlling and/or configuring/reconfiguring (e.g. provisioning) the device 106a to operate accordingly. For example, the device configuration data may be used for remotely controlling and/or configuring/reconfiguring the device 106a for communication over communication network(s) 108 of one or more MNOs.

[0077] Further modifications and/or features of the device synchronisation apparatus 110, traffic monitoring apparatus, the first platform 102, the second platform 104 and/or system 100 are described herein in more detail with reference to figures 2a to 4b. For simplicity, reference numerals for the same or similar components, apparatus and/or system(s) as used in figures 1 a to 1 d are reused in relation to figures 2a to 4b.

[0078] Figure 2a is a schematic diagram of another example remote provisioning system 200 according to the invention. The remote provisioning system 200 includes system 100, device synchronisation apparatus 110, device state synchronisation process 120, and/or device traffic monitoring process 130 as described with reference to figures 1 a to 1 c are further combined and/or modified for use in remote SIM provisioning based on the GSMA standard. In this example, the remote provisioning system 200 is based on the GSMA standard for providing remote SIM provisioning to the one or more devices 106a-106n via the first and second platforms 102 and 104. The remote provisioning system 200 includes the first platform 102 in communication with the second platform 104 that are configured for enabling remote SIM provisioning of each of the plurality of devices 106a, 106b to 106n. Each of the plurality of devices 106a-106n includes a corresponding SIM component 210a-210n. The SIM component 210a for device 106a may be configured based on device configuration data (e.g. data representative of SIM/eSIM/iSIM profile(s) and the like) associated with device 106a for enabling device 106a to be authenticated on and communicate over a communication network 108 of an MNO in relation to the device configuration data. However, the device configuration data provisioned to a device 106a and the device state information associated with the device configuration data stored by the first and second platforms 102 and 104 may become unsynchronised for various reasons as described with reference to figures 1a-1 c. Thus, the first platform 102 includes a device synchronisation apparatus 110 configured for ensuring, based on device traffic, that device state information associated with each of the devices 106a-106n is synchronised between the first platform 102, the second platform 104 and each corresponding remote provisioned plurality of devices 106a-106n. The device synchronisation apparatus 110 is configured to pro-actively detect synchronisation errors or issues between the first platform 102, the second platform 104 (and/or other third-party platforms and/or systems), which include SM-SR component(s) 208a and SM-DP component(s) 208b, and/or devices 106a-106n. On detecting synchronisation errors or issues associated with one or more of the devices 106a-106n, the device synchronisation apparatus 110 may trigger automatic alerting and/or corrective actions to mitigate and/or correct the synchronisation errors or issues.

[0079] In this example, each of the SIM components 210a, 210b to 21 On of the devices 106a, 106b to 106n may store device configuration data such as, without limitation, for example network-specific information, often referred to as a SIM profile or operator profile, used by each of the corresponding devices 106a-106n to authenticate and identify subscribers of the devices 106a-106n on a communication network 108 of an MNO. The network-specific information for a device 106a may include, without limitation, for example, the integrated circuit card identifier (ICCID), International mobile subscriber identity (IMSI), Authentication Key (Ki), Local Area Identity (LAI) and Operator- Specific Emergency Number in relation to the device 106a and/or the one or more MNOs. A SIM component 210a of a device 106a may also store other device configuration data such as, without limitation, for example carrier-specific data such as the SMSC (Short Message service centre) number, Service Provider Name (SPN), Service Dialling Numbers (SDN), Advice-Of-Charge parameters and Value Added Service (VAS) applications. The network-specific information and/or carrier-specific data and the like may be used to form and/or create device configuration data such as, without limitation, for example, one or more SIM, eSIM and/or ISIM profiles associated with one or more MNOs and the like that, when downloaded and installed on the SIM component 210a of a device 106a, enable the device 106a to be authenticated and communicate over the communication network associated with one or more MNOs in relation to the device configuration data.

[0080] Given the scaling up of the number of loT devices and systems, the number of RSP system(s), third party RSP(s) and interoperability required between multiple mobile operators and RSP system(s), the device synchronisation apparatus 110 is configured to automatically, based on device traffic, detect and correct synchronisation errors or issues of device state information and/or device configuration data of the devices 106a-106n that may occur between loT systems, RSP systems, mobile operator(s) and the like. When a synchronisation error or issue occurs in relation to one or more devices 106a of the plurality of devices 106a-106n, this may involve updating the device status and/or device state information on the first and/or second platform(s) 102 and/or 104 and/or reconfiguring the affected devices of the plurality of devices 106a-106n. For example, based on the GSMA standard the device synchronisation apparatus 110 may be configured to issue actions and/or commands in relation to affected devices, without limitation, for example Audit and/or GetEIS type commands/functions may be issued for: checking the status of the device state information recorded by the second platform 104 and comparing with device state information recorded by the first platform 102 in relation to a device 106a; checking status of the device 106a; checking all device configuration data (e.g. data representative of SIM/iSIM/eSIM profiles etc.) provisioned on the device 106a (e.g. including SIM profiles on the device 106a); and enabling resyncing between third party RSPs such as, for example, between the second platform 104 and the first platform 102. The device synchronisation apparatus 110 overcomes the issues associated deployment of large scale loT solution(s) requiring a massive amount of SIM cards/components 210a-210n being used by a corresponding plurality of devices 106a-106n in the field by using the analysis of device traffic to check whether each device 106a-106n of one or more loT deployments are operating with the expected profiles, behaviours, and the like and are only using the communication network(s) 108 of MNOs that they have been authorised to use by the first and second platforms 102 and 104.

[0081 ] The device synchronisation apparatus or mechanism 110 is configured to receive an indication of the status of a device 106a of the plurality of devices 106a-106n based on device traffic or message traffic 114 associated with the device 106a communicating over a communication network 108 of an MNO. The device synchronisation mechanism 110 determines based on, without limitation, for example databases 103a and 105a of the first and second platforms 102 and 104 and/or data sources 214 whether first device state information of the device 106a stored by the first platform 102, second device state information of the device 106a stored by the second platform 104 during provisioning of device configuration data to the device 106a correlate or are in line with the received status indication of the device 106a. This ensures that the device configuration data that was remotely provisioned onto the SIM component 210a of device 106a is what both the first and second platforms 102 and 104 expect it to be when the device 106a authenticates and communicates over communication network 108 associated with an MNO. The device synchronisation apparatus 110 is configured to trigger a device state update and/or action for at least one of the corresponding first and second platforms 102 and 104 and/or the device 106a when at least one of the first and second device state information does not correlate to and/or differs to the received status indication of the device 106a.

[0082] In this example, the device synchronisation mechanism 110 may be further configured to receive a device status indication derived from message traffic 114 from a device 106a hosting a SIM component 210a that has been remotely provisioned with device configuration data. When the device 106a authenticates and begins communicating over a communication network 108 of an MNO according to the device configuration data that has been downloaded onto its SIM component 210a, any device traffic or message traffic received by the communication network 108 is reported to an APN 112a which is configured to act as a gateway between the mobile network 108 and the first platform 102. From there, the message traffic 114 of device 106a may be passed to a device traffic monitoring apparatus 212 for analysis and subsequent notification of device status indication to the device synchronisation mechanism 110. Although the device traffic monitoring apparatus 212 may be separate from the device synchronisation mechanism 110, it is to be appreciated by the skilled person that the device synchronisation mechanism 110 may include the functionality of the device traffic monitoring apparatus 212 and/or that the device traffic monitoring apparatus 212 may be a separate component of the first platform 102. In this example, the device synchronisation apparatus 110 includes device traffic monitoring apparatus 212 and a synchronisation/trigger action component 213. The device traffic monitoring apparatus 212 includes a traffic analytics engine 212a coupled to an automation rules engine 212b. The traffic analytics engine 212a may be configured for generating the device status indication of the device 106a. The automation rules engine 212b may be configured using a rule engine comprising a plurality of rules that may include a set of synchronisation rules for determining whether there are any synchronisation issues associated with the first platform 102, second platform 104 and/or the device 106a based on the device status indication of device 106a. For example, whether or not first device state information of the device 106a stored by the first platform 102, second device state information of the device 106a stored by the second platform 104 during provisioning of device configuration data to the device 106a correlate or are in line with the received status indication of the device 106a. Should one or more rules of the set of synchronisation rules be triggered, the automation rules engine 212b may send a notification to the synchronisation/trigger action component 213 for resolving the synchronisation error/issue that has been detected.

[0083] The remote provisioning operations of the first platform 102 and second platform 104 are now described. The first platform 102 includes an Internet of Things (loT) front-end platform (IOTX) 202 through which a user 201 may define a request for downloading and installing device configuration data (e.g. SIM, eSIM and/or ISIM profiles and the like) for one or more of the plurality of devices 106a- 106n. For example, the user 201 may define and specify device configuration data including networkspecific information and/or carrier-specific information for defining a profile A, which is to be downloaded onto the SIM component 210b of device 106b. The IOTX 202 is coupled to a eUlCC API component 204, which is configured to generate the appropriate API call based on the specified device configuration data including profile A and the SIM pairing (e.g. SR-DP pairing) associated with device 106b. The first platform 102 includes database(s) 103a that includes, without limitation, for example at least the eUlCC database including a configuration table database (Config DB) 203a, a profile database (Profile DB) 203b and a transaction database (Transaction DB) 203c.

[0084] For example, the Config DB 203a, Profile DB 203b, and/or Transaction DB 203c may store and maintain device status information including, without limitation, for example subscriber(s) associated with one or more devices 106a, integrated circuit card identifier (ICCID), International mobile subscriber identity (IMSI), EID, RSP the device 106a is configured with, transaction logs associated with the device 106a and the like. The Config DB 203a is further configured to maintain a mapping between the allowable SM-SR and SM-SP pairings in relation to each of the devices 106a- 106n and the like. The Transaction DB 203c is further configured to maintain a list of transactions for each of the devices 106a-106n to be instructed by the eUlCC API in response to user requests and the like. The Profile DB 203b is further configured to maintain and/or store updates regarding device state information and/or device configuration data changes (e.g. profile changes) in relation to each of the devices 106a-106n and the like. The database(s) 103a of the first platform 102 may further include other data sources 214 and/or access to other data sources 214. The one or more other data sources 214 may include, without limitation, for example subscriber databases; call data records (CDRs) associated with devices 106a-106n and the like; access point network (APN) data sources including radius traffic; and/or any other data source and the like as the application demands.

[0085] The eUlCC API component 204 may be coupled to an outgoing request handler 206a. In this example, the eUlCC API component 204 is coupled to the outgoing request handler 206a via the transaction database 203c, which receives the various transactions associated with user requests from IOTX 202 in relation to one or more of the devices 106a-106n and/or the plurality of devices 106a-106n. The outgoing request handler component 206a is configured to handle the issuance of outgoing transactions instructions to the second platform 104, which includes an SM-SR component 208a coupled with a SM-DP component 208b. This forms an SM-SR/SM-DP pairing that is associated with one or more devices. In this example, the SM-SR/SM-DP components 208a and 208b of the second platform 104 form a SM-SR/SM-DP pairing that is associated with the plurality of devices 106a-106n. The SM-SR component 208a and SM-DP component 208b of the second platform 104 are used for downloading the corresponding device configuration data associated with one or more of the plurality of devices 106a-106n. The SM-SR component 208a of the second platform 104 receives the outgoing transaction instructions, which may include the device configuration data of device 106b, which may include profile A of device 106b. This is transmitted by the SM-SR component 208a via communication interface 208c to device 106b. When device 106b receives the device configuration data of device 106b, the device 106b configures the SIM component 210b of device 106b based on the device configuration data (e.g. the profile A may be stored and/or installed on the SIM component 210b). Once installed/stored, the device 106b transmits an acknowledgement or confirmation message to the SM-SR component 208a to confirm that the transmitted/received device configuration data of device 106b has been successfully stored/received. The SM-SR component 208a may maintain a database (not shown) for recording device state information of each device 106b of the plurality of device 106a-106n, where for device 106b, the database stores the device configuration data of device 106b and/or confirmation of its storage/installation on device 106b in the database (not shown). The SM-SR component 208a notifies the SM-DP component 208b of the successful installation/storage of the device configuration data of device 106b on device 106b. The SM-DP component 208b sends a notification/message confirming that the transaction associated with remotely provisioning the device configuration data of device 106b successfully completed etc. to the incoming response handler component 206b of the first platform 102. The incoming handler 206b notifies the profile database 203b of the changes to device 106b, i.e. the successful download/installation of the device configuration data of device 106b that the transaction database 203c/outgoing request handler component 206a sent to the second platform 104. The profile database 203b stores and updates the device state information associated with device 106b with the profile changes associated with the device 106b successfully downloading/installing the device configuration data. Thus, both the databases 103a and 105a of the first and second platforms 102 and 104, respectively, have been updated based on the successful download and remote provisioning of device configuration data on device 106b. This is performed for each device in the plurality of devices 106a-106n, where there is a corresponding plurality of device configuration data for each device of the plurality of devices 106a-106n that is remotely provisioned via first and second platforms 102 and 104.

[0086] For example, the user 201 may use the IOTX 202 for performing a remote SIM provisioning procedure on device 106b of the plurality of devices 106a-106n. This may include the user 201 specifying, generating and/or requesting the download and/or installation of device configuration data including profile A onto the SIM component 210b of device 106b. The eUlCC API component 204 receives the request from the IOTX 202 for downloading profile A to the SIM component 210b of device 106b and generates the appropriate API call based on profile A and the SIM pairing associated with device 106b. In this example, it is assumed that the SM-SR/SM-DP pair associated with device 106b is the SM-SR and SM-DP components 208a and 208b of the second platform 104. The SIM pairing identifies the second platform 104 as having the SM-SR/SM-DP pairing associated with device 106b. The API call is logged as a transaction by the transaction database 203c for remote SIM provisioning profile A (e.g. downloading) onto device 106b using the SM-SR/SM-DP components 208a and 208b of the second platform 104. The outgoing request handler 206a sends the transaction request for provisioning profile A onto device 106b to the second platform 104. The SM-SR component 208a receives the request and downloads the device configuration data of profile A to device 106b for sto ring/install Ing on the SIM component 210b of device 106b. Device 106b may send a notification back to the SM-SR component 208a and/or SM-DP component 208b, which records device state information representing the successful provisioning of device 106b with profile A in their corresponding database(s) (not shown). The SM-DP 208b sends a confirmation response to the transaction request in relation to the successful provisioning of device 106b with profile A being completed to the incoming response handler 206b. The profile database 203b is updated with device state information representing the successful provisioning of device configuration data including profile A onto SIM component 210b of device 106b. This remote SIM provisioning procedure may be requested by the user for each device in the plurality of devices 106a-106n, where there is a corresponding plurality of device configuration data including various profiles and the like for downloading onto the SIM components 210a-210n of each of the plurality of devices 106a-106n via first and second platforms 102 and 104.

[0087] The above remote SIM provisioning procedure assumed ideal conditions in which the device 106b and/or other devices 106a-106n were successfully provisioned with corresponding device configuration data specified by user 201 and that the device configuration data maintained by the first and second platforms 102 and 104 and the devices 106a-106n are all synchronised and that no synchronisation errors or issues have occurred. However, a number of synchronisation events and/or issues may occur during remote SIM provisioning for one or more devices of the plurality of devices 106a-106n and/or during operation of one or more devices of the plurality of devices 106a-106n. For example, one or more SIM cards/components 210a-210n of a corresponding one or more devices 106a-106n can end up in a "broken" state. This may occur when a device 106b downloads a device configuration data including a profile that the first and second platforms 102 and 104 are not aware of. The device 106b may be accidentally configured to go into a bootstrap profile rather than an operational profile etc., which the first and second platforms 102 and 104 may be unaware of.

[0088] Due to the plethora of devices 106a-106n, using conventional tools and methods, it typically may take a while for the users of the first and second platforms 102 and 104 to determine synchronisation errors and/or issues have happened. Once determined, it is a slow and laborious process for the users to manually proceed to perform an audit to reconfigure the first and second platforms 102 and 104 and/or the affected device(s) 106b, resynchronise, and/or remove the offending profile(s) and download another one to the device(s) 106b. Quite often a number of events will need to be followed to eventually determine that one or more devices or a group of devices may each have a "broken" SIM component and/or profile and/or to determine a synchronisation profile issue between the first platform 102, the second platform 104, and/or the device 106b. These might be identified based on one or more of the following events of: 1) the end user or customer of devices 106a-106n realising one or more device(s) 106b of the plurality of devices 106a-106n have no connectivity or are unable to connect to an APN 112a of a communication network 108 they are authorised to access; 2) a user manually requesting a check of the first platform 102 (e.g. IOT management platform) to see what the status of one or more devices of the plurality of devices 106a- 106n are; 3) a user manually running a whole set of MNO troubleshooting tools such as, without limitation, for example disconnect/reconnect/refresh and the like before it is realised that there is a synchronisation error/issue with the remote SIM provisioned device configuration data (e.g. RSP SIM/ISIM/eSIM profiles and the like).

[0089] Thus, the device synchronisation apparatus 110 is configured to automatically detect and correct synchronisation issues using device traffic monitoring apparatus 212 and the synchronisation/trigger action component 213. The device traffic monitoring apparatus 212 includes the traffic analytics engine 212a coupled to the automation rules engine 212b. The traffic analytics engine 212a may be configured for generating the device status indication of the device 106a. The automation rules engine 212b may be configured using a rule engine comprising a plurality of rules that may include a set of synchronisation rules for determining whether there are any synchronisation issues associated with the first platform 102, second platform 104 and/or the device 106a based on the device status indication of device 106a. For example, whether or not first device state information of the device 106a stored by the first platform 102, second device state information of the device 106a stored by the second platform 104 during provisioning of device configuration data to the device 106a correlate or are in line with the received status indication of the device 106a. Should one or more rules of the set of synchronisation rules be triggered, the automation rules engine 212b may send a notification to the synchronisation/trigger action component 213 for resolving the synchronisation error/issue that has been detected.

[0090] The device or message traffic 114 of device 106a is passed to, without limitation, for example the traffic analytics engine 212a which performs, among other things, some unification of data from disparate data sources 214 in relation to the received message traffic 114 from device 106a. The unified message data may include the device status indication of the device 106a. The unified message data may also include the device status and/or state information of the device 106a maintained by the first and second platforms 102 and 104. The unified message data is passed to the automation rules engine 212b for processing by a rules engine (not shown) with a plurality of rules associated with checking the device status of each of the devices 106a-106n based on the unified message data and/or data sources 214.

[0091] The rules engine of the automation rules engine 212b is configured to perform checks whether any of the rules operable in the rules engine are triggered by the unified message data including the received message traffic 114 of the device 106a. A set of synchronisation rules of the plurality of rules may be configured to detect any potential synchronisation issues between the device state information including the state of the device configuration data for device 106a stored in the first platform 102 (e.g. profiles of device 106a stored by the first platform 102), the device state information including the state of the device configuration data for device 106a stored in the second platform 104 (e.g. profiles of device 106a stored by third party SM-SRs and SM-DPs), and/or the device status of the device 106a and/or the SIM component 210a of the device 106a. The set of synchronisation rules may include rules associated with determining whether a device's SIM component is broken and/or whether one or more of the first and second platform 102 and 104 and/or a device 106a are out of synchronisation with each other in relation to device configuration data that has been provisioned on the device 106a. A notification that one or more of the set of synchronisation rules has been triggered may be sent to the synchronisation/trigger action component 213, which selects an appropriate action such as, for example, EIS and/or an Audit of the device and the like. Additionally or alternatively, a rule in the set of synchronisation rules may be configured to check whether any message traffic 114 for each device 106a of the plurality of devices 106a-106n is received which relates to a device configuration data including a profile which, according to the device state information for said each device 106a in the first platform 102, is not currently attached to a SIM component 210a of the device 106a. By creating this rule, if message or device traffic 114 of the device 106a associated with such device configuration data including the profile is identified, it may be inferred that the profile is not current and is unattached. The automation engine 212a can send a notification to the synchronisation/trigger action component 213 for triggering or recommending an action based on the synchronisation error/issue rule being met. Additionally or alternatively, if a synchronisation rule of the set of synchronisation rules determines that a profile of a device 106b is actually in use when the first or second platforms 102 or 104 indicate it is not in use, then the synchronisation/trigger action component 213 may be configured to issue an action or command that ensures the state of the profile is rectified in the first platform 102 and/or the second platform 104 of the remote provisioning system 200. Alternatively or additionally, an alert or action could be triggered which forces a re-download of the device configuration data including the profile to the SIM component 210a of the affected device 106a. Alternatively or additionally, an alert to a customer or owner of the device 106a and/or the SIM component 210a and device 106a could be triggered which recommends that an audit be triggered to resolve the synchronisation issue between the first platform 102, the second platform 104 and/or the device 106a.

[0092] Figure 2b is a flow diagram illustrating an example synchronisation checking process 220 that may be performed by the device synchronisation apparatus 110 as described with reference to figure 2a. The device synchronisation apparatus 110 is configured to respond on any device traffic from any device 106a with a SIM component 210a. The device traffic monitoring apparatus 212 includes traffic analytics engine 212a and automation rules engine 212b. Traffic analytics engine 212a monitors device traffic and other data sources for deriving the required device status indication information for use with the automation rules engine 212b in determining whether a synchronisation issue or error may be occurring in relation to the first platform 102, second platform 104 and/or one or more devices generating the device traffic. The steps of the synchronisation checking process 220 may be performed by the traffic analytics engine 212a, the automation rules engine 212b and the synchronisation/trigger action component 213 of the device synchronisation apparatus 110. The synchronisation checking process 220, which may be performed for each device 106a of the plurality of devices 106a-106n, includes the following steps of:

[0093] In step 222, analysing the device message traffic 114 of a device 106a and other data sources 214 to determine device status indication information associated with the device 106a.

[0094] In step 224, a check is performed to determine whether the device status indication information is correlated or in line with the device state information of the device 106a maintained by the first platform 102. If the device status indication information correlates with the device state information of the device 106a maintained by the first platform 102 (e.g. Y) then the process 220 proceeds to step 222 for analysing further message traffic from the device 106a. If the device status indication information does not correlate (e.g. N) with the device state information of the device 106a maintained by the first platform 102, then the process 220 proceeds to step 226.

[0095] In step 226, triggering the first platform 102 to send a request to the second platform 104 for determining and/or receiving the device state information of device 106a maintained by the second platform 104. The request by the first platform 102 may be in the form of a GSMA Get EIS action, which is a data call directly to the second platform 104 (e.g. RSP) for retrieving the device state information of the device 106a maintained by the second platform 104.

[0096] In step 228, a check is performed on whether the device status indication information is correlated or in line with the device state information of the device 106a maintained by the second platform 104. If the device status indication information correlates with the device state information of the device 106a maintained by the second platform 104 (e.g. Y) then the process 220 proceeds to step 232 for updating the device state information of device 106a maintained by the first platform 102. If the device status indication information does not correlate (e.g. N) with the device state information of the device 106a maintained by the second platform 104, then the process 220 proceeds to step 230.

[0097] In step 230, an update is triggered for updating and/or synchronising the device state information in relation to the first platform 102, the second platform 104 and the device 106a. For example, the update that is triggered may be a GSMA Audit action that performs a full check of the SIM component 210a of the device 106a. This may include remotely reprovisioning the SIM component 210a of the device 106a with the device configuration data associated with the device state information maintained by the first and second platforms 102 and 104 to bring the device 106a in line with the device state information maintained by the first and second platforms 102 and 104. Prior to the Audit action, a GSMA EIS action may be performed to check that the device state information of the device 106a maintained by first and second platform 102 and 104 are correlated and/or in line with each other. If the device state information of the device 106a maintained by the first and second platform 104 are different or uncorrelated, then the Audit in relation to the SIM component 210a of the device 106a may be based on the device state information maintained by the second platform 104, in which the device state information of the device 106a maintained by the first platform 102 is updated based on the device state information of the device 106a maintained by the second platform 104. The process 220 proceeds to step 222 for analysing further message traffic from device 106a.

[0098] In step 232, an update is triggered for updating and/or synchronising the device state information maintained by the first platform 102 to be in line and/or correlated with the device status information of device 106a and device state information maintained by the second platform 104. The process 220 proceeds to step 222 for analysing further message traffic from device 106a.

[0099] The Get EIS action/operation is performed in step 226 prior to the first platform 102 performing the Audit action/operation in step 230. This is because a Get EIS action/operation is less costly in terms of resources and/or cost than the Audit action. The Get EIS action/operation is a data call directly to the second platform 104 (e.g. RSP), when it is received by the SM-SR component 208a of the second platform 104, the SM-SR component 208a or SM-DP component 208b sends the information associated with the SIM component 210a of the device 106a to the first platform 102. The Get EIS action/operation may be used in scenarios in which the first platform 102 is out of synchronisation with the second platform 102, where the second platform 102 is in synchronisation with the SIM component 210a of the device 106a, or it is assumed that the second platform 104 is synchronised with the SIM component 210a of the device 106a. The Audit action/operation is used when the SIM component 210a of the device 106a is out of synchronisation with either: a) the second platform (e.g. RSP); and/or b) the first and second platforms 102 and 104. [0100] An example use case of process 220 may be as follows: a SIM component/card 210a of device 106a is online, but the device 106a has been configured to be online with profile 1 , which is maintained by the first and second platforms 102 and 104. In step 222, the analysis of message traffic associated with device 106a indicates the traffic is associated with a subscriber profile 2 instead. Step 224 would determine that the device state information of the device 106a maintained by the first platform 102 indicates profile 1 is meant to be used by the SIM component 210 of device 106a. Given this is different to the first platform 102, in step 226, an EIS is used to look at second platform 104 to request whether it has recorded that profile 1 has downloaded and it is active subscriber. In step 228, it is determined that the traffic for subscriber profile 2 generated by device 106a, hence, given that both the first and second platforms are out of synchronisation, an Audit operation is performed to bring the SIM component 210a of device 106a in line with the first and second platforms 102 and 104.

[0101] Figure 2c is a flow diagram illustrating another example synchronisation checking process 240 that may be performed by the device synchronisation apparatus 110 as described with reference to figure 2a. The example synchronisation checking process 220 may be further modified to include further checks to ensure that the status of the device(s) 106a-106n, and recorded/stored status(es) of the devices on the first platform 102 and second platform 104 are synchronised. The device synchronisation apparatus 110 is configured to respond on any device traffic from any of the plurality of devices 106a-106n with a corresponding SIM component 21 Oa-21 On and the like. The device traffic monitoring apparatus 212 includes traffic analytics engine 212a and automation rules engine 212b. Traffic analytics engine 212a monitors device traffic, first and second platforms 102 and 104, and other data sources 214 for deriving the required device status indication information for use with the automation rules engine 212b in determining whether a synchronisation issue or error may be occurring in relation to the first platform 102, second platform 104 and/or one or more of the devices of the plurality of devices 106a-106n that may be generating the device traffic. The steps of the synchronisation checking process 240 may be performed by the traffic analytics engine 212a, the automation rules engine 212b and the synchronisation/trigger action component 213 of the device synchronisation apparatus 110. The synchronisation checking process 240, which may be performed using device traffic 114 corresponding to each device 106a of the plurality of devices 106a-106n, includes the following steps of:

[0102] In step 242, analysing the device message traffic 114 of a device 106a and other data sources 214 to determine device status indication information associated with the device 106a. In step 244, retrieving device state information for said device 106a from first and second platforms 102 and 104.

[0103] In step 246, a check is performed to determine whether the device status indication information is correlated or in line with the device state information of the device 106a maintained by the first platform 102. If the device status indication information correlates with the device state information of the device 106a maintained by the first platform 102 (e.g. Y) then the process 240 proceeds to step 254 for further checks. If the device status indication information does not correlate (e.g. N) with the device state information of the device 106a maintained by the first platform 102, then the process 240 proceeds to step 248.

[0104] In step 248, a check is performed on whether the device status indication information is correlated or in line with the device state information of the device 106a maintained by the second platform 104. If the device status indication information correlates with the device state information of the device 106a maintained by the second platform 104 (e.g. Y) then the process 240 proceeds to step 250 for a further check. If the device status indication information does not correlate (e.g. N) with the device state information of the device 106a maintained by the second platform 104, then the process 240 proceeds to step 256.

[0105] In step 250, given that the device status indication information is correlated or in line with the device state information of the device 106a maintained by the second platform 104, a check is performed on whether the device state information of the device 106a maintained by the second platform 104 is the most-up-to-date device state information for the device 106a. For example, this may be checked using timestamps, queried using one or more of the Config DB 203a, Profile DB 203b, Transaction DB 203c, outgoing and/or incoming handlers 206a and/or 206b and the like. If the device state information of the device 106a maintained by the second platform 104 is the most up-to- date device state information for the device 106a (e.g. Y) then the process 240 proceeds to step 252 where an update is triggered in which the device state information corresponding to the device 106a that is maintained by the first platform 102 is updated with the device state information of the device 106a maintained by the second platform 104. If the device state information of the device 106a maintained by the second platform is not the most up-to-date device state information for the device 106a (e.g. N), then the process 240 proceeds to step 260 for generating new device configuration information for updating the device 106a and also the first and second platforms 102 and 104 and the like.

[0106] In step 252, an update is triggered in which the device state information corresponding to the device 106a that is maintained by the first platform 102 is updated with the device state information of the device 106a maintained by the second platform 104. In this case, both the device 106a and the second platform 102 have the current and correct device configuration, so the first platform 102 is updated accordingly. There may have been some error or corruption that occurred when the second platform 104 reported successful configuration of the device 106a to the first platform 102 along with the device state information and the like that was uploaded to the device 106a.

[0107] In step 254, a check is performed on whether the device status indication information is correlated or in line with the device state information of the device 106a maintained by the second platform 104. If the device status indication information correlates with the device state information of the device 106a maintained by the second platform 104 (e.g. Y) then the process 240 proceeds to step 242, because the device status indication information of the device 106a, the device state information of the device 106a maintained by the first and second platforms 102 and 104 are all in agreement or correlate with each other as expected. The process 240 proceeds to monitor and analyse message traffic associated with each of those plurality of devices 106a-106n that are generating message traffic accordingly. If the device status indication information does not correlate (e.g. N) with the device state information of the device 106a maintained by the second platform 104, then the process 240 proceeds to step 256.

[0108] In step 256, even though the device status indication information is not correlated or in line with the device state information of the device 106a maintained by the second platform 104, a check is performed on whether the device state information of the device 106a maintained by the second platform 104 is the most-up-to-date device state information for the device 106a. For example, this may be checked using timestamps, queried using one or more of the Config DB 203a, Profile DB 203b, Transaction DB 203c, outgoing and/or incoming handlers 206a and/or 206b and the like. If the device state information of the device 106a maintained by the second platform 104 is the most up-to- date device state information for the device 106a (e.g. Y) then the process 240 proceeds to step 258 where an update is triggered in which the device state information corresponding to the device 106a that is maintained by the first platform 102 and the device configuration of the device 106a are updated based on the device state information of the device 106a maintained by the second platform 104. If the device state information of the device 106a maintained by the second platform is not the most up-to-date device state information for the device 106a (e.g. N), then the process 240 proceeds to step 260 for generating new device configuration information for updating the device 106a and also the first and second platforms 102 and 104 and the like.

[0109] In step 258, an update is triggered in which the device state information corresponding to the device 106a that is maintained by the first platform 102 is updated with the device state information of the device 106a maintained by the second platform 104, and the device configuration of the device 106a is updated based on the device state information of the device 106a maintained by the second platform 104. In this case, only the second platform 102 has the current and correct device configuration state information, so the first platform 102 and the device 106a are updated accordingly.

[0110] In step 260, an update is triggered for updating and/or synchronising the device state information in relation to the first platform 102, the second platform 104 and the device 106a. It may be that the device 106a, first and/or second platform 102 and/or 104 are not synchronised/correlated, and it is unclear where the synchronisation issue may lie, thus the device status information of the device 106a of the first and second platforms 102 and 104 and the device 106a are updated - i.e. a reset of the device configuration of the device 106a may be performed so the first platform 102, second platform 104, and the device 106a reaches a known device state. This may involve generating new device configuration data for the device 106a by the first platform 102 for distributing to the second platform 104 and uploading to the device 106a. For example, the update that is triggered may be a GSMA Audit action that performs a full check of the SIM component 210a of the device 106a. This may include remotely reprovisioning the SIM component 210a of the device 106a with the device configuration data associated with the device state information maintained by the first and second platforms 102 and 104 to bring the device 106a in line with the device state information maintained by the first and second platforms 102 and 104. Prior to the Audit action, a GSMA EIS action may be performed to check that the device state information of the device 106a maintained by first and second platforms 102 and 104 are correlated and/or in line with each other. If the device state information of the device 106a maintained by the first and second platform 104 are different or uncorrelated, then the Audit in relation to the SIM component 210a of the device 106a may be based on, without limitation, for example a) the device state information maintained by the second platform 104 with the device state information of the device 106a maintained by the first platform 102 updated based on the device state information of the device 106a maintained by the second platform 104, or b) new device state information for the device 106a generated by the first platform 102 that is distributed to the second platform 104 for updating the second platform 104, where a GSMA Audit action is performed for reprovisioning the device 106a accordingly. The process 240 proceeds to step 242 for analysing further message traffic from those devices of the plurality of devices 106a-106n generating message traffic.

[0111] Figure 3 is a schematic diagram illustrating an example device synchronisation apparatus 300 based on device synchronisation apparatus 110 of figure 2a with a traffic analytics engine 212a, an automation rules engine 212b and synchronisation component 213. The traffic analytics engine 212a receives device status information from various data sources 214 and device traffic 114 and derives an indication of the device status for a device 106a based on the device traffic 114 of the device 106a and/or data source(s) 214 available to the first platform 102 that may provide device state information for the device 106a. On receipt of device traffic 114 for a device 106a from the APN 112a, the traffic analytics engine 212a retrieves the device identity of the device 106a and/or other data representative of the device 106a. This may be used to then retrieve device state information of the device 106a from the data source(s) 214. These may be used by the traffics analytics engine 212a to provide indications of the status 302a-302n of the device 106a in a message format for sending to the automation rules engine 212b. The indications of the device status 302a-302n of the device 106a include, without limitation, for example first indications of the device status 302a derived from device traffic 114 of the device 106a, and second indications of the device status 302b-302n of the device 106a derived from data source(s) 214 available to the first platform 102.

[0112] The first and second indications of device status 302a-302n are provided to the automation rules engine 212b for determining whether the device configuration data of the SIM component 210a of the device 106a is in line or correlates with the device state information of the first and second platforms 102 and 104. If they are determined correlate, then the device 106a is operating as expected. If they are determined not to correlate then there is a synchronisation issue or error associated with the first platform 102, second platform 104 and/or the SIM component 210a of device 106a. The automation rules engine 212b is configured to request and receive further device state information 214d from the second platform 104 (e.g. instruct the synchronisation component 213 to issue a EIS command/action to the first platform 102). Thus the first indication of device status 302a, second indications of device status 302b-302n and the device state information 214d associated with device 106a from the second platform 104 may be used by the automation rules engine 212b and the set of synchronisation rules to determine whether at least one of the first platform 102, second platform 104 and/or SIM component 210a of device 106a require updating of their device state information and/or device configuration data to ensure the first platform 102, the second platform 104 and the SIM component 210a of the device 106a are synchronised and operating as expected. This may involve the synchronisation component 213 issuing an EIS action and/or an Audit action depending on the severity of the synchronisation issue and/or error.

[0113] The information that that is used for performing a synchronisation and/or Audit may be taken from different data source(s) 214 including one or more data sources 214a-214d and/or device traffic 114 of each of the devices 106a-106n. The data source(s) 214 may include, without limitation, for example 1) Call Data Records I EDRs 214a associated with each SIM component of each device of the plurality of devices 106a-106n; 2) configuration data 214b from Configuration/transaction database 203a/203c (e.g. Config DB) associated with each device of the plurality of devices 106a- 106n, the configuration data 214b may include, without limitation for example, device configuration data such as, without limitation, for example subscriber data 214c, operator data and/or SIM profile data, which may also be from profile database 203b - the Config DB 203a may include other databases such as profile database 203b; and/or 3) device state information data 214d (e.g. RSP data) from the second platform 104 (e.g. RSP) associated with each device of the plurality of devices 106a-106n that are provisioned by the second platform 104. The device traffic 114 may be derived from APN traffic (e.g. radius traffic) associated with each device of the plurality of devices 106a-106n.

[0114] CDRs/EDRs are associated with the devices and are received from each MNO based on the device usage of the respective communication network(s) 108. For example, CDR/EDR may include data representative of usage data based on used X amount of data between X time and Y time, for each is an individual event, get it for voice calls, SMS etc. APN traffic 114 for a device 106a may be based on a Radius counting system, where get data feed for each device 106a from the MNO over Radius protocol or other means in which traffic packets associated with each device 106a of the plurality of devices 106a-106n are counted as they cross the communications network 108. The Config DB 203a-203c may include device state information 214b/214c for each device 106a of the plurality of devices 106a-106n such as, without limitation, for example out subscriber, ICCID, EID, RSP each device is configured with (e.g. second platform 104), transaction logs and the like. RSP data 214d is device state information of the device 106a maintained by the second platform 104 (e.g. RSP) that performs a remote SIM provisioning procedure on the SIM component/card 210a of the device 106a. The traffic analytics engine 212a may compile the data received from data sources 214a-214c and the device traffic 114 of the device 106a and provide the automation engine with first indication of status 302a of the device 106a derived from the device traffic 114 of the device 106a and second indications of status 302b-302n of the device derived from the data sources(s) 214a-214c available to the first platform 102 and the identification of the device 106a from the device traffic 114 of the device 106a.

[0115] CDR/EDR may be seen as a record of events in relation to each device of the plurality of devices 106a-106n that have taken place and can be used as a source of truth in relation to what the communication network 108 of each MNO is experiencing/seeing/charging on the core network where the APN 112a or radius feed is counting headers in relation to device traffic of each device. The CDRs/EDRs may be used as an approximate indication of the amount of traffic from a device etc. The CDRs/EDRs are used to cross reference with APN traffic 114 or radius feed to check that the amount of traffic measured for each device is correct. The combination of the data sources 214 such as, without limitation, 1) CDRs/EDRs for a device 106a; 2) configuration data 214b/c for device 106a; 3) APN traffic 114 for device 106a; form a set of indications of device status 302a-302n of the device 106a that may be fed from the traffic analytics engine 212a, and/or in conjunction with 4) RSP data 214d for device 106a second platform 104, into the automation rules engine 212b. At a minimum, at last two of the APN traffic 114 for device 106a and device state information 214b/c or RSP sourced 214d information may be used by automation rules engine 212b to provide an action/trigger for selecting by synchronisation component 213 for identifying and correcting any synchronisation issues/errors occurring in at least one of the first platform 102, second platform 104 and/or device 106a. The combination of traffic information 114 and status information or RSP sourced information 214d gives a certain level of confidence that there is an synchronisation issue/error or not. Simply put, the moment a mismatch occurs between the first indication of device status 302a, the device state information of device 106a derived from the first platform 102 such as the second indications of device status 302b-302n, and the device state information of device 106a derived from the second platform 104, then the set of synchronisation rule(s) of the automation rules engine 212b triggers a notification to the synchronisation component 213 to perform a synchronisation action such as, for example, a Get EIS action and/or an Audit action and/or any other synchronisation functionality for mitigating and/or correcting the synchronisation error/issue. Examples of which are described with reference to figures 1 a to 2b, for example, synchronisation checking process 220 of figure 2b.

[0116] An example scenario may be that the second platform 104 (e.g. RSP) is out of synchronisation with the SIM component 210a of device 106a. This will not be spotted in conventional RSP/MNO systems, in which it is reliant upon the network operator to notice a discrepancy and/or the customer to notice and issue after a long period of time in which the device 106a may have been operating incorrectly over a communication network of an MNO. The traffic analytics engine 212a of the device synchronisation apparatus 300 has access to various data source(s) 214a-214b and also APN traffic 114, in particular, the traffic analytics engine 212a has access to the data source CDRs 214a of the device 106a and the APN traffic 114 of the device 106a, which may be a real-time radius feed providing a real-time counting packets associated with the traffic 114 of the device 106a. This provides, in essence, a live feed of traffic from a subscription associated with a SIM component 210a of device 106a. Thus, an audit of CDRs 214a of the device 106a and the APN traffic 114 associated with the device 106a may be used to determine whether synchronisation issues exist between the first platform 102, the second platform 104 and/or the SIM component 210a of the device 106a. For example, if a SIM component/card 210a of a device 106a is online, it can only be online with 1 profile at a time. If the second platform 104 managed to perform a remote provisioning in which it recorded profile 1 as being downloaded to the SIM component/card 210a of device 106a, then this would be expected to be the active profile 1 when the SIM component/card 210a of a device 106a is online. However, if instead the traffic analytics engine 212a sees device traffic 114 of device 106a over APN 112a in relation to a different profile 2, then the automation rules engine 212b, once it receives the RSP data 214d for the device 106a from the second platform 104, which shows the active profile should be profile 1 , then the synchronisation ruleset of the automation rules engine 212b is configured to determine that at least the second platform 104 is out of synchronisation with the SIM component 210a of the device 106a. Given this and that from the APN traffic 114, CDR 214a, and RSP data 214d, there is a high confidence level that the SIM component 210a of the device 106a is not operating appropriately or in line with the device state information maintained by the first and/or second platforms 102 and 104. Thus, the synchronisation component 213 may trigger an Audit action to be performed in relation to the device 106a, which may involve reprovisioning the device 106a with profile 1 and removing profile 2 to ensure the device 106a be card is doing different data to what the RSP thinks it is doing.

[0117] The traffic analytics engine 212a may be further configured to detect when a device 106a is not transmitting as much traffic 114 as it should or is disconnected from the network 108. For example, a device 106a may connect to the communications network 108 of a network operator (NO) using a valid profile on its SIM component 210a. The traffic analytics engine 212a may analyse the CDRs 214a of the device 106a and/or the device traffic 114 of device 106a (when it gets device traffic) to determine when the device 106a initiates a session start and when the device 106a disconnects and initiates a session end. The traffic analytics engine 212a may be configured to track the number of multiple session starts and ends for a device 106a, which may be provided to automation rules engine 212b for determining the behaviour of the device 106a and/or whether the behaviour of the device 106a is in line with the expected behaviour of the device 106a. By tracking when a device 106a connects to the communication network 108 of an MNO, it can be determined when the device 106a gets disconnected or has a connection failure. For example, the traffic analytics engine 212a may use a timer or counter that is linked to a SIM/eSIM/iSIM profile of the SIM component 210a of the device 106a so that when the device 106a gets disconnected, the timer linked to subscriber/SIM profile is activated and so, the traffic analytics engine 212a may provide a periodic device status indication 302a or 302n to the automation rules engine 212b indicating the device 106a is offline or disconnected. For example, the device status indication 302a or 302n may indicate the device 106a as offline every X minutes (e.g. 15 minutes or any other time period set by a user, operator or process). A rule in the automation rule engine 212b may be set that if the traffic from the device 106a stops for X amount of time, then perform a particular action such as, without limitation, for example check synchronisation of device 106a with first and second platform(s) 102 and 104 (e.g. perform EIS and/or Audit actions), and/or notify customer/user of the device 106a that device 106a may be faulty and/or replace the device 106a and the like. These actions may be provided to and/or taken by the synchronisation component 213.

[0118] There may be other reasons why a device 106a has not connected to the expected communications network 108 of an MNO. Once the traffic analytics engine 212a does not see that device 106a has not been online or communicating X amount of time, then the automation rule engine 212b may use a rule and/or logic to look at the history of transactions that may have been performed by first and/or second platforms 102 and/or 104 in relation to the device 106a. For example, there may be a rule or logic for checking whether there has been a recent remote provisioning action in relation to the device 106a. If this is the case, and the second platform 102 recently attempted to download device configuration data such as a profile to the SIM component 210a of the device 106a, but the device 106a is not responding, then another rule may be set for use in determining what the device state information maintained by the second platform 104 (e.g. RSP) is when the device 106a is not responding. For example, the automation rule engine 212b may notify the synchronisation component 213 to send an EIS action in relation to device 106a to the second platform 104, which should provide further device state information of the device 106a such as RSP data 214a maintained by the second platform 102 to the automation rules engine 212b. The RSP data 214a may indicate the profile downloaded and whether it was successful of not, where further rules in the automation rules engine 212b acts on the device status information 302a-302n and 214d received in relation to device 106a, and if traffic associated with the device 106a is still not seen (e.g. traffic analytics engine 212a is still sending periodic device status indications for device 106a that device 106a has not connected or is offline still), then this may result in the automation rule engine 212b sending a notification or triggering the synchronisation component 213 for performing an Audit in relation to device 106a. The Audit action may result in the device configuration data including the required profile(s) for device 106a being reprovisioned and downloaded to the SIM component 210a of the device 106a, and the first and second platforms 102 and 104 being resynchronised in relation to the device state information of the device 106a maintained by these platforms 102 and 104. Thus, the device 106a may have been provided with the correct profile and use the correct communication network/APN 108/112a, where it is expected the device 106a will begin generating device traffic/data over the communication network 108 according to the reprovisioned data.

[0119] Although this example is for detecting a device 106a that is unable to connect to the communication network, this is by way of example only and the invention is not so limited, it is to be appreciated by the skilled person that the device synchronisation apparatus 300 may be configured for many other scenarios for detecting synchronisation error/issues in relation to the first platform 102, the second platform 104 and/or one or more devices 106a-106n in which the traffic analytics engine 212a, the automation rule engine 212b and synchronisation component 213 may be further modified and/or configured based on further logic used in the traffic analytics engine 212a and/or using one or more further sets of rules and logic in the automation rules engine 212b and/or synchronisation component 213 in relation to these many other scenarios.

[0120] A further scenario may include when one or more devices of the plurality of devices 106a- 106n are mobile and/or move around, for example, in an loT transport deployment for monitoring shipping. Such devices may transmit multiple regions and hence transit multiple communication networks, some of which the device may not have a SIM profile and so may have to resort to using the boot profile on the device for connecting to the new communication network in a new region. The device synchronisation apparatus 110 and/or 300 for figures 1 a to 3 may detect this from device traffic 114 received by the traffic analytics engine 212a. Thus, on detecting the SIM card/component 210a coming on line for the first time in a different region/destination may trigger the provisioning of additional device configuration suitable for a communication network of an MNO in the region/destination that the device finds itself in. Thus, the device 106a with SIM component 210a may be able to travel from region to region (e.g. territory 1 to territory 2), such that the device 106a and SIM component 210a are automatically remote provisioned (e.g. using EIS and/or Audit actions) with additional device configuration data including new profiles for the new region or location (e.g. territory 2). Thus may be because the third party IOT provider may have a contract in both territories so that a new profile can be automatically provisioned once the device transits to the new territory.

[0121] Other scenarios may include, without limitation, for example 1) SIM component/card 210a of a device 106a is not responding; 2) another SIM profile is being used by SIM component/card 210a of device 106a that what the first and second platforms 102 and 104 expect or have recorded should be used. For example, SIM component/card 210a of a device 106a may have 4 or 5 different profiles, but second platform 104 indicates that only profile 1 should be online, but device synchronisation apparatus 110 is seeing device traffic in relation to device 106a using profile 2. Thus, the automation rule engine 212b using its set of synchronisation rules will detect that an anomaly is occurring in relation to first platform 102, second platform 104 and/or the device 106a and may be configured to investigate further as outlined herein and/or as the application demands. No device traffic at all for one or more devices of the plurality of devices 106a-106n and/or the wrong device traffic for one or more devices of the plurality of devices 106a-106n to what was expected by the first and/or second platforms 102 and 105 are further scenarios that mean that there is a synchronisation error/issue in relation to the first and/or second platforms 102 and/or 104 and/or the one or more devices of the plurality of devices 106a-106n.

[0122] Figure 4 is a schematic diagram illustrating an example computing system 400 with a computing device 402 that may be used to implement one or more aspects of the remote provisioning system, device, loT device, service, first and/or second platform(s), device synchronisation apparatus, traffic analytics component(s), automation rule engine/component(s), device synchronisation process(es) and/or traffic monitoring/analytics process(es), cloud-based platforms and components and the like according to the invention and/or based on the process(es), method(s), system(s), and/or apparatus, combinations thereof, modifications thereof, and/or as described with reference to figures 1a to 3 and/or as described herein. Computing device 402 includes one or more processor unit(s) 404, memory unit 406 and communication interface 408 in which the one or more processor unit(s) 404 are connected to the memory unit 406 and the communication interface 408. In some embodiments, the computing device 402 may be a server, or one or more servers networked together. In some embodiments, the computing device 402 may be a mobile device, loT device, or other device for use in loT deployments and capable of communications with a communications network 410. The communications interface 408 may connect the computing device 402, via a communication network 410, with one or more services, devices, remote provisioning system(s) including one or more first and/or second platforms, other processing system(s) or computing device(s) for implementing the invention as described herein. The memory unit 406 may store one or more program instructions, code or components 406a such as, by way of example only but not limited to, an operating system and/or SIM component(s)/data for authenticating or operating computing device 402 over a communication network 410 and a data store 406b for storing additional data, applications, application firmware/software and/or further program instructions, code and/or components associated with implementing the functionality and/or one or more function(s) or functionality associated with one or more of the method(s) and/or process(es) of the device, service and/or server(s) hosting the remote provisioning system, first and second platforms, services, apparatus, mechanisms and/or system(s)/platforms/architectures as described herein, combinations thereof, modifications thereof, and/or as described with reference to at least one of figure(s) 1 a to 3.

[0123] In the embodiments, examples, of the invention as described above such as remote provisioning platforms and/or first and second platforms may comprise one or more cloud platforms, one or more server(s) or computing system(s) or device(s). A server may comprise a single server or network of servers, the cloud platform may include a plurality of servers or network of servers. In some examples the functionality of the server and/or cloud platform may be provided by a network of servers distributed across a geographical area, such as a worldwide distributed network of servers, and a user may be connected to an appropriate one of the network of servers based upon a user location and the like.

[0124] The above description discusses embodiments of the invention with reference to a single user for clarity. It will be understood that in practice the system may be shared by a plurality of users, and possibly by a very large number of users simultaneously.

[0125] The embodiments described above are fully automatic. In some examples a user or operator of the remote provisioning system, first and/or second platforms may manually instruct some steps of the method to be carried out.

[0126] In the described embodiments of the invention the device, loT device, service, remote provisioning system, first and/or second platform(s), device synchronisation apparatus and/or process(es), traffic analytics component(s), automation rule engine/component(s), and/or synchronisation action component and the like according to the invention and/or as herein described may be implemented as any form of a computing and/or electronic device. Such a device may comprise one or more processors which may be microprocessors, controllers or any other suitable type of processors for processing computer executable instructions to control the operation of the device in order to gather and record routing information. In some examples, for example where a system on a chip architecture is used, the processors may include one or more fixed function blocks (also referred to as accelerators) which implement a part of the method in hardware (rather than software or firmware). Platform software comprising an operating system or any other suitable platform software may be provided at the computing-based device to enable application software to be executed on the device.

[0127] Various functions described herein can be implemented in hardware, software, or any combination thereof. If implemented in software, the functions can be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media may include, for example, computer-readable storage media. Computer-readable storage media may include volatile or non-volatile, removable or non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. A computer-readable storage media can be any available storage media that may be accessed by a computer. By way of example, and not limitation, such computer- readable storage media may comprise RAM, ROM, EEPROM, flash memory or other memory devices, CD-ROM or other optical disc storage, magnetic disc storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Disc and disk, as used herein, include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and blu-ray disc (BD). Further, a propagated signal is not included within the scope of computer-readable storage media. Computer-readable media also includes communication media including any medium that facilitates transfer of a computer program from one place to another. A connection or coupling, for instance, can be a communication medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of communication medium. Combinations of the above should also be included within the scope of computer-readable media.

[0128] Alternatively, or in addition, the functionality described herein can be performed, at least in part, by one or more hardware logic components. For example, and without limitation, hardware logic components that can be used may include Field-programmable Gate Arrays (FPGAs), Programspecific Integrated Circuits (ASICs), Program-specific Standard Products (ASSPs), System-on-a-chip systems (SOCs). Complex Programmable Logic Devices (CPLDs), etc.

[0129] Although illustrated as a single system, it is to be understood that the computing device may be a distributed system. Thus, for instance, several devices may be in communication by way of a network connection and may collectively perform tasks described as being performed by the computing device. Although illustrated as a local device it will be appreciated that the computing device may be located remotely and accessed via a network or other communication link (for example using a communication interface).

[0130] The term 'computer ¹ is used herein to refer to any device with processing capability such that it can execute instructions. Those skilled in the art will realise that such processing capabilities are incorporated into many different devices and therefore the term 'computer' includes PCs, servers, loT devices, mobile telephones, personal digital assistants and many other devices.

[0131] Those skilled in the art will realise that storage devices utilised to store program instructions can be distributed across a network. For example, a remote computer may store an example of the process described as software. A local or terminal computer may access the remote computer and download a part or all of the software to run the program. Alternatively, the local computer may download pieces of the software as needed, or execute some software instructions at the local terminal and some at the remote computer (or computer network). Those skilled in the art will also realise that by utilising conventional techniques known to those skilled in the art that all, or a portion of the software instructions may be carried out by a dedicated circuit, such as a DSP, programmable logic array, or the like.

[0132] It will be understood that the benefits and advantages described above may relate to one embodiment or may relate to several embodiments. The embodiments are not limited to those that solve any or all of the stated problems or those that have any or all of the stated benefits and advantages. Variants should be considered to be included into the scope of the invention.

[0133] Any reference to 'an' item refers to one or more of those items. The term 'comprising' is used herein to mean including the method steps or elements identified, but that such steps or elements do not comprise an exclusive list and a method or apparatus may contain additional steps or elements. As used herein, the terms "component" and "system" are intended to encompass computer-readable data storage that is configured with computer-executable instructions that cause certain functionality to be performed when executed by a processor. The computer-executable instructions may include a routine, a function, or the like. It is also to be understood that a component or system may be localized on a single device or distributed across several devices. Further, as used herein, the term "exemplary" is intended to mean "serving as an illustration or example of something". Further, to the extent that the term "includes" is used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term "comprising" as "comprising" is interpreted when employed as a transitional word in a claim.

[0134] The figures illustrate exemplary methods. While the methods are shown and described as being a series of acts that are performed in a particular sequence, it is to be understood and appreciated that the methods are not limited by the order of the sequence. For example, some acts can occur in a different order than what is described herein. In addition, an act can occur concurrently with another act. Further, in some instances, not all acts may be required to implement a method described herein.

[0135] Moreover, the acts described herein may comprise computer-executable instructions that can be implemented by one or more processors and/or stored on a computer-readable medium or media. The computer-executable instructions can include routines, sub-routines, programs, threads of execution, and/or the like. Still further, results of acts of the methods can be stored in a computer- readable medium, displayed on a display device, and/or the like.

[0136] The order of the steps of the methods described herein is exemplary, but the steps may be carried out in any suitable order, or simultaneously where appropriate. Additionally, steps may be added or substituted in, or individual steps may be deleted from any of the methods without departing from the scope of the subject matter described herein. Aspects of any of the examples described above may be combined with aspects of any of the other examples described to form further examples without losing the effect sought.

[0137] It will be understood that the above description of a preferred embodiment is given by way of example only and that various modifications may be made by those skilled in the art. What has been described above includes examples of one or more embodiments. It is, of course, not possible to describe every conceivable modification and alteration of the above devices or methods for purposes of describing the aforementioned aspects, but one of ordinary skill in the art can recognize that many further modifications and permutations of various aspects are possible. Accordingly, the described aspects are intended to embrace all such alterations, modifications, and variations that fall within the scope of the appended claims.