Method for integrating blockchain node compliance data within blockchain transaction data

Implementations provide a computer-implemented method that includes: accessing, by a node of a blockchain network, a first set of data encoding a set of transaction records, wherein the blockchain network comprises a plurality of consensus nodes; at least based on the first set of data, generating, by the node, a transaction hash for the set of transaction; accessing a second set of data encoding a compliance status of the node of the blockchain network; at least based on the second set of data; generating, by the node, a compliance hash for the node of blockchain network; generating, by the node, a root hash that combines the transaction hash and the compliance hash; and submitting, by the node and to the plurality of consensus nodes of the blockchain network, a block that includes the root hash for entry into the blockchain.

TECHNICAL FIELD

This disclosure generally relates to large block chain networks involving a large number of nodes, including consensus nodes.

BACKGROUND

Distributed ledger systems (DLSs), which can also be referred to as consensus networks, and/or blockchain networks, enable participating entities to securely, and immutably store data. DLSs are commonly referred to as blockchain networks without referencing any particular user case. Examples of types of blockchain networks can include public blockchain networks, private blockchain networks, and consortium blockchain networks. A consortium blockchain network is provided for a select group of entities, which control the consensus process, and includes an access control layer.

SUMMARY

In one aspect, some implementations provide a computer-implemented method to enforce trustworthiness of nodes on a blockchain network hosting a blockchain, the method comprising: accessing, by a node of the blockchain network, a first set of data encoding a set of transaction records, wherein the blockchain network comprises a plurality of consensus nodes; at least based on the first set of data, generating, by the node, a transaction hash for the set of transaction records; accessing a second set of data encoding a compliance status of the node of the blockchain network; at least based on the second set of data, generating, by the node, a compliance hash for the node of blockchain network; generating, by the node, a root hash that combines the transaction hash and the compliance hash; and submitting, by the node and to the plurality of consensus nodes of the blockchain network, a block that includes the root hash for entry into the blockchain.

The compliance status of the node may be provided by at least one of: an integrity check of the node's hard disk drives, an integrity check of the node's file system, or an integrity check of a database file on the node. The transaction may include at least one smart contract, which, when executed on an Ethereum Virtual Machine (EVM), causes the EVA/I's hosting node to perform a function. The function may include generating a compliance status of the hosting node by generating at least one of: an integrity check of the hosting node's hard disk drives, an integrity check of the hosting node's file system, or an integrity check of a database file on the hosting node.

Generating the root hash may include applying a hashing function using a nonce such that the root hash leads with at least a pre-determined number of zeros. Applying a hashing function may include: applying a secure hash algorithm (SHA)-256. The block being submitted may further include the nonce such that the consensus nodes determine the encoded transaction hash and compliance hash are valid before entering the block into the blockchain. The node may be a consensus node, and wherein the root hash may be a Merkel root hash.

In another aspect, some implementations may provide a computer system to enforce trustworthiness of nodes on a blockchain network hosting a blockchain, the computer system residing on a node of the blockchain network and comprising at least one processor configured to perform operations of: accessing, by a node of the blockchain network, a first set of data encoding a set of transaction records, wherein the blockchain network comprises a plurality of consensus nodes; at least based on the first set of data, generating, by the node, a transaction hash for the set of transaction records; accessing a second set of data encoding a compliance status of the node of the blockchain network; at least based on the second set of data, generating, by the node, a compliance hash for the node of blockchain network; generating, by the node, a root hash that combines the transaction hash and the compliance hash; and submitting, by the node and to the plurality of consensus nodes of the blockchain network, a block that includes the root hash for entry into the blockchain.

The compliance status of the node may be provided by at least one of: an integrity check of the node's hard disk drives, an integrity check of the node's file system, or an integrity check of a database file on the node. The transaction may include at least one smart contract, which, when executed on an Ethereum Virtual Machine (EVM), causes the EVM's hosting node to perform a function. The function may include generating a compliance status of the hosting node by generating at least one of: an integrity check of the hosting node's hard disk drives, an integrity check of the hosting node's file system, or an integrity check of a database file on the hosting node.

Generating the root hash may include applying a hashing function using a nonce such that the root hash leads with at least a pre-determined number of zeros. Applying a hashing function may include: applying a secure hash algorithm (SHA)-256. The block being submitted may further include the nonce such that the consensus nodes determine the encoded transaction hash and compliance hash are valid before entering the block into the blockchain. The node may be a consensus node, and wherein the root hash may be a Merkel root hash.

In yet another aspect, some implementations provide a non-transitory computer-readable medium comprising software to enforce trustworthiness of nodes on a blockchain network hosting a blockchain, which software, when executed by a processor of a node on the blockchain network, causes the processor to perform operations of: accessing, by a node of the blockchain network, a first set of data encoding a set of transaction records, wherein the blockchain network comprises a plurality of consensus nodes; at least based on the first set of data, generating, by the node, a transaction hash for the set of transaction records; accessing a second set of data encoding a compliance status of the node of the blockchain network; at least based on the second set of data, generating, by the node, a compliance hash for the node of blockchain network; generating, by the node, a root hash that combines the transaction hash and the compliance hash; and submitting, by the node and to the plurality of consensus nodes of the blockchain network, a block that includes the root hash for entry into the blockchain.

The compliance status of the node may be provided by at least one of: an integrity check of the node's hard disk drives, an integrity check of the node's file system, or an integrity check of a database file on the node. The transaction may include at least one smart contract, which, when executed on an Ethereum Virtual Machine (EVM), causes the EVM's hosting node to perform a function. The function may include generating a compliance status of the hosting node by generating at least one of: an integrity check of the hosting node's hard disk drives, an integrity check of the hosting node's file system, or an integrity check of a database file on the hosting node.

Generating the root hash may include applying a hashing function using a nonce such that the root hash leads with at least a pre-determined number of zeros. Applying a hashing function may include: applying a secure hash algorithm (SHA)-256. The block being submitted may further include the nonce such that the consensus nodes determine the encoded transaction hash and compliance hash are valid before entering the block into the blockchain. The node may be a consensus node, and wherein the root hash may be a Merkel root hash.

Implementations according to the present disclosure may be realized in computer implemented methods, hardware computing systems, and tangible computer readable media. For example, a system of one or more computers can be configured to perform particular actions by virtue of having software, firmware, hardware, or a combination of them installed on the system that in operation causes or cause the system to perform the actions. One or more computer programs can be configured to perform particular actions by virtue of including instructions that, when executed by data processing apparatus, cause the apparatus to perform the actions.

The details of one or more implementations of the subject matter of this specification are set forth in the description, the claims, and the accompanying drawings. Other features, aspects, and advantages of the subject matter will become apparent from the description, the claims, and the accompanying drawings.

DETAILED DESCRIPTION

The technology relates to integrating Smart Contract functionality within block chain implementations to generate immutable compliance data regarding each node on the blockchain network. This data will then be stored on the blockchain implementation along with transactional data. The compliance data can be queried by consensus nodes of the blockchain network to verify the compliance of a given node to a set of applicable security controls. As the given node deviates from acceptable compliance baselines, the given node's threat level increases, allowing the consensus nodes to apply threat mitigation. If the given node compliance level reaches a threshold condition, the given node may be terminated from the blockchain network and new transactions by the given node can be voided by the consensus process.

Within a blockchain environment, the security of a participating node is paramount to the efficient and secure operation of the blockchain network. Whilst the transactions are vetted using consensus mechanisms, the integrity of each network node itself is subject to traditional cyber security processes that operate outside of blockchain mechanisms. Under the blockchain mechanism, only the submitted “block” or encrypted list of transactions is immutable during the consensus process.

Implementations of the present disclosure aims to introduce specific compliance data into the blockchain network, creating an immutable ledger of node compliance data. This compliance data can be analyzed by the consensus nodes within the blockchain network to determine a level of trust that can be placed on the participating node generating the transaction. This level of trust can then be used as a weighting factor when determining whether a given transaction is coming from a compromised source and can trigger additional actions prior to the submitted data being accepted into the chain.

Referring toFIG.1, a diagram illustrates an example of an environment100that can be used to execute embodiments of this specification. In some examples, the environment100enables entities to participate in a consortium blockchain network102. The environment100includes computing devices106,108, and a network110. In some examples, the network110includes a local area network (LAN), wide area network (WAN), the Internet, or a combination thereof, and connects web sites, user devices (e.g., computing devices), and back-end systems. In some examples, the network110can be accessed over a wired and/or a wireless communications link. In some examples, the network110enables communication with, and within the consortium blockchain network102. In general the network110represents one or more communication networks. In some cases, the computing devices106,108can be nodes of a cloud computing system (not shown), or each computing device106,108can be a separate cloud computing system including a number of computers interconnected by a network and functioning as a distributed processing system.

In the depicted example, the computing systems106,108can each include any appropriate computing system that enables participation as a node in the consortium blockchain network102. Examples of computing devices include, without limitation, a server, a desktop computer, a laptop computer, a tablet computing device, and a smartphone. In some examples, the computing systems106,108host one or more computer-implemented services for interacting with the consortium blockchain network102. For example, the computing system106can host computer-implemented services of a first entity (e.g., user A), such as a transaction management system that the first entity uses to manage its transactions with one or more other entities (e.g., other users). The computing system108can host computer-implemented services of a second entity (e.g., user B), such as a transaction management system that the second entity uses to manage its transactions with one or more other entities (e.g., other users). In the example ofFIG.1, the consortium blockchain network102is represented as a peer-to-peer network of nodes, and the computing systems106,108provide nodes of the first entity, and second entity respectively, which participate in the consortium blockchain network102.

FIG.2depicts an example of an architecture200in accordance with embodiments of this specification. The example conceptual architecture200includes participant systems202,204,206that correspond to Participant A, Participant B, and Participant C, respectively. Each participant (e.g., user, enterprise) participates in a blockchain network212provided as a peer-to-peer network including a plurality of nodes214, at least some of which immutably record information in a blockchain216. Although a single blockchain216is schematically depicted within the blockchain network212, multiple copies of the blockchain216are provided, and are maintained across the blockchain network212, as described in further detail herein.

In the depicted example, each participant system202,204,206is provided by, or on behalf of Participant A, Participant B, and Participant C, respectively, and functions as a respective node214within the blockchain network. As used herein, a node generally refers to an individual system (e.g., computer, server) that is connected to the blockchain network212, and enables a respective participant to participate in the blockchain network. In the example ofFIG.2, a participant corresponds to each node214. It is contemplated, however, that a participant can operate multiple nodes214within the blockchain network212, and/or multiple participants can share a node214. In some examples, the participant systems202,204,206communicate with, or through the blockchain network212using a protocol (e.g., hypertext transfer protocol secure (HTTPS)), and/or using remote procedure calls (RPCs).

Nodes214can have varying degrees of participation within the blockchain network212. For example, some nodes214can participate in the consensus process (e.g., as minder nodes that add blocks to the blockchain216), while other nodes214do not participate in the consensus process. As another example, some nodes214store a complete copy of the blockchain216, while other nodes214only store copies of portions of the blockchain216. For example, data access privileges can limit the blockchain data that a respective participant stores within its respective system. In the example ofFIG.2, the participant systems202,204store respective, complete copies216′,216″ of the blockchain216.

A blockchain (e.g., the blockchain216ofFIG.2) is made up of a chain of blocks, each block storing data. Examples of data include transaction data representative of a transaction between two or more participants. While transactions are used herein by way of non-limiting example, it is contemplated that any appropriate data can be stored in a blockchain (e.g., documents, images, videos, audio). Examples of a transaction can include, without limitation, exchanges of something of value (e.g., assets, products, services, currency). The transaction data is immutably stored within the blockchain. That is, the transaction data cannot be changed.

Before storing in a block, the transaction data is hashed. Hashing is a process of transforming the transaction data (provided as string data) into a fixed-length hash value (also provided as string data). It is not possible to un-hash the hash value to obtain the transaction data. Hashing ensures that even a slight change in the transaction data results in a completely different hash value. Further, and as noted above, the hash value is of fixed length. That is, no matter the size of the transaction data the length of the hash value is fixed. Hashing includes processing the transaction data through a hash function to generate the hash value. An example of a hash function includes, without limitation, the secure hash algorithm (SHA)-256, which outputs 256-bit hash values.

Transaction data of multiple transactions are hashed and stored in a block. For example, hash values of two transactions are provided, and are themselves hashed to provide another hash. This process is repeated until, for all transactions to be stored in a block, a single hash value is provided. This hash value is referred to as a Merkle root hash, and is stored in a header of the block. A change in any of the transactions will result in change in its hash value, and ultimately, a change in the Merkle root hash.

Blocks are added to the blockchain through a consensus protocol. Multiple nodes within the blockchain network participate in the consensus protocol, and perform work to have a block added to the blockchain. Such nodes are referred to as consensus nodes. PBFT, introduced above, is used as a non-limiting example of a consensus protocol. The consensus nodes execute the consensus protocol to add transactions to the blockchain, and update the overall state of the blockchain network.

In further detail, the consensus node generates a block header, hashes all of the transactions in the block, and combines the hash value in pairs to generate further hash values until a single hash value is provided for all transactions in the block (the Merkle root hash). This hash is added to the block header. The consensus node also determines the hash value of the most recent block in the blockchain (i.e., the last block added to the blockchain). The consensus node also adds a nonce value, and a timestamp to the block header.

In general, PBFT provides a practical Byzantine state machine replication that tolerates Byzantine faults (e.g., malfunctioning nodes, malicious nodes). This is achieved in PBFT by assuming that faults will occur (e.g., assuming the existence of independent node failures, and/or manipulated messages sent by consensus nodes). In PBFT, the consensus nodes are provided in a sequence that includes a primary consensus node, and backup consensus nodes. The primary consensus node is periodically changed, Transactions are added to the blockchain by all consensus nodes within the blockchain network reaching an agreement as to the world state of the blockchain network. In this process, messages are transmitted between consensus nodes, and each consensus nodes proves that a message is received from a specified peer node, and verifies that the message was not modified during transmission.

In PBFT, the consensus protocol is provided in multiple phases with all consensus nodes beginning in the same state. To begin, a client sends a request to the primary consensus node to invoke a service operation (e.g., execute a transaction within the blockchain network). In response to receiving the request, the primary consensus node multicasts the request to the backup consensus nodes. The backup consensus nodes execute the request, and each sends a reply to the client. The client waits until a threshold number of replies are received. In some examples, the client waits for f+1 replies to be received, where f is the maximum number of faulty consensus nodes that can be tolerated within the blockchain network. The final result is that a sufficient number of consensus nodes come to an agreement on the order of the record that is to be added to the blockchain, and the record is either accepted, or rejected.

The consensus mechanism of blockchain network is also called proof of work (PoW). As described above in association withFIGS.1and2, consensus nodes (also referred to as miners) may compete to produce new blocks of processed transactions. In public and private blockchain networks, compromising the consensus mechanism may entail an attacker gaining access to over 51% of the consensus nodes. In a public blockchain network, the scenario may boil down to compromising multiple distributed systems in different locations. However, in a private blockchain network, an internal attacker may be better positioned to target the whole blockchain and reach the 51% requirement with less effort. In such a scenario, integrating node compliance data within the blockchain can help to ensure the blockchain network is able to self-regulate when node status changes.

As detailed above in association withFIGS.1and2, in some implementations, a block includes of hashed transactional data that is aggregated. As illustrated in diagram300ofFIG.3, blocks302,304,306each includes a previous hash, a timestamp for adding the block to the blockchain, a transaction hash (Tx_root), and a nonce. Here, Tx_root represents a Merkle root hash for all transactions (up to the corresponding block). In block304, for example, four transactions, namely, Tx0, Tx1, Tx2& Tx3, are the source transactions being hashed in hash values Hash0, Hash1, Hash2and Hash3. In this example, pairs of hashes are concatenated to form the top level hash tables Hash_01(314A) and Hash_23(314B). These top level hash tables are then concatenated to form the submission of block304to the blockchain. In these implementations, compliance data from traditional compliance tools can be added to the blockchain by each node, every time a transaction block is being submitted to the blockchain.

Referring toFIG.4, diagram400shows that implementations may introduce the compliance transaction (Cx0), alongside the regular transaction data. The compliance transaction (Cx0) is an aggregated score from compliance checks performed against the underlying node and can include, for example, data integrity checks results, malware detection results, suspicious port activity summary, threat intelligence data from installed security products, or other cybersecurity metric. The implementations may, based on the compliance transaction data, generate a hash value cHash0for each top level hash table. As illustrated, compliance transaction data Cx0(e.g.,434A and434B) may be hashed into cHash0(424A and424B), Implementations may then concatenate the compliance hashes (424A and424B) and regular transaction data hashes (e.g., Hash0, Hash1, and Hash2and Hash3) to generate compliance transaction hash, referred to as Hash_c01(414A) and Hash_c23(414B) inFIG.4. Hash_c01(414A) and Hash_c23(414B) may then form the root hash cTx_Root of block404. Indeed, each top level hash can now concatenate one or more compliance hashes into the Merkel root hash.

In some implementations, Ethereum Virtual Machine (EV VI) can be used to generate hashed compliance data within the blockchain. In these implementations, the Ethereum Runtime environment can operate smart contracts and decentralized applications (DApp). In one illustration, along with the Blockchain's normal operational DApps or smart contracts, a compliance DApp can be deployed via the blockchain network to perform compliance checks on the node and the node's host system. The additional complexity provided by these implementations can provide different compliance check results than those inFIG.4. Here, the DApps may generate a series of compliance results (Cx0, Cx1, . . . , Cxn−1, Cxn) that provide a more comprehensive overview of the compliance of the host and node. The data is similarly hashed into respective hash values (cHash0, cHash1, . . . , cHashn−1, cHashn) and submitted to the blockchain network, as discussed above.

FIG.5is a flow chart illustrating process500for submitting a block to be entered into a blockchain. Process500may initiate by hashing transaction data to transaction hash (502). As illustrated inFIG.4, transaction data can be hashed in pairs (e.g., Tx0and Tx1) to respectively generate transaction hashes Hash0and Hash1. Process500may then hash compliance transaction data to generate a compliance hash (504). As illustrated inFIG.4, compliance transaction data. Cx0(434A) can be hashed to generate compliance transaction data cHash0(424A). Process500may then combine transaction hash and compliance hash to generate root hash (506). As illustrated inFIG.4, compliance hash cHash0(424A) can be concatenated with transaction hashes Hash0and Hash1to generate root hash Hash_c01(414A), as the root hash for block404being submitted for addition to blockchain. In general, the hashing process involves the use a unique nonce with the mindset for proof of work. For example, when the nonce is added to the underlying payload data (e.g., transaction data, compliance transaction data, and previous hash value), the hash generated can have the requisite number of bits of leading zeros. Process500may then submit, to a blockchain network, the block (including transaction data and compliance transaction data) for entry into a blockchain (508).

FIG.6is a flow chart illustrating process600for validating a block being submitted for entry into a blockchain. Here, the block being submitted includes the nonce being added to the underlying payload data (e.g., transaction data, compliance transaction data, and previous hash value), and the process can verify by performing a hash function and then inspecting the generated hash value for the number of leading zeros. The duration of the verification process can be limited to the execution of one hash function, which is substantially more expedient than the process for identifying the corresponding nonce. In some cases, such Proof-of-Work under the consensus protocol can start with receiving data encoding a hash of the nonce and the underlying transaction data being submitted from a participant node (602). The data may be encrypted using the private key of the participant node. The data may then be decrypted, by a consensus node in receipt of such data, using the public key of the participant node. The consensus node may further perform a hash of the nonce and the underlying transaction data being submitted from a participant node (604). The consensus node may then determine the number of leading zeros in the hash value (606). Upon determining that the hash, which is a fixed length hash value, satisfies the requisite number of leading bits of zero (608), the consensus node than then add the submitted block into the copy of the block chain (610), as further described above in association withFIGS.1and2. Otherwise, the consensus node may discard the block being submitted (612).

FIG.7is a block diagram illustrating an example of a computer system700used to provide computational functionalities associated with described algorithms, methods, functions, processes, flows, and procedures, according to an implementation of the present disclosure. The illustrated computer702is intended to encompass any computing device such as a server, desktop computer, laptop/notebook computer, wireless data port, smart phone, personal data assistant (PDA), tablet computing device, one or more processors within these devices, another computing device, or a combination of computing devices, including physical or virtual instances of the computing device, or a combination of physical or virtual instances of the computing device. Additionally, the computer702can comprise a computer that includes an input device, such as a keypad, keyboard, touch screen, another input device, or a combination of input devices that can accept user information, and an output device that conveys information associated with the operation of the computer702, including digital data, visual, audio, another type of information, or a combination of types of information, on a graphical-type user interface (UI) (or GUI) or other UI.

The computer702can serve in a role in a computer system as a client, network component, a server, a database or another persistency, another role, or a combination of roles for performing the subject matter described in the present disclosure. The illustrated computer702is communicably coupled with a network704. In some implementations, one or more components of the computer702can be configured to operate within an environment, including cloud-computing-based, local, global, another environment, or a combination of environments.

The computer702is an electronic computing device operable to receive, transmit, process, store, or manage data and information associated with the described subject matter. According to some implementations, the computer702can also include or be communicably coupled with a server, including an application server, e-mail server, web server, caching server, streaming data server, another server, or a combination of servers.

The computer702can receive requests over network703(for example, from a client software application executing on another computer702) and respond to the received requests by processing the received requests using a software application or a combination of software applications. In addition, requests can also be sent to the computer702from internal users, external or third-parties, or other entities, individuals, systems, or computers.

Each of the components of the computer702can communicate using a system bus703. In some implementations, any or all of the components of the computer702, including hardware, software, or a combination of hardware and software, can interface over the system bus703using an application programming interface (API)712, a service layer713, or a combination of the API712and service layer713. The API712can include specifications for routines, data structures, and object classes. The API712can be either computer-language independent or dependent and refer to a complete interface, a single function, or even a set of APIs. The service layer713provides software services to the computer702or other components (whether illustrated or not) that are communicably coupled to the computer702. The functionality of the computer702can be accessible for all service consumers using this service layer. Software services, such as those provided by the service layer713, provide reusable, defined functionalities through a defined interface. For example, the interface can be software written in JAVA, C++, another computing language, or a combination of computing languages providing data in extensible markup language (XML) format, another format, or a combination of formats. While illustrated as an integrated component of the computer702, alternative implementations can illustrate the API712or the service layer713as stand-alone components in relation to other components of the computer702or other components (whether illustrated or not) that are communicably coupled to the computer702. Moreover, any or all parts of the API712or the service layer713can be implemented as a child or a sub-module of another software module, enterprise application, or hardware module without departing from the scope of the present disclosure.

The computer702includes an interface704. Although illustrated as a single interface704inFIG.7, two or more interfaces704can be used according to particular needs, desires, or particular implementations of the computer702. The interface704is used by the computer702for communicating with another computing system (whether illustrated or not) that is communicatively linked to the network703in a distributed environment. Generally, the interface704is operable to communicate with the network703and comprises logic encoded in software, hardware, or a combination of software and hardware. More specifically, the interface704can comprise software supporting one or more communication protocols associated with communications such that the network703or interface's hardware is operable to communicate physical signals within and outside of the illustrated computer702.

The computer702includes a processor705. Although illustrated as a single processor705inFIG.7, two or more processors can be used according to particular needs, desires, or particular implementations of the computer702. Generally, the processor705executes instructions and manipulates data to perform the operations of the computer702and any algorithms, methods, functions, processes, flows, and procedures as described in the present disclosure.

The computer702also includes a database706that can hold data for the computer702, another component communicatively linked to the network703(whether illustrated or not), or a combination of the computer702and another component. For example, database706can be an in-memory, conventional, or another type of database storing data consistent with the present disclosure. In some implementations, database706can be a combination of two or more different database types (for example, a hybrid in-memory and conventional database) according to particular needs, desires, or particular implementations of the computer702and the described functionality. Although illustrated as a single database706inFIG.7, two or more databases of similar or differing types can be used according to particular needs, desires, or particular implementations of the computer702and the described functionality. While database706is illustrated as an integral component of the computer702, in alternative implementations, database706can be external to the computer702. As illustrated, the database706holds data716encoding, for example, blocks incorporating a compliance hash in blockchain implementations described above.

The computer702also includes a memory707that can hold data for the computer702, another component or components communicatively linked to the network703(whether illustrated or not), or a combination of the computer702and another component. Memory707can store any data consistent with the present disclosure. In some implementations, memory707can be a combination of two or more different types of memory (for example, a combination of semiconductor and magnetic storage) according to particular needs, desires, or particular implementations of the computer702and the described functionality. Although illustrated as a single memory707inFIG.7, two or more memories707or similar or differing types can be used according to particular needs, desires, or particular implementations of the computer702and the described functionality. While memory707is illustrated as an integral component of the computer702, in alternative implementations, memory707can be external to the computer702.

The application708is an algorithmic software engine providing functionality according to particular needs, desires, or particular implementations of the computer702, particularly with respect to functionality described in the present disclosure. For example, application708can serve as one or more components, modules, or applications. Further, although illustrated as a single application708, the application708can be implemented as multiple applications708on the computer702. In addition, although illustrated as integral to the computer702, in alternative implementations, the application708can be external to the computer702.

The computer702can also include a power supply714. The power supply714can include a rechargeable or non-rechargeable battery that can be configured to be either user- or non-user-replaceable. In some implementations, the power supply714can include power-conversion or management circuits (including recharging, standby, or another power management functionality). In some implementations, the power-supply714can include a power plug to allow the computer702to be plugged into a wall socket or another power source to, for example, power the computer702or recharge a rechargeable battery.

There can be any number of computers702associated with, or external to, a computer system containing computer702, each computer702communicating over network703. Further, the term “client,” “user,” or other appropriate terminology can be used interchangeably, as appropriate, without departing from the scope of the present disclosure. Moreover, the present disclosure contemplates that many users can use one computer702, or that one user can use multiple computers702.

Non-transitory computer-readable media for storing computer program instructions and data can include all forms of media and memory devices, magnetic devices, magneto optical disks, and optical memory device. Memory devices include semiconductor memory devices, for example, random access memory (RAM), read-only memory (ROM), phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory devices. Magnetic devices include, for example, tape, cartridges, cassettes, internal/removable disks. Optical memory devices include, for example, digital video disc (DVD), CD-ROM, DVD+/−R, DVD-RAM, DVD-ROM, HD-DVD, and BLURAY, and other optical memory technologies. The memory can store various objects or data, including caches, classes, frameworks, applications, modules, backup data, jobs, web pages, web page templates, data structures, database tables, repositories storing dynamic information, or other appropriate information including any parameters, variables, algorithms, instructions, rules, constraints, or references. Additionally, the memory can include other appropriate data, such as logs, policies, security or access data, or reporting files. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.