TECHNICAL FIELD

[0001] Various example embodiments relate to automating software updating of devices.

BACKGROUND

[0002] This section illustrates useful background information without admission of any technique described herein representative of the state of the art.

[0003] Networked devices, such as computer servers, need periodic updates. These updates, from now on referred to as patches, should be applied to all devices in a timely manner. Patching of systems is often done in a manual and time-consuming manner.

[0004] Various processor operated devices are typically shipped with a set of firmware and software. After some time, the devices need to be updated by means of software patches. These updates may occur regularly. They can include firmware, software and application updates. Regular updates keep the devices protected against vulnerabilities in software.

[0005] There are devices that are easily left without updates. For example, there is an increasing number of lnternet of Things (IoT) devices that can be connected to the cloud and lnternet enabled toys and entertainment devices that their users cannot or do not remember to update. The lnternet of Things devices are devices that automatically communicate measurements or detections of physical events to other devices or that control physical actuators according to commands received from the lnternet, without need for manual supervision or interaction for such tasks.

[0006] The updates of lnternet enabled devices are not only needed to protect the devices in question from abuse, but for avoiding their use in botnet attacks against other lnternet devices. Such attacks may harm other devices and at the very least, they waste bandwidth and may trigger blacklisting the devices and closing lnternet access by lnternet service providers.

[0007] Personal computers typically periodically poll for available updates to the operating system and install the updates automatically or with a user permission. This operation mode is rather well scalable as the detection of patching need is distributed to the computers themselves. However, large number of computers skip updates for various reasons including the users’ choice not to approve any updates, e.g., in fear of some application or service stopping to work due to buggy patches or changing way of operation after feature updates.

SUMMARY

[0008] Various aspects of examples of the invention are set out in the claims.

[0009] According to a first example aspect of the present invention, there is provided an update system comprising:

[0010] a communication block configured to communicate with lnternet devices comprising trusted platform modules;

[0011] computer program code; and

[0012] a processing block configured to execute the computer program code and accordingly to perform:

[0013] checking states of a plurality of lnternet devices through quotes obtained from trusted platform modules of the lnternet devices;

[0014] checking patch availability for each of the plurality of lnternet devices;

[0015] making patching decisions independent of other entities;

[0016] determining the need for software updates based on quotes; and

[0017] maintaining policies that drive the quoting process.

[0018] The entities may be or comprise data processing agents in communicative connection with the update system. The entities may be or comprise data processing agents in the update system.

[0019] The determining of the need for software updates based on the quotes may be made by the patch management system.

[0020] Each of the lnternet devices may comprise a trusted platform module. Alternatively, some of the lnternet devices may comprise a trusted platform module.

[0021] The policies may allow an agent, e.g. a patch management system, to determine which lnternet device needs an update.

[0022] The checking of the states of the plurality of lnternet device may comprise checking for each of the lnternet devices an update state for each of one or more updateable components. The checking of the update state may comprise checking of current software or firmware version.

[0023] The communication block may comprise computer program code. The communication block may comprise a communication circuitry.

[0024] The processing block may comprise computer program code. The processing block may comprise a processing circuitry.

[0025] The received quotes may comprise platform configuration registers.

The

[0026] The processing block may be further configured to define the policies that drive the quoting process.

[0027] The update system may comprise or the update system may be a patch management system. The patch management system may comprise the communication block; the processing block; and at least some of the computer program code. The update system may further comprise a policy database comprising the policies that drive the quoting process. The update system may further comprise a quote engine configured to provide the patch management system with the predicted quotes. The quote engine may comprise a quote database comprising previously computed predicted quotes for different lnternet device components and patches. The quote engine may further comprise a quote processing block configured to compute predicted quotes on request of the patch management system. The quote engine may further be configured to update the quote database on computing new predicted quotes.

[0028] The updating system may further comprise a patch database. The patch database may comprise patches for the components of the lnternet devices. Alternatively, or additionally, the patch database may comprise links to externally stored patches for the components of the lnternet devices.

[0029] The software element may comprise a basic input/output system program code. The software element may comprise firmware of a hardware component of the lnternet device. The software element may comprise a device driver. The software element may comprise a software library component, such as a dynamic link library component. The software element may comprise at least one operating system component. The software element may comprise at least one application component.

[0030] The processing block may be further configured to perform verifying each of the lnternet devices has been successfully patched. The verifying may comprise comparing a received quote of the lnternet device with a predicted quote. The predicted quote may comprise check a code produced for a software element being patched after a patch in question has been applied to the software element. The check code may be based on a cyclic redundant code. The check code may comprise an authenticator. The authenticator may comprise a cryptographic presentation of the check code. The cryptographic presentation may comprise a cryptographic one-way hashing of the check code. The authenticator may comprise a digital signature of the check code. The digital signature may be formed using an attestation key of the lnternet device. The attestation key may be formed by a trusted platform module of the lnternet device. The authenticator may comprise as such or as a derivative state information of the trusted platform module, such as a reboot count. The authenticator may comprise as such or as a derivative a timestamp.

[0031] The verifying of successful patching may comprise obtaining a new quote from an lnternet device and determining whether the new quote matches a predicted quote lf no, a patching error may be indicated lf yes, the verifying may further comprise determining whether reboot count has increased by an expected amount lf no, a patching error may be indicated lf yes, the verifying may further comprise determining whether the timestamp of the new quote indicates lapse of time by an expected duration lf no, a patching error may be indicated lf yes, the patching success may be considered correctly applied.

[0032] Some of the patches may be made unnecessary by subsequent patches so that updating of one lnternet device with one patch may bring the lnternet device up to date. The verifying may then indicate successful patching regardless whether all preceding patches have been applied by the lnternet device.

[0033] The processing block may be further configured to maintain statistics of average success rate of different patches. The statistics may indicate the average success rate separately for different classes of lnternet devices. The different classes may be classified using at least one of: type; make; model; model version; and age. The processing block may be further configured to alert of patches that statistically appear failure prone. The alerting may inform of the class or classes in which the patching statistically appears failure prone. The failure prone patch may have a success rate less than any one of: 99%; 95 %; 90 %; 80 %; 70%; 60 % or 50 %. [0034] The update system may comprise or the update system may be an attestation server. The patch management system may be configured to communicate with the attestation server. The patch management system may be configured to communicate with the lnternet devices directly or via the attestation server.

[0035] The update system may comprise a blockchain delivery channel configured to distribute patches to the lnternet devices through a blockchain. The lnternet devices may obtain the patches from the blockchain.

[0036] Any one of the policy database, quote database; and patch database may be centralized or distributed. Centralized databases may be implemented using a relational database, such as a structured query language database. The distributed databases may be implemented using one or more distributed relational databases and/or a blockchain, such as Ethereum.

[0037] The update system may comprise a first subset of the plurality of lnternet devices.

[0038] According to a second example aspect of the present invention, there is provided an update system comprising:

[0039] a communication block configured to communicate with lnternet devices comprising trusted platform modules;

[0040] computer program code; and

[0041] a processing block configured to execute the computer program code and accordingly to perform:

[0042] checking states of a plurality of lnternet devices through quotes obtained from trusted platform modules of the lnternet devices;

[0043] checking patch availability for each of the plurality of lnternet devices;

[0044] making patching decisions independent of other agents in the system;

[0045] determining the need for software updates based on quotes; and

[0046] maintaining policies that drive the quoting process.

[0047] According to a third example aspect of the present invention, there is provided a method comprising:

[0048] communicating with lnternet devices comprising trusted platform modules;

[0049] checking states of a plurality of lnternet devices through quotes obtained from trusted platform modules of the lnternet devices; [0050] checking patch availability for each of the plurality of lnternet devices;

[0051 ] making patching decisions independent of other entities;

[0052] determining the need for software updates based on quotes; and

[0053] maintaining policies that drive the quoting process.

[0054] The determining of the need for software updates based on the quotes may be made by the patch management system.

[0055] According to a fourth example aspect of the present invention, there is provided a computer program comprising computer executable program code configured to execute any method of the third example aspect.

[0056] The computer program may be stored in a computer readable memory medium. The computer medium may be a non-transitory memory medium.

[0057] Any foregoing memory medium may comprise a digital data storage such as a data disc or diskette, optical storage, magnetic storage, holographic storage, opto-magnetic storage, phase-change memory, resistive random access memory, magnetic random access memory, solid-electrolyte memory, ferroelectric random access memory, organic memory or polymer memory. The memory medium may be formed into a device without other substantial functions than storing memory or it may be formed as part of a device with other functions, including but not limited to a memory of a computer, a chip set, and a sub assembly of an electronic device.

[0058] Different non-binding example aspects and embodiments of the present invention have been illustrated in the foregoing. The embodiments in the foregoing are used merely to explain selected aspects or steps that may be utilized in implementations of the present invention. Some embodiments may be presented only with reference to certain example aspects of the invention lt should be appreciated that corresponding embodiments may apply to other example aspects as well.

BRIEF DESCRIPTION OF THE DRAWINGS

[0059] For a more complete understanding of example embodiments of the present invention, reference is now made to the following descriptions taken in connection with the accompanying drawings in which:

[0060] Fig. 1 shows an architectural drawing of a system of an example embodiment;

[0061] Fig. 2 shows a block diagram of the patch management system of Fig. 1;

[0062] Fig. 3 shows a block diagram of the lnternet device of Fig. 1;

[0063] Fig. 4 shows a flow chart of a process of an example embodiment;

[0064] Fig. 5 shows a flow chart of a process of an example embodiment;

[0065] Fig. 6 shows a signaling chart of an example embodiment;

[0066] Figs. 7 and 8 show schematic architectural drawings of two different example embodiments; and

[0067] Fig. 9 shows a flow chart of a process of an example embodiment.

DETAILED DESCRIPTON OF THE DRAWINGS

[0068] An example embodiment of the present invention and its potential advantages are understood by referring to Figs. 1 through 9 of the drawings ln this document, like reference signs denote like parts or steps.

[0069] Fig. 1 shows an architectural drawing of an update system 100 of an example embodiment The update system 100 comprises a patch management system 110 and connected to the patch management system: a quote engine 120 comprising a quote database 122; a policy database 130; a patch database 140; and a plurality of lnternet devices 150 which comprise trusted platform modules 152. Any one or more of the quote engine 120; quote database 122; policy database 130; and patch database 140 may be entirely or partly comprised by the patch management system 110.

[0070] Fig. 2 shows a block diagram of the patch management system of Fig. 1. The patch management system 110 comprises:

[0071] a communication block 210 configured to communicate with the lnternet devices 150;

[0072] computer program code 222 stored in a memory 220; and

[0073] a processing block 230 configured to execute the computer program code and accordingly to perform:

[0074] checking states 410 (Fig. 4) of a plurality of lnternet devices through quotes obtained from trusted platform modules of the lnternet devices;

[0075] checking patch availability 420 (Fig. 4) for each of the plurality of lnternet devices;

[0076] making patching decisions 430 (Fig. 4) independent of other entities (e.g., data processing agents in the update system or in communicative connection with the update system);

[0077] determining 440 (Fig. 4, e.g. by the patch management system) the need for software updates based on quotes; and

[0078] maintaining policies 450 (Fig. 4) that drive the quoting process.

[0079] ln an example embodiment, each of the lnternet devices 150 comprises a trusted platform module TPM. ln an alternative embodiment, some of the lnternet devices 150 comprise a TPM.

[0080] Fig. 3 shows a block diagram of the lnternet device 150. The lnternet device 150 comprises a communication block 310 configured to communicate over the lnternet; a memory 310; one or more applications 322; one or more pieces of firmware 324; and an operating system 326. The memory 310 may comprise one or more non volatile memories, including, for example, a hard disk drive or solid state drive of the lnternet device 150; one or more non-volatile memories of various components such as of a graphics processing unit, or of a communication unit or of a microprocessor. The internet device 150 further comprises a basic input/output system 328 (which refers here to the B10S code that is updateable rather than the hardware) and the trusted platform module 152. The trusted platform module 152 comprises a certificate 340; an endorsement key EK 350; an attestation key AK 360; and a plurality of platform configuration registers PCR 370. ln an example embodiment, the PCRs 370 store measurements, e.g., in the form of hashes, of different software, firmware or B10S components of the lnternet device 150.

[0081] The attestation key AK 360 is in an example embodiment an attestation key complying with TPM 2.0. ln another example embodiment, the attestation key AK 360 is in an example embodiment an attestation identity key complying with TPM 1.0. ln an example embodiment, the certificate 340 is, or comprises, an attestation certificate compliant with TPM 2.0. ln an example embodiment, the certificate 340 is, or comprises, an attestation identity key certificate compliant with TPM 1.0.

[0082] ln an example embodiment, the TPM 152 stores cryptographic keys, certificates and confidential data. For example, the TPM 152 stores two unique key pairs: The EK 350 and the AK 360. Additionally, the platform configuration registers 370 store measurements, e.g., in the form of hashes, of the (updateable) components of the lnternet device 150. ln an example embodiment, the TPM 152 can be asked to provide a quote for a set of PCRs. The quote is, for example, a hash over the stored values of the selected set PCRs. ln an example embodiment, the TPM will then return the quote for the requested PCRs, a cryptographic signature of that quote (signed by the AK) and other information, including a timestamp and a reboot count.

[0083] ln an example embodiment, the lnternet device 150 signs the quote with the AK 360. ln an example embodiment, the TPM 152 can also store an externally provided key, which has the AK of the lnternet device 150 in a signature chain. This externally provided key can be used to sign quotes.

[0084] Fig. 4 has already been discussed in connection with Fig. 2 description.

[0085] ln an example embodiment, the policies allow an agent, e.g. the patch management system 110, to determine which lnternet device 150 needs an update, as will be further exemplified with reference to Figs. 5 and 6. ln this document, the internet device 150 may refer to any device that uses the lnternet for communication.

[0086] Fig. 5 shows a flow chart of a process of an example embodiment. The process comprises checking 510 whether patching is needed for the lnternet devices 150. Let us consider this process for a given internet device 150. lf not, it is determined that no patch is needed in step 580.

[0087] ln an example embodiment, the checking of the states of the plurality of lnternet device 150 comprises checking for each of the lnternet devices 150 an update state for each of one or more updateable components. The checking of the update state may comprise checking of current software or firmware version.

[0088] ln step 520 it is calculated which patch is needed. To this end, combinations of the present state of the lnternet device 520 and of a set of patches P is generated 530 and an expected result V(E+P) is calculated 540 for the tested combination of present state and the set of patches P. lt is then tested 550 if the tested combination would comply with current policy (e.g., correspond to the set of latest patches that are available for the lnternet device 150). lf a match is found, the tested set of patches P is presented 570 for patching the lnternet device 150. Otherwise the process returns to step 530 until no more combinations of patch sets are available for the lnternet device 150 and the process goes to end in step 560 (for the lnternet device 150 in question). Notably, the process can be performed in plurality of parallel processes for individual lnternet devices 150. Moreover, in an example embodiment, a group of lnternet devices with same hardware and installed applications processed simultaneously as one group in terms of determining the need of patching and the suitable patch or patches if any are needed. The actual patching and verifying the end result can be performed individually or on a group level as well, provided that that actual verification of successful patching can be made for each lnternet device 150 of a group.

[0089] ln an example embodiment, the policy database 130 comprises the policies that drive the quoting process ln an example embodiment, the updating system further comprises the quote engine 120 configured to provide the patch management system 110 with the predicted quotes ln an example embodiment, the quote engine 120 comprises the quote database 122 comprising previously computed predicted quotes 122 (or expected values, when the received quotes and the predicted quotes are in the form of values) for different lnternet device 150 components and patches ln an example embodiment, the quote engine 120 further comprises a quote processing block (not shown) configured to compute predicted quotes on request of the patch management system 110. ln an example embodiment, the quote engine 120 is further configured to update the quote database 122 on computing new predicted quotes.

[0090] ln an example embodiment, the policy is or the policy comprises a set of expected values (or predicted quotes) for different measurements that can be taken from the lnternet device 150. When the lnternet device 150 is equipped with the TPM 152, the policy can be a mapping between the PCRs and expected results or values. For example, an administrator can define policies for an lnternet device 150 to be considered in a trusted state. When attestation is done, the measurements or received quotes are checked against the expected values in the policy or expected quotes.

[0091] Furthermore, the policy can potentially become quite complex. Both simple and compound policies can be contemplated. A simple policy is a set of expected values ln an example embodiment, the policy is a compound policy that comprises set of simple policies lt is possible to define very specific policies as building blocks for more complex policies. For example: if there are two lnternet devices 150 running the same B10S version but different software on top, there is defined in an example embodiment a simple policy for the B10S and then two different policies for the other software on top. Two compound policies can then be created, which compound policies will both share the B10S policy. The quotes can also be requested separately for each separately updateable component so that the need of updating and the success can be determined and the actual performing of updates in the lnternet devices 150 can be verified.

[0092] ln an example embodiment, the updating system 100 further comprises the patch database 140. ln an example embodiment, the patch database 140 comprise patches for the components of the lnternet devices 150. Alternatively, or additionally, the patch database 140 comprises links to externally stored patches for the components of the lnternet devices 150.

[0093] ln an example embodiment, the processing block 230 is configured to perform verifying that each of the lnternet devices 150 has been successfully patched ln an example embodiment, the verifying comprises comparing a received quote of the lnternet device 150 with the predicted quote ln an example embodiment, the predicted quote comprise check a code produced for a software element being patched after a patch in question has been applied to the software element ln an example embodiment, the check code is based on a cyclic redundant code ln an example embodiment, the check code comprises an authenticator ln an example embodiment, the authenticator comprises a cryptographic presentation of the check code such ln an example embodiment, the cryptographic presentation comprises a cryptographic one way hashing of the check code ln an example embodiment, the authenticator comprises a digital signature of the check code ln an example embodiment, the digital signature is formed using an attestation key of the lnternet device 150. ln an example embodiment, the key is formed by the trusted platform module 152 of the lnternet device 150. ln an example embodiment, the authenticator comprises as such or as a derivative state information of the trusted platform module 152, such as a reboot count ln an example embodiment, the authenticator comprises as such or as a derivative a timestamp.

[0094] ln an example embodiment, the verifying of successful patching comprises obtaining a new quote from an lnternet device 150 and determining whether the new quote matches a predicted quote lf no, a patching error may be indicated lf yes, the verifying may further comprise determining whether reboot count has increased by an expected amount lf no, a patching error may be indicated lf yes, the verifying may further comprise determining whether the timestamp of the new quote indicates lapse of time by an expected duration lf no, a patching error may be indicated lf yes, the patching success may be considered correctly applied. [0095] Some of the patches may be made unnecessary by subsequent patches so that updating of one lnternet device 150 with one patch may bring the lnternet device 150 up to date. The verifying may then indicate successful patching regardless whether all preceding patches have been applied by the lnternet device 150.

[0096] ln an example embodiment, the processing block 230 is further configured to maintain statistics of average success rate of different patches. The statistics may indicate the average success rate separately for different classes of lnternet devices 150. ln an example embodiment, the different classes are classified using at least one of: type; make; model; model version; and age. ln an example embodiment, the processing block 230 is further configured to alert of patches that statistically appear failure prone ln an example embodiment, the alerting informs of the class or classes in which the patching statistically appears failure prone. The failure prone patch may have a success rate less than any one of: 99%; 95 %; 90 %; 80 %; 70%; 60 % or 50 %.

[0097] Fig. 6 shows a signaling chart of an example embodiment. The signaling chart shows the following events:

[0098] 610. The lnternet device 150 requests an update policy from the policy DB 130.

[0099] 615. The policy DB returns the policy for PCRs 1 to 7 of the lnternet device 150.

[0100] 620. The TPM 152 computes a quote against policy 620.

[0101] 625. The lnternet device 150 uploads to the Quote DB 122 a quote for the PCRs 1-7.

[0102] 630. The Quote DB 122 is requested for the quote by the patch management system 110.

[0103] 635. The Quote DB 122 returns the requested quote to the patch management system 110.

[0104] 640. The patch management system 110 requests the policy from the policy DB 130.

[0105] 645. The policy DB 130 returns the requested policy.

[0106] 650. The patch management system 110 checks the PCRs 1-7 against the policy EV.

[0107] 655. The patch management system 110 requests a set of patches is from the patch DB 140.

[0108] 660. The patch DB 140 returns the requested set of patches.

[0109] 665. The patch management system 110 tests whether the returned set of patches would comply with the policy EV. lf yes, the set of patches is presented 680 by the patch management system 110 to the lnternet device 150. lf no, it is checked if there is another quote + set of patches to be tested in steps 655 to 670, and if there is, a new round is started in step 675, otherwise it is determined that the lnternet device 150 is not to be patched with respect to its components corresponding to the PCRs 1- 7 of this example.

[0110] ln an example embodiment, the update system 100 comprises an attestation server 710 (Fig. 7). The patch management system 110 may be configured to communicate with the attestation server 710. The patch management system 110 may be configured to communicate with the lnternet devices 150 directly (as in Fig. 7) or via the attestation server 710 (as in Fig. 8).

[0111] ln an example embodiment, the update system 100 comprises a blockchain delivery channel configured to distribute patches to the lnternet devices 150 through a blockchain. The lnternet devices 150 may obtain the patches from the blockchain.

[0112] Any one of the policy database 130, quote database 122; and patch database 140 may be centralized or distributed. Centralized databases may be implemented using a relational database, such as a structured query language database. The distributed databases may be implemented using one or more distributed relational databases and/or a blockchain, such as Ethereum.

[0113] ln an example embodiment, the update system 100 comprises a first subset of the plurality of lnternet devices 150.

[0114] Fig. 8 shows a schematic architectural drawing of an example embodiments. Fig. 8 presents an attestation Server 810, which in this embodiment is a main component in which required functionality is encapsulated, i.e.: the mechanisms for requesting a quote, receiving a quote, cross-referencing with external systems (e.g., patch management system 850, a database 820 for storing relevant attestation data) and a reasoning or decision engine 818 that can reason in some form over the collected data and inputs.

[0115] The attestation server 810 of Fig. 8 comprises internal components that include Quoting 812 that is a functionality for performing operations for the process of quoting a device.

[0116] The internal components further include an internal database 814, which is, for example, a functionality that performs operations for storing information related to attestation. This may additionally call external database 820 processing for convenience, long-term storage etc.

[0117] NB: in the diagram an external Database 820 is shown, which is, for example, be any external mechanism for storing data, including traditional databases, log files, blockchain, etc.

[0118] The internal components further include monitoring 816, which is, for example, a functionality that performs operations relating to active or passive monitoring of systems.

[0119] The internal components further include decision maker 818, which is, for example, a functionality that performs operations relating to deciding on the course of action of some event (internal or external) related to attestation functionality. Such functionality might be relatively simple and hard encoded in some code or could be implemented using some Al mechanism.

[0120] The internal components further include action 819, which is, for example, a functionality that performs or triggers some attestation action to take place. This could include communication with external systems.

[0121] Fig. 8 shows a box representing machines 840, which may include any devices that can receive (including proxy) a request for attestation, or can (including proxy) relay attestation data, e.g., in the form of a TPM2 quote or other similar structure.

[0122] Fig. 8 further shows a patch management system 850, which may be, e.g., any system that coordinates, manages, orchestrates etc. the update and patching of machines, software and other devices (loT, Edge, etc.).

[0123] Fig. 8 further shows a security orchestrator 830. This may be, e.g., any system that coordinates, manages, orchestrates etc. security policies and response mechanisms to certain system events, e.g., attestation failures ln an example embodiment, the security orchestrator 830 may also interact with the attestation server 810 to obtain information about a given machine or processes' state as necessary. The security orchestrator may also be referred to as security orchestration management.

[0124] Fig. 8 further shows a box for other systems 860, which may comprise any other system(s) that can receive or send pertinent information or signals to the attestation server 810. For example, in the proof of concept individual machines can report their boot status. This information can be used by the attestation server 810 to trigger a post-boot attestation of that machine ln another example, this is a virtual infrastructure manager (VIM) 870 in some network functions virtualization management and orchestration (NFV MANO) component that "proxies" or triggers the attestation server 810 on some operation in some way.

[0125] One Use Case is next presented:

[0126] The patch management system 850 notifies the V1M that a given machine 840 requires an update.

[0127] The V1M 870 requests that the attestation server 810 take a quote of said machine 840.

[0128] The V1M 870 causes the machine 840 to reboot.

[0129] The machine 840 reports to the V1M that it has successfully rebooted.

[0130] The V1M 870 requests that the attestation server 810 take a second quote of said machine 840.

[0131] The V1M 870 requests of the attestation server 810 its decision regarding the machine's 840 state, expected state, prior states and various combinations thereof as required.

[0132] Other subsequent actions may take place, for example:

[0133] The attestation server 810 reports that the machine 840 has failed attestation to the security orchestrator 830.

[0134] The security orchestrator 830 informs the V1M 870 that the security orchestrator 830 is taking actions to sand-box the machine by some means (e.g., virtual network function (VNF) wrapping, software defined networking (SDN) rerouting, etc.

[0135] Fig. 9 shows a flow chart of a process of an example embodiment. The process comprises:

[0136] 910. communicating with lnternet devices 150 comprising trusted platform modules 152;

[0137] 920. checking states of a plurality of lnternet devices 150 through quotes obtained from trusted platform modules 152 of the lnternet devices 150; [0138] 930. checking patch availability for each of the plurality of lnternet devices 150;

[0139] 940. making patching decisions independent of other entities such as data processing agents in the update system or in communicative connection with the update system;

[0140] 950. determining the need for software updates based on quotes (e.g., by the patch management system 110); and

[0141] 960. maintaining policies that drive the quoting process.

[0142] ln an example embodiment, the lnternet devices 150 with a trusted platform module 152 can generate a hash that summarizes the hardware and software configuration of that platform, as well as other interesting metadata, such as reboot count. These hashes may be compared with a known good value in order to verify that a specific software is running on a machine. This process may be referred to as attestation of a platform. By storing the results of attestation into a database, either centralized or distributed, system agents may determine what software is running on each machine.

[0143] ln an example embodiment, in cloud environments, such as the Telco Cloud, there are machines running the virtual workload, as well as different hardware connected to the cloud, such as base stations. The embodiments described in the foregoing may be used to find out the state in which these devices are and versions of software or firmware they are running.

[0144] Reference has been made to the measurements performed by the TPM 152. lt should be appreciated that these measurements may also comprise version numbers of software and firmware or B10S components.

[0145] As used in this application, the term "circuitry" may refer to one or more or all of the following:

(a) hardware-only circuit implementations (such as implementations in only analog and/or digital circuitry) and;

(b) combinations of hardware circuits and software, such as (as applicable):

(i) a combination of analog and/or digital hardware circuit(s) with software/firmware; and

(ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions); and

(c) hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.

[0146] This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.

[0147] Without in any way limiting the scope, interpretation, or application of the claims appearing below, a technical effect of one or more of the example embodiments disclosed herein is that reliability of patching lnternet devices can be improved. Another technical effect of one or more of the example embodiments disclosed herein is that suitability of patches can be commonly tailored by owners or organizations that control numerous lnternet devices. Yet another technical effect of one or more of the example embodiments disclosed herein is that actual performing of patching can be reliably verified by owners or controlling organizations. Yet another technical effect of one or more of the example embodiments disclosed herein is that patching can be improved for lnternet of Things devices and other devices with insufficient direct manual supervision.

[0148] Embodiments of the present invention may be implemented in software, hardware, application logic or a combination of software, hardware and application logic. The software, application logic and/or hardware may reside on a patch management system, patch database, quote database, policy database and lnternet device lf desired, part of the software, application logic and/or hardware may reside on a patch management system, and part of the software, application logic and/or hardware may reside on patch database, quote database, policy database and lnternet device ln an example embodiment, the application logic, software or an instruction set is maintained on any one of various conventional computer-readable media ln the context of this document, a "computer-readable medium" may be any non-transitory media or means that can contain, store, communicate, propagate or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer, with one example of a computer described and depicted in Fig. 9. A computer-readable medium may comprise a computer-readable storage medium that may be any media or means that can contain or store the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer.

[0149] lf desired, the different functions discussed herein may be performed in a different order and/or concurrently with each other. Furthermore, if desired, one or more of the before-described functions may be optional or may be combined.

[0150] Although various aspects of the invention are set out in the independent claims, other aspects of the invention comprise other combinations of features from the described embodiments and/or the dependent claims with the features of the independent claims, and not solely the combinations explicitly set out in the claims.

[0151] lt is also noted herein that while the foregoing describes example embodiments of the invention, these descriptions should not be viewed in a limiting sense. Rather, there are several variations and modifications which may be made without departing from the scope of the present invention as defined in the appended claims.