BUILDING CODE COMPLIANCE

BACKGROUND

[0001] Assessing compliance of a building or construction project with the applicable building codes and/or certification or rating systems such as, for example, with fire-resistance rating system requirements, green building rating systems (e.g., Leadership in Energy and Environmental Design (LEED)), and/or the like, typically involves contributing and tracking a significant amount of information across the design, material and system specifications, construction, and use of the project.

[0001] Initially, this information is compiled by the designer and submitted to appropriate officials or third party verifiers for pre-construction compliance approval. As the project moves into the construction phase, a vast array of building materials and building and construction equipment are ordered as well as multiple trades are scheduled. Invariably, order and construction sequence changes occur that must be appropriately documented. Officials and other inspectors/verifiers responsible for assurance of compliance with the codes and/or certification or rating systems must independently verify that the as-built information equally fulfills compliance.

[0002] This document describes methods and systems that are directed to addressing the problems, challenges and complexities described above, and/or other issues. SUMMARY

[0003] This disclosure is not limited to the particular systems, methodologies or protocols described, as these may vary. The terminology used in this description is for the purpose of describing the particular versions or embodiments, and is not intended to limit the scope.

[0004] As used in this document, the singular forms “a,” “an,” and “the” include plural references unless the context clearly dictates otherwise. Unless defined otherwise, all technical and scientific terms used in this document have the same meanings as commonly understood by one of ordinary skill in the art. As used in this document, the term “comprising” means “including, but not limited to.”

[0005] In an embodiment, a method of securing data associated with one or more building rating systems includes, by one or more electronic devices, receiving, from a building owner of a target building that is a subject of a building rating system, a communication that includes building information corresponding to the target building, generating a building owner block that is associated with the building owner, storing at least a portion of the building information in the building owner blocks, adding the building owner block to a blockchain, identifying a certifier associated with the target building, and receiving, from the identified certifier, a communication that includes certification information corresponding to the target building. The certification information includes at least a portion of the building information that the certifier has retrieved from the building owner block. The method includes generating a certifier block that is associated with the identified certifier, storing at least a portion of the certification information in the certifier block, adding the certifier block to the blockchain, identifying an inspector associated with a certification organization responsible for administering the building rating system, and receiving, from the identified inspector, a communication comprising inspection information corresponding to the target building. The inspection information includes information pertaining to compliance of the target building or one or more components of the target building with one or more requirements of the building rating system. The method includes generating an inspection block that is associated with the identified inspector, storing at least a portion of the inspection information in the inspection block, and adding the inspection block to the blockchain. At least a portion of the blockchain is accessible by the building owner, the certifier, the certification organization, and/or one the inspector according to an access policy associated with the blockchain. The access policy includes an access control list that defines one or more access rights to the blockchain.

[0006] In various embodiments, a computer program that includes one or more programming instructions, that when executed by one or more electronic devices, causes the one or more electronic devices to perform the above-described method is disclosed.

[0007] In various embodiments, a system for securing data associated with one or more building rating systems includes one or more electronic devices and a computer-readable storage medium is disclosed. The computer-readable storage medium includes one or more programming instructions that, when executed, cause one or more of the one or more electronic devices to perform the above-described method.

[0008] In various embodiments, a non-transitory computer-readable storage medium includes one or more programming instructions that, when executed by one or more processors, performs the above-described method. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] FIG. 1 illustrates an example building rating system lifecycle.

[0010] FIG. 2 illustrates an example building rating system management system.

[0011] FIG. 3 illustrates an example blockchain structure.

[0012] FIG. 4 illustrates a flow chart of an example method of performing tamper- evident logging.

[0013] FIG. 5 illustrates an example of a source log.

[0014] FIG. 6A illustrates a flow chart of an example method of verifying access requests to a target blockchain.

[0015] FIG. 6B illustrates example access requests according to various embodiments.

[0016] FIG. 7 illustrates an example delegation process.

[0017] FIG. 8 illustrates an example multiple-tier delegation process according to an embodiment.

[0018] FIGS. 9A and 9B illustrate example tokens and data according to various embodiments.

[0019] FIG. 10 illustrates a block diagram of example hardware that may be used to contain or implement program instructions.

DETAILED DESCRIPTION

[0020] The following terms shall have, for purposes of this application, the respective meanings set forth below: [0021] A “block” or a “node” refers to a data structure that includes a link to one or more other data structures. In certain embodiments, a block may include a grouping of data or data records. A block of a blockchain may include a link to an immediately preceding block in the blockchain, a subsequent block in the blockchain, a different block in the blockchain, or a different block in another blockchain.

[0022] A “blockchain” refers to a distributed data structure that includes a sequence of blocks that are linked together.

[0023] An “electronic device” or a “computing device” refers to a device that includes a processor and memory. Each device may have its own processor and/or memory, or the processor and/or memory may be shared with other devices as in a virtual machine or container arrangement. The memory may contain or receive programming instructions that, when executed by the processor, cause the electronic device to perform one or more operations according to the programming instructions. Examples of electronic devices include personal computers, servers, mainframes, virtual machines, containers, gaming systems, televisions, and mobile electronic devices such as smartphones, personal digital assistants, cameras, tablet computers, laptop computers, media players and the like. In a client-server arrangement, the client device and the server are each electronic devices, in which the server contains instructions and/or data that the client device accesses via one or more communications links in one or more communications networks. In a virtual machine arrangement, a server may be an electronic device, and each virtual machine or container may also be considered to be an electronic device. In the discussion below, a client device, server device, virtual machine or container may be referred to simply as a “device” for brevity. [0024] The terms “memory,” “memory device,” “computer-readable storage medium”, “data store,” “data storage facility” and the like each refer to a non-transitory device on which computer-readable data, programming instructions or both are stored. Except where specifically stated otherwise, the terms “memory,” “memory device,” “computer-readable storage medium”, “data store,” “data storage facility” and the like are intended to include single device embodiments, embodiments in which multiple memory devices together or collectively store a set of data or instructions, as well as individual sectors within such devices.

[0025] The terms “processor” and “processing device” refer to a hardware component of an electronic device that is configured to execute programming instructions. Except where specifically stated otherwise, the singular term “processor” or “processing device” is intended to include both single-processing device embodiments and embodiments in which multiple processing devices together or collectively perform a process.

[0026] A “private key” refers to an asymmetric cryptographic key that is used to encrypt or decrypt messages, data, information, or other content. Messages encrypted using a private key may be decrypted by a recipient who possesses an associated public key. Likewise, messages that are encrypted using an associated public key may be decrypted using a private key.

[0027] A “public key” refers to an asymmetric cryptographic key that are generally obtained and used without restriction to encrypt and/or decrypt messages. Messages encrypted using a public key may be decrypted by a recipient who possesses an associated private key. Likewise, messages that are encrypted using a private key may be decrypted by a recipient who possesses an associated public key.

[0028] A “building rating system” refers to one or more requirements, criteria or other forms of assessment pertaining to the performance, compliance, or operation of a building, a construction project or development, and/or a component or portion thereof. Green building rating systems, which rate relative levels of compliance or performance of a building, development, or portion thereof to one or more specific environmental requirements or goals is an example of a building rating system. A building code compliance system is also an example of a building rating system as the term is used in this document, including fire resistance, water resistance, earthquake resistance, and/or the like. A building rating system may include information that is voluntary, such as, for example, a green building rating system. A building rating system may include information that is mandatory, such as, for example, in building code compliance. The blanket term “building rating system” includes information for systems that apply to the building, that may be useful to different parties or participants as described in this document. Building rating systems may be used to assess new construction or renovations of existing structures.

[0029] There are various types of building rating systems that pertain to buildings, developments, or portions thereof. Green building rating systems are an example of a building rating system. Green building rating systems may rate relative levels of compliance or performance of a building, development, or portion thereof to one or more specific environmental requirements or goals. These environmental requirements or goals may include, for example, metrics or thresholds pertaining to energy savings, water efficiency, emissions reduction, and indoor environmental quality, among others. Leadership in Energy and Environmental Design (LEED) is an example of a green building rating system. LEED provides a point system to score green building design and construction across five basic areas: Sustainable Sites, Water Efficiency, Energy and Atmosphere, Materials and Resources, and Indoor Environmental Quality. Buildings are awarded points based on their compliance with criteria in these categories, such that the more points that are awarded results in an higher level of certification for the building. LEED awards certifications at the Certified, Silver, Gold, and Platinum levels.

[0030] WELL Certification, Green Globes, Building Research Establishment Environmental Assessment Method (BREEM), and DGNB, are examples of other green building rating systems. It is understood that this disclosure contemplates additional and/or alternate green building rating systems, whether now known or existing in the future.

[0031] Another type of building rating system is a fire-resistance rating system. A fire- resistance rating system may rate the fire risk of one or more assemblies or components of a building (e.g., walls, ceilings, floors, and other building systems) or may determine compliance of one or more of these assemblies or components to code requirements pertaining to fire resistance.

[0032] For example, an assembly may be installed in a temperature-controlled furnace with the temperature increased over a certain period of time in accordance with one or criteria, standards, or requirements of the applicable fire-resistance rating system. If the assembly survives or withstands the fire test for the time period, the assembly is recognized as meeting the applicable rating.

[0033] FIG. 1 illustrates an example building rating system lifecycle for an example building according to various embodiments. An example lifecycle may involve a building owner 102, a certifier 104, a certification organization 106, one or more inspectors 108 and/or one or more potential purchasers 110.

[0034] A building owner 102 may be one or more individuals, entities and/or organizations who own a building that is the subject of one or more building rating system reviews. For the purposes of this disclosure, a building or component thereof that is the subject of one or more building rating system reviews is referred to as a “target building.” In some embodiments, a building owner 102 may also include one or more individuals, entities and/or organizations that manage, operate, or otherwise run a target building on behalf of the building owner. Examples may include, without limitation, a building or property manager, an operations manager, an architect, and/or the like.

[0035] A building owner 102 may provide building information pertaining to one or more target buildings to a blockchain system, as described in more detail below. Building information may include, without limitation, information about materials used in the construction of at least a portion of a target building, assemblies of the target building, design of the target building and/or the like. Example building information may include, without limitation, identification of the types of materials used, unique identifiers associated with one or more materials used (e.g., model or serial numbers), a supplier of one or more materials or assemblies, a manufacturer of one or more materials or assemblies, an installer of one or more materials and/or assemblies, specifications associated with one or more materials and/or assemblies (e.g., a color, a finish, etc.), and/or the like

[0036] A certifier 104 refers to an individual, entity and/or organization who is responsible for gathering certification information for consideration by a certifying organization with respect to a target building’s compliance with one or more building rating systems. Certification information may include, without limitation, information about materials used in the construction of at least a portion of a target building, assemblies of the target building, design of the target building and/or the like. Example certification information may include, without limitation, data pertaining to the target building’s energy consumption, energy sources, water consumption, water sources, location, waste reduction, reuse and recycling, and/or the like. In various embodiments, certification information may include a subset or portion of building information.

[0037] In various embodiments, a certifier 104 may work with a building owner 102 to collect or access relevant certification information for rating/certification consideration. The certifier 104 may provide at least a portion of this certification information to a blockchain system, as described in more detail below. The information that is provided by a certifier (e.g., certification information), may be uniquely correlated with one or more target buildings, for example, by a unique identifier.

[0038] A certification organization 106 refers to an organization or entity that administers one or more building rating systems. This administration may include performing third-party technical reviews and verification of registered projects. As an example, The Green Business Certification Inc. administers LEED. In various embodiments, a certification organization may provide administration information to a blockchain system, as described in more detail below. Administration information may include information pertaining to one or more building rating systems such as, for example, one or more tests to be performed as party of a building rating system, criteria associated with a building rating system, information about the available ratings or certifications for a building rating system, and/or the like. The information that is provided by a certification organization (e.g., administration information), may be uniquely correlated with one or more target buildings, for example, by a unique identifier.

[0039] In various embodiments, one or more inspectors 108 may act on behalf of a certification organization 106. For instance, a certification organization 106 may employ one or more inspectors 108 to perform reviews of target buildings to determine or verify their compliance with the applicable building rating systems. In these situations, the inspectors 108 may be affiliated with one or more certification organizations 106.

[0040] As an example, an inspector 108 may inspect a target building or portions of a target building to determine whether certification information that was provided is accurate and whether the target building is compliant with the applicable building rating system. As another example, an inspector 108 may perform one or more tests or analyses to ascertain whether a target building satisfies one or more building rating systems. For instance, with respect to a fire- resistance rating system, an inspector may conduct one or more tests of one or more assemblies of a target building. For example, an inspector 108 may conduct the fire resistance test ASTM El 19-20 (Standard Test Method for Fire Tests of Building Construction and Materials) in the United States. Additional and/or alternate fire-resistance tests and/or rating systems may be used within the scope of this disclosure.

[0041] One or more inspectors 108 may provide inspection information pertaining to one or more inspections of a target building to a blockchain system, as described in more detail below. Inspection information may include information pertaining to compliance of a target building or one or more components of the target building with one or more requirements of a building rating system. For instance, inspection information may include information such as, for example, inspection specifications, an inspection location, a date of inspection, a name of one or more individuals who inspected the target building, one or more images of the inspected target building or portion thereof, results of one or more inspections or tests performed by an inspector, a report or other proof of inspector approval or comments, and/or the like. An image capture device such as, for example, a camera, a video recorder, an infrared imaging device, and/or the like may be used to capture one or more images or videos within the scope of this disclosure. The information that is provided by an inspector (e.g., inspection information), may be uniquely correlated with one or more target buildings, for example, by a unique identifier.

[0042] In various embodiments, one or more potential purchasers 110 may be involved in the lifecycle of a target building. A potential purchaser 110 may be an individual, entity or organization that is considering acquiring ownership rights and/or usage or access rights to a target building. As part of the diligence process in deciding whether to purchase an interest in a target building, a potential purchaser 110 may wish to access information stored by a blockchain system pertaining to building rating system certifications held by the target building, and/or building rating system tests, reviews, inspections and/or the like pertaining to the target building, as described in more detail below.

[0043] The ability to track collect and maintain secure information pertaining to one or more building rating systems for one or more target buildings over time may provide benefits to one or more participants of the lifecycle described above. For example, a building owner and/or subsequent purchaser, may be able to track what building rating systems have been performed for a target building, and data associated with each of those building rating systems, including, without limitation, information from inspectors as to whether the inspection was successful or not. As another example, certification organizations and/or inspectors can access building information and/or certification information pertaining to materials, structures, assemblies, and/or design of a target building and use this information in performance of one or more building rating system reviews without concern that such information has been altered or modified after it was provided.

[0044] FIG. 2 illustrates an example building management system according to an embodiment. As illustrated in FIG. 2, a system 200 may include one or more host electronic devices 204a-N and one or more client electronic devices 202a-N. A host electronic device

204a-N may be located remotely from a client electronic device 202a-N. A server is an example of a host electronic device 204a-N according to an embodiment. A host electronic device 204a-N may have or be in communication with one or more data stores 206a-N. In various embodiments, a host electronic device 204a-N may include or be in communication with a rights management system 220.

[0045] A host electronic device 204a-N may be in communication with one or more client electronic devices 202a-N over one or more communication networks 208a-N. A communication network 208a-N may be a local area network (LAN), a wide area network (WAN), a mobile or cellular communication network, an extranet, an intranet, the Internet and/or the like.

[0046] In various embodiments, a client electronic device 202a-N may be a portable electronic device such as, for example, a smartphone, a tablet, a laptop, a wearable and/or the like. In other embodiments, a client electronic device 202a-N may be desktop computer or other electronic device.

[0047] A client electronic device 202a-N may be associated with a particular participant or representative in the target building rating system lifecycle. For example, as illustrated in FIG. 2, one or more client electronic devices 202a-N may be associated with a building owner 212, a certifier 214, a certification organization 216, an inspector 218, a potential purchaser 222, and/or the like.

[0048] As illustrated by FIG. 2, one or more host electronic devices 204a-N may have access to one or more blockchains 210a-N. The one or more blockchains may be used to manage information pertaining to one or more building rating systems for one or more target buildings over a period of time, as described throughout this disclosure. The one or more host electronic devices 204a-N may read, write, query, and/or otherwise access the blockchain. For example, the one or more host electronic devices may create new blocks on the blockchain, access the blockchain, and/or retrieve information from the blockchain in response to receiving requests from one or more client electronic devices.

[0049] As illustrated by FIG. 2, one or more host electronic devices 204a-N may include or be in communication with a rights management system 220. A rights management system 220 may include one or more electronic devices and/or one or more data stores. A rights management system 220 may maintain and/or implement one or more access policies that are applicable to the blockchain as explained in more detail below.

[0050] FIG. 3 illustrates an example blockchain data structure according to an embodiment. A blockchain 300a-N includes one or more blocks 302a-N. Optionally, a block may include one or more log records 304a-N. As new log records are generated, a corresponding data representation of those log records may be added to the blockchain 300a-N as part of a new block. As such, blocks 302a-N of a blockchain 300a-N may be positioned in a linear, sequential order. For example, blocks may be arranged in a chronological order. Blocks 302a-N in a blockchain 300a-N are linked to preceding blocks in the chain as illustrated in FIG. 3.

[0051] Optionally, one or more blocks 302a-N of a blockchain 300a-N may occupy the same data store or memory space. Alternatively, a blockchain 300a-N may be implemented as via a distributed data store. For instance, blocks 302a-N of a blockchain 300a-N may not occupy the same data store or memory space, but rather two or more blocks in a blockchain may be implemented as distributed data stores. These distributed data stores may exist amongst remote electronic devices. For instance, part of a blockchain 300a-N may be stored in a data store that is associated with a first electronic device in a first location, while a different part of the blockchain may be stored in a different data store that is associated with a second electronic device in a second location that is different from the first location.

[0052] A block 302a-N of a blockchain 300a-N may be located in a data store at a first location, while a second block of the blockchain may be located in a data store at a second location. Despite remote storage proximity to one another, the blocks 302a-N may still form the blockchain 300a-N as they are linked to one another such as, for example, by way of their signatures.

[0053] In various embodiments, one or more participants of the system (e.g., building owners, certifiers, certification organizations, inspectors, potential purchasers, and/or other authorized users) may have a key pair that each may use to communicate and/or verify or authenticate communications and other information shared throughout the system. The key pair may include a private key and a public key associated with each participant. For example, if Building Owner A and Building Owner B are participants of the system, each may be associated with its own public/private key pair { K _pu , K _pr }.

[0054] A participant may generate its own public and private keys. For example, a system associated with a participant may include a key generator, such as, for example, a random key generator, which may generate a public/private key pair for the participant. All client electronic devices associated with the participant may utilize the same public/private key pair in its communications with the system in order to uniquely authenticate itself as part of the participant’s network. It is understood that client electronic devices associated with a participant may utilize different public/private key pairs in some embodiments, each associated with the participant. In various embodiments, one or more electronic devices associated with a participant (e.g., one or more client electronic devices) may store a generated key pair in a secure data store associated with such device.

[0055] In various embodiments, each participant of the system may provide its public key with the system. The system may store one or more public keys and an indication of the participant to which it belongs in one or more data stores such as, for example, a key store. As explained in more detail below, the system may utilize a key store to authenticate communications via the system.

[0056] FIG. 4 illustrates a flow chart of an example method of securing the integrity of information provided as part of a building rating system review for a target building through tamper-evident logging according to an embodiment. Tamper-evident logging refers to a process that makes changes, modifications or access to log records easily detectable. This is true for modifications or changes made by unauthorized users who have no privileges on the system, as well as authorized users of the system.

[0057] In various embodiments, the system may identify one or more building owners. A system may identify one or more building owners In various embodiments, a listing of one or more building owners may be stored in a data store associated with or accessible by a host electronic device.

[0058] As illustrated by FIG. 4A, the system may receive 400 a communication from one or more building owners. For instance, a host electronic device may receive 400 an electronic communication from one or more client electronic devices associated with a building owner. The communication may include building information. This building information may be provided by a building owner as part of the construction or renovation of a target building. In other embodiments, building information may be provided by a building owner after the completion of construction or renovation of a target building, or separate and apart from the development or renovation of a target building. In various embodiments, at least a portion of the building information provided by a building owner may be stored in a data store associated with or accessible by a host electronic device.

[0059] In various embodiments, the received communication may include message content and a digital signature. The message content may be building information. The system may use the digital signature to confirm that the communication actually came from the building owner.

[0060] A building owner may generate a digital signature for a communication by performing one or more cryptographic operations on at least a portion of the message content. For example, a building owner may generate a digital signature for a communication by generating, by an electronic device, a hash of at least a portion of the message content to generate a hashed value. For instance, a building owner that is sending building information may generate a hashed value corresponding to the building information by applying one or more hashing algorithms to the building information. The building owner may encrypt the hashed value with the building owner’s private key to generate a digital signature corresponding to the message content.

[0061] The building owner may send the communication and corresponding digital signature to the system. In various embodiments, the system may authenticate 402 the received communication. Authenticating the communication may involve verifying that the communication originated from an authorized source such as, for example, an authorized building owner. In this way, only authorized building owner may request that information be added to a target blockchain, and users or those who access the target blockchain can be confident that the target blockchain only includes relevant data. Authenticating the received communication may also involve confirming that the message content was not altered, modified or otherwise changed after it was sent.

[0062] The system may decrypt the received digital signature using the building owner’s public key to yield a decrypted value. The decrypted value may be the received hashed value. If the decryption is successful, the system will know that the communication originated with the building owner. If the decryption is not successful, the system may disregard the communication.

[0063] The system may also verify the integrity of the message content. The system may apply the same hashing algorithm(s) used by the building owner to the received message content to generate a hashed value. The system may compare the hashed value it generated to the received hashed value. If the two values are the same, the system has verified that the message content has not changed since it was sent. If the values do not match, the system may disregard the communication as the message content has been changed after it was sent.

[0064] The system may create 404 a log file that includes at least a portion of the received building information. The log file may store the received building information in association with one or more target buildings, so that the building information is correlated to the target building to which it corresponds. The system may generate 406 a new block for a blockchain. The system may store the created log file in the new block.

[0065] In various embodiments, if a target blockchain already exists, the system may generate 406 a block to append to the end of the target blockchain. The target blockchain may store information about a target building through its rating system lifecycle. Additional and/or other target blockchains may be used within the scope of this disclosure. [0066] Referring back to FIG. 4A, the system may add 408 the new block to a target blockchain. If the target blockchain already exists, the system may identify the last block of the target blockchain. The last block may be associated with a signature. The signature may be derived or based on a signature of a block that precedes the last block in the target blockchain. The preceding block may immediately precede the last block in the target blockchain, or it may not immediately precede the last block but be separated from the target block by one or more other blocks.

[0067] For instance, the signature of the last block may be a result of one or more cryptographic operations, such as, for example, a hash function, performed on at least a portion of the contents of a block that precedes the last block in the target blockchain. As such, the blocks of the blockchain may be inextricably linked together, and modification of one block will require modification of the previous blocks in the chain.

[0068] The system may add 408 the new block to the target blockchain by performing one or more cryptographic operations on at least a portion of the content of the last block in the target blockchain to generate a signature. The system may add the signature to the new block and append it the end of the target blockchain. For instance, the system may link the new block to the last block of the target blockchain.

[0069] If a target blockchain does not already exist, the system may generate a first block of a blockchain. If the generated block is also the only block in the target blockchain, then the signature of the block may not be based on a preceding block because there is no preceding block in the chain. In this situation, the signature of the block may be a result of one or more cryptographic operations performed on at least part of the block, such as, for example, a portion of the block’s log records. [0070] In various embodiments, the system may maintain a source log that tracks which blocks are associated with which participant in the lifecycle. For instance, if the system receives building information from Building Owner 1 to add to the target block chain for a target building, the system may assign a unique identifier to Building Owner 1. The system may update a source log to associate one or more generated blocks with the source of the information stored within the block. For instance, the system may assign Building Owner 1 the unique identifier “02d3” and may store in the source log an indication of the newly created block associated with Building Owner 1. This indication may be the signature of or other unique identifier associated with the newly created block. FIG. 5 illustrates an example of a source log according to an embodiment.

[0071] In various embodiments, the system may identify one or more certifiers. A listing of one or more certifiers may be stored in a data store associated with or accessible by a host electronic device. The listing may correlate one or more certifiers to one or more building owners according to an embodiment.

[0072] Referring back to FIG. 4A, the system may receive 410 a communication from one or more certifiers. For instance, a host electronic device may receive 410 an electronic communication from one or more client electronic devices associated with a certifier. The communication may include certification information. This certification information may be provided by a certifier as part of the construction or renovation of a target building. In other embodiments, certification information may be provided by a certifier after the completion of construction or renovation of a target building, or separate and apart from the development or renovation of a target building. In various embodiments, at least a portion of the building information provided by a certifier may be stored in a data store associated with or accessible by a host electronic device.

[0073] The information that is provided by a certifier (e.g., certification information), may be uniquely correlated with a target building or one or more components or portions thereof, for example, by a unique identifier.

[0074] In various embodiments, the received communication may include message content and a digital signature. The message content may be certification information corresponding to a target building or one or more components or portions thereof. The system may use the digital signature to confirm that the communication actually came from the certifier.

[0075] A certifier may generate a digital signature for a communication by performing one or more cryptographic operations on at least a portion of the message content. For example, a certifier may generate a digital signature for a communication by generating, by an electronic device, a hash of at least a portion of the message content to generate a hashed value. For instance, a certifier that is sending certification information for a target building may generate a hashed value corresponding to the certification information by applying one or more hashing algorithms to the certification information. The certifier may encrypt the hashed value with the certifier’s private key to generate a digital signature corresponding to the message content.

[0076] The certifier may send the communication and corresponding digital signature to the system. In various embodiments, the system may authenticate 412 the received communication. Authenticating the communication may involve verifying that the communication originated from an authorized source such as, for example, an authorized certifier. In this way, only authorized certifiers may request that information be added to a target blockchain, and users or those who access the target blockchain can be confident that the target blockchain only includes relevant data. Authenticating the received communication may also involve confirming that the message content was not altered, modified or otherwise changed after it was sent.

[0077] The system may decrypt the received digital signature using the certifier’s public key to yield a decrypted value. The decrypted value may be the received hashed value. If the decryption is successful, the system will know that the communication originated with the certifier. If the decryption is not successful, the system may disregard the communication.

[0078] The system may also verify the integrity of the message content. The system may apply the same hashing algorithm(s) used by the certifier to the received message content to generate a hashed value. The system may compare the hashed value it generated to the received hashed value. If the two values are the same, the system has verified that the message content has not changed since it was sent. If the values do not match, the system may disregard the communication as the message content has been changed after it was sent.

[0079] The system may create 414 a log file that includes at least a portion of the received certification information. The log file may store the received certification information in association with one or more target buildings, so that the certification information is correlated to the target building to which it corresponds. The system may generate 416 a new block for a blockchain. The system may store the created log file in the new block.

[0080] In various embodiments, if a target blockchain already exists, the system may generate 416 a block to append to the end of the target blockchain. For example, the target blockchain may store information about a target building or one or more components thereof throughout its lifecycle. Additional and/or other target blockchains may be used within the scope of this disclosure. [0081] Referring back to FIG. 4A, the system may add 418 the new block to a target blockchain. If the target blockchain already exists, the system may identify the last block of the target blockchain. The last block may be associated with a signature. The signature may be derived or based on a signature of a block that precedes the last block in the target blockchain. The preceding block may immediately precede the last block in the target blockchain, or it may not immediately precede the last block but be separated from the target block by one or more other blocks.

[0082] For instance, the signature of the last block may be a result of one or more cryptographic operations, such as, for example, a hash function, performed on at least a portion of the contents of a block that precedes the last block in the target blockchain. As such, the blocks of the blockchain may be inextricably linked together, and modification of one block will require modification of the previous blocks in the chain.

[0083] The system may add 418 the new block to the target blockchain by performing one or more cryptographic operations on at least a portion of the content of the last block in the target blockchain to generate a signature. The system may add the signature to the new block and append it the end of the target blockchain. For instance, the system may link the new block to the last block of the target blockchain.

[0084] If a target blockchain does not already exist, the system may generate a first block of a blockchain. If the generated block is also the only block in the target blockchain, then the signature of the block may not be based on a preceding block because there is no preceding block in the chain. In this situation, the signature of the block may be a result of one or more cryptographic operations performed on at least part of the block, such as, for example, a portion of the block’s log records. [0085] In various embodiments, the system may maintain a source log that tracks which blocks are associated with which participant in the lifecycles. For instance, if the system receives quality data from Certifier 1 to add to the target block chain for a target building, the system may assign a unique identifier to Certifier 1. The system may update a source log to associate one or more generated blocks with the source of the information stored within the block. For instance, the system may assign Certifier 1 the unique identifier “024v3” and may store in the source log an indication of the newly created block associated with Certifier 1. This indication may be the signature of or other unique identifier associated with the newly created block.

[0086] In various embodiments, the system may receive 420 a communication from one or more certification organizations. For instance, a host electronic device may receive 420 an electronic communication from one or more client electronic devices associated with a certification organization. The communication may include administration information corresponding to one or more building rating systems for a target building.

[0087] The information that is provided by a certification organization (e.g., administration information) may be uniquely correlated with one or more target buildings, for example, by a unique identifier.

[0088] In various embodiments, the received communication may include message content and a digital signature. The message content may be administration information, corresponding to one or more target buildings. The system may use the digital signature to confirm that the communication actually came from the certification organization.

[0089] A certification organization may generate a digital signature for a communication by performing one or more cryptographic operations on at least a portion of the message content. For example, a certification organization may generate a digital signature for a communication by generating, by an electronic device, a hash of at least a portion of the message content to generate a hashed value. For instance, a certification organization that is sending administration information may generate a hashed value corresponding to the data by applying one or more hashing algorithms to the data. The certification organization may encrypt the hashed value with the certification organization’s private key to generate a digital signature corresponding to the message content.

[0090] The certification organization may send the communication and corresponding digital signature to the system. In various embodiments, the system may authenticate 422 the received communication. Authenticating the communication may involve verifying that the communication originated from an authorized source such as, for example, an authorized certification organization. In this way, only authorized certification organizations may request that information be added to a target blockchain, and users or those who access the target blockchain can be confident that the target blockchain only includes relevant data. Authenticating the received communication may also involve confirming that the message content wasn’t altered, modified or otherwise changed after it was sent.

[0091] The system may decrypt the received digital signature using the certification organization’s public key to yield a decrypted value. The decrypted value may be the received hashed value. If the decryption is successful, the system will know that the communication originated with the certification organization. If the decryption is not successful, the system may disregard the communication.

[0092] The system may also verify the integrity of the message content. The system may apply the same hashing algorithm(s) used by the certification organization to the received message content to generate a hashed value. The system may compare the hashed value it generated to the received hashed value. If the two values are the same, the system has verified that the message content has not changed since it was sent. If the values do not match, the system may disregard the communication as the message content has been changed after it was sent.

[0093] The system may create 424 a log file that includes at least a portion of the received administration information. The log file may store the received administration information in association with one or more target buildings, so that the administration information is correlated to the target building to which it corresponds.

[0094] The system may generate 426 a new block for the target blockchain. The system may store the created log file in the new block. In various embodiments, the system may add 428 the new block to the target blockchain. For example, the system may add 428 the new block to the target blockchain in a manner similar to that described above.

[0095] The system may update the source log to associate with generated certification organization block with the certification organization that provided the corresponding administration information. For instance, the system may assign Certification Organization 1 the unique identifier “u9ra” and may store in the source log an indication of the newly created block associated with Certification Organization 1. This indication may be the signature of or other unique identifier associated with the newly created block.

[0096] In various embodiments, the system may identify one or more inspectors of one or more target buildings. The system may access a list of inspectors from one or more data stores associated with or accessible by a host electronic device. An inspector may be associated with one or more certification organizations. By knowing which certification organization was administering a building rating system for a target building, the system may access a corresponding list of inspectors associated with the certification organization from one or more data stores.

[0097] The system may receive 430 a communication from one or more of the identified inspectors. For instance, a host electronic device may receive 430 an electronic communication from one or more client electronic devices associated with an inspector. The communication may include inspection information associated with a target building.

[0098] In various embodiments, the received communication may include message content and a digital signature. The message content may be inspection information. The system may use the digital signature to confirm that the communication actually came from the inspector.

[0099] An inspector may generate a digital signature for a communication by performing one or more cryptographic operations on at least a portion of the message content. For example, an inspector may generate a digital signature for a communication by generating, by an electronic device, a hash of at least a portion of the message content to generate a hashed value. For instance, an inspector that is sending installation data may generate a hashed value corresponding to the data by applying one or more hashing algorithms to the data. The inspector may encrypt the hashed value with the inspector’s private key to generate a digital signature corresponding to the message content.

[00100] The inspector may send the communication and corresponding digital signature to the system. In various embodiments, the system may authenticate 432 the received communication. Authenticating the communication may involve verifying that the communication originated from an authorized source such as, for example, an identified inspector (or an otherwise authorized inspector). In this way, only authorized inspectors may request that information be added to a target blockchain, and users or those who access the target blockchain can be confident that the target blockchain only includes relevant data.

Authenticating the received communication may also involve confirming that the message content was not altered, modified or otherwise changed after it was sent.

[00101] The system may decrypt the received digital signature using the inspector’s public key to yield a decrypted value. The decrypted value may be the received hashed value. If the decryption is successful, the system will know that the communication originated with the installer. If the decryption is not successful, the system may disregard the communication.

[00102] The system may also verify the integrity of the message content. The system may apply the same hashing algorithm(s) used by the inspector to the received message content to generate a hashed value. The system may compare the hashed value it generated to the received hashed value. If the two values are the same, the system has verified that the message content has not changed since it was sent. If the values do not match, the system may disregard the communication as the message content has been changed after it was sent.

[00103] The system may authenticate 432 a received communication using cryptography. For example, the system may verify that a received communication was sent by a known or authorized inspector by confirming that the communication was encrypted using the installer’s private key. For example, in response to receiving a communication from an inspector, the system may retrieve that inspector’s public key from the key store. The system may attempt to decrypt the received communication using the retrieved public key. If the retrieved public key is successful in decrypting the communication, the system can be confident that the communication originated from the authorized inspector. If the retrieved public key is not successful in decrypting the communication, the system may discard the communication since it was not sent from the purported inspector. Additional and/or alternate authentication protocols may be used within the scope of this disclosure.

[00104] The system may create 434 a log file that includes at least a portion of the received inspection information. The log file may store the received inspection information in association with one or more target buildings, so that the inspection information is correlated to the target building to which it corresponds.

[00105] The system may generate 436 a new block for the target blockchain. The system may store the created log file in the new block. In various embodiments, the system may add 438 the new block to the target blockchain. For example, the system may add 438 the new block to the target blockchain in a manner similar to that described above.

[00106] The system may update the source log to associate with generated inspector block with the inspector that provided the corresponding inspection information. For instance, the system may assign Inspector 1 the unique identifier “lx2h” and may store in the source log an indication of the newly created block associated with Inspector 1. This indication may be the signature of or other unique identifier associated with the newly created block.

[00107] In various embodiments, at least a portion of the target blockchain may be accessible by one or more of the identified participants, such as, for example, building owners, certifiers, certification organizations, inspectors, potential purchasers, and/or the like. As described in more detail below, one or more participants may query or request information that is stored in the target blockchain.

[00108] One or more host electronic devices may receive one or more access requests.

An access request may include a request to access certain information that is stored on the target blockchain. For instance, an access request may be a request to access information associated with a particular target building or component thereof. As another example, an access request may be a request to access information about one or more building rating system reviews performed for a target building. Additional and/or alternate access requests may be made within the scope of this disclosure.

[00109] An access request may originate from a participant (e.g., a building owner, a certifier, a certification organization, an inspector, a potential purchaser, and/or the like) and/or one or more authorized business partners of one or more participants. However, the system may only grant access to requested information if it is permitted by an access policy associated with the target blockchain. An access policy is a list, table, or other data structure that identifies privileges or permissions that apply to a particular resource or set of resources.

[00110] An access control list (ACL) is an example of an access policy according to an embodiment. A blockchain is another example of an access policy according to an embodiment. For example, one or more permissions and associated requestors may be stored on an access control blockchain. The access control blockchain may be separate from the target blockchain. A host electronic device may access an access control blockchain in order to determine whether a requestor has the requisite permissions to access the requested resources from the target blockchain. For example, an access control blockchain may include one or more blocks with one or more access rights associated with one or more of the resources and/or one or more authorized users of the target blockchain.

[00111] An access policy may define one or more permissions associated with one or more authorized users of the target blockchain. In various embodiments, the access policy may define one or more permissions based on type of authorized users, for example, building owners, certifiers, certification organizations, inspectors, or potential purchasers. Alternatively, an access policy may define one or more permissions to one or more users on a case-by-case basis. Example permissions may include, without limitation, read access, write access, copy permission, download permission, and/or the like.

[00112] A rights management system may restrict access to one or more blockchains and/or information stored by one or more blockchains in accordance with one or more applicable access policies. For example, a rights management system may control who can access what information on a blockchain and for what purposes this information may be accessed or further utilized. For instance, a certifier may access building information for a building owner on whose behalf the certifier is working. However, the certifier may not access data of a different building owner.

[00113] As another example, a potential purchaser may access inspection data for a target building that it is considering purchasing (e.g., one that is under contract), but the potential purchaser may not have access to inspection data for other buildings.

[00114] FIG. 6A illustrates a flow chart of an example method of verifying access requests to a target blockchain according to an embodiment. As illustrated by FIG. 6A, a host electronic device may receive 600 an access request from a requestor. In various embodiments, a requestor may be a building owner, a certifier, a certification organization, an inspector, a potential purchaser, another authorized user, and/or the like. The access request may include an indicator of one or more resources stored on the blockchain for which access is sought. A resource refers to information pertaining to the supply, manufacturer, installation, inspection, use, and/or performance of one or more components of a target building having information that is stored on a target blockchain. A resource may be information itself or one or more log records that includes such information. The resources may be identified based on the source of the access request.

[00115] For example, information associated with a component of a target building may be stored and/or indexed according to a unique identifier. Information stored on the blockchain pertaining to the component may be stored in association with its unique identifier.

[00116] The host electronic device may identify 602 one or more blocks of the target blockchain that include at least a portion of the resources. For example, if an inspector would like to know if the characteristics of a component comply with one or more requirements of a building rating system, the inspector may query the blockchain for relevant data pertaining to the component to verify compliance. For example, an inspector may query the blockchain to determine the dates and reports from any previous inspections that may have been conducted.

[00117] The host electronic device may identify 604 the access policy that corresponds to the target blockchain, and may determine 606, based on the access policy whether the requestor is permitted to access the requested resources. For instance, the host electronic device may search the access policy for the requestor’s identity, and may obtain the permissions granted to the requestor. If the request being made by the requestor is permitted by the policy, the host electronic device may grant 608 access to the requested resources to the requestor. Otherwise, the host electronic device may deny 610 access.

[00118] As an example, Building Owner A may make an access request to obtain building information associated with a target building and that is stored on a target blockchain. The access policy for the target blockchain may indicate that Building Owner A is permitted to access its own information (e.g., information that it provided to the target blockchain), and therefore may grant access to the requesting building owner. However, if Building Owner A attempts to access building information associated with a different building owned by Building Owner B, the system may deny the request.

[00119] In various embodiments, the system may determine a unique identifier associated with a requestor. If the unique identifier of the requestor does not match a unique identifier associated with the creator of block for which access is being sought (as specified, for example, by the source log), the system may deny the request. If the unique identifier of the requestor matches a unique identifier associated with the creator of the block for which access is being sought, the system may grant the request.

[00120] The types of queries of a target blockchain that may be made may vary based on the user or type of user requesting the query. For example, a building owner and/or certifier may submit a query to a host electronic device for access to a specification report for one or more components of a target building. As another example, a building owner and/or certifier may query for information pertaining to a certification organization’s building rating information. As yet another example of querying, an inspector may query building information provided by a building owner, certification information provided by a certifier, and/or administration information of a certification organization to assess compliance of a target building or component thereof with one or more applicable building rating system requirements.

[00121] FIGS. 6B-6C show a visual depiction of example access requests according to various embodiments. As shown in FIG. 6B, a portion of an example blockchain 612 includes two building owner blocks 614, 616, two certifier blocks 618, 620, two certification organization blocks 622, 624, and two inspector blocks 626, 628. It is understood that different numbers of one or more such blocks may be used within the scope of this disclosure. [00122] In this example, Building Owner A has shared building information pertaining to Building A to the blockchain. As such, the system may grant a request by Building Owner A to access this building information because the access rights may permit Building Owner A to access information that it has supplied to the blockchain 612.

[00123] In this example, Building Owner B has shared building information pertaining to Building B to the blockchain 612. As such, the system may deny a request by Building Owner A to access this building information because the access rights may prohibit Building Owner A from accessing this information.

[00124] As another example, Inspector B may be performing a certification inspector of Building B for compliance with a building rating system administered by Certification Organization B. As part of this inspection, Inspector B may be allowed to access building information and certification information associated with Building B. However, Inspector B may be prohibited from accessing certification information for Building A.

[00125] As another example, Potential Purchaser A may be under contract to purchase Building A. As part of its diligence, Potential Purchaser A may be permitted to access inspection data associated with Building A. However, Potential Purchaser A may be prohibited from accessing inspection data associated with Building B.

[00126] It is understood that additional and/or alternate access examples, access rights, participants, and/or the like may be used within the scope of this disclosure.

[00127] For example, a building inspector may access certification information for a building, as well as past inspection reports, to determine an on-going certification compliance for a building. [00128] In various embodiments, an authorized blockchain participant may delegate one or more of its access rights to the blockchain to one or more business partners. A business partner refers to an entity, organization, or individual with whom a participant has a business or other relationship. Examples of business partners include, without limitation, customers, clients, partners, manufacturers, installers, inspectors, suppliers, distributors, vendors, agents, affiliates, subsidiaries, contractors, and/or the like.

[00129] For example, a building owner may delegate one or more of its blockchain access rights to one or more of its property managers or subcontractors. Similarly, an authorized certifier may delegate one or more of its blockchain access rights to one or more of its agents, and/or other partners. A certification organization may delegate one or more of its blockchain access rights to one or more inspectors.

[00130] FIG. 7 illustrates an example delegation process according to an embodiment. As illustrated by FIG. 7, the system may generate 700 a token for one or more authorized participants. For example, when an authorized user registers with, enrolls with, and/or accesses the system, the system may generate 700 one or more tokens for the user. A token refers to an object that includes an identifier associated with the user and one or more blockchain access rights granted to that user. In various embodiments, a token may include an indication of the information or resources on a blockchain to which one or more of the access rights apply or correspond. For instance, a participant may have a first set of access rights to a first set of information that is on a blockchain, but a second set of access rights to a second set of information that is stored on the blockchain. A token that is generated for the participant may include a listing of such access rights and information or resources to which each of the access rights apply. Alternatively, the system may generate 700 multiple tokens for a participant, each token corresponding to particular information from the blockchain and one or more applicable access rights.

[00131] For example, FIGS. 9A and 9B illustrate two sets of building information that a building owner may store on a blockchain. The system may generate a token 902 that corresponds to both sets of building information (or at least a portion of both sets) as illustrated in FIG. 9A. As illustrated in FIG. 9A, the token may identify a particular subset of the building information and one or more access rights associated with the subset. In various embodiments, one or more access rights may apply to the building information as a whole rather than on a subset-by-subset basis.

[00132] In other embodiments, the system may generate multiple tokens 904a, 904b as illustrated in FIG. 9B. As shown in FIG. 9B, one token 904a corresponds to the access rights associated with one set of information (Building Information 1), while another token 904b corresponds to access rights associated with another set of information (Building Information 2). It is understood that additional and/or alternate tokens, information, access rights and/or the like may be used within the scope of this disclosure.

[00133] The access rights and information to which they correspond may be determined based on those reflected in one or more access policies associated with the blockchain, as described above. In various embodiments, the access rights may include an indication as to whether a user may delegate one or more access rights may be delegated. The indication may also indicate which access the rights the user may delegate, which information stored on the blockchain such rights may be delegated, how many tiers of delegation are permitted, and/or the like. For example, FIG. 7 illustrates a single tier of delegation (from a participant to one or more business partners). But, in certain embodiments, a participant may be able to delegate one or more rights through multiple tiers of business partners. FIG. 8 illustrates an illustration of an example multiple-tier delegation process according to an embodiment. As illustrated in FIG. 8, a system 800 may issue a token to a participant 802. The participant 802 may delegate one or more of its access rights to access certain information Business Partner 1 804 and Business Partner 2 806. For example, as illustrated in FIG. 8, participant 802 may delegate access rights A and B to Info A Business Partner 1 804, and access rights C and D to Info A Business Partner 2 806. It is understood that additional or alternate right delegations or combinations of delegations may be made within the scope of this disclosure. As illustrated in FIG. 8, this may be considered a single tier of delegation.

[00134] Business Partner 1 804 in turn may delegate at least a portion of its access rights for Info A to Business Partner 3 808, while Business Partner 2 806 may delegate at least a portion of its access rights for Info A to Business Partner 4810 and Business Partner 5 812. As illustrated in FIG. 8, this may be considered a second tier of delegation. Although FIG. 8 illustrates two delegation tiers, it is understood that additional or fewer tiers of delegation may be used within the scope of this disclosure.

[00135] Referring back to FIG. 7, the system may send 702 the generated token to the authorized participant. The authorized participant may receive the token and store 704 the token. In some embodiments, the participant may send the token as part of a communication to the system. For example, a participant may send its token to the system along with an access request. In some embodiments, the system may determine what access rights the participant has based on the received token. In other embodiments, the system may confirm that the access rights denoted in the received token align with the access rights maintained by the system (e.g., those of one or more access policies). [00136] A participant may generate 706 a digital signature for a token by generating, by an electronic device, a hash of at least a portion of the token to generate a hashed value. The participant may encrypt the hashed value with the participant’s private key to generate a digital signature corresponding to the message content.

[00137] A participant may delegate one or more of its access rights to a business partner by providing 708 the business partner with a delegated token and the digital signature corresponding to the delegated token. The delegated token may be the participant’s token (or a portion thereof), a reference to the participant’s token, a new token based on the participant’s token, and/or the like. A participant may only delegate the access rights that it has for certain information. In this way, a participant cannot grant more rights to a delegate that it itself has.

[00138] For example, a building owner may have read access for a first set of building information that includes identification and installation information pertaining to a component of its building. The building owner may have read and modify access for a second set of building information that includes information about personnel at the building. The building owner may delegate its read access to the first set of building information and/or its read/modify access to the second set of building information to one of its property managers. However, the building owner may not delegate modify access to the second set of building information to the property manager because the building owner does not have this right. The delegated token may include an indication of the participant who delegated one or more access rights, and an indication of the one or more delegated access rights.

[00139] The participant may send the token and corresponding digital signature to a business partner. When the business partner makes an access request 710 to the system, it may include the delegated token and the received digital signature with the request. The system may attempt to decrypt 712 the received digital signature using the participant’s public key to yield a received hashed value. If the decryption is successful, the system will know that the token provided by the business partner was issued by the participant. If the decryption is not successful, the system may disregard the communication.

[00140] The system may also verify 714 the integrity of the token. The system may apply the same hashing algorithm(s) used by the participant to generate a hashed value. The system may compare the hashed value it generated to the received hashed value. If the two values are the same, the system has verified that the token has not changed since it was sent. If the values do not match, the system may disregard the communication as the token has been changed after it was sent.

[00141] The system may determine 716 whether the delegating participant has the right to delegate the access rights to the information being requested. For instance, the system may identify the delegating participant from the received token, and may confirm its delegation rights with one or more of the system access policies. If the system determines that the delegating participant does not have the necessary delegation rights for the information being requested, the system may deny the access request.

[00142] Referring to FIG. 4A, in various embodiments, the system may perform 440 one or more verification checks on of the target blockchain. The system may perform 440 one or more verification checks in response to one or more triggering events. A triggering event refers to an action performed on the target blockchain or a request made to the target blockchain. For example, if a request for a particular type of information is made to the target blockchain, the system may perform a verification check to determine whether the requested information is consi stent with other information logged at the target blockchain. Additional and/or alternate triggering events may be used within the scope of this disclosure.

[00143] In other embodiments, the system may perform 440 one or more verification checks at one or more regular intervals, or in response to a user requesting a verification check.

[00144] For example, an inspector may perform a verification check to ensure that a test performed is consistent with a building’s rating. Additional and/or alternate types of comparisons may be performed within the scope of this disclosure.

[00145] In response to the verification check failing, the system may perform 442 one or more remedial actions. For example, in the above example, the system may automatically send one or more notifications if an inconsistency is detected. The notification may be an email or other electronic notification, and the system may send it to one or more applicable parties such as, for example, one or more participants of the system. For example, if a test performed by an inspector should fail to meet expectations, the system may automatically send one or more notifications to a building owner, a certification organization, or other business partner, or one or more other parties. For instance, a target blockchain may include administration information in one or more certification organization blocks that correspond to one or more building rating systems administered by a certification organization. The administration information may include one or more acceptable values and/or ranges of values associated with one or more tests that are performed as part of the building rating system. If an inspector performs a test and the result differs from an acceptable value or is outside of an acceptable range for that test, the system may send one or more notifications to a building owner, a certification organization, or other business partner. [00146] Alternative remedial actions may include opening a case that includes a root cause analysis, making corrective action assignments, and/or identifying one or more proposed preventive measures. In various embodiments, one or more participants of the system may be able to contribute to identifying the root cause and/or proposed one or more corrective or remedial actions.

[00147] FIG. 10 depicts a block diagram of hardware that may be used to contain or implement program instructions, such as those of a cloud-based server, electronic device, virtual machine, or container. A bus 1000 serves as an information highway interconnecting the other illustrated components of the hardware. The bus may be a physical connection between elements of the system, or a wired or wireless communication system via which various elements of the system share data. Processor 1005 is a processing device that performs calculations and logic operations required to execute a program. Processor 1005, alone or in conjunction with one or more of the other elements disclosed in FIG. 10, is an example of a processing device, computing device or processor as such terms are used within this disclosure. The processing device may be a physical processing device, a virtual device contained within another processing device, or a container included within a processing device.

[00148] A memory device 1020 is a hardware element or segment of a hardware element on which programming instructions, data, or both may be stored. Read only memory (ROM) and random access memory (RAM) constitute examples of memory devices, along with cloud storage services.

[00149] An optional display interface 1030 may permit information to be displayed on the display 1035 in audio, visual, graphic or alphanumeric format. Communication with external devices, such as a computing device, may occur using various communication devices 1040, such as a communication port or antenna. A communication device 1040 may be communicatively connected to a communication network, such as the Internet or an intranet.

[00150] The hardware may also include a user input interface 1045 which allows for receipt of data from input devices such as a keyboard or keypad 1050, or other input device 1055 such as a mouse, a touch pad, a touch screen, a remote control, a pointing device, a video input device and/or a microphone. Data also may be received from an image capturing device 1010 such as a digital camera or video camera. A positional sensor 1015 and/or motion sensor 1065 may be included to detect position and movement of the device. Examples of motion sensors 1065 include gyroscopes or accelerometers. An example of a positional sensor 1015 is a global positioning system (GPS) sensor device that receives positional data from an external GPS network.

[00151] Various embodiments may include a computer-readable medium containing programming instructions that are configured to cause one or more processors to perform the functions described in the context of the previous figures.

[00152] The features and functions described above, as well as alternatives, may be combined into many other different systems or applications. Various alternatives, modifications, variations or improvements may be made by those skilled in the art, each of which is also intended to be encompassed by the disclosed embodiments.