Failover responses using known good state from the distributed ledger

Abstract

A technique is described for repairing and / or recovering (multiple) computer programs installed on programmable devices using a distributed ledger based on cryptography and blockchain technology. One or more self-reliant logic / modules may submit records of watchdog communications between devices to a distributed ledger located on interconnected devices. One or more interconnected devices may include corresponding self-reliant logic / modules. The logic / module may use the records of the distributed ledger to check that (multiple) computer programs on the interconnected devices are operating as expected. When the self-reliant logic / module fails to respond to the watchdog communication, the distributed ledger may be updated to include the fault. The self-reliant logic / module may determine that the installed computer program is faulty based on the distributed ledger and / or the fault. In addition, the self-reliant logic / module may initiate one or more software recovery services based on the determination. Other advantages and embodiments are described.

Description

Technical Field

[0001] Embodiments described herein generally relate to the field of programmable devices. More specifically, embodiments described herein relate to repairing or recovering a failed computer program (eg, software, firmware, etc.) installed on one or more interconnected programmable devices. Background Art

[0002] Programmable devices - e.g., Internet of Things (IoT) devices, mobile computing devices, cloud computing devices, logical computing devices, virtual computing devices - can form a computer system consisting of interconnected programmable devices. In such a computer system, each programmable device includes one or more computer programs (e.g., software, firmware, etc.) for performing its operations and functions.

[0003] As the improvement of technology continues to make programmable devices more accessible and efficient, the number of interconnected programmable devices may increase. Therefore, some computer systems may include many interconnected programmable devices (e.g., tens, hundreds, thousands, millions, billions, etc.). In such a system, one problem that may arise is the scalability problem. This problem occurs when one or more programmable devices fail due to one or more erroneous computer programs installed thereon, which in turn leads to the need for restoring or repairing the erroneous (multiple) computer programs installed thereon. A current method adopted by an enterprise information technology (IT) system serving a computer system composed of interconnected devices relies on a central configuration server to update the system's faulty programmable devices using a known good image of a computer program (e.g., software, firmware, etc.) installed on the device. In this current method, the user of the programmable device plays an important role in notifying the central configuration server when a problem occurs (e.g., when the programmable device fails, etc.). For example, a user of a faulty programmable device can open a service call sheet to be served by a service facility, and talk to an agent from the service facility that diagnoses the problem and recommends a repair action.

[0004] As the number of interconnected programmable devices that make up the computer system increases, these devices become too many and cannot work for the method described in the preceding paragraph. This is because the service facility may not have enough resources to solve many devices that may fail. The problem described in this paragraph is further aggravated by the potential lack of user interface capabilities on the programmable device (or on the computing system available to the user of the failed device), which may hinder the detection, diagnosis and repair of the device that promotes the user. Failure to solve the failed device may then cause adverse effects on the availability of one or more interconnected devices. Therefore, lack of resources to realize the recovery or repair of the computer program installed on one or more interconnected programmable devices of the computer system may increase the risk of the operational integrity of the computer system.

[0005] The above problems are also exacerbated in computer systems consisting of interconnected programmable devices because such systems rely on a centralized communication model, otherwise known as a server / client model. The servers used in the server / client model are potential bottlenecks and failure points that may disrupt the operation of the entire computer system. In addition, these servers are susceptible to security compromises (e.g., man-in-the-middle attacks, etc.) because all data associated with multiple devices of the computer system must pass through the servers. Therefore, a server whose task is to recover or repair a computer program installed on a failed programmable device may fail, which is undesirable. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Figure 1 is a block diagram illustrating a computer system including interconnected programmable devices according to one embodiment.

[0007] Figure 2 is a sequence diagram illustrating a technique for software recovery of a computer program installed on a programmable device that is part of a computer system composed of interconnected programmable devices according to one embodiment.

[0008] Figure 3 is a block diagram illustrating a software recovery service for repair and recovery of computer programs according to one embodiment.

[0009] Figure 4 is a flow chart illustrating a technique for software recovery of a computer program using a distributed ledger according to one embodiment.

[0010] Figure 5 is a block diagram illustrating a programmable device for use with one or more of the techniques described herein, according to one embodiment.

[0011] Figure 6 is a block diagram illustrating a programmable device for use with one or more of the techniques described herein, according to another embodiment. DETAILED DESCRIPTION

[0012] The embodiments described herein relate to using a distributed ledger available to multiple devices of a computer system to recover or repair (multiple) computer programs installed on one or more interconnected programmable devices of a computer system. The embodiments described herein have several advantages, which are directed to improving computer functions. An advantage of the embodiments described herein is that these embodiments can help solve the scalability problems described in the background technology section of this document. For example, one or more of the embodiments described herein can use a distributed ledger available to multiple programmable devices in a computer system to automatically recover a faulty programmable device in a computer system consisting of interconnected programmable devices. For this example, the distributed ledger promotes device-driven recovery, failover, or replacement strategies, which can be referred to as "self-reliance" strategies or "self-reliance" in this article. Another advantage of the embodiments described herein is that these embodiments can provide an alternative to the central communication model (i.e., client / server model) for repairing or recovering a computer program. In addition, at least one of the embodiments described herein may help to one or more of the following: (i) minimize or eliminate the failure rate of devices in a computer system composed of interconnected programmable devices, which in turn helps prevent other devices in the system from becoming unavailable; (ii) minimize or eliminate the risk to the operational integrity of a computer system composed of interconnected programmable devices caused by failed devices; (iii) minimize or eliminate the use of a server as the sole watchdog device for recovering or repairing computer programs installed on the interconnected programmable devices of a computer system, because such a server is a potential bottleneck and failure point that may disrupt the operation of the entire computer system; and (iv) minimize or eliminate vulnerabilities caused by security compromises (e.g., man-in-the-middle attacks, etc.), because data associated with multiple interconnected devices of a computer system is not necessarily transmitted using a centralized communication model.

[0013] In the following description, for the purpose of explanation, several specific details are set forth in order to provide a comprehensive understanding of the embodiments described herein. However, it is obvious to those skilled in the art that the embodiments described herein can be practiced without these specific details. In other examples, structures and devices are shown in block diagram form to avoid making the embodiments described herein unclear. References to numbers without subscripts or suffixes should be understood as all instances of subscripts and suffixes corresponding to the referenced numbers. In addition, the language used in the present disclosure is selected mainly for readability and guidance purposes, and the language used in the present disclosure may not be selected to describe or limit the subject matter of the invention in the embodiments described herein. Therefore, it is necessary to determine the subject matter of the invention in the embodiments described herein by means of the claims. References to "one embodiment", "embodiment", "another embodiment" or its variations in the specification mean that the specific features, structures or characteristics described in conjunction with the embodiments are included in at least one embodiment of the embodiments described herein, and multiple references to "one embodiment", "embodiment", "another embodiment" or its variations should not be understood as necessarily referring to the same embodiment.

[0014] As used herein, the term "programmable device" and its variations refer to a physical object that includes electronic components configured to receive, send, and / or process data information. For one embodiment, one or more of the electronic components may be embedded in a physical object, for example, in a wearable device and a mobile device (e.g., an autonomous vehicle). For one embodiment, the device may also include actuators, motors, control functions, sensors, and / or other components that perform one or more tasks without human intervention, for example, a drone, an autonomous vehicle, and / or an automated transporter. A programmable device may refer to a computing device, such as (but not limited to) a mobile computing device, a laptop computer, a wearable computing device, a network device, an Internet of Things (IoT) device, a cloud computing device, a vehicle, a smart lock, and the like.

[0015] As used herein, the terms "program," "computer program," and variations thereof refer to one or more computer instructions executed by a programmable device to perform tasks. Examples include, but are not limited to, software and firmware.

[0016] As used herein, "software recovery service", "software recovery", "software repair", "restore", "repair" and variations thereof refer to the modification, reinstallation, and / or removal of a computer program installed on a programmable device to a known good configuration of the computer program. For simplicity, the term "software recovery" or "software recovery service" will be used to refer to "software recovery service", "software recovery", "software repair", "restore" and "repair" as described herein. Software recovery services include, but are not limited to, rollback operations that roll back a computer program currently installed on a programmable device to the last known good configuration of the computer program. Examples of rolling back a computer program include, but are not limited to, major version rollbacks, minor version rollbacks, patches, hot fixes, maintenance releases, and service packs. Thus, rolling back a computer program includes moving from a version of the computer program to another version, and from one state of a version of the computer program to another state of the same version of the computer program. Rollbacks can be used to patch security vulnerabilities and other bugs, improve device functionality by adding new features, improve power consumption and performance, repair faulty programmable devices, and the like. Rollbacks can be viewed as an important feature in the life cycle of a programmable device. Additional details about software recovery services will be described below in conjunction with the following. Figure 1-4 One or more of them are described.

[0017] As used herein, the term "computer system" may refer to a single programmable device or to multiple programmable devices that work together to perform functions or operations described as being performed on or by a computer system. For one embodiment of a computer system consisting of multiple programmable devices, one or more of the devices may perform at least one function or at least one operation that is different from one or more functions or operations performed by one or more other devices in the system. For one example, a first device of the computer system may perform a first function or operation that is different from a second function or operation performed by a second device of the computer system. For another embodiment of a computer system consisting of multiple programmable devices, one or more of the devices may have at least one function or at least one operation that is performed thereon that is different from one or more functions or operations performed on one or more other devices in the system. For example, a first device of a computer system may have a first function or operation that is performed thereon that is different from a second function or operation performed on a second device of the computer system.

[0018] As used herein, "computer network", "network" and its variations refer to a plurality of interconnected programmable devices that can exchange data with each other. For example, a computer network can enable a computer system consisting of interconnected programmable devices to communicate with each other. Examples of computer networks include, but are not limited to, peer-to-peer networks, any type of data network such as a local area network (LAN), a wide area network (WAN) such as the Internet, a fiber optic network, a storage network, or a combination thereof, which can be wired or wireless. In a computer network, interconnected programmable devices use a communication mechanism to exchange data with each other, and a communication mechanism refers to one or more facilities that allow communication between devices in a network. The connection between interconnected programmable devices is established using a wired or wireless communication link. Communication mechanisms also include networking hardware (e.g., switches, gateways, routers, bridges, modems, wireless access points, networking cables, line drivers, switches, hubs, repeaters, etc.).

[0019] As used herein, "watchdog system", "watchdog device", "watchdog" and variations thereof refer to hardware (e.g., one or more processing units, electronic circuits, etc.), software (e.g., a computer program executed by one or more processing units or electronic circuits, etc.), or a combination of the two that sends messages (e.g., signals, ping packets, etc.) to a programmable device on a periodic basis for the purpose of receiving a response from the programmable device. When the watchdog does not receive a response to its message from the programmable device within a predetermined time period, the watchdog device may initiate one or more software recovery services for the device that failed to respond to the watchdog device, as described in conjunction with one or more of the embodiments set forth herein. The predetermined time period may be based on a time from when the watchdog message is sent by the watchdog device or a time from when the watchdog message is received by a client device. For one embodiment, the watchdog device is a programmable device configured to perform the operations described in this paragraph.

[0020] As used herein, "watchdog message", "watchdog signal", "message", "signal" and variations thereof refer to a signal sent by a watchdog device to a programmable device in a computer system composed of interconnected programmable devices, to which the programmable device must respond within a predetermined amount of time to indicate that the computer program installed on the programmable device is operating without error (e.g., the program is operating as expected, etc.). The response to a watchdog message may also be referred to herein as a "watchdog response message".

[0021] As used herein, the term "distributed ledger" and its variations refer to a database available to multiple programmable devices and / or multiple watchdogs of a computer system consisting of interconnected programmable devices. A key feature of a distributed ledger is that there is no central data repository that maintains a master copy of the distributed ledger. Instead, the distributed ledger is stored in many different data repositories, and the consensus protocol ensures that each copy of the ledger is the same as each other copy of the distributed ledger. For example, the distributed ledger can be based on blockchain-based technology, which is well known in the field of passwords and cryptocurrencies (e.g., Bitcoin, Ethereum, etc.). The distributed ledger can provide a public and / or non-public verifiable ledger for software recovery in one or more programmable devices and / or one or more watchdog devices in a computer system consisting of interconnected programmable devices. Changes in the distributed ledger (e.g., a successful response to a watchdog message, a failed response to a watchdog message, etc.) represent the working conditions of one or more computer programs installed on one or more programmable devices of a computer system consisting of interconnected programmable devices. These changes can be added to and / or recorded in the distributed ledger. For one embodiment, multiple programmable devices and / or watchdog devices of a computer system composed of interconnected programmable devices are required to confirm the changes, add the changes to their copies of distributed ledgers, and broadcast their updated distributed ledgers to the entire computer system. Each of the programmable devices and / or watchdog devices with distributed ledgers can confirm the changes according to a confirmation protocol. For one embodiment, the confirmation protocol defines a process by which interconnected devices in a computer system including interconnected programmable devices reach consensus on changes and / or additions to distributed ledgers. For one embodiment, the confirmation protocol may include a proof-of-work protocol implemented by Bitcoin or a public consensus protocol. For another embodiment, the confirmation protocol may include a private and / or custom confirmation protocol. The distributed ledger enables the interconnected devices in a computer system composed of interconnected programmable devices to reach consensus on one or more changes and / or additions to the distributed ledger (e.g., including a successful response to a watchdog message, including a failed response to a watchdog message, etc.) via a verification protocol.

[0022] Figure 1 1 is a block diagram showing a computer system 100 composed of interconnected programmable client devices 102A-N (hereinafter referred to as "client devices 102A-N") according to one embodiment. As shown, the computer system 100 includes multiple client devices 102A-N, multiple programmable watchdog devices 104A-N (hereinafter referred to as "watchdog devices 104A-N"), one or more software recovery services 199, and one or more networks 105.

[0023] Each of the client devices 102A-N may be an Internet of Things (IoT) device, a mobile computing device, a cloud computing device, a logical computing device, or a virtual computing device. In addition, each of the client devices 102A-N may include an electronic component 130A-N. Examples of components 130A-N include: (multiple) processing units (e.g., microprocessors, coprocessors, other types of integrated circuits (ICs), etc.); corresponding memories; and / or other related circuits. For one embodiment, each of the client devices 102A-N includes a corresponding one of the self-reliance logic / modules 101 that implements a distributed ledger 103. The ledger 103 is used to perform software recovery of one or more computer programs installed on one or more of the client devices 102A-N. For one embodiment, the distributed ledger 103 may be distributed across at least two of the devices 102A-N and 104A-N. In this way, the distributed ledger 103 may be used to avoid one or more disadvantages of central communication technologies (e.g., server / client models) for software recovery of computer programs. In addition, and as Figure 1 As shown, for one embodiment, the distributed ledger 103 is replicated on and available to the client devices 102A-N and the watchdog devices 104A-N. Therefore, for this embodiment, each of the watchdog devices 104A-N includes the same features as those incorporated throughout this document. Figure 1-6 The described self-contained logic / module 101 corresponds similarly to the self-contained logic / module 101 .

[0024] Each of the stand-alone logic / modules 101 may be implemented as at least one of hardware (e.g., electronic circuitry of processing unit(s), dedicated logic, etc.), software (e.g., one or more instructions associated with a computer program executed by processing unit(s), software running on a general purpose computer system or a dedicated machine, etc.), or a combination thereof. For one embodiment, each of the stand-alone logic / modules 101 performs one or more embodiments of techniques for software recovery of computer programs installed on one or more interconnected client devices 102A-N, as described herein.

[0025] For some embodiments, each of the self-supporting logic / modules 101 of the client device 102A-N is implemented as one or more dedicated processors with tamper-resistant features. These types of dedicated processors are generally referred to as tamper-resistant processors. Examples of such dedicated processors include trusted platform module (TPM) cryptographic processors, application-specific integrated circuits (ASICs), application-specific instruction set processors (ASIPs), field programmable gate arrays (FPGAs), digital signal processors (DSPs), any type of cryptographic processor, embedded processor, coprocessor, or any other type of logic with tamper-resistant features that can process instructions. In this way, the self-supporting logic / module 101 and the distributed ledger 103 can be implemented and maintained in a secure manner that helps minimize or prevent security vulnerabilities while helping to improve the resilience of the client device 102A-N to software failures. For other embodiments, the self-supporting logic / module 101 and / or the distributed ledger 103 can be maintained separately from the components 130A-N. For example, the self-supporting logic / module 101 can be implemented as one or more dedicated processors separate from the components 130A-N.

[0026] In the computer system 100, each of the client devices 102A-N includes one or more computer programs (e.g., software, firmware, etc.) for performing its operations and / or functions. In addition, each of the (multiple) computer programs of the client devices 102A-N can be rolled back as the (multiple) computer programs fail and / or become erroneous. These rollbacks are typically in the form of major version rollbacks, minor version rollbacks, patches, hot fixes, maintenance releases, service packs, etc. The goal of rolling back the (multiple) computer programs installed on the programmable devices 102A-N is to return such devices to a known good operating state (before the failure or erroneous operation of the client device). Rollbacks can help to patch security vulnerabilities and other program errors, return device functionality to a usable operating state, or return power consumption and performance to a normal state. Therefore, such rollbacks can be considered an important feature in the life cycle of IoT devices, mobile computing devices, cloud computing devices, logical computing devices, and virtual computing devices.

[0027] For a particular embodiment, each of the self-contained logic / modules 101 is implemented in a trusted execution environment (TEE) of one or more processors of the client device 102A-N. Examples of TEEs may include processors and / or cryptographic processors based on Intel Software Guard Extensions (SGX) technology, processors and / or cryptographic processors based on Intel Convergent Security and Manageability Engine (CSME) technology, processors and / or cryptographic processors based on Intel Trusted Execution Technology (TXT) technology, processors and / or cryptographic processors based on Trusted Platform Module (TPM) technology, processors and / or cryptographic processors based on ARM TrustZone technology, and the like. In this way, the TEE serves as an isolated environment for the distributed ledger 103 that runs in parallel with other computer programs (e.g., software, firmware, etc.) installed on the client device 102A-N. For one example, the self-contained logic / module 101 may be implemented in a TEE of a TPM cryptographic processor, an ASIC, an ASIP, an FPGA, a DSP, any type of cryptographic processor, an embedded processor, a coprocessor, or any other type of logic with tamper-resistant features that is capable of processing instructions.

[0028] Each of the watchdog devices 104A-N in the computer system 100 is a computer system that performs various types of processing including the sending of watchdog messages and the reception thereof. In addition, each of the watchdog devices 104A-N may include electronic components 131A-N. Examples of components 131A-N include: (multiple) processing units (e.g., microprocessors, coprocessors, other types of integrated circuits (ICs), etc.); corresponding memories; and / or other related circuits. Therefore, each of the watchdog devices 104A-N may be any of various types of computers, including general-purpose computers, workstations, personal computers, servers, etc. For one embodiment, the watchdog devices 104A-N in the computer system 100 are associated with an external entity (e.g., a service facility that provides software recovery services 199, etc.). Therefore, the watchdog devices 104A-N can facilitate the delivery of (multiple) software recovery services 199 without the need for a user to contact the service facility that provides software recovery services 199 to initiate a software recovery operation. Examples of service facilities that provide software recovery services 199 include, but are not limited to, Internet-based service facilities that facilitate software recovery of computer programs installed on one or more client devices 102A-N. Figure 3104A-N).

[0029] For some embodiments, the rollback may be in the form of a software image (e.g., a disk image, a process image, etc.). For other embodiments, the rollback may be in the form of a software package (e.g., a directory with a standardized hierarchical structure that retains executable code and resources used by the code, etc.).

[0030] The client devices 102A-N and the watchdog devices 104A-N communicate within the computer system 100 via one or more networks 105. These networks 105 include one or more different types of computer networks, such as the Internet, an enterprise network, a data center, a fiber optic network, a storage network, a WAN, and / or a LAN. Each of the networks 105 can provide wired and / or wireless connections between the devices 102A-N and the watchdog devices 104A-N operating in the electrical domain and / or the optical domain, and also employ any number of network communication protocols (e.g., TCP / IP). For example, one or more of the networks 105 within the computer system 100 can be Wireless Fidelity (Wi-Fi). )network, network, Networks, and / or any other suitable radio-based networks that will be appreciated by those of ordinary skill in the art upon reviewing this disclosure. Those of ordinary skill in the art will appreciate that (multiple) networks 105 may also include any desired networking hardware, for example, network nodes configured to transmit data through (multiple) networks 105. Examples of network nodes include, but are not limited to, switches, gateways, routers, bridges, modems, wireless access points, networking cables, line drivers, switches, hubs, and repeaters. For embodiments, at least one of the client devices 102A-N and at least one of the watchdog devices 104A-N implement the functionality of a network node.

[0031] One or more of the networks 105 within the computer system 100 may be configured to implement computer virtualization, such as a virtual private network (VPN) and / or cloud-based networking. For one embodiment, at least one of the client devices 102A-N and at least one of the watchdog devices 104A-N include a plurality of virtual machines (VMs), containers, and / or other types of virtualized computing systems for processing computing instructions and sending and / or receiving data over the network(s) 105. In addition, at least one of the client devices 102A-N and at least one of the watchdog devices 104A-N may be configured to support a multi-tenant architecture in which each tenant may implement its own secure and isolated virtual network environment. Although Figure 1 Not shown, the computer system 100 may enable at least one of the client devices 102A-N and / or at least one of the watchdog devices 104A-N to connect to various other types of programmable devices, such as VMs, containers, hosts, storage devices, wearable devices, mobile devices, and / or any other device configured to send and / or receive data using (multiple) wired or wireless networks 105.

[0032] For some embodiments, the network(s) 105 include a cellular network for use with at least one of the client devices 102A-N and at least one of the watchdog devices 104A-N. For this embodiment, the cellular network may be capable of supporting a variety of client devices 102A-N and watchdog devices 104A-N, including but not limited to computers, laptops, and / or various mobile devices (e.g., mobile phones, autonomous vehicles, ships, and drones). The cellular network may be used in place of and / or in conjunction with at least one of the other networks 105 described above. Cellular networks are known and therefore are not described in detail in this document.

[0033] In some cases, the computer program(s) installed on the client devices 102A-N are intended to operate without any obstructions or adverse ramifications. However, one or more of these computer programs may sometimes introduce problems (e.g., erroneous operation of a device, disabling of a device, etc.). In some scenarios, an erroneous computer program installed on a single client device (e.g., client device 102A, etc.) of the client devices 102A-N may disable one or more of the client devices 102A-N (e.g., one or more client devices 102B-N, etc.), which may in turn pose a risk to the operational integrity of the computer system 100. The software recovery service(s) 199 may be used to help resolve an erroneous computer program installed on one or more of the client devices 102A-N by reinstalling a previous version of the installed computer program that is known to operate as expected.

[0034] The distributed ledger 103 as implemented by the self-reliant logic / module 101 can help minimize or eliminate at least one of the problems described in the immediately preceding paragraph. This is because the distributed ledger 103 operates based on the concept of decentralized consensus, as opposed to the concept of centralized consensus currently used. Centralized consensus is the basis of the client / server model, and it requires a central database or server for deciding how to provide (multiple) software recovery services to (multiple) client devices 102A-N or which software recovery service(s) to provide to (multiple) client devices 102A-N, which, as a result, may create a single point of failure that is susceptible to security vulnerabilities. In contrast, the distributed ledger 103 operates based on a decentralized approach that does not require a central database for deciding how to provide (multiple) software recovery services to one or more of the client devices 102A-N or which software recovery service(s) to provide to one or more of the client devices 102A-N. For one embodiment, the computer system 100 enables its nodes (e.g., client devices 102A-N, watchdog devices 104A-N, etc.) to continuously and sequentially record watchdog communications between client devices 102A-N and watchdog devices 104A-N in a unique chain, i.e., in a distributed ledger 103. For one embodiment, the distributed ledger 103 is an append-only record of watchdog communications between client devices 102A-N and watchdog devices 104A-N based on a combination of cryptographic and blockchain technology. For this embodiment, each successive block of the distributed ledger 103 includes a unique fingerprint of the immediately preceding watchdog communications between the client devices 102A-N and the watchdog devices 104A-N. The unique fingerprint may include at least one of: (i) a hash as known in the cryptographic arts (e.g., SHA, RIPEMD, Whirlpool, Scrypt, HAS-160, etc.); or (ii) a digital signature generated using a public key, a private key, or a hash, as known in the art of generating digital signatures. Examples of digital signature algorithms include secure asymmetric key digital signature algorithms. One advantage of the distributed ledger 103 is that it can facilitate software recovery even in situations where a portion of the computer system 100 is unavailable, which in turn removes the need for a central database or server required in a client / server model. Another advantage of the distributed ledger 103 is that it can facilitate software recovery even in situations where the user of the failed client device 102A-N has not yet contacted a service facility that can provide (multiple) software recovery services 199, which in turn can facilitate automatic software recovery of failed client devices 102A-N in the computer system 100 and help improve resilience to failures within the computer system 100.Yet another advantage of the distributed ledger 103 is that it can prevent unnecessary rollback operations from being performed on a failed client device in the client devices 102A-N. In particular, the distributed ledger 103 can help ensure that no more than one rollback operation is performed on a failed client device in the client devices 102A-N. For example, when the client device 102A receives a first watchdog message from the watchdog device 104A and a second watchdog message from the watchdog device 104B simultaneously or approximately simultaneously, the self-reliant logic / module 101 records the response from the client device 102A to either of the watchdog messages in the distributed ledger 103 as a response to both messages. For this example, the record created by the self-reliant logic / module 101 in the distributed ledger 103 is transmitted via the network(s) 105 to each other copy of the distributed ledger 103 stored on other self-reliant logic / modules 101 or available to other self-reliant logic / modules 101. In this way, and for this example, the distributed ledger 103 enables all client devices 102A-N and / or watchdog devices 104A-N to maintain a record of responses to watchdog messages, which can help determine the point of failure and initiate (multiple) software recovery services 199.

[0035] The distributed ledger 103 as a blockchain includes information stored in its header accessible to the client device(s) 102A-N and / or the watchdog device 104A-N, which enables the client device(s) 102A-N and / or the watchdog device 104A-N to "see" one or more of the following: (i) watchdog messages that have been sent by the watchdog device 104A-N to the client device(s) 102A-N; and (ii) responses to watchdog messages that have been sent by the client device(s) 102A-N to the watchdog device 104A-N. In this way, the distributed ledger 103 is a software design approach that ties the client devices 102A-N and / or the watchdog devices 104A-N together so that they all follow the same consensus process for publishing or recording what information they hold, and where all related interactions are cryptographically verified. The distributed ledger 103 can be a private blockchain or a public blockchain. Furthermore, the distributed ledger 103 may be a permissioned blockchain or a permissionless blockchain.

[0036] One problem associated with distributed ledgers based on blockchain technology is that they are resource intensive. That is, they require a large amount of processing power, storage capacity, and computing resources that grow as the ledger is replicated on more and more devices. This problem is based at least in part on the requirement that each node or device including the ledger must process each transaction in order to ensure security, which can become computationally expensive. Therefore, each device including the ledger may require access to a considerable amount of computing resources. On programmable devices (e.g., mobile devices, vehicles, smart phones, laptops, tablet computers, and media players, micro consoles, IoT devices, etc.) with fixed or limited computing resources, processing the ledger may prove difficult.

[0037] At least one embodiment of the distributed ledger 103 described herein can help minimize the resource-intensive problem described above. For one embodiment, the distributed ledger 103 is not constructed as a monolithic blockchain whose blocks are present on all client devices 102A-N and / or watchdog devices 104A-N. Instead, the distributed ledger 103 is constructed as a light ledger based on, for example, a light client protocol for the Ethereum blockchain, a light client protocol for the Bitcoin blockchain, etc. In this way, the distributed ledger 103 can be replicated on client devices 102A-N and / or watchdog devices 104A-N on an on-demand basis. For one embodiment, any one of the client devices 102A-N and / or watchdog devices 104A-N that is resource-constrained will only store the most recent blocks of the ledger 103 (as opposed to all blocks of the ledger 103). For this embodiment, the number of blocks stored by a particular device or entity can be dynamically determined based on its storage and processing capabilities. For example, any of the client devices 102A-N and / or the watchdog devices 104A-N may store (and also process) only the current block and the immediately following block of the ledger 103. This ensures that any consensus protocol required to add a new block to the ledger 103 can be successfully executed without requiring all of the client devices 102A-N and / or the watchdog devices 104A-N to store the ledger 103 as a large, monolithic blockchain. For another embodiment, each block of the ledger 103 may be based on a light client protocol such that the block is decomposed into two parts: (a) a block header showing metadata about which of the watchdog communications (i.e., watchdog messages and responses to watchdog messages) were committed to the block; and (b) a transaction tree containing the actual data for the committed watchdog communications in the block. For this embodiment, the block header may include at least one of: (i) a hash of the block header of the previous block; (ii) a Merkle root of the transaction tree; (iii) a proof of work-once usage; (iv) a timestamp associated with a committed watchdog communication in the block; (v) a Merkle root for verifying the presence of a committed watchdog communication in the block; or (vi) a Merkle root for verifying which of the client devices 102A-N and / or the watchdog devices 104A-N generated the committed watchdog communication. For this embodiment, the client devices 102A-N and / or the watchdog devices 104A-N with the ledger 103 may use the block header to keep track of the entire ledger 103 and request the transaction tree of a particular block only when a processing operation needs to be performed on the ledger 103 (e.g., adding a new block to the ledger 103, etc.). For yet another embodiment, the ledger 103 may be made more resource efficient by being based on epoch slasher technology associated with the light client protocol for the Ethereum blockchain.

[0038] In some instances, a blockchain synchronization algorithm is required to maintain the ledger 103 across client devices 102A-N and / or watchdog devices 104A-N. Here, the blockchain synchronization algorithm enables nodes of the computer system 100 (e.g., one or more of the client devices 102A-N and / or watchdog devices 104A-N) to perform a process of adding transactions to the ledger 103 and reaching consensus on the contents of the ledger 103. The blockchain synchronization algorithm allows one or more of the client devices 102A-N and / or watchdog devices 104A-N using the ledger 103 as a blockchain to distinguish legitimate transactions (i.e., watchdog communications consisting of a watchdog message and its response) from attempts to compromise or include false / erroneous / flawed information in the computer system 100 by an attacker (e.g., a man-in-the-middle attack, etc.).

[0039] Execution of the blockchain synchronization algorithm is designed to be resource intensive so that individual blocks of the ledger 103 must contain proofs to be considered valid. Examples of proofs include, but are not limited to, proof of work and proof of stake. The proof of each block is verified by the client device 102A-N and / or the watchdog device 104A-N when it receives the block. In this way, the blockchain synchronization algorithm helps to allow the client devices 102A-N and / or the watchdog devices 104A-N to reach a secure, tamper-proof consensus. For one embodiment, the blockchain synchronization algorithm is embedded in the computer system 100 and is executed by at least one of the client devices 102A-N and / or the watchdog devices 104A-N. For example, one or more of the client devices 102A-N and / or the watchdog devices 104A-N may include an FPGA or other type of processor dedicated to executing and implementing the blockchain synchronization algorithm. For this example, the FPGA or other type of processor generates proofs of blocks to be included in the ledger 103. In addition, and for this example, blocks are added to the ledger 103 only through validation and consensus (as described above). The blockchain synchronization algorithm can be performed by: (i) any one of the client devices 102A-N and / or the watchdog devices 104A-N; or (ii) multiple devices 102A-N and / or watchdog devices 104A-N. For further embodiments, the proof of generating a new block is performed in response to automatically determining the complexity of the operation given the availability of resources in the computer system 100. In this way, the resources of the computer system 100 can be more efficiently utilized.

[0040] For another embodiment, the blockchain synchronization algorithm is performed outside of the computer system 100, for example, by a synchronization device (not shown). The synchronization device can be paired with one or more of the client devices 102A-N and / or the watchdog devices 104A-N having the ledger 103. For example, one or more of the client devices 102A-N can be paired with a synchronization device outside of the system 100 via (multiple) networks 105. For this example, the synchronization device includes electronic components similar to components 130A-N (described above). In addition, and for this example, each transaction is transmitted to the synchronization device via (multiple) networks 105 using one or more secure communication techniques. Here, the synchronization device generates and transmits the proofs required for verification and consensus back to the system 100. For one embodiment, each transaction includes one or more of the following: (i) a watchdog message; (ii) a record of watchdog messages that have been sent or received; (iii) a response to a watchdog message; and (iv) a record of responses to watchdog messages that have been sent or received.

[0041] For yet another embodiment, the ledger 103 may be maintained across the system 100 without using a blockchain synchronization algorithm. As a first example, the ledger 103 may be implemented as a distributed database. For a second example, the ledger 103 may be maintained across the system 100 such as a distributed version control system (DVCS), which is sometimes also referred to as a distributed revision control system (DVRS). Examples of DVCS include, but are not limited to, ArX, BitKeeper, Codeville, Darcs, DCVS, Fossil, Git, and Veracity.

[0042] The ledger 103 may also be implemented as a combination of the immediately preceding embodiments. For one embodiment, the ledger 103 is implemented using a blockchain synchronization algorithm in response to determining that the resources of the system 100 are sufficient for a resource-intensive synchronization process. For this embodiment, the ledger 103 is implemented without using a blockchain synchronization algorithm in response to determining that the resources of the system 100 are insufficient for the synchronization process.

[0043] Enabling the client devices 102A-N and / or enabling the watchdog devices 104A-N to record watchdog communications (e.g., watchdog messages, responses to watchdog messages, etc.) to the ledger 103 can be based on an enhanced privacy identification (EPID) protocol, such as a zero-knowledge proof protocol. For embodiments based on a zero-knowledge proof protocol, one or more of the client devices 102A-N and / or the watchdog devices 104A-N (e.g., device 102A, device 104A, etc.) serve as a validator that determines whether other devices in the client devices 102A-N and / or the watchdog devices 104A-N are members of a group of devices that have been granted the privilege of having their actions processed and added to the blockchain represented as the ledger 103. For this embodiment, each of the client devices 102A-N and / or watchdog devices 104A-N that has privileged access to the ledger 103 cryptographically binds its corresponding public key to the zero-knowledge proof sent to the validator, resulting in the public key being identified as an identity that has obtained permission to perform actions on the blockchain represented as the ledger 103. For one embodiment, the client device(s) 102A-N and / or watchdog device(s) 104A-N acting as validators add the verified public key to the ledger 103. Thus, the ledger 103 can maintain its own list of client devices 102A-N and / or watchdog devices 104A-N that are able to interact with the ledger 103. In this way, the client device(s) 102A-N and / or watchdog device(s) 104A-N acting as validators ensure that any of the devices 102A-N and / or watchdog devices 104A-N that write to the ledger 103 are authorized to do so.

[0044] To aid in security, and for one embodiment, the ledger 103 may be accessible to the watchdog device(s) 104A-N only via public key cryptography. Here, the public key associated with the ledger 103 may be distributed to the watchdog device(s) 104A-N on an as-needed basis using a private key associated with the ledger 103, the private key associated with the ledger 103 being known only to the users of the client devices 102A-N. In this manner, the public key cryptography may be used for two functions: (i) using the public key to authenticate that a watchdog message originates from one of the watchdog devices 104A-N that is the holder of the paired private key; or (ii) using the public key to encrypt a watchdog message provided by one of the watchdog devices 104A-N to ensure that only the client device 102A-N that is the holder of the paired private key can decrypt and respond to the watchdog message. For example, and for one embodiment, the watchdog device 104A cannot submit watchdog communications (e.g., watchdog messages, responses to watchdog messages, etc.) to the ledger 103 unless the watchdog device 104A is granted access to the ledger 103 via public key cryptography and / or unless the watchdog entity 104A has been authenticated via the zero proof protocol described above. While the public key may be publicly available to the watchdog devices 104A-N, the private key and / or prior authentication via the zero proof protocol is necessary to submit the watchdog communications (e.g., watchdog messages, responses to watchdog messages, etc.) to the ledger 103. For this example, the private key may be provided to the watchdog device 104A by the logic / module 101 of the client device 102A via the network(s) 105 in response to input provided to the client device 102A by a user. A combination of public key cryptography and / or authentication via a zero proof protocol enables the watchdog device 104A to submit watchdog communications (e.g., watchdog messages, responses to watchdog messages, etc.) to the ledger 103. As shown in the immediately preceding example, only the users of the client devices 102A-N can provide the watchdog devices 104A-N with access to the ledger 103. This has the advantage of minimizing or eliminating the risk of security breaches (e.g., man-in-the-middle attacks, eavesdropping, unauthorized data modification, denial of service attacks, sniffer attacks, identity spoofing, etc.) because the user always knows which of the watchdog devices 104A-N have been granted access to their devices 102A-N via the ledger 103. For one embodiment, the private key may include information granting access to the ledger 103 to the watchdog devices 104A-N for a limited period of time (e.g., 10 minutes, 1 hour, any other period of time, etc.). Thus, security is further enhanced by preventing the watchdog device(s) 104A-N from having unfettered access to the devices 102A-N and / or the ledger 103 .

[0045] One feature of the distributed ledger 103 based on blockchain technology is the ability to resolve forks caused by devices 102A-N and / or watchdog devices 104A-N with access to the ledger 103 attempting to add blocks to the end of the chain by discovering the number of one-time uses that produce a valid hash for a given block of data. A fork is created in the chain when two blocks are found to both claim to reference the same previous block. Some of the devices 102A-N and / or watchdog devices 104A-N in the system 100 will attempt to discover the next block on one end of the fork, while other devices in the devices 102A-N and / or watchdog devices 104A-N will work from the other end of the fork. Eventually, one of the forks will surpass the other in length, and the longest chain will be accepted as the valid chain by consensus. This is typically achieved using a consensus algorithm or protocol. Therefore, an intruder attempting to change a block must not only rediscover a valid hash for each subsequent block, but must also do it faster than everyone else working on the currently accepted chain. Thus, after a certain number of blocks have been linked to a particular block, proving that the contents of the block are false becomes a resource intensive task, which helps minimize or eliminate security vulnerabilities. For one embodiment, this ability to resolve forks can be used to perform rollback operations necessary to handle one or more faulty computer programs.

[0046] Detecting defects in the configuration of a computer program may occur due to an audit, demonstration, or other investigation of the configuration installed on the client device 102A-N. The investigation may include, but is not limited to, an investigation performed based on information recorded in the ledger 103. One or more logic / modules 101 may use one or more software configuration management (SCM) techniques to detect defects in the computer program installed on the client device 102A-N. An example of an SCM technique is a watchdog timing technique and / or a heartbeat timing technique, which can be used to detect defects caused by the computer program installed on the client device 102A-N. The watchdog timing technique includes, for example, the client device 102A periodically resetting a timer before the timer expires to indicate that there is no error in the operation of the device 102A. When the client device 102A does not reset its timer, it is assumed that the operation of the device 102A is defective. Therefore, when the one or more logic / modules 101 determine that the client device 102A fails to reset its timer during the execution of the computer program, the one or more logic / modules 101 can detect a defect in the computer program installed on the client device 102A. The heartbeat timing technique generally includes the client device 102A sending a heartbeat signal with a payload to another device (e.g., any of the watchdog devices 104, etc.) in the computer system (e.g., system 100, etc.) to indicate that the device 102A is operating correctly. Therefore, when the one or more logic / modules 101 determine that the client device 102A fails to send its heartbeat signal on time during the execution of the installed computer program by the client device 102A, the one or more logic / modules 101 can detect a defect in the computer program installed on the client device 102A. The watchdog timing technique and / or the heartbeat timing technique can be implemented in a processor (e.g., a fault-tolerant microprocessor, etc.) of the client device 102A. For another example of SCM techniques, exception handling techniques (e.g., language-level features, checking of error codes, etc.) can be used by the logic / module 101 to determine that the computer program installed on the client device 102A is defective. For a specific example of an exception handling technique applied when a client device 102A includes or executes a script, the one or more logic / modules 101 may determine that the computer program installed on the client device 102A is defective when the one or more logic / modules 101 determine that the client device 102A fails to output or return a result message (e.g., an exit status message, a result value, etc.) to indicate that the script has been successfully run or executed during execution of the installed computer program by the client device 102A. The one or more logic / modules 101 may request the result message from the processor(s) of the client device 102A that runs or executes the script.In response to detecting a defective computer program, at least one of the logic / modules 101 may initiate execution of a rollback operation to return the computer program to a previous state - that is, to return the computer program from the bad state to the correctly functioning state recorded in the blocks of the ledger 103. This is important in situations where the actual effect of an update may be unknown or conjectured, which may result in the computer program being in an inconsistent state.

[0047] For one embodiment, the operations performed in the immediately preceding paragraph are performed in response to one or more logic / modules 101 checking the ledger 103 to determine that a client device (e.g., client device 102A, etc.) has failed to respond to a watchdog message or has failed to send a watchdog response message within a predetermined amount of time. For another embodiment, the logic / modules 101 transmit messages to each other to report that a client device (e.g., client device 102A, etc.) has failed to respond to a watchdog message or has failed to send a watchdog response message within a predetermined amount of time. When the logic / module 101 of an erroneous client device (e.g., client device 102A, etc.) receives a message reporting the erroneous device, the logic / module 101 of the erroneous client device can initiate one or more software recovery services 199.

[0048] Figure 2 is a sequence diagram illustrating a technique 200 for performing software recovery on a computer program installed on a programmable device 102A as part of a computer system (e.g., system 100) composed of interconnected programmable devices according to one embodiment. The technique 200 may be combined with the above Figure 1 One or more elements of the system 100 described herein may perform, for example, implementing a self-contained logic / module (e.g., Figure 1 The technology 200 includes the above combined Figure 1 Some elements of the system 100 are described. For simplicity, some of these elements are not described again.

[0049] exist Figure 2 , a more detailed version of client device 102A is shown. Figure 1 Any of the client devices 102A-N in the Figure 2 The client device 102A in is the same or similar. Figure 2The client device 102A shown includes a self-contained logic / module 101, an auxiliary power supply 205 for powering the logic / module 101 independently of the other component(s) 130A of the client device 102A, one or more computer programs 206 installed on the client device 102A, a copy image 207 of the computer program(s) (which is a copy of the computer program(s) 206), and the component(s) 130A (in combination with the above) Figure 1 described).

[0050] The technique 200 begins at operation 210, where the watchdog device 104A sends a first watchdog message to the client device 102A. One embodiment of the technique 200 may optionally include operation 217, which includes the watchdog device 104A submitting a record that the first watchdog message was sent to the distributed ledger 103. Next, at operation 211, the self-reliant logic / module 101 in the client device 102A may respond to the first watchdog message within a predetermined time period to indicate that the (multiple) computer programs 206 are operating without any problems (i.e., as expected). As shown, operations 212A-B include a record of a successful response to the first watchdog message being submitted to the ledger 103. Operation 212A may be performed by the watchdog device 104A, and operation 212B may be performed by the self-reliant logic / module 101 of the client device 102A. For one embodiment, only one of operations 212A-B is performed. For another embodiment, both operations 212A-B are performed.

[0051] The technique 200 also includes an operation 213, in which the watchdog device 104A transmits the second watchdog message to the independent logic / module 101 of the client device 102A. An embodiment of the technique 200 may optionally include an operation 218, which includes the watchdog device 104A submitting a record that the second watchdog message was sent to the distributed ledger 103. Figure 2As shown, the self-reliant logic / module 101 fails to respond to the second watchdog message within a second predetermined time period, the second predetermined time period being substantially equal to or equal to the first predetermined time period described above in conjunction with operation 211. The failure may indicate that the computer program(s) 206 are not executing correctly (i.e., as expected), and / or the client device 102A may have failed due to an erroneous computer program(s) 206. In response to the self-reliant logic / module 101 failing to respond to the second watchdog message, the technique 200 proceeds to operations 214A-B. As shown, operations 214A-B include a record of an unsuccessful response to the second watchdog message being submitted to the ledger 103. Operation 214A may be performed by the watchdog device 104A, and operation 214B may be performed by the self-reliant logic / module 101 of the client device 102A. For one embodiment, only one of operations 214A-B is performed. For another embodiment, both operations 214A-B are performed.

[0052] Next, the technique 200 proceeds to operation 215, where the self-supporting logic / module 101 of the client device 102A detects that the computer program(s) 206 have an error or failure. This detection may be performed in response to the self-supporting logic / module 101 performing operation 214B. Alternatively or additionally, the detection may be performed in response to the self-supporting logic / module 101 checking the ledger 103 after one or more of operations 214A-B. After operation 215, the technique 200 proceeds to operation 216. Here, the self-supporting logic / module 101 initiates the software recovery service(s) 199, which will be combined with the Figure 3 Give a description.

[0053] Brief reference Figure 3 , Figure 3 Included with Figure 1 and Figure 2 102A; and (ii) service(s) 199 that are (at least partially) external to the client device 102A. An example of a service(s) 199 that is internal to the client device 102A includes the use of the image 207, such as Figure 3, as shown in the service 302 in the replica image. For one embodiment, the service 302 includes an image 207 of (multiple) computer programs 206 used by the logic / module 101 to perform software recovery. For example, the logic / module 101 can automatically replace the faulty (multiple) program 206 with a known good configuration of the (multiple) programs in the image 207. In this way, the self-reliant logic / module 101 can help enable the client device 102A to participate in recovery without user intervention or communication with external types of (multiple) services 199. During execution of the service 302, the self-reliant logic / module responds to any watchdog messages when the faulty (multiple) computer programs are replaced by (multiple) known good computer programs from the replica image. Another example of (multiple) services 199 internal to the client device 102A includes deactivating the client device 102A, such as Figure 3 305 in. Deactivating a device (e.g., client device 102A) includes operatively decoupling the device from a computer system (e.g., system 100, etc.) comprised of a plurality of interconnected programmable devices. An example of a service (s) 199 at least partially external to client device 102A includes transferring one or more operations performed by failed client device 102A to a nearby or available client device within the computer system comprised of interconnected programmable devices, such as Figure 3 Another example of a service 199 located at least partially external to the client device 102A includes dispatching a replacement device or a maintenance entity (e.g., a technician, a drone, a delivery truck, etc.) to the location of the client device 102A to repair and / or replace the client device 102A, such as Figure 3 As shown in the service 304 in FIG. For one embodiment, the above combined Figure 1-3 Any of the service(s) 199 described in one or more of the above may be combined with one or more of the other service(s) 199.

[0054] Reference again Figure 2, the illustrated embodiment of the client device 102A includes an auxiliary power source 205 for powering the logic / module 101 independently of the other component(s) 130A of the client device 102A. For one embodiment, the auxiliary power source 205 is used when, for example, the client device 102A is no longer operable due to an erroneous operation of the computer program(s) 206, when the main power source (not shown) of the client device 102A does not provide power to the client device 102A due to an erroneous operation of the computer program(s) 206, etc. In this way, the auxiliary power source 205 can enable the logic / module 101 to perform the operation 216 (i.e., the activation of the service(s) 199) even when the main power source (not shown) of the client device 102A does not provide power to the client device 102A. The power source 205 can include a capacitor, a battery, a solar cell, a fuel cell, or any other power source capable of being used as an alternative power source. For certain embodiments, the auxiliary power supply 205 may be configured to power one or more tamper-resistant processors used to implement the self-contained logic / module 101 independently of other components of the client device 102A. Figure 1 A tamper-resistant processor is described.

[0055] Reference now Figure 4 , Figure 4 is a flow chart illustrating a technique 400 for performing software recovery on a computer program using a distributed ledger 103 according to one embodiment. The technique 400 may be combined with the above Figure 1 For example, a TEE that implements independent logic / modules (e.g., the TEE described above in conjunction with Figure 1 The technology 400 includes the above combined with the independent logic / module 101 described above. Figure 1-3 For simplicity, some of these elements are not described again.

[0056] When the watchdog devices 104A-B and the client devices 102A-N have a contract to transmit watchdog messages to each other, the self-reliant logic / module (e.g., one or more of the logic / modules 101) of any of the client devices 102A-N can perform technique 400. For one embodiment, each contract can be a smart contract - that is, a state stored in a blockchain represented as a distributed ledger 103 that facilitates, authenticates, and / or enforces the execution of the contract between the watchdog device 104A-B and the client device 102A-N. Therefore, a smart contract is a feature of the ledger 103 as a blockchain that can assist one or more self-reliant logic / modules 101 in locating erroneous or defective computer program(s) installed in one or more of the client devices 102A-N. This is beneficial because the smart contract can enable the ledger 103 to remain stable even when the account maintenance role is transferred or passed between the watchdog devices 104A-B. As described below and in conjunction with Figure 4 The described technique 400 includes one or more examples of smart contracts between the watchdog devices 104A-B and the client devices 102A-N.

[0057] Technique 400 begins at operation 402, where a self-contained logic / module of client device 102A monitors a computer program installed on client device 102A using ledger 103. For one embodiment, as described above in conjunction with Figure 1 The described SCM techniques are used by independent logic / modules to monitor the client device 102A. Additionally or alternatively, operation 402 may include one or more watchdog devices 104A-B sending watchdog communications (e.g., watchdog messages, etc.) to the client device 102A to monitor the operation of the installed computer program on the client device 102A.

[0058] Operation 403 includes the client device 102A generating a watchdog communication (eg, a watchdog response message, etc.) and sending the watchdog communication to one or more watchdog devices 104A-B. For one embodiment, operation 403 is based on Figure 1-3 For another embodiment, operation 403 may be performed with or without receiving any watchdog communications (e.g., watchdog messages, etc.) from the watchdog devices 104A-B. For this embodiment, the client device 102A generates and sends watchdog communications (e.g., watchdog response messages, etc.) according to a predetermined schedule (e.g., every hour, every second, every two days, any time period for scheduling behavior, etc.).

[0059] Technique 400 proceeds to operation 404, where one or more records of watchdog communications are submitted to the distributed ledger 103. For one embodiment, the one or more records include one or more of: (i) a record of sent watchdog response messages, which may be submitted to the ledger 103 by the client device 102A; (ii) a record of received watchdog response messages, which may be submitted to the ledger 103 by one of the watchdog devices 104A-N that received the watchdog response message; (iii) a record of sent watchdog messages, which may be submitted to the ledger 103 by one of the watchdog devices 104A-N that sent the watchdog message; and (iv) a record of received watchdog messages, which may be submitted to the ledger 103 by the client device 102A that received the watchdog message.

[0060] Next, at operation 405, the self-reliant logic / module of the client device 102A may detect whether the client device 102A has failed due to a faulty computer program(s) installed thereon. Local failure detection refers to the self-reliant logic / module of the client device 102A determining that a faulty computer program(s) installed thereon has caused the client device 102A to fail. Local detection is determined, for example, based on checking the ledger 103 and / or based on internal SCM techniques, as described above according to Figure 1-3 If no local failure is detected, the technique 400 proceeds to operation 406, where the self-reliant logic / module of the client device 102A can detect whether any of the other client devices 102B-N in the system 100 have failed due to a faulty computer program(s) installed thereon based on checking the ledger 103. Remote failure detection refers to the self-reliant logic / module of the client device 102A determining whether a faulty computer program(s) installed on one or more other client devices 102B-N has caused these other client devices 102B-N to fail. Remote detection is based on checking the ledger 103. For example, remote detection can be based on the above-described Figure 1-3 If no remote fault is detected, technique 400 returns to operation 402 .

[0061] When a remote fault is detected, the technique 400 proceeds to operation 407. Here, the self-reliant logic / module of the client device 102A sends a fault message to the self-reliant logic / module of the faulty device, which may cause the self-reliant logic / module of the faulty device to trigger software recovery services (multiple), as described below in conjunction with operation 408 (or above in conjunction with operation 409). Figure 1-3In addition, when a local failure is detected or after performing operation 407, the technique 400 proceeds to operation 408. Operation 408 includes the initiation of one or more software recovery services, which is at least combined with the above Figure 3 For one embodiment of technique 400, operation 408 includes operations 409-416.

[0062] Operation 409 includes the independent logic / module of the client device 102A determining whether the defective computer program(s) installed on the client device 102A can be locally recovered using data from the client device 102A. Examples of such data are described above. Figure 2 For an embodiment, operation 409 is performed by a self-contained logic / module of client device 102A that checks client device 102A for a copy image of the program(s) that is the last known good configuration of the installed computer program(s). When the copy image exists, technique 400 moves to operation 413. Here, the self-contained logic / module of client device 102A replaces the defective program(s) with the known good program(s) from the image. For an embodiment, operation 413 is performed at least according to the method described above. Figure 2-3 Alternatively, when the replica image cannot be located by the self-reliant logic / module of the client device 102A, or when the replica image cannot be successfully used to roll back the erroneous program(s), the technique 400 moves to operation 410. Here, a determination is made as to whether the failover device (i.e., one or more of the client devices 102B-N) is able to take over the execution of one or more operations performed by the failed client device 102A. For one embodiment, the self-reliant logic / module of the client device 102 may send a failover message to one or more of the client devices 102B-N in the system 100 that request computing resources for taking over the operations of the client device 102A. In response, the self-reliant logic / module(s) of the client device 102B-N may check the client device 102B-N for the available resources of the client device 102B-N and send a failover response message indicating the availability or lack thereof back to the self-reliant logic / module of the client device 102A. After receiving the failover response message, the self-supporting logic / module of the client device 102A selects one or more client devices with sufficient available resources in the client devices 102B-N as the failover device. Any technology for selecting a failover device can be used. It should be appreciated that "sufficient resources" can vary depending on the operation to be performed. At operation 414, the technology 400 includes configuring (multiple) failover devices to perform the operation of the failed client device 102A.

[0063] When the failover device is not available, the technique 400 proceeds to operation 411. Here, a determination is made as to whether the failed client device 102A is repairable by a repair entity (e.g., a service technician, a drone, etc.) or replaceable by an entity (e.g., a service technician, a drone, a delivery vehicle, etc.). When the failed client device 102A is repairable or replaceable, the technique 400 proceeds to operation 415. Here, the (multiple) self-contained logic / modules of the client device 102A communicate with an appropriate service facility via the (multiple) networks 105 to dispatch the installation of a replacement device or repair of the failed client device 102A. For one embodiment, operation 415 is performed automatically and / or without requiring a user of the client device 102A to initiate communication with an appropriate service facility.

[0064] Technique 400 also includes operation 416, which occurs after performing operations 411 and 413-415. For an embodiment, whether or not operation 415 can be performed, technique 400 proceeds from operation 411 to operation 416. For one embodiment, technique 400 proceeds to operation 416 after the execution of operations 413-415. At operation 416, a determination is made as to whether the failure of the (multiple) programs has been resolved. When the failure has been resolved, technique 400 returns to operation 402 (described above). Alternatively, when the failure has not been resolved, technique 400 proceeds to operation 412. Here, the faulty client device 102A is deactivated. For one embodiment, the self-supporting logic / module of client device 102A deactivates client device 102A. For another embodiment, the self-supporting logic / module of client device 102A communicates via network (multiple) 105 with an appropriate entity (e.g., enterprise IT service facility, etc.) that can perform the deactivation process.

[0065] For one embodiment, the ledger 103 may be generated during operation 402 by creating a genesis block (when the ledger 103 lacks any blocks) or appending a block to an already existing ledger 103. For one embodiment, the standalone logic / module registers the client devices 102A-N and / or the watchdog devices 104A-N with the ledger 103 by submitting to the ledger 103 a record of transmitted watchdog messages and / or a record of transmitted watchdog response messages.

[0066] Figure 5 is a block diagram illustrating a programmable device 500 that can be used to implement the techniques described herein (eg, system 100 and techniques 200 , 300 , and 400 ), according to one or more embodiments. Figure 5The illustrated programmable device 500 is a multi-processor programmable device including a first processing element 570 and a second processing element 580. Although two processing elements 570 and 580 are shown, embodiments of programmable device 500 may also include only one such processing element or include more than two such processing elements.

[0067] Programmable device 500 is shown as a point-to-point interconnect system, where a first processing element 570 and a second processing element 580 are coupled via a point-to-point interconnect 550 . Figure 5 Any or all of the interconnects shown may be implemented as a multi-drop bus rather than a point-to-point interconnect.

[0068] like Figure 5 As shown, each of the processing elements 570 and 580 can be a multi-core processor, including a first processor core and a second processor core (i.e., processor cores 574A and 574B and processor cores 584A and 584B). Such cores 574A, 574B, 584A, 584B can be configured to execute computing instruction codes. However, other embodiments can use processing elements as single-core processors as desired. In embodiments with multiple processing elements 570, 580, each processing element can be implemented using different numbers of cores as desired.

[0069] Each processing element 570, 580 may include at least one shared cache 546. Shared caches 546A, 546B may store data (e.g., computational instructions) used by one or more components of the processing element (e.g., cores 574A, 574B and 584A, 584B), respectively. For example, the shared cache may locally cache data stored in memories 532, 534 for faster access by components of processing elements 570, 580. For one or more embodiments, shared caches 546A, 546B may include one or more mid-level caches, such as a level 2 (L2) cache, a level 3 (L3) cache, a level 4 (L4) cache, or other levels of cache, a last level cache (LLC), or a combination thereof. Memories 532, 534 may include software instructions representing one or more independent logic / modules 101, which include a distributed ledger 103 accessible by each of processing elements 570 and 580. At least in combination with the above Figure 1 , Figure 2 , Figure 3 or Figure 4 Each of the logic / module 101 and the distributed ledger 103 is described.

[0070] Although for the sake of simplicity, Figure 5A programmable device with two processing elements 570, 580 is shown, but the scope of the present invention is not limited thereto, and any number of processing elements may be present. Alternatively, one or more of the processing elements 570, 580 may be an element other than a processor, such as a graphics processing unit (GPU), a digital signal processing (DSP) unit, a field programmable gate array, or any other programmable processing element. The processing element 580 may be heterogeneous or asymmetric with the processing element 570. There are various differences between the processing elements 570, 580 in a range of advantage metrics, including architectural, microarchitectural, thermal, power consumption characteristics, etc. These differences can efficiently present themselves as being asymmetric and heterogeneous among the processing elements 570, 580. In some embodiments, the various processing elements 570, 580 may be located in the same die package.

[0071] First processing element 570 may also include memory controller (MC) logic 572 and point-to-point (PP) interconnects 576 and 578. Similarly, second processing element 580 may include MC 582 and PP interconnects 586 and 588. Figure 5 As shown, MC logic 572 and MC logic 582 couple processing elements 570, 580 to respective memories, namely, memory 532 and memory 534, which may be portions of main memory locally attached to respective processors. Although MC logic 572 and MC logic 582 are shown as being integrated into processing elements 570, 580, in some embodiments, memory controller logic may be discrete logic external to processing elements 570, 580 rather than integrated therein.

[0072] Processing element 570 and processing element 580 may be coupled to I / O subsystem 590 via links 552 and 554 via respective PP interconnects 576 and 586. Figure 5 As shown, I / O subsystem 590 includes PP interconnects 594 and 598. In addition, I / O subsystem 590 includes interface 592 that couples I / O subsystem 590 with high performance graphics engine 538. In one embodiment, a bus (not shown) may be used to couple graphics engine 538 to I / O subsystem 590. Alternatively, a point-to-point interconnect 539 may couple these components.

[0073] In turn, I / O subsystem 590 may be coupled to first link 516 via interface 596. In one embodiment, first link 516 may be a peripheral component interconnect (PCI) bus or a bus such as a PCI Express bus or another I / O interconnect bus, although the scope of the invention is not limited in this regard.

[0074] like Figure 5As shown, various I / O devices 514, 524 can be coupled to the first link 516 together with the bridge 518, and the bridge 518 can couple the first link 516 to the second link 520. In one embodiment, the second link 520 can be a low pin count (LPC) bus. For one embodiment, various devices can be coupled to the second link 520, including, for example, a keyboard / mouse 512, (multiple) communication devices 526 (which can in turn communicate with one or more other programmable devices via one or more networks 505) and a data storage unit 528 such as a disk drive or other mass storage device that can include code 530. The code 530 may include instructions for performing one or more embodiments of the technology described above. In addition, an audio I / O 524 can be coupled to the second link 520.

[0075] Note that other embodiments are contemplated. For example, instead of Figure 5 The system may implement a multi-point bus or another such communication topology. Although links 516 and 520 are Figure 5 is shown as a bus, but any desired type of link may be used. Figure 5 The components can be used instead Figure 5 More or fewer integrated chips are shown for partitioning.

[0076] Figure 6 is a block diagram illustrating a programmable device 600 for use with the techniques described herein, according to another embodiment. Figure 6 Some aspects of Figure 6 Omitted to avoid Figure 6 Other aspects are unclear.

[0077] Figure 6 Processing elements 670, 680 are shown to include integrated memory and / or I / O control logic ("CL") 672 and 682, respectively. In some embodiments, 672, 682 may include memory control logic (MC), for example, in conjunction with the above Figure 6 In addition, the CL 672, 682 may also include I / O control logic. Figure 6 It is shown that not only can the memory 632, 634 be coupled to the CL 672, 682, but also the I / O device 644 can be coupled to the control logic 672, 682. The conventional I / O device 615 can be coupled to the I / O subsystem 690 through the interface 696. Each processing element 670, 680 may include multiple processor cores. Figure 6 674A, 674B, 684A, and 684B. Figure 6As shown, I / O subsystem 690 includes point-to-point (PP) interconnects 694 and 698 connecting PP interconnects 676 and 686 of processing elements 670 and 680 to links 652 and 654. Processing elements 670 and 680 may also be interconnected via link 650 and interconnects 678 and 688, respectively. Memories 632 and 634 may include software instructions representing one or more independent logic / modules 101, including distributed ledger 103 that may be accessed and / or executed by each of processing elements 670 and 680. At least in combination with the above Figure 1 , Figure 2 , Figure 3 or Figure 4 Each of the logic / module 101 and the distributed ledger 103 is described.

[0078] Figure 5 and Figure 6 The programmable device depicted in FIG. 1 is a schematic illustration of an embodiment of a programmable device that can be used to implement the various embodiments discussed herein. Figure 5 and Figure 6 The various components of the programmable device depicted in can be combined in a system-on-chip (SoC) architecture.

[0079] Program instructions can be used to make a general or special processing system programmed with instructions perform the operations described herein. Alternatively, the operation can be performed by a specific hardware component containing hard-wired logic for performing the operation, or by any combination of programmed computer components and custom hardware components. The method described herein can be provided as a computer program product, which may include a machine-readable medium on which instructions that can be used to program a processing system or other device to perform the method are stored. The term "machine-readable medium" used herein should include any medium that can store or encode a sequence of instructions for execution by a machine and cause the machine to perform any of the methods described herein. The term "machine-readable medium" should therefore include, but is not limited to, tangible non-temporary memories, such as solid-state memories, optical disks, and magnetic disks. In addition, it is common in the art to describe software in one form or another (e.g., programs, processes, processes, applications, modules, logic, etc.) as taking actions or causing results. Such an expression is simply a shorthand way of stating that the processing system executes software so that the processor performs actions or produces results.

[0080] At least one embodiment is disclosed, and changes, combinations, and / or modifications to the features of (multiple) embodiments and / or (multiple) embodiments made by ordinary technicians in the field are within the scope of the present disclosure. Alternative embodiments resulting from combining, integrating, and / or omitting the features of (multiple) embodiments are also within the scope of the disclosure. Where a numerical range or limitation is explicitly stated, such an expression range or limitation may be understood to include iterative ranges or limitations of the same magnitude that fall within the explicitly stated range or limitation (e.g., from about 1 to about 10 includes 2, 3, 4, etc.; greater than 0.10 includes 0.11, 0.12, 0.13, etc.). Unless otherwise stated, the use of the term "approximately" means ±10% of the subsequent number.

[0081] Use of the term "optionally" with respect to any element of a claim means that the element is required, or alternatively the element is not required, both alternatives being within the scope of the claim. Use of broader terms such as comprising, including, and having may be understood to provide support for narrower terms such as consisting of, consisting essentially of, and consisting generally of. Accordingly, the scope of protection is not limited by the description set forth above, but rather by the appended claims, which scope includes all equivalents of the subject matter of the claims. Each and every claim is incorporated into the description as additional disclosure and the claims are (multiple) embodiments of the present disclosure.

[0082] The following examples relate to further embodiments.

[0083] Example 1 includes a machine-readable medium storing instructions for recovering a program installed on a client device, including instructions that, when executed, cause a watchdog device to: send a request to a client device for an indication of an expected operation of a program installed on the client device; in response to receiving a response to the request from the client device within a predetermined time period, submitting a first record to a distributed ledger on a plurality of interconnected devices, the client device and the watchdog device being among the plurality of interconnected devices; in response to not receiving a response to the request within a predetermined time period, submitting a second record to the distributed ledger; and in response to submitting the second record, initiating a software recovery service for the client device.

[0084] In Example 2, the subject matter of Example 1 can optionally include that the instructions further include instructions that, when executed, cause the watchdog device to submit a request to the distributed ledger.

[0085] In Example 3, the subject matter of claim 1 or 2 may optionally include that the software recovery service for the client device includes one or more of the following: a first software recovery service, which includes replacing the program using a known configuration of the program stored in the image; a second software recovery service, which includes transferring one or more operations performed by the client device to a second client device, the second client device being one of a plurality of interconnected devices; a third software recovery service, which includes deactivating the client device; and a fourth software recovery service, which includes dispatching a replacement device for replacing the client device or a repair entity for repairing the client device.

[0086] In Example 4, the subject matter of claim 1, 2, or 3 can optionally include the distributed ledger storing a record of a successful response and an indication of a failure to respond in separate blocks of the blockchain.

[0087] In Example 5, the subject matter of claim 1, 2, 3, or 4 can optionally include that each sent response is generated according to a predetermined schedule.

[0088] In Example 6, the subject matter of claim 1, 2, 3, 4, or 5 can optionally include that the watchdog device includes at least one tamper-resistant processor that is used to execute at least some of the instructions in a secure environment to minimize or prevent security vulnerabilities.

[0089] In Example 7, the subject matter of claim 1, 2, 3, 4, 5, or 6 can optionally include that the instructions further include instructions that when executed cause the watchdog device to perform the following operations: determine that the program is faulty based on the distributed ledger.

[0090] Example 8 includes a method for recovering a program installed on a client device, the method comprising: sending a request to the client device and by a watchdog device for an indication of expected operation of the program installed on the client device; in response to receiving a response to the request from the client device within a predetermined time period, submitting a first record to a distributed ledger on a plurality of interconnected devices, the client device and the watchdog device being among the plurality of interconnected devices; in response to not receiving a response to the request within the predetermined time period, submitting a second record to the distributed ledger; and in response to submitting the second record, initiating a software recovery service for the client device.

[0091] In Example 9, the subject matter of claim 8 can optionally include that the method further comprises submitting the request to the distributed ledger.

[0092] In Example 10, the subject matter of claim 8 or 9 may optionally include that the software recovery service for the client device includes one or more of the following: a first software recovery service, which includes replacing the program using a known configuration of the program stored in the image; a second software recovery service, which includes transferring one or more operations performed by the client device to a second client device, the second client device being one of a plurality of interconnected devices; a third software recovery service, which includes deactivating the client device; and a fourth software recovery service, which includes dispatching a replacement device for replacing the client device or a repair entity for repairing the client device.

[0093] In Example 11, the subject matter of claim 8, 9, or 10 can optionally include the distributed ledger storing a record of a successful response and an indication of a failure to respond in separate blocks of the blockchain.

[0094] In Example 12, the subject matter of claim 8, 9, 10, or 11 can optionally include that each sent response is generated according to a predetermined schedule.

[0095] In Example 13, the subject matter of claim 8, 9, 10, 11, or 12 can optionally include that the method further comprises determining that the program is faulty based on the distributed ledger.

[0096] Example 14 includes a watchdog device for recovering a program installed on a client device, the watchdog device comprising: one or more processors; and a memory coupled to the one or more processors and storing instructions, including instructions that, when executed, cause the one or more processors to perform the following operations: sending a request to a client device for an indication of an expected operation of a program installed on the client device; in response to receiving a response to the request from the client device within a predetermined time period, submitting a first record to a distributed ledger on a plurality of interconnected devices, the client device and the watchdog device being among the plurality of interconnected devices; in response to not receiving a response to the request within a predetermined time period, submitting a second record to the distributed ledger; and in response to submitting the second record, initiating a software recovery service for the client device.

[0097] In example 15, the subject matter of claim 14 can optionally include that the instructions further include instructions that when executed cause the one or more processors to submit the request to the distributed ledger.

[0098] In Example 16, the subject matter of claim 14 or 15 may optionally include that the software recovery service for the client device includes one or more of the following: a first software recovery service, which includes replacing the program using a known configuration of the program stored in the image; a second software recovery service, which includes transferring one or more operations performed by the client device to a second client device, the second client device being one of a plurality of interconnected devices; a third software recovery service, which includes deactivating the client device; and a fourth software recovery service, which includes dispatching a replacement device for replacing the client device or a repair entity for repairing the client device.

[0099] In Example 17, the subject matter of claim 14, 15, or 16 can optionally include the distributed ledger storing a record of a successful response and an indication of a failure to respond in separate blocks of the blockchain.

[0100] In Example 18, the subject matter of claim 14, 15, 16, or 17 can optionally include that each sent response is generated according to a predetermined schedule.

[0101] In Example 19, the subject matter of claim 14, 15, 16, 17, or 18 can optionally include that the one or more processors include at least one tamper-resistant processor that is used to execute at least some of the instructions in a secure environment to minimize or prevent security vulnerabilities.

[0102] In Example 20, the subject matter of claim 14, 15, 16, 17, 18, or 19 can optionally include that the instructions further include instructions that, when executed, cause the one or more processors to determine that the program has an error based on the distributed ledger.

[0103] Example 21 includes a machine-readable medium storing instructions for recovering a program installed on a client device, including instructions that, when executed, cause the client device to perform the following operations: sending a message to a watchdog device indicating an expected operation of a program installed on the client device; in response to sending the message to the watchdog device within a predetermined time period, submitting a first record to a distributed ledger on a plurality of interconnected devices, the client device and the watchdog device being among the plurality of interconnected devices; in response to not sending the message to the watchdog device within the predetermined time period, submitting a second record to the distributed ledger; and in response to submitting the second record, initiating a software recovery service for the client device.

[0104] Example 22 includes a method for recovering a program installed on a client device, the method comprising: sending, by a client device and to a watchdog device, a message indicating an expected operation of a program installed on the client device; in response to sending the message to the watchdog device within a predetermined time period, submitting a first record to a distributed ledger on a plurality of interconnected devices, the client device and the watchdog device being among the plurality of interconnected devices; in response to not sending the message to the watchdog device within the predetermined time period, submitting a second record to the distributed ledger; and in response to submitting the second record, initiating a software recovery service for the client device.

[0105] Example 23 includes a client device for recovering an installed program, comprising: one or more processors; and a memory coupled to the one or more processors and storing instructions, wherein the instructions include instructions that, when executed, cause at least some of the one or more processors to perform the following operations: sending a message to a watchdog device indicating an expected operation of a program installed on the client device; in response to sending the message to the watchdog device within a predetermined time period, submitting a first record to a distributed ledger on a plurality of interconnected devices, the client device and the watchdog device being among the plurality of interconnected devices; in response to not sending the message to the watchdog device within the predetermined time period, submitting a second record to the distributed ledger; and in response to submitting the second record, initiating a software recovery service for the client device.

[0106] In Example 24, the subject matter of claim 23 can optionally include that the one or more processors include at least one tamper-resistant processor that is configured to execute at least some of the instructions in a secure environment to minimize or prevent security vulnerabilities.

[0107] In Example 25, the subject matter of claim 23 or 24 can optionally include that the client device further comprises: an auxiliary power supply configured to power the tamper-resistant processor independently of other components of the client device.

[0108] It should be understood that the above description is intended to be illustrative rather than restrictive. For example, the above embodiments can be used in combination with each other. After reviewing the above description, many other embodiments will be apparent to those skilled in the art. Therefore, the scope of the present invention should be determined with reference to the complete scope of the equivalent content of the attached claims and these claims being given rights.

[0109] References to blockchain technology, such as Ethereum and Bitcoin, are made in this document. ETHEREUM may be a trademark of the Ethereum Foundation (Stiftung Ethereum). BITCOIN may be a trademark of the Bitcoin Foundation. These marks and any other marks mentioned herein may be common law or registered trademarks of third parties, whether affiliated or unaffiliated with the applicant or the assignee. The use of these marks is by way of example only and should not be construed as descriptive or to limit the scope of the embodiments described herein to only the materials associated with these marks.

Claims

1. A machine-readable medium storing instructions for recovering a program installed on a client device, comprising instructions that, when executed, cause a watchdog device to perform the following operations: sending a request to the client device for an indication of an intended operation of a program installed on the client device; In response to receiving a response to the request from the client device within a predetermined time period, submitting a first record to a distributed ledger on a plurality of interconnected devices, the client device and the watchdog device being among the plurality of interconnected devices; In response to not receiving a response to the request within the predetermined time period, submitting a second record to the distributed ledger; as well as In response to submitting the second record, a software recovery service for the client device is initiated.

2. The machine-readable medium of claim 1, wherein: The instructions also include instructions that, when executed, cause the watchdog device to submit the request to the distributed ledger.

3. The machine-readable medium of claim 1, wherein: The software recovery service for the client device includes one or more of the following: a first software recovery service comprising replacing said program with a known configuration of said program stored in an image; a second software recovery service comprising transferring one or more operations performed by the client device to a second client device, the second client device being one of the plurality of interconnected devices; A third software recovery service includes deactivating the client device; as well as A fourth software recovery service includes dispatching a replacement device for replacing the client device or a maintenance entity for repairing the client device.

4. The machine-readable medium of claim 1, wherein: The distributed ledger stores records of successful responses and indications of failed responses in separate blocks of the blockchain.

5. The machine-readable medium of claim 4, wherein: Each sent response is generated according to a predetermined schedule.

6. The machine-readable medium of claim 1, wherein: The watchdog device includes at least one tamper-resistant processor for executing at least some of the instructions in a secure environment to minimize or prevent security breaches.

7. The machine-readable medium of claim 1, wherein: The instructions also include instructions that, when executed, cause the watchdog device to perform the following operations: The program is determined to be faulty based on the distributed ledger.

8. A method for restoring a program installed on a client device, the method comprising: sending, to the client device and by a watchdog device, a request for an indication of an intended operation of a program installed on the client device; In response to receiving a response to the request from the client device within a predetermined time period, submitting a first record to a distributed ledger on a plurality of interconnected devices, the client device and the watchdog device being among the plurality of interconnected devices; In response to not receiving a response to the request within the predetermined time period, submitting a second record to the distributed ledger; as well as In response to submitting the second record, a software recovery service for the client device is initiated.

9. The method of claim 8, further comprising submitting the request to the distributed ledger.

10. The method according to claim 8, wherein: The software recovery service for the client device includes one or more of the following: a first software recovery service comprising replacing said program with a known configuration of said program stored in an image; a second software recovery service comprising transferring one or more operations performed by the client device to a second client device, the second client device being one of the plurality of interconnected devices; A third software recovery service includes deactivating the client device; as well as A fourth software recovery service includes dispatching a replacement device for replacing the client device or a maintenance entity for repairing the client device.

11. The method according to claim 8, wherein: The distributed ledger stores records of successful responses and indications of failed responses in separate blocks of the blockchain.

12. The method according to claim 11, wherein: Each sent response is generated according to a predetermined schedule.

13. The method of claim 8, further comprising determining that the program is faulty based on the distributed ledger.

14. A watchdog device for recovering a program installed on a client device, the watchdog device comprising: one or more processors; as well as A memory coupled to the one or more processors and storing instructions, including instructions that, when executed, cause the one or more processors to: sending a request to the client device for an indication of an intended operation of a program installed on the client device; In response to receiving a response to the request from the client device within a predetermined time period, submitting a first record to a distributed ledger on a plurality of interconnected devices, the client device and the watchdog device being among the plurality of interconnected devices; In response to not receiving a response to the request within the predetermined time period, submitting a second record to the distributed ledger; as well as In response to submitting the second record, a software recovery service for the client device is initiated.

15. The watchdog device according to claim 14, wherein: The instructions also include instructions that, when executed, cause the one or more processors to submit the request to the distributed ledger.

16. The watchdog device according to claim 14, wherein: The software recovery service for the client device includes one or more of the following: a first software recovery service comprising replacing said program with a known configuration of said program stored in an image; a second software recovery service comprising transferring one or more operations performed by the client device to a second client device, the second client device being one of the plurality of interconnected devices; A third software recovery service includes deactivating the client device; as well as A fourth software recovery service includes dispatching a replacement device for replacing the client device or a maintenance entity for repairing the client device.

17. The watchdog device according to claim 14, wherein: The distributed ledger stores records of successful responses and indications of failed responses in separate blocks of the blockchain.

18. The watchdog device according to claim 17, wherein: Each sent response is generated according to a predetermined schedule.

19. The watchdog device according to claim 14, wherein: The one or more processors include at least one tamper-resistant processor for executing at least some of the instructions in a secure environment to minimize or prevent security breaches.

20. The watchdog device according to claim 14, wherein: The instructions also include instructions that, when executed, cause the one or more processors to determine that the program is faulty based on the distributed ledger.

21. A machine-readable medium storing instructions for restoring a program installed on a client device, comprising instructions that, when executed, cause the client device to: sending a message to a watchdog device indicating an intended operation of a program installed on the client device; In response to sending the message to the watchdog device within a predetermined time period, submitting a first record to a distributed ledger on a plurality of interconnected devices, the client device and the watchdog device being among the plurality of interconnected devices; in response to not sending the message to the watchdog device within the predetermined time period, submitting a second record to the distributed ledger; as well as In response to submitting the second record, a software recovery service for the client device is initiated.

22. A method for restoring a program installed on a client device, the method comprising: sending, by the client device and to a watchdog device, a message indicating an intended operation of a program installed on the client device; In response to sending the message to the watchdog device within a predetermined time period, submitting a first record to a distributed ledger on a plurality of interconnected devices, the client device and the watchdog device being among the plurality of interconnected devices; in response to not sending the message to the watchdog device within the predetermined time period, submitting a second record to the distributed ledger; as well as In response to submitting the second record, a software recovery service for the client device is initiated.

23. A client device for restoring an installed program, comprising: one or more processors; as well as A memory coupled to the one or more processors and storing instructions, wherein the instructions include instructions that, when executed, cause at least some of the one or more processors to: sending a message to a watchdog device indicating an intended operation of a program installed on the client device; In response to sending the message to the watchdog device within a predetermined time period, submitting a first record to a distributed ledger on a plurality of interconnected devices, the client device and the watchdog device being among the plurality of interconnected devices; In response to not sending the message to the watchdog device within the predetermined time period, submitting a second record to the distributed ledger; and In response to submitting the second record, a software recovery service for the client device is initiated.

24. The client device of claim 23, wherein: The one or more processors include at least one tamper-resistant processor for executing at least some of the instructions in a secure environment to minimize or prevent security breaches.

25. The client device of claim 24, wherein: The client device further comprises: An auxiliary power supply is configured to power the tamper-resistant processor independently of other components of the client device.

Images