COMPUTER-IMPLEMENTED METHODS FOR CONTROLLING RIGHTS RELATED TO DIGITAL KNOWLEDGE

[0001] This application is a continuation of U.S. patent application Ser. No. 17/378,393 (SFTX-0018-U01), filed on Jul. 16, 2021, entitled “SYSTEMS AND METHODS FOR CONTROLLING RIGHTS RELATED TO DIGITAL KNOWLEDGE.”

[0002] U.S. patent application Ser. No. 17/378,393 (SFTX-0018-U01) is a continuation-in-part of U.S. patent application Ser. No. 17/243,145 (SFTX-0017-U01), filed Apr. 28, 2021, entitled “ARTIFICIAL INTELLIGENCE SELECTION AND CONFIGURATION.”

[0003] U.S. patent application Ser. No. 17/243,145 (SFTX-0017-U01) claims the benefit of priority to U.S. Provisional Applications No. 63/016,975 (SFTX-0017-P01), filed on Apr. 28, 2020, entitled “DIGITAL TWIN SYSTEMS FOR FINANCIAL SYSTEMS”; and 63/054,603 (SFTX-0017-P02), filed on Jul. 21, 2020, entitled “DIGITAL TWIN SYSTEMS AND METHODS FOR FINANCIAL SYSTEMS.”

[0004] U.S. patent application Ser. No. 17/378,393 (SFTX-0018-U01) is a continuation-in-part of U.S. patent application Ser. No. 17/332,700 (SFTX-0013-U01), filed May 27, 2021, entitled “AUTOMATED ROBOTIC PROCESS SELECTION AND CONFIGURATION.”

[0005] U.S. patent application Ser. No. 17/378,393 (SFTX-0018-U01) is a continuation-in-part of U.S. patent application Ser. No. 16/780,519 (SFTX-0012-U01), filed Feb. 3, 2020, entitled “ADAPTIVE INTELLIGENCE AND SHARED INFRASTRUCTURE LENDING TRANSACTION ENABLEMENT PLATFORM RESPONSIVE TO CROWD SOURCED INFORMATION.”

[0006] U.S. patent application Ser. No. 17/378,393 (SFTX-0018-U01) is a continuation-in-part of U.S. patent application Ser. No. 16/998,668 (SFTX-0010-U01), filed Aug. 20, 2020, entitled “ROBOTIC PROCESS AUTOMATION SYSTEM FOR NEGOTIATION.”

[0007] U.S. patent application Ser. No. 16/998,668 (SFTX-0010-U01) is a bypass continuation of PCT Application PCT/US19/58671 (Attorney Docket No. SFTX-0010-WO), filed Oct. 29, 2019, entitled “METHODS AND SYSTEMS FOR IMPROVING MACHINES AND SYSTEMS THAT AUTOMATE EXECUTION OF DISTRIBUTED LEDGER AND OTHER TRANSACTIONS IN SPOT AND FORWARD MARKETS FOR ENERGY, COMPUTE, STORAGE AND OTHER RESOURCES.”

[0008] PCT Application PCT/US19/58671 (SFTX-0010-WO) claims the benefit of priority to the following U.S. Provisional Patent Applications: Ser. No. 62/751,713 (Attorney Docket No. SFTX-0003-P01), filed Oct. 29, 2018, entitled “METHODS AND SYSTEMS FOR IMPROVING MACHINES AND SYSTEMS THAT AUTOMATE EXECUTION OF DISTRIBUTED LEDGER AND OTHER TRANSACTIONS IN SPOT AND FORWARD MARKETS FOR ENERGY, COMPUTE, STORAGE AND OTHER RESOURCES”, Ser. No. 62/843,992 (Attorney Docket No. SFTX-0005-P01), filed May 6, 2019, entitled “ADAPTIVE INTELLIGENCE AND SHARED INFRASTRUCTURE LENDING TRANSACTION ENABLEMENT PLATFORM WITH ROBOTIC PROCESS ARCHITECTURE”; Ser. No. 62/818,100 Attorney Docket No. SFTX-0006-P01), filed Mar. 13, 2019, entitled “ROBOTIC PROCESS AUTOMATION ARCHITECTURE, SYSTEMS AND METHODS IN TRANSACTION ENVIRONMENTS”; Ser. No. 62/843,455 (Attorney Docket No. SFTX-0007-P01), filed May 5, 2019, entitled “ADAPTIVE INTELLIGENCE AND SHARED INFRASTRUCTURE LENDING TRANSACTION ENABLEMENT PLATFORM WITH ROBOTIC PROCESS ARCHITECTURE”; and Ser. No. 62/843,456 (Attorney Docket No. SFTX-0008-P01), filed May 5, 2019, entitled ADAPTIVE INTELLIGENCE AND SHARED INFRASTRUCTURE LENDING TRANSACTION ENABLEMENT PLATFORM WITH ROBOTIC PROCESS ARCHITECTURE.”

[0009] U.S. patent application Ser. No. 17/378,393 (SFTX-0018-U01) is a continuation-in-part of U.S. patent application Ser. No. 16/803,387 (SFTX-0009-U01), filed Feb. 27, 2020, entitled “SYSTEM THAT VARIES THE TERMS AND CONDITIONS OF A SUBSIDIZED LOAN.”

[0010] U.S. patent application Ser. No. 17/378,393 (SFTX-0018-U01) is a continuation-in-part of U.S. patent application Ser. No. 16/457,890 (SFTX-0004-U01), filed Jun. 28, 2019, entitled “TRANSACTION-ENABLING SYSTEMS AND METHODS FOR USING A SMART CONTRACT WRAPPER TO ACCESS EMBEDDED CONTRACT TERMS.”

[0011] U.S. patent application Ser. No. 16/457,890 (SFTX-0004-U01) is a bypass continuation of International Application Serial No. PCT/US2019/030934 (SFTX-0004-WO), filed May 6, 2019, entitled “METHODS AND SYSTEMS FOR IMPROVING MACHINES AND SYSTEMS THAT AUTOMATE EXECUTION OF DISTRIBUTED LEDGER AND OTHER TRANSACTIONS IN SPOT AND FORWARD MARKETS FOR ENERGY, COMPUTE, STORAGE AND OTHER RESOURCES.”

[0012] International Application Serial No. PCT/US2019/030934 (SFTX-0004-WO) claims the benefit of priority to the following U.S. Provisional Patent Applications: Ser. No. 62/787,206 (Attorney Docket No. SFTX-0001-P01), filed Dec. 31, 2018, entitled “METHODS AND SYSTEMS FOR IMPROVING MACHINES AND SYSTEMS THAT AUTOMATE EXECUTION OF DISTRIBUTED LEDGER AND OTHER TRANSACTIONS IN SPOT AND FORWARD MARKETS FOR ENERGY, COMPUTE, STORAGE AND OTHER RESOURCES”; Ser. No. 62/667,550 (Attorney Docket No. SFTX-0002-P01), filed May 6, 2018, entitled “METHODS AND SYSTEMS FOR IMPROVING MACHINES AND SYSTEMS THAT AUTOMATE EXECUTION OF DISTRIBUTED LEDGER AND OTHER TRANSACTIONS IN SPOT AND FORWARD MARKETS FOR ENERGY, COMPUTE, STORAGE AND OTHER RESOURCES”; and Ser. No. 62/751,713 (Attorney Docket No. SFTX-0003-P01), filed Oct. 29, 2018, entitled “METHODS AND SYSTEMS FOR IMPROVING MACHINES AND SYSTEMS THAT AUTOMATE EXECUTION OF DISTRIBUTED LEDGER AND OTHER TRANSACTIONS IN SPOT AND FORWARD MARKETS FOR ENERGY, COMPUTE, STORAGE AND OTHER RESOURCES.”

[0013] U.S. patent application Ser. No. 17/378,393 (SFTX-0018-U01) claims the benefit of priority to the following U.S. Provisional Patent Applications: Ser. No. 63/052,475 (Attorney Docket No. SFTX-0018-P01), filed Jul. 16, 2020, entitled “METHODS AND SYSTEMS FOR MANAGEMENT OF DIGITAL KNOWLEDGE”, Ser. No. 63/054,603 (Attorney Docket No. SFTX-0017-P02), filed Jul. 21, 2020, entitled “DIGITAL TWIN SYSTEMS AND METHODS FOR FINANCIAL SYSTEMS”; Ser. No. 63/069,542 (Attorney Docket No. SFTX-0015-P01), filed Aug. 24, 2020, entitled “INFORMATION TECHNOLOGY SYSTEMS AND METHODS FOR TRANSACTION ARTIFICIAL INTELLIGENCE LEVERAGING DIGITAL TWINS”; and Ser. No. 63/127,980 (Attorney Docket No. SFTX-0016-P01), filed Dec. 18, 2020, entitled “MARKET ORCHESTRATION SYSTEM FOR FACILITATING ELECTRONIC MARKETPLACE TRANSACTIONS”.

[0014] Each of the foregoing applications is incorporated herein by reference in its entirety for all purposes.

[0015] An incredible amount of information is digitally exchanged on a regular basis, and the amount is increasing each day. This information can include valuable and sensitive information, such as trade secrets, know how, patented material, and works of authorship. Some of the information is subject to access and control restrictions, such as restrictions on who can view, edit, change, use, transmit, sell, buy, rent, review, license, and source the digital information (e.g., vis-à-vis patent licenses, trademark licenses, contract agreements, copyright licenses, and the like). Setting and enforcing access and control restrictions is difficult, as any computer-based system for doing so has potential flaws, such as risks of impropriety or unreliability of an owner or maintainer of the system, or risks of other parties gaining unauthorized access and illegitimately accessing, copying, editing, or otherwise tampering with the digital knowledge.

[0016] Lending transactions provide financing for a wide variety of needs, ranging from housing and education to corporate and government projects, among many others, while enabling lenders to earn financial returns. However, lending transactions are plagued by a number of problems, including opacity and asymmetry of information, moral hazard induced by shifting of the consequences of risky or inappropriate behavior, complexity of application and negotiation processes, burdensome regulatory and policy regimes, difficulty in determining the value of property that is used as collateral or backing for obligations, difficulty in determining the reliability or financial health of entities, and others.

[0017] Machines and automated agents are increasingly involved in market activities, including for data collection, forecasting, planning, transaction execution, and other activities. This includes increasingly high-performance systems, such as used in high-speed trading. A need exists for methods and systems that improve the machines that enable markets, including for increased efficiency, speed, reliability, and the like for participants in such markets.

[0018] Many markets are increasingly distributed, rather than centralized, with distributed ledgers like Blockchain, peer-to-peer interaction models, and micro-transactions replacing or complementing traditional models that involve centralized authorities or intermediaries. A need exists for improved machines that enable distributed transactions to occur at scale among large numbers of participants, including human participants and automated agents.

[0019] Operations on blockchains, such as ones using cryptocurrency, increasingly require energy-intensive computing operations, such as calculating very large hash functions on growing chains of blocks. Systems using proof-of-work, proof-of-stake, and the like have led to “mining” operations by which computer processing power is applied at a large scale in order to perform calculations that support collective trust in transactions that are recorded in blockchains.

[0020] Many applications of artificial intelligence also require energy-intensive computing operations, such as where very large neural networks, with very large numbers of interconnections, perform operations on large numbers of inputs to produce one or more outputs, such as a prediction, classification, optimization, control output, or the like.

[0021] The growth of the Internet of Things and cloud computing platforms have also led to the proliferation of devices, applications, and connections among them, such that data centers, housing servers and other IT components, consume a significant fraction of the energy consumption of the United States and other developed countries.

[0022] As a result of these and other trends, energy consumption has become a major factor in utilization of computing resources, such that energy resources and computing resources (or simply “energy and compute”) have begun to converge from various standpoints, such as requisitioning, purchasing, provisioning, configuration, and management of inputs, activities, outputs and the like. Projects have been undertaken, for example, to place large scale computing resource facilities, such as Bitcoin™ or other cryptocurrency mining operations, in close proximity to large-scale hydropower sources, such as Niagara Falls.

[0023] A major challenge for facility owners and operators is the uncertainty involved in optimizing a facility, such as resulting from volatility in the cost and availability of inputs (in particular where less stable renewable resources are involved), variability in the cost and availability of computing and networking resources (such as where network performance varies), and volatility and uncertainty in various end markets to which energy and compute resources can be applied (such as volatility in cryptocurrencies, volatility in energy markets, volatility in pricing in various other markets, and uncertainty in the utility of artificial intelligence in a wide range of applications), among other factors.

[0024] Example embodiments herein disclose systems, procedures, and aspects that provide cryptographically secure blockchains for knowledge systems capable of storing digital knowledge for providing convenient and secure control of the same. Example methods and systems herein provide for improvements in determining property valuation, reliability of financial health of entities, transparency, symmetry of information, and application and negotiation processes in the lending environment. Example methods and systems herein provide for improvements to the machines that enable markets, providing for increased efficiency, speed, and/or reliability for participants in such markets. Example methods and systems herein provide for improvements to data collection, storage and processing, automated configuration of inputs, resource, and outputs, and means for facility optimization for an energy and compute facility.

[0025] In one or more example embodiments, a knowledge distribution system for controlling rights related to digital knowledge is disclosed. The knowledge distribution system may be a blockchain for knowledge system that allows for storage of digital knowledge, buying and selling of digital knowledge, tokenization of digital knowledge, and/or reviewing/auditing of the digital knowledge via a cryptographically secure distributed ledger. Smart contracts may be implemented on the distributed ledger and controlling of rights to digital knowledge, transferring digital knowledge, and adherence of parties to agreements related to the digital knowledge. The blockchain for knowledge system can also facilitate third parties reviewing, auditing, or verifying information related to digital knowledge.

[0026] There can be a number of practical obstacles to the sharing of knowledge such as the absence of trust between parties that could potentially benefit from sharing of the knowledge. A platform exists for a digital knowledge distribution system that facilitates orchestration of the sharing of knowledge by providing a high degree of control over the extent to which counterparties can access shared knowledge. Even where knowledge is secure and well-controlled, some types of knowledge are so sensitive that an owner may be unwilling to share the entire set of knowledge with a single counterparty. In embodiments, a platform is disclosed for a digital knowledge distribution system that facilitates handling and control of subsets of knowledge, including automated handling of aggregation of knowledge, or related outputs, that result from division of knowledge subsets.

[0027] The knowledge distribution system may include a ledger management system configured to create and manage a distributed ledger where the distributed ledger may be distributed over nodes of a network and may include blocks linked via cryptography. A smart contract system may be communication with the distributed ledger and may be configured to implement and manage a smart contract via the distributed ledger. The smart contract may be stored in the distributed ledger and may include a triggering event. The smart contract may be configured to perform a smart contract action with respect to the digital knowledge in response to an occurrence of the triggering event. The knowledge distribution system may be configured to receive from a user an instance of the digital knowledge. The digital knowledge may be tokenized such that the instance of the digital knowledge can be manipulated as a token on the distributed ledger. The tokenized digital knowledge may be stored via the distributed ledger. Commitments of parties to the smart contract may be processed. The knowledge distribution system may be configured to manage rights of control of and access to the tokenized digital knowledge according to the smart contract and manage the smart contract action in response to the triggering event.

[0028] One or more of the following example features may be included. The digital knowledge may include intellectual property where the smart contract embeds intellectual property licensing terms for intellectual property embedded in the distributed ledger, and where executing an operation on the distributed ledger may provide access to the intellectual property and may process a commitment of a party to the smart contract to the intellectual property licensing terms. A smart contract wrapper on the distributed ledger may allow an operation on the ledger to add intellectual property to an aggregate stack of intellectual property, may allow an operation on the ledger to add intellectual property to agree to an apportionment of royalties among the parties in the ledger, may allow an operation on the ledger to add intellectual property to an aggregate stack of intellectual property, and/or may allow an operation on the ledger to process a commitment of a party to a contract term. The tokenized digital knowledge may include an instruction set. The distributed ledger may be configured to provide provable access to the instruction set and execute the instruction set on a system resulting in recording a transaction in the distributed ledger. The tokenized digital knowledge may include executable algorithmic logic, a three-dimensional (3D) printer instruction set, an instruction set for a coating process, an instruction set for a semiconductor fabrication process, a firmware program, an instruction set for a field-programmable gate array, serverless code logic, an instruction set for a crystal fabrication system, an instruction set for a food preparation process, an instruction set for a polymer production process, an instruction set for a chemical synthesis process, an instruction set for a biological production process, a data set for a digital twin, and/or a trade secret with an expert wrapper. The system may be configured to aggregate views of a trade secret into a chain that proves which knowledge recipients of the parties have viewed the trade secret. The knowledge distribution system may include a reporting system configured to report an analytic result based on operations performed on the distributed ledger or the digital knowledge. The distributed ledger may be configured to aggregate a set of instructions where an operation on the distributed ledger may add at least one instruction to a pre-existing set of instructions to provide a modified set of instructions. The smart contract may be configured to manage allocation of instruction sub-sets to the distributed ledger and access to the instruction sub-sets. The distributed ledger may be configured to log parties who have contributed to an instance of the digital knowledge by storing data related to the parties in at least one of the blocks. The knowledge distribution system may be configured to log a source of an instance of the digital knowledge by storing data related to the source in at least one of the blocks. The distributed ledger may be configured such that a private network of authorized participants may establish cryptography-based consensus required for verification of new blocks to be added to the blocks. The ledger management system may be configured to facilitate crowdsourcing of information added to a block of the blocks of the distributed ledger. The distributed ledger may be configured such to store a review of an instance of the digital knowledge by a crowdsourcer in a block of the blocks. The distributed ledger may be configured such to store a signature of an instance of the digital knowledge by a crowdsourcer in a block of the blocks. The distributed ledger may be configured such to store a verification of an instance of the digital knowledge by a crowdsourcer in a block of the blocks. The ledger management system may be configured to establish cryptographic currency tokens that may be tradeable among users of the distributed ledger. The knowledge distribution system may include an account management system in communication with the distributed ledger that may be configured to facilitate creation and management of user accounts related to users of the knowledge distribution system. The knowledge distribution system may include a user interface system in communication with the distributed ledger and may be configured to present a user interface to a user of the knowledge distribution system where the user interface allows the user to view data related to an instance of the digital knowledge. The knowledge distribution system may include a marketplace system in communication with the distributed ledger and may be configured to establish and maintain a digital marketplace that may be configured to visually present data related to an instance of the digital knowledge to a user of the knowledge distribution system. The knowledge distribution system may include a knowledge datastore in communication with the distributed ledger and may be configured to store data related to the digital knowledge. The knowledge distribution system may include a client datastore in communication with the distributed ledger and may be configured to store data related to users of the knowledge distribution system. The knowledge distribution system may include a smart contract datastore in communication with the distributed ledger and may be configured to store data related to the smart contract. The knowledge distribution system may include a reporting system in communication with the distributed ledger and may be configured to analyze said tokenized digital knowledge and report an analytic result based on the analysis of the tokenized digital knowledge. The smart contract may be generated using a parameterizable smart contract template. The smart contract may include parameters based on type of digital knowledge to be tokenized. The parameters may include financial parameters, royalty parameters, usage parameters, output produced parameters, allocation of consideration parameters, identity parameters, and/or access condition parameters.

[0029] In other example embodiments, a knowledge distribution system may use a distributed ledger and smart contracts to facilitate management and exchange of access, licensing, and ownership rights of digital knowledge.

[0030] In other example embodiments, a computer-implemented method for controlling rights related to digital knowledge is disclosed. The method may include creating and managing a distributed ledger that is distributed over nodes of a network and includes blocks linked via cryptography. A smart contract may be implemented and managed via the distributed ledger where the smart contract may be stored in the distributed ledger and may include a triggering event. A smart contract action may be performed with respect to the digital knowledge in response to an occurrence of the triggering event. An instance of the digital knowledge may be received. The digital knowledge may be tokenized such that the instance of the digital knowledge can be manipulated as a token on the distributed ledger. The tokenized digital knowledge may be stored via the distributed ledger. Commitments of parties to the smart contract may be processed. The method may include management of rights over control of and access to the tokenized digital knowledge according to the smart contract and management of the smart contract action in response to the triggering event.

[0031] One or more of the following example features may be included. A knowledge exchange for the exchange of the tokenized digital knowledge based on the smart contract may be orchestrated. The knowledge exchange of the tokenized digital knowledge may be integrated with another exchange where the knowledge exchange facilitates exchange of valuable and/or sensitive knowledge related to a subject matter of the other exchange.

[0032] In other example embodiments, a knowledge distribution system for controlling rights related to digital knowledge is disclosed. The knowledge distribution system may include a ledger management system configured to create and manage a distributed ledger. The distributed ledger may be distributed over nodes of a network and may include blocks linked via cryptography. A smart contract system may be in communication with the distributed ledger and may be configured to implement and manage a smart contract via the distributed ledger. The smart contract may be stored in the distributed ledger and may include a triggering event. The smart contract may be configured to perform a smart contract action with respect to the digital knowledge in response to an occurrence of the triggering event. The knowledge distribution system may be configured to receive from a knowledge provider device an instance of the digital knowledge including a three-dimensional (3D) printer instruction set for 3D printing an object. The digital knowledge may be tokenized such that the instance of the digital knowledge may be manipulated as a token on the distributed ledger. The tokenized digital knowledge may be stored via the distributed ledger. Commitments of the knowledge provider and a knowledge recipient of the 3D printer instruction set to the smart contract may be processed. The knowledge distribution system may be configured to manage rights of control of and access to the tokenized digital knowledge according to the smart contract and may manage the smart contract action according to a condition and the triggering event.

[0033] One or more of the following example features may be included. The 3D printer instruction set may include a 3D printing schematic. The object may be at least one of a custom part, a custom product, a manufacturing part, a replacement part, a toy, a medical device, and a tool. The knowledge recipient may use a knowledge recipient device to download and use the 3D printer instruction set. The knowledge recipient device may be at least one of a computing device, a server, a 3D printer, and a manufacturing device. The knowledge recipient may use a knowledge recipient device to purchase the tokenized digital knowledge corresponding to the 3D printer instruction set. The knowledge distribution system may include an event listener configured to listen to an application programming interface (API) that may provide a connection between the knowledge distribution system and a knowledge recipient device of the knowledge recipient. The smart contract may be configured to trigger the condition of the knowledge recipient to make a payment when the 3D printer instruction set may be transferred or used based on the rights of control of and access to the tokenized digital knowledge. The rights of control of and access to the tokenized digital knowledge may include a permission for a user to 3D print using multiple instances of the 3D printer instruction set. The rights of control of and access to the tokenized digital knowledge may include at least one of 3D printer requirements, a time period during which the object can be 3D printed, whether the tokenized digital knowledge is transferred to a downstream knowledge recipient, warranties, disclaimers, indemnifications, and certifications with respect to the object. Information related to the 3D printer instruction set of the tokenized digital knowledge may be modified on the distributed ledger when the 3D printer instruction set is at least one of purchased, downloaded, and used. In examples, information related to the 3D printer instruction set may include at least one of origin, date of creation, names of one or more contributing individuals, groups, and/or companies, pricing, market trends for related schematics, serial numbers, and part identifiers. The smart contract action may be one of an assignment of a serial number to the object that is 3D printed, monitoring for the triggering event, verifying fulfillment of an obligation based on the condition, verifying payment and/or transfer of the tokenized digital knowledge, transferring the tokenized digital knowledge, logging one or more transactions in the distributed ledger, performing one or more operations with respect to the distributed ledger, and creating one or more new blocks in the distributed ledger. The smart contract action may include verifying that the condition is met as defined in the smart contract where the condition may be one of printer requirements, payment received or currency transferred from a knowledge recipient device of the knowledge recipient, and transfer of the tokenized digital knowledge to the knowledge recipient device. When the tokenized digital knowledge may be transferred to a knowledge recipient device of a knowledge recipient, a 3D printer may be configured to print the object according to the 3D printer instruction set. The knowledge distribution system may include a smart contract generator that may be configured to parametrize a smart contract template based on at least one of information provided by the knowledge provider, the condition, and the triggering event.

[0034] In other example embodiments, a computer-implemented method for controlling rights related to digital knowledge is disclosed. The method may include creating and managing a distributed ledger that is distributed over nodes of a network and includes blocks linked via cryptography. A smart contract may be implemented and managed via the distributed ledger where the smart contract may be stored in the distributed ledger and may include a triggering event. A smart contract action may be performed with respect to the digital knowledge in response to an occurrence of the triggering event. The method may include receiving from a knowledge provider device an instance of the digital knowledge that includes a three-dimensional (3D) printer instruction set for 3D printing an object. The digital knowledge may be tokenized such that the instance of the digital knowledge can be manipulated as a token on the distributed ledger. The tokenized digital knowledge may be stored via the distributed ledger. Commitments of the knowledge provider and a knowledge recipient of the 3D printer instruction set to the smart contract may be processed. The method may include management of rights of control of and access to the tokenized digital knowledge according to the smart contract, and management of the smart contract action according to a condition and the triggering event.

[0035] One or more of the following example features may be included. An element of the instance of the digital knowledge via the smart contract may be crowdsourced. The element of the instance of the digital knowledge may be managed by a smart contract system according to the smart contract.

[0036] Provided herein is a lending transaction enablement platform having a set of data-integrated microservices including data collection and monitoring services, blockchain services, and smart contract services for handling lending entities and transactions. The platform is capable of enabling a wide range of dedicated solutions, which may share data collection and storage infrastructure, and which may share or exchange inputs, events, activities, and outputs, such as to reinforce learning, enable automation, and enable adaptive intelligence across the various solutions.

[0037] Aspects of the present disclosure relate to a method for electronically facilitating licensing of one or more personality rights of a licensor. The method may include receiving an access request from a licensee to obtain approval to license personality rights from a set of available licensors. The method may include selectively granting access to the licensee based on the access request. The method may include receiving confirmation of a deposit of an amount of funds from the licensee. The method may include issuing an amount of cryptocurrency corresponding to the amount of funds deposited by the licensee to an account of the licensee. The method may include receiving a smart contract request to create a smart contract governing the licensing of the one or more personality rights of the licensor by the licensee. The smart contract request may indicate one or more terms including a consideration amount of cryptocurrency to be paid to the licensor in exchange for one or more obligations on the licensor. The method may include generating the smart contract based on the smart contract request. The method may include escrowing the consideration amount of cryptocurrency from the account of the licensee. The method may include deploying the smart contract to a distributed ledger. The method may include verifying, by the smart contract, that the licensor has performed the one or more obligations. The method may include, in response to receiving verification that the licensor has performed the one or more obligations, releasing at least a portion of the consideration amount of cryptocurrency into a licensor account of the licensor. The method may include outputting a record indicating a completion of a licensing transaction defined by the smart contract to the distributed ledger.

[0038] Other aspects of the present disclosure relate to a system configured for electronically facilitating licensing of one or more personality rights of a licensor. The system may include one or more hardware processors configured by machine-readable instructions. The processor(s) may be configured to receive an access request from a licensee to obtain approval to license personality rights from a set of available licensors. The processor(s) may be configured to selectively grant access to the licensee based on the access request. The processor(s) may be configured to receive confirmation of a deposit of an amount of funds from the licensee. The processor(s) may be configured to issue an amount of cryptocurrency corresponding to the amount of funds deposited by the licensee to an account of the licensee. The processor(s) may be configured to receive a smart contract request to create a smart contract governing the licensing of the one or more personality rights of the licensor by the licensee. The smart contract request may indicate one or more terms including a consideration amount of cryptocurrency to be paid to the licensor in exchange for one or more obligations on the licensor. The processor(s) may be configured to generate the smart contract based on the smart contract request. The processor(s) may be configured to escrow the consideration amount of cryptocurrency from the account of the licensee. The processor(s) may be configured to deploy the smart contract to a distributed ledger. The processor(s) may be configured to verify, by the smart contract, that the licensor has performed the one or more obligations. The processor(s) may be configured to, in response to receiving verification that the licensor has performed the one or more obligations, release at least a portion of the consideration amount of cryptocurrency into a licensor account of the licensor. The processor(s) may be configured to output a record indicating a completion of a licensing transaction defined by the smart contract to the distributed ledger.

[0204] The term services/microservices (and similar terms) as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, a service/microservice includes any system (or platform) configured to functionally perform the operations of the service, where the system may be data-integrated, including data collection circuits, blockchain circuits, artificial intelligence circuits, and/or smart contract circuits for handling lending entities and transactions. Services/microservices may facilitate data handling and may include facilities for data extraction, transformation and loading; data cleansing and deduplication facilities; data normalization facilities; data synchronization facilities; data security facilities; computational facilities (e.g., for performing pre-defined calculation operations on data streams and providing an output stream); compression and de-compression facilities; analytic facilities (such as providing automated production of data visualizations), data processing facilities, and/or data storage facilities (including storage retention, formatting, compression, migration, etc.), and others.

[0205] Services/microservices may include controllers, processors, network infrastructure, input/output devices, servers, client devices (e.g., laptops, desktops, terminals, mobile devices, and/or dedicated devices), sensors (e.g., IoT sensors associated with one or more entities, equipment, and/or collateral), actuators (e.g., automated locks, notification devices, lights, camera controls, etc.), virtualized versions of any one or more of the foregoing (e.g., outsourced computing resources such as a cloud storage, computing operations; virtual sensors; subscribed data to be gathered such as stock or commodity prices, recordal logs, etc.), and/or include components configured as computer readable instructions that, when performed by a processor, cause the processor to perform one or more functions of the service, etc. Services may be distributed across a number of devices, and/or functions of a service may be performed by one or more devices cooperating to perform the given function of the service.

[0206] Services/microservices may include application programming interfaces that facilitate connection among the components of the system performing the service (e.g., microservices) and between the system to entities (e.g., programs, web sites, user devices, etc.) that are external to the system. Without limitation to any other aspect of the present disclosure, example microservices that may be present in certain embodiments include (a) a multi-modal set of data collection circuits that collect information about and monitor entities related to a lending transaction; (b) blockchain circuits for maintaining a secure historical ledger of events related to a loan, the blockchain circuits having access control features that govern access by a set of parties involved in a loan; (c) a set of application programming interfaces, data integration services, data processing workflows and user interfaces for handling loan-related events and loan-related activities; and (d) smart contract circuits for specifying terms and conditions of smart contracts that govern at least one of loan terms and conditions, loan-related events and loan-related activities. Any of the services/microservices may be controlled by or have control over a controller. Certain systems may not be considered to be a service/microservice. For example, a point of sale device that simply charges a set cost for a good or service may not be a service. In another example, a service that tracks the cost of a good or service and triggers notifications when the value changes may not be a valuation service itself, but may rely on valuation services, and/or may form a portion of a valuation service in certain embodiments. It can be seen that a given circuit, controller, or device may be a service or a part of a service in certain embodiments, such as when the functions or capabilities of the circuit, controller, or device are configured to support a service or microservice as described herein, but may not be a service or part of a service for other embodiments (e.g., where the functions or capabilities of the circuit, controller, or device are not relevant to a service or microservice as described herein). In another example, a mobile device being operated by a user may form a portion of a service as described herein at a first point in time (e.g., when the user accesses a feature of the service through an application or other communication from the mobile device, and/or when a monitoring function is being performed via the mobile device), but may not form a portion of the service at a second point in time (e.g., after a transaction is completed, after the user un-installs an application, and/or when a monitoring function is stopped and/or passed to another device). Accordingly, the benefits of the present disclosure may be applied in a wide variety of processes or systems, and any such processes or systems may be considered a service (or a part of a service) herein.

[0207] One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system ordinarily available to that person, can readily determine which aspects of the present disclosure will benefit a particular system, how to combine processes and systems from the present disclosure to construct, provide performance characteristics (e.g., bandwidth, computing power, time response, etc.), and/or provide operational capabilities (e.g., time between checks, up-time requirements including longitudinal (e.g., continuous operating time) and/or sequential (e.g., time-of-day, calendar time, etc.), resolution and/or accuracy of sensing, data determinations (e.g., accuracy, timing, amount of data), and/or actuator confirmation capability) of components of the service that are sufficient to provide a given embodiment of a service, platform, and/or microservice as described herein. Certain considerations for the person of skill in the art, in determining the configuration of components, circuits, controllers, and/or devices to implement a service, platform, and/or microservice (“service” in the listing following) as described herein include, without limitation: the balance of capital costs versus operating costs in implementing and operating the service; the availability, speed, and/or bandwidth of network services available for system components, service users, and/or other entities that interact with the service; the response time of considerations for the service (e.g., how quickly decisions within the service must be implemented to support the commercial function of the service, the operating time for various artificial intelligence or other high computation operations) and/or the capital or operating cost to support a given response time; the location of interacting components of the service, and the effects of such locations on operations of the service (e.g., data storage locations and relevant regulatory schemes, network communication limitations and/or costs, power costs as a function of the location, support availability for time zones relevant to the service, etc.); the availability of certain sensor types, the related support for those sensors, and the availability of sufficient substitutes (e.g., a camera may require supportive lighting, and/or high network bandwidth or local storage) for the sensing purpose; an aspect of the underlying value of an aspect of the service (e.g., a principal amount of a loan, a value of collateral, a volatility of the collateral value, a net worth or relative net worth of a lender, guarantor, and/or borrower, etc.) including the time sensitivity of the underlying value (e.g., if it changes quickly or slowly relative to the operations of the service or the term of the loan); a trust indicator between parties of a transaction (e.g., history of performance between the parties, a credit rating, social rating, or other external indicator, conformance of activity related to the transaction to an industry standard or other normalized transaction type, etc.); and/or the availability of cost recovery options (e.g., subscriptions, fees, payment for services, etc.) for given configurations and/or capabilities of the service, platform, and/or microservice. Without limitation to any other aspect of the present disclosure, certain operations performed by services herein include: performing real-time alterations to a loan based on tracked data; utilizing data to execute a collateral-backed smart contract; re-evaluating debt transactions in response to a tracked condition or data, and the like. While specific examples of services/microservices and considerations are described herein for purposes of illustration, any system benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein, are specifically contemplated within the scope of the present disclosure.

[0208] Without limitation, services include a financial service (e.g., a loan transaction service), a data collection service (e.g., a data collection service for collecting and monitoring data), a blockchain service (e.g., a blockchain service to maintain secure data), data integration services (e.g., a data integration service to aggregate data), smart contract services (e.g., a smart contract service to determine aspects of smart contracts), software services (e.g., a software service to extract data related to the entities from publicly available information sites), crowdsourcing services (e.g., a crowdsourcing service to solicit and report information), Internet of Things services (e.g., an Internet of Things service to monitor an environment), publishing services (e.g., a publishing services to publish data), microservices (e.g., having a set of application programming interfaces that facilitate connection among the microservices), valuation services (e.g., that use a valuation model to set a value for collateral based on information), artificial intelligence services, market value data collection services (e.g., that monitor and report on marketplace information), clustering services (e.g., for grouping the collateral items based on similarity of attributes), social networking services (e.g., that enables configuration with respect to parameters of a social network), asset identification services (e.g., for identifying a set of assets for which a financial institution is responsible for taking custody), identity management services (e.g., by which a financial institution verifies identities and credentials), and the like, and/or similar functional terminology. Example services to perform one or more functions herein include computing devices; servers; networked devices; user interfaces; inter-device interfaces such as communication protocols, shared information and/or information storage, and/or application programming interfaces (APIs); sensors (e.g., IoT sensors operationally coupled to monitored components, equipment, locations, or the like); distributed ledgers; circuits; and/or computer readable code configured to cause a processor to execute one or more functions of the service. One or more aspects or components of services herein may be distributed across a number of devices, and/or may consolidated, in whole or part, on a given device. In embodiments, aspects or components of services herein may be implemented at least in part through circuits, such as, in non-limiting examples, a data collection service implemented at least in part as a data collection circuit structed to collect and monitor data, a blockchain service implemented at least in part as a blockchain circuit structured to maintain secure data, data integration services implemented at least in part as a data integration circuit structured to aggregate data, smart contract services implemented at least in part as a smart contract circuit structed to determine aspects of smart contracts, software services implemented at least in part as a software service circuit structured to extract data related to the entities from publicly available information sites, crowdsourcing services implemented at least in part as a crowdsourcing circuit structured to solicit and report information, Internet of Things services implemented at least in part as an Internet of Things circuit structured to monitor an environment, publishing services implemented at least in part as a publishing services circuit structured to publish data, microservice service implemented at least in part as a microservice circuit structured to interconnect a plurality of service circuits, valuation service implemented at least in part as valuation services circuit structured to access a valuation model to set a value for collateral based on data, artificial intelligence service implemented at least in part as an artificial intelligence services circuit, market value data collection service implemented at least in part as market value data collection service circuit structured to monitor and report on marketplace information, clustering service implemented at least in part as a clustering services circuit structured to group collateral items based on similarity of attributes, a social networking service implemented at least in part as a social networking analytic services circuit structured to configure parameters with respect to a social network, asset identification services implemented at least in part as an asset identification service circuit for identifying a set of assets for which a financial institution is responsible for taking custody, identity management services implemented at least in part as an identity management service circuit enabling a financial institution to verify identities and credentials, and the like. Accordingly, the benefits of the present disclosure may be applied in a wide variety of systems, and any such systems may be considered with respect to items and services herein, while in certain embodiments a given system may not be considered with respect to items and services herein. One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system ordinarily available to that person, can readily determine which aspects of the present disclosure will benefit a particular system, and/or how to combine processes and systems from the present disclosure to enhance operations of the contemplated system. Among the considerations that one of skill in the art may contemplate to determine a configuration for a particular service include: the distribution and access devices available to one or more parties to a particular transaction; jurisdictional limitations on the storage, type, and communication of certain types of information; requirements or desired aspects of security and verification of information communication for the service; the response time of information gathering, inter-party communications, and determinations to be made by algorithms, machine learning components, and/or artificial intelligence components of the service; cost considerations of the service, including capital expenses and operating costs, as well as which party or entity will bear the costs and availability to recover costs such as through subscriptions, service fees, or the like; the amount of information to be stored and/or communicated to support the service; and/or the processing or computing power to be utilized to support the service.

[0209] The terms items and services (and similar terms) as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, items and service include any items and service, including, without limitation, items and services used as a reward, used as collateral, become the subject of a negotiation, and the like, such as, without limitation, an application for a warranty or guarantee with respect to an item that is the subject of a loan, collateral for a loan, or the like, such as a product, a service, an offering, a solution, a physical product, software, a level of service, quality of service, a financial instrument, a debt, an item of collateral, performance of a service, or other items. Without limitation to any other aspect or description of the present disclosure, items and service include any items and service, including, without limitation, items and services as applied to physical items (e.g., a vehicle, a ship, a plane, a building, a home, real estate property, undeveloped land, a farm, a crop, a municipal facility, a warehouse, a set of inventory, an antique, a fixture, an item of furniture, an item of equipment, a tool, an item of machinery, and an item of personal property), a financial item (e.g., a commodity, a security, a currency, a token of value, a ticket, a cryptocurrency), a consumable item (e.g., an edible item, a beverage), a highly valued item (e.g., a precious metal, an item of jewelry, a gemstone), an intellectual item (e.g., an item of intellectual property, an intellectual property right, a contractual right), and the like. Accordingly, the benefits of the present disclosure may be applied in a wide variety of systems, and any such systems may be considered with respect to items and services herein, while in certain embodiments a given system may not be considered with respect to items and services herein. One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system ordinarily available to that person, can readily determine which aspects of the present disclosure will benefit a particular system, and/or how to combine processes and systems from the present disclosure to enhance operations of the contemplated system.

[0210] The terms agent, automated agent, and similar terms as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, an agent or automated agent may process events relevant to at least one of the value, the condition, and the ownership of items of collateral or assets. The agent or automated agent may also undertake an action related to a loan, debt transaction, bond transaction, subsidized loan, or the like to which the collateral or asset is subject, such as in response to the processed events. The agent or automated agent may interact with a marketplace for purposes of collecting data, testing spot market transactions, executing transactions, and the like, where dynamic system behavior involves complex interactions that a user may desire to understand, predict, control, and/or optimize. Certain systems may not be considered an agent or an automated agent. For example, if events are merely collected but not processed, the system may not be an agent or automated agent. In some embodiments, if a loan-related action is undertaken not in response to a processed event, it may not have been undertaken by an agent or automated agent. One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system ordinarily available to that person, can readily determine which aspects of the present disclosure include and/or benefit from agents or automated agent. Certain considerations for the person of skill in the art, or embodiments of the present disclosure with respect to an agent or automated agent include, without limitation: rules that determine when there is a change in a value, condition or ownership of an asset or collateral, and/or rules to determine if a change warrants a further action on a loan or other transaction, and other considerations. While specific examples of market values and marketplace information are described herein for purposes of illustration, any embodiment benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein are specifically contemplated within the scope of the present disclosure.

[0211] The term marketplace information, market value and similar terms as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, marketplace information and market value describe a status or value of an asset, collateral, food, or service at a defined point or period in time. Market value may refer to the expected value placed on an item in a marketplace or auction setting, or pricing or financial data for items that are similar to the item, asset, or collateral in at least one public marketplace. For a company, market value may be the number of its outstanding shares multiplied by the current share price. Valuation services may include market value data collection services that monitor and report on marketplace information relevant to the value (e.g., market value) of collateral, the issuer, a set of bonds, and a set of assets. a set of subsidized loans, a party, and the like. Market values may be dynamic in nature because they depend on an assortment of factors, from physical operating conditions to economic climate to the dynamics of demand and supply. Market value may be affected by, and marketplace information may include, proximity to other assets, inventory or supply of assets, demand for assets, origin of items, history of items, underlying current value of item components, a bankruptcy condition of an entity, a foreclosure status of an entity, a contractual default status of an entity, a regulatory violation status of an entity, a criminal status of an entity, an export controls status of an entity, an embargo status of an entity, a tariff status of an entity, a tax status of an entity, a credit report of an entity, a credit rating of an entity, a website rating of an entity, a set of customer reviews for a product of an entity, a social network rating of an entity, a set of credentials of an entity, a set of referrals of an entity, a set of testimonials for an entity, a set of behavior of an entity, a location of an entity, and a geolocation of an entity. In certain embodiments, a market value may include information such as a volatility of a value, a sensitivity of a value (e.g., relative to other parameters having an uncertainty associated therewith), and/or a specific value of the valuated object to a particular party (e.g., an object may have more value as possessed by a first party than as possessed by a second party).

[0212] Certain information may not be marketplace information or a market value. For example, where variables related to a value are not market-derived, they may be a value-in-use or an investment value. In certain embodiments, an investment value may be considered a market value (e.g., when the valuating party intends to utilize the asset as an investment if acquired), and not a market value in other embodiments (e.g., when the valuating party intends to immediately liquidate the investment if acquired). One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system ordinarily available to that person, can readily determine which aspects of the present disclosure will benefit from marketplace information or a market value. Certain considerations for the person of skill in the art, in determining whether the term market value is referring to an asset, item, collateral, good, or service include: the presence of other similar assets in a marketplace, the change in value depending on location, an opening bid of an item exceeding a list price, and other considerations. While specific examples of market values and marketplace information are described herein for purposes of illustration, any embodiment benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein are specifically contemplated within the scope of the present disclosure.

[0213] The term apportion value or apportioned value and similar terms as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, apportion value describes a proportional distribution or allocation of value proportionally, or a process to divide and assign value according to a rule of proportional distribution. Apportionment of the value may be to several parties (e.g., each of the several parties is a beneficiary of a portion of the value), to several transactions (e.g., each of the transactions utilizes a portion of the value), and/or in a many-to-many relationship (e.g., a group of objects has an aggregate value that is apportioned between a number of parties and/or transactions). In some embodiments, the value may be a net loss and the apportioned value is the allocation of a liability to each entity. In other embodiments, apportioned value may refer to the distribution or allocation of an economic benefit, real estate, collateral or the like. In certain embodiments, apportionment may include a consideration of the value relative to the parties—for example, a $10 million asset apportioned 50/50 between two parties, where the parties have distinct value considerations for the asset, may result in one party crediting the apportionment differing resulting values from the apportionment. In certain embodiments, apportionment may include a consideration of the value relative to given transactions—for example a first type of transaction (e.g., a long-term loan) may have a different valuation of a given asset than a second type of transaction (e.g., a short-term line of credit).

[0214] Certain conditions or processes may not relate to apportioned value. For example, the total value of an item may provide its inherent worth, but not how much of the value is held by each identified entity. One of skill in the art, having the benefit of the disclosure herein and knowledge about apportioned value, can readily determine which aspects of the present disclosure will benefit a particular application for apportioned value. Certain considerations for the person of skill in the art, or embodiments of the present disclosure with respect to an apportioned value include, without limitation: the currency of the principal sum, the anticipated transaction type (loan, bond or debt), the specific type of collateral, the ratio of the loan to value, the ratio of the collateral to the loan, the gross transaction/loan amount, the amount of the principal sum, the number of entities owed, the value of the collateral, and the like. While specific examples of apportioned values are described herein for purposes of illustration, any embodiment benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein are specifically contemplated within the scope of the present disclosure.

[0215] The term financial condition and similar terms as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, financial condition describes a current status of an entity's assets, liabilities, and equity positions at a defined point or period in time. The financial condition may be memorialized in financial statement. The financial condition may further include an assessment of the ability of the entity to survive future risk scenarios or meet future or maturing obligations. Financial condition may be based on a set of attributes of the entity selected from among a publicly stated valuation of the entity, a set of property owned by the entity as indicated by public records, a valuation of a set of property owned by the entity, a bankruptcy condition of an entity, a foreclosure status of an entity, a contractual default status of an entity, a regulatory violation status of an entity, a criminal status of an entity, an export controls status of an entity, an embargo status of an entity, a tariff status of an entity, a tax status of an entity, a credit report of an entity, a credit rating of an entity, a website rating of an entity, a set of customer reviews for a product of an entity, a social network rating of an entity, a set of credentials of an entity, a set of referrals of an entity, a set of testimonials for an entity, a set of behavior of an entity, a location of an entity, and a geolocation of an entity. A financial condition may also describe a requirement or threshold for an agreement or loan. For example, conditions for allowing a developer to proceed may be various certifications and their agreement to a financial payout. That is, the developer's ability to proceed is conditioned upon a financial element, among others. Certain conditions may not be a financial condition. For example, a credit card balance alone may be a clue as to the financial condition, but may not be the financial condition on its own. In another example, a payment schedule may determine how long a debt may be on an entity's balance sheet, but in a silo may not accurately provide a financial condition. One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system ordinarily available to that person, can readily determine which aspects of the present disclosure include and/or will benefit from a financial condition. Certain considerations for the person of skill in the art, in determining whether the term financial condition is referring to a current status of an entity's assets, liabilities, and equity positions at a defined point or period in time and/or for a given purpose include: the reporting of more than one financial data point, the ratio of a loan to value of collateral, the ratio of the collateral to the loan, the gross transaction/loan amount, the credit scores of the borrower and the lender, and other considerations. While specific examples of financial conditions are described herein for purposes of illustration, any embodiment benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein are specifically contemplated within the scope of the present disclosure.

[0216] The term interest rate and similar terms, as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, interest rate includes an amount of interest due per period, as a proportion of an amount lent, deposited or borrowed. The total interest on an amount lent or borrowed may depend on the principal sum, the interest rate, the compounding frequency, and the length of time over which it is lent, deposited or borrowed. Typically, interest rate is expressed as an annual percentage but can be defined for any time period. The interest rate relates to the amount a bank or other lender charges to borrow its money, or the rate a bank or other entity pays its savers for keeping money in an account. Interest rate may be variable or fixed. For example, an interest rate may vary in accordance with a government or other stakeholder directive, the currency of the principal sum lent or borrowed, the term to maturity of the investment, the perceived default probability of the borrower, supply and demand in the market, the amount of collateral, the status of an economy, or special features like call provisions. In certain embodiments, an interest rate may be a relative rate (e.g., relative to a prime rate, an inflation index, etc.). In certain embodiments, an interest rate may further consider costs or fees applied (e.g., “points”) to adjust the interest rate. A nominal interest rate may not be adjusted for inflation while a real interest rate takes inflation into account. Certain examples may not be an interest rate for purposes of particular embodiments. For example, a bank account growing by a fixed dollar amount each year, and/or a fixed fee amount, may not be an example of an interest rate for certain embodiments. One of skill in the art, having the benefit of the disclosure herein and knowledge about interest rates, can readily determine the characteristics of an interest rate for a particular embodiment. Certain considerations for the person of skill in the art, or embodiments of the present disclosure with respect to an interest rate include, without limitation: the currency of the principal sum, variables for setting an interest rate, criteria for modifying an interest rate, the anticipated transaction type (loan, bond or debt), the specific type of collateral, the ratio of the loan to value, the ratio of the collateral to the loan, the gross transaction/loan amount, the amount of the principal sum, the appropriate lifespans of transactions and/or collateral for a particular industry, the likelihood that a lender will sell and/or consolidate a loan before the term, and the like. While specific examples of interest rates are described herein for purposes of illustration, any embodiment benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein are specifically contemplated within the scope of the present disclosure.

[0217] The term valuation services (and similar terms) as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, a valuation service includes any service that sets a value for a good or service. Valuation services may use a valuation model to set a value for collateral based on information from data collection and monitoring services. Smart contract services may process output from the set of valuation services and assign items of collateral sufficient to provide security for a loan and/or apportion value for an item of collateral among a set of lenders and/or transactions. Valuation services may include artificial intelligence services that may iteratively improve the valuation model based on outcome data relating to transactions in collateral. Valuation services may include market value data collection services that may monitor and report on marketplace information relevant to the value of collateral. Certain processes may not be considered to be a valuation service. For example, a point of sale device that simply charges a set cost for a good or service may not be a valuation service. In another example, a service that tracks the cost of a good or service and triggers notifications when the value changes may not be a valuation service itself, but may rely on valuation services and/or form a part of a valuation service. Accordingly, the benefits of the present disclosure may be applied in a wide variety of processes systems, and any such processes or systems may be considered a valuation service herein, while in certain embodiments a given service may not be considered a valuation service herein. One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system ordinarily available to that person, can readily determine which aspects of the present disclosure will benefit a particular system and how to combine processes and systems from the present disclosure to enhance operations of the contemplated system and/or to provide a valuation service. Certain considerations for the person of skill in the art, in determining whether a contemplated system is a valuation service and/or whether aspects of the present disclosure can benefit or enhance the contemplated system include, without limitation: perform real-time alterations to a loan based on a value of a collateral; utilize marketplace data to execute a collateral-backed smart contract; re-evaluate collateral based on a storage condition or geolocation; the tendency of the collateral to have a volatile value, be utilized, and/or be moved; and the like. While specific examples of valuation services and considerations are described herein for purposes of illustration, any system benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein, are specifically contemplated within the scope of the present disclosure.

[0218] The term collateral attributes (and similar terms) as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, collateral attributes include any identification of the durability (ability of the collateral to withstand wear or the useful life of the collateral), value, identification (does the collateral have definite characteristics that make it easy to identify or market), stability of value (does the collateral maintain value over time), standardization, grade, quality, marketability, liquidity, transferability, desirability, trackability, deliverability (ability of the collateral be delivered or transfer without a deterioration in value), market transparency (is the collateral value easily verifiable or widely agreed upon), physical or virtual. Collateral attributes may be measured in absolute or relative terms, and/or may include qualitative (e.g., categorical descriptions) or quantitative descriptions. Collateral attributes may be different for different industries, products, elements, uses, and the like. Collateral attributes may be assigned quantitative or qualitative values. Values associated with collateral attributes may be based on a scale (such as 1-10) or a relative designation (high, low, better, etc.). Collateral may include various components; each component may have collateral attributes. Collateral may, therefore, have multiple values for the same collateral attribute. In some embodiments, multiple values of collateral attributes may be combined to generate one value for each attribute. Some collateral attributes may apply only to specific portions of collateral. Some collateral attributes, even for a given component of the collateral, may have distinct values depending upon the party of interest (e.g., a party that values an aspect of the collateral more highly than another party) and/or depending upon the type of transaction (e.g., the collateral may be more valuable or appropriate for a first type of loan than for a second type of loan). Certain attributes associated with collateral may not be collateral attributes as described herein depending upon the purpose of the collateral attributes herein. For example, a product may be rated as durable relative to similar products; however, if the life of the product is much lower than the term of a particular loan in consideration, the durability of the product may be rated differently (e.g., not durable) or irrelevant (e.g., where the current inventory of the product is attached as the collateral, and is expected to change out during the term of the loan). Accordingly, the benefits of the present disclosure may be applied to a variety of attributes, and any such attributes may be considered collateral attributes herein, while in certain embodiments a given attribute may not be considered a collateral attribute herein. One of skill in the art, having the benefit of the disclosure herein and knowledge about contemplated collateral attributes ordinarily available to that person, can readily determine which aspects of the present disclosure will benefit a particular collateral attribute. Certain considerations for the person of skill in the art, in determining whether a contemplated attribute is a collateral attribute and/or whether aspects of the present disclosure can benefit or enhance the contemplated system include, without limitation: the source of the attribute and the source of the value of the attribute (e.g. does the attribute and attribute value comes from a reputable source), the volatility of the attribute (e.g. does the attribute values for the collateral fluctuate, is the attribute a new attribute for the collateral), relative differences in attribute values for similar collateral, exceptional values for attributes (e.g., some attribute values may be high, such as, in the 98th percentile or very low, such as in the 2nd percentile, compared to similar class of collateral), the fungibility of the collateral, the type of transaction related to the collateral, and/or the purpose of the utilization of collateral for a particular party or transaction. While specific examples of collateral attributes and considerations are described herein for purposes of illustration, any system benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein, are specifically contemplated within the scope of the present disclosure.

[0219] The term blockchain services (and similar terms) as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, blockchain services include any service related to the processing, recordation, and/or updating of a blockchain, and may include services for processing blocks, computing hash values, generating new blocks in a blockchain, appending a block to the blockchain, creating a fork in the blockchain, merging of forks in the blockchain, verifying previous computations, updating a shared ledger, updating a distributed ledger, generating cryptographic keys, verifying transactions, maintaining a blockchain, updating a blockchain, verifying a blockchain, generating random numbers. The services may be performed by execution of computer readable instructions on local computers and/or by remote servers and computers. Certain services may not be considered blockchain services individually but may be considered blockchain services based on the final use of the service and/or in a particular embodiment—for example, a computing a hash value may be performed in a context outside of a blockchain such in the context of secure communication. Some initial services may be invoked without first being applied to blockchains, but further actions or services in conjunction with the initial services may associate the initial service with aspects of blockchains. For example, a random number may be periodically generated and stored in memory; the random numbers may initially not be generated for blockchain purposes but may be utilized for blockchains. Accordingly, the benefits of the present disclosure may be applied in a wide variety of services, and any such services may be considered blockchain services herein, while in certain embodiments a given service may not be considered a blockchain service herein. One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated blockchain service ordinarily available to that person, can readily determine which aspects of the present disclosure can be configured to implement, and/or will benefit, a particular blockchain service. Certain considerations for the person of skill in the art, in determining whether a contemplated service is a blockchain service and/or whether aspects of the present disclosure can benefit or enhance the contemplated system include, without limitation: the application of the service, the source of the service (e.g., if the service is associated with a known or verifiable blockchain service provider), responsiveness of the service (e.g., some blockchain services may have an expected completion time, and/or may be determined through utilization), cost of the service, the amount of data requested for the service, and/or the amount of data generated by the service (blocks of blockchain or keys associated with blockchains may be a specific size or a specific range of sizes). While specific examples of blockchain services and considerations are described herein for purposes of illustration, any system benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein, are specifically contemplated within the scope of the present disclosure.

[0220] The term blockchain (and variations such as cryptocurrency ledger, and the like) as utilized herein may be understood broadly to describe a cryptocurrency ledger that records, administrates or otherwise processes online transactions. A blockchain may be public, private, or a combination thereof, without limitation. A blockchain may also be used to represent a set of digital transactions, agreement, terms or other digital value. Without limitation to any other aspect or description of the present disclosure, in the former case, a blockchain may also be used in conjunction with investment applications, token-trading applications, and/or digital/cryptocurrency based marketplaces. A blockchain can also be associated with rendering consideration, such as providing goods, services, items, fees, access to a restricted area or event, data or other valuable benefit. Blockchains in various forms may be included where discussing a unit of consideration, collateral, currency, cryptocurrency or any other form of value. One of skill in the art, having the benefit of the disclosure herein and knowledge ordinarily available about a contemplated system, can readily determine the value symbolized or represented by a blockchain. While specific examples of blockchains are described herein for purposes of illustration, any embodiment benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein, are specifically contemplated within the scope of the present disclosure.

[0221] The terms ledger and distributed ledger (and similar terms) as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, a ledger may be a document, file, computer file, database, book, and the like which maintains a record of transactions. Ledgers may be physical or digital. Ledgers may include records related to sales, accounts, purchases, transactions, assets, liabilities, incomes, expenses, capital, and the like. Ledgers may provide a history of transactions that may be associated with time. Ledgers may be centralized or decentralized/distributed. A centralized ledger may be a document that is controlled, updated, or viewable by one or more selected entities or a clearinghouse and wherein changes or updates to the ledger are governed or controlled by the entity or clearinghouse. A distributed ledger may be a ledger that is distributed across a plurality of entities, participants or regions which may independently, concurrently, or consensually, update, or modify their copies of the ledger. Ledgers and distributed ledgers may include security measures and cryptographic functions for signing, concealing, or verifying content. In the case of distributed ledgers, blockchain technology may be used. In the case of distributed ledgers implemented using blockchain, the ledger may be Merkle trees comprising a linked list of nodes in which each node contains hashed or encrypted transactional data of the previous nodes. Certain records of transactions may not be considered ledgers. A file, computer file, database, or book may or may not be a ledger depending on what data it stores, how the data is organized, maintained, or secured. For example, a list of transactions may not be considered a ledger if it cannot be trusted or verified, and/or if it is based on inconsistent, fraudulent, or incomplete data. Data in ledgers may be organized in any format such as tables, lists, binary streams of data, or the like which may depend on convenience, source of data, type of data, environment, applications, and the like. A ledger that is shared among various entities may not be a distributed ledger, but the distinction of distributed may be based on which entities are authorized to make changes to the ledger and/or how the changes are shared and processed among the different entities. Accordingly, the benefits of the present disclosure may be applied in a wide variety of data, and any such data may be considered ledgers herein, while in certain embodiments a given data may not be considered a ledger herein. One of skill in the art, having the benefit of the disclosure herein and knowledge about contemplated ledgers and distributed ledger ordinarily available to that person, can readily determine which aspects of the present disclosure can be utilized to implement, and/or will benefit a particular ledger. Certain considerations for the person of skill in the art, in determining whether a contemplated data is a ledger and/or whether aspects of the present disclosure can benefit or enhance the contemplated ledger include, without limitation: the security of the data in the ledger (can the data be tampered or modified), the time associated with making changes to the data in the ledger, cost of making changes (computationally and monetarily), detail of data, organization of data (does the data need to be processed for use in an application), who controls the ledger (can the party be trusted or relied to manage the ledger), confidentiality of the data (who can see or track the data in the ledger), size of the infrastructure, communication requirements (distributed ledgers may require a communication interface or specific infrastructure), resiliency. While specific examples of blockchain services and considerations are described herein for purposes of illustration, any system benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein, are specifically contemplated within the scope of the present disclosure.

[0222] The term loan (and similar terms) as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, a loan may be an agreement related to an asset that is borrowed, and that is expected to be returned in kind (e.g., money borrowed and money returned) or as an agreed transaction (e.g., a first good or service is borrowed, and money, a second good or service, or a combination, is returned). Assets may be money, property, time, physical objects, virtual objects, services, a right (e.g., a ticket, a license, or other rights), a depreciation amount, a credit (e.g., a tax credit, an emissions credit, etc.), an agreed assumption of a risk or liability, and/or any combination thereof. A loan may be based on a formal or informal agreement between a borrower and a lender wherein a lender may provide an asset to the borrower for a predefined amount of time, a variable period of time, or indefinitely. Lenders and borrowers may be individuals, entities, corporations, governments, groups of people, organizations, and the like. Loan types may include mortgage loans, personal loans, secured loans, unsecured loans, concessional loans, commercial loans, microloans, and the like. The agreement between the borrower and the lender may specify terms of the loan. The borrower may be required to return an asset or repay with a different asset than was borrowed. In some cases, a loan may require interest to be repaid on the borrowed asset. Borrowers and lenders may be intermediaries between other entities and may never possess or use the asset. In some embodiments, a loan may not be associated with direct transfer of goods but may be associated with usage rights or shared usage rights. In certain embodiments, the agreement between the borrower and the lender may be executed between the borrower and the lender, and/or executed between an intermediary (e.g., a beneficiary of a loan right such as through a sale of the loan). In certain embodiment, the agreement between the borrower and the lender may be executed through services herein, such as through a smart contract service that determines at least a portion of the terms and conditions of the loans, and in certain embodiments may commit the borrower and/or the lender to the terms of the agreement, which may be a smart contract. In certain embodiments, the smart contract service may populate the terms of the agreement, and present them to the borrower and/or lender for execution. In certain embodiments, the smart contract service may automatically commit one of the borrower or the lender to the terms (at least as an offer) and may present the offer to the other one of the borrower or the lender for execution. In certain embodiments, a loan agreement may include multiple borrowers and/or multiple lenders, for example where a set of loans includes a number of beneficiaries of payment on the set of loans, and/or a number of borrowers on the set of loans. In certain embodiments, the risks and/or obligations of the set of loans may be individualized (e.g., each borrower and/or lender is related to specific loans of the set of loans), apportioned (e.g., a default on a particular loan has an associated loss apportioned between the lenders), and/or combinations of these (e.g., one or more subsets of the set of loans is treated individually and/or apportioned).

[0223] Certain agreements may not be considered a loan. An agreement to transfer or borrow assets may not be a loan depending on what assets are transferred, how the assets were transferred, or the parties involved. For example, in some cases, the transfer of assets may be for an indefinite time and may be considered a sale of the asset or a permanent transfer. Likewise, if an asset is borrowed or transferred without clear or definite terms or lack of consensus between the lender and the borrower it may, in some cases, not be considered a loan. An agreement may be considered a loan even if a formal agreement is not directly codified in a written agreement as long as the parties willingly and knowingly agreed to the arrangement, and/or ordinary practices (e.g., in a particular industry) may treat the transaction as a loan. Accordingly, the benefits of the present disclosure may be applied in a wide variety of agreements, and any such agreement may be considered a loan herein, while in certain embodiments a given agreement may not be considered a loan herein. One of skill in the art, having the benefit of the disclosure herein and knowledge about contemplated loans ordinarily available to that person, can readily determine which aspects of the present disclosure implement a loan, utilize a loan, or benefit a particular loan transaction. Certain considerations for the person of skill in the art, in determining whether a contemplated data is a loan and/or whether aspects of the present disclosure can benefit or enhance the contemplated loan include, without limitation: the value of the assets involved, the ability of the borrower to return or repay the loan, the types of assets involved (e.g., whether the asset is consumed through utilization), the repayment time frame associated with the loan, the interest on the loan, how the agreement of the loan was arranged, formality of the agreement, detail of the agreement, the detail of the agreements of the loan, the collateral attributes associated with the loan, and/or the ordinary business expectations of any of the foregoing in a particular context. While specific examples of loans and considerations are described herein for purposes of illustration, any system benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein, are specifically contemplated within the scope of the present disclosure.

[0224] The term loan related event(s) (and similar terms, including loan-related events) as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, a loan related events may include any event related to terms of the loan or events triggered by the agreement associated with the loan. Loan-related events may include default on loan, breach of contract, fulfillment, repayment, payment, change in interest, late fee assessment, refund assessment, distribution, and the like. Loan-related events may be triggered by explicit agreement terms; for example—an agreement may specify a rise in interest rate after a time period has elapsed from the beginning of the loan; the rise in interest rate triggered by the agreement may be a loan related event. Loan-related events may be triggered implicitly by related loan agreement terms. In certain embodiments, any occurrence that may be considered relevant to assumptions of the loan agreement, and/or expectations of the parties to the loan agreement, may be considered an occurrence of an event. For example, if collateral for a loan is expected to be replaceable (e.g., an inventory as collateral), then a change in inventory levels may be considered an occurrence of a loan related event. In another example, if review and/or confirmation of the collateral is expected, then a lack of access to the collateral, the disablement or failure of a monitoring sensor, etc. may be considered an occurrence of a loan related event. In certain embodiments, circuits, controllers, or other devices described herein may automatically trigger the determination of a loan-related events. In some embodiments, loan-related events may be triggered by entities that manage loans or loan-related contracts. Loan-related events may be conditionally triggered based on one or more conditions in the loan agreement. Loan related events may be related to tasks or requirements that need to be completed by the lender, borrower, or a third party. Certain events may be considered loan-related events in certain embodiments and/or in certain contexts, but may not be considered a loan-related event in another embodiment or context. Many events may be associated with loans but may be caused by external triggers not associated with a loan. However, in certain embodiments, an externally triggered event (e.g., a commodity price change related to a collateral item) may be loan-related events. For example, renegotiation of loan terms initiated by a lender may not be considered a loan related event if the terms and/or performance of the existing loan agreement did not trigger the renegotiation. Accordingly, the benefits of the present disclosure may be applied in a wide variety of events, and any such event may be considered a loan related event herein, while in certain embodiments given events may not be considered a loan related event herein. One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system ordinarily available to that person, can readily determine which aspects of the present disclosure may be considered a loan-related event for the contemplated system and/or for particular transactions supported by the system. Certain considerations for the person of skill in the art, in determining whether a contemplated data is a loan related event and/or whether aspects of the present disclosure can benefit or enhance the contemplated transaction system include, without limitation: the impact of the related event on the loan (events that cause default or termination of the loan may have higher impact), the cost (capital and/or operating) associated with the event, the cost (capital and/or operating) associated with monitoring for an occurrence of the event, the entities responsible for responding to the event, a time period and/or response time associated with the event (e.g., time required to complete the event and time that is allotted from the time the event is triggered to when processing or detection of the event is desired to occur), the entity responsible for the event, the data required for processing the event (e.g., confidential information may have different safeguards or restrictions), the availability of mitigating actions if an undetected event occurs, and/or the remedies available to an at-risk party if the event occurs without detection. While specific examples of loan-related events and considerations are described herein for purposes of illustration, any system benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein, are specifically contemplated within the scope of the present disclosure.

[0225] The term loan-related activities (and similar terms) as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, a loan related activity may include activities related to the generation, maintenance, termination, collection, enforcement, servicing, billing, marketing, ability to perform, or negotiation of a loan. Loan-related activity may include activities related to the signing of a loan agreement or a promissory note, review of loan documents, processing of payments, evaluation of collateral, evaluation of compliance of the borrower or lender to the loan terms, renegotiation of terms, perfection of security or collateral for the loan, and/or a negation of terms. Loan-related activities may relate to events associated with a loan before formal agreement on the terms, such as activities associated with initial negotiations. Loan-related activities may relate to events during the life of the loan and after the termination of a loan. Loan-related activities may be performed by a lender, borrower, or a third party. Certain activities may not be considered loan related activities services individually but may be considered loan related activities based on the specificity of the activity to the loan lifecycle—for example, billing or invoicing related to outstanding loans may be considered a loan related activity, however when the invoicing or billing of loans is combined with billing or invoicing for non loan-related elements the invoicing may not be considered a loan related activity. Some activities may be performed in relation to an asset regardless if a loan is associated with the asset; in these cases, the activity may not be considered a loan related activity. For example, regular audits related to an asset may occur regardless if the asset is associated with a loan and may not be considered a loan related activity. In another example, a regular audit related to an asset may be required by a loan agreement and would not typically occur but for the association with a loan, in this case, the activity may be considered a loan related activity. In some embodiments, activities may be considered loan-related activities if the activity would otherwise not occur if the loan is not active or present, but may still be considered a loan-related activity in some instances (e.g., if auditing occurs normally, but the lender does not have the ability to enforce or review the audit, then the audit may be considered a loan-related activity even though it already occurs otherwise). Accordingly, the benefits of the present disclosure may be applied in a wide variety of events, and any such event may be considered a loan related event herein, while in certain embodiments given events may not be considered a loan related events herein. One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system ordinarily available to that person, can readily determine a loan related activity for the purposes of the contemplated system. Certain considerations for the person of skill in the art, in determining whether a contemplated data is a loan related activity and/or whether aspects of the present disclosure can benefit or enhance the contemplated loan include, without limitation: the necessity of the activity for the loan (can the loan agreement or terms be satisfied without the activity), the cost of the activity, the specificity of the activity to the loan (is the activity similar or identical to other industries), time involved in the activity, the impact of the activity on a loan life cycle, entity performing the activity, amount of data required for the activity (does the activity require confidential information related to the loan, or personal information related to the entities), and/or the ability of parties to enforce and/or review the activity. While specific examples of loan-related events and considerations are described herein for purposes of illustration, any system benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein, are specifically contemplated within the scope of the present disclosure.

[0226] The terms loan-terms, loan terms, terms for a loan, terms and conditions, and the like as utilized herein should be understood broadly (“loan terms”). Without limitation to any other aspect or description of the present disclosure, loan terms may relate to conditions, rules, limitations, contract obligations, and the like related to the timing, repayment, origination, and other enforceable conditions agreed to by the borrower and the lender of the loan. Loan terms may be specified in a formal contract between a borrower and the lender. Loan terms may specify aspects of an interest rate, collateral, foreclose conditions, consequence of debt, payment options, payment schedule, a covenant, and the like. Loan terms may be negotiable or may change during the life of a loan. Loan terms may be change or be affected by outside parameters such as market prices, bond prices, conditions associated with a lender or borrower, and the like. Certain aspects of a loan may not be considered loan terms. In certain embodiments, aspects of loan that have not been formally agreed upon between a lender and a borrower, and/or that are not ordinarily understood in the course of business (and/or the particular industry) may not be considered loan terms. Certain aspects of a loan may be preliminary or informal until they have been formally agreed or confirmed in a contract or a formal agreement. Certain aspects of a loan may not be considered loan terms individually but may not be considered loan terms based on the specificity of the aspect to a specific loan. Certain aspects of a loan may not be considered loan terms at a particular time during the loan, but may be considered loan terms at another time during the loan (e.g., obligations and/or waivers that may occur through the performance of the parties, and/or expiration of a loan term). For example, an interest rate may generally not be considered a loan term until it is defined in relation of a loan and defined as to how the interest compounded (annual, monthly), calculated, and the like. An aspect of a loan may not be considered a term if it is indefinite or unenforceable. Some aspects may be manifestations or related to terms of a loan but may themselves not be the terms. For example, a loan term may be the repayment period of a loan, such as one year. The term may not specify how the loan is to be repaid in the year. The loan may be repaid with 12 monthly payments or one annual payment. A monthly payment plan in this case may not be considered a loan term as it can be just one or many options for repayment not directly specified by a loan. Accordingly, the benefits of the present disclosure may be applied in a wide variety of loan aspects, and any such aspect may be considered a loan term herein, while in certain embodiments given aspects may not be considered loan terms herein. One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system ordinarily available to that person, can readily determine which aspects of the present disclosure are loan terms for the contemplated system.

[0227] Certain considerations for the person of skill in the art, in determining whether a contemplated data is a loan term and/or whether aspects of the present disclosure can benefit or enhance the contemplated loan include, without limitation: the enforceability of the terms (can the conditions be enforced by the lender or the lender or the borrower), the cost of enforcing the terms (amount of time, or effort required ensure the conditions are being followed), the complexity of the terms (how easily can they be followed or understood by the parties involved, are the terms error prone or easily misunderstood), entities responsible for the terms, fairness of the terms, stability of the terms (how often do they change), observability of the terms (can the terms be verified by a another party), favorability of the terms to one party (do the terms favor the borrower or the lender), risk associated with the loan (terms may depend on the probability that the loan may not be repaid), characteristics of the borrower or lender (their ability to meet the terms), and/or ordinary expectations for the loan and/or related industry.

[0228] While specific examples of loan terms are described herein for purposes of illustration, any system benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein, are specifically contemplated within the scope of the present disclosure.

[0229] The term loan conditions, loan-conditions, conditions for a loan, terms and conditions, and the like as utilized herein should be understood broadly (“loan conditions”). Without limitation to any other aspect or description of the present disclosure, loan conditions may relate to rules, limits, and/or obligations related to a loan. Loan conditions may relate to rules or necessary obligations for obtaining a loan, for maintaining a loan, for applying for a loan, for transferring a loan, and the like. Loan conditions may include principal amount of debt, a balance of debt, a fixed interest rate, a variable interest rate, a payment amount, a payment schedule, a balloon payment schedule, a specification of collateral, a specification of substitutability of collateral, treatment of collateral, access to collateral, a party, a guarantee, a guarantor, a security, a personal guarantee, a lien, a duration, a covenant, a foreclose condition, a default condition, conditions related to other debts of the borrower, and a consequence of default.

[0230] Certain aspects of a loan may not be considered loan conditions. Aspects of loan that have not been formally agreed upon between a lender and a borrower, and/or that are not ordinarily understood in the course of business (and/or the particular industry), may not be considered loan conditions. Certain aspects of a loan may be preliminary or informal until they have been formally agreed or confirmed in a contract or a formal agreement. Certain aspects of a loan may not be considered loan conditions individually but may be considered loan conditions based on the specificity of the aspect to a specific loan. Certain aspects of a loan may not be considered loan conditions at a particular time during the loan, but may be considered loan conditions at another time during the loan (e.g., obligations and/or waivers that may occur through the performance of the parties, and/or expiration of a loan condition). Accordingly, the benefits of the present disclosure may be applied in a wide variety of loan aspects, and any such aspect may be considered loan conditions herein, while in certain embodiments given aspects may not be considered loan conditions herein. One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system ordinarily available to that person, can readily determine which aspects of the present disclosure are loan conditions for the contemplated system. Certain considerations for the person of skill in the art, in determining whether a contemplated data is a loan condition and/or whether aspects of the present disclosure can benefit or enhance the contemplated loan include, without limitation: the enforceability of the condition (can the conditions be enforced by the lender or the lender or the borrower), the cost of enforcing the condition (amount of time, or effort required ensure the conditions are being followed), the complexity of the condition (how easily can they be followed or understood by the parties involved, are the conditions error prone or easily misunderstood), entities responsible for the conditions, fairness of the conditions, observability of the conditions (can the conditions be verified by a another party), favorability of the conditions to one party (do the conditions favor the borrower or the lender), risk associated with the loan (conditions may depend on the probability that the loan may not be repaid), and/or ordinary expectations for the loan and/or related industry.

[0231] While specific examples of loan conditions are described herein for purposes of illustration, any system benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein, are specifically contemplated within the scope of the present disclosure.

[0232] The term loan collateral, collateral, item of collateral, collateral item, and the like as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, a loan collateral may relate to any asset or property that a borrower promises to a lender as backup in exchange for a loan, and/or as security for the loan. Collateral may be any item of value that is accepted as an alternate form of repayment in case of default on a loan. Collateral may include any number of physical or virtual items such as a vehicle, a ship, a plane, a building, a home, real estate property, undeveloped land, a farm, a crop, a municipal facility, a warehouse, a set of inventory, a commodity, a security, a currency, a token of value, a ticket, a cryptocurrency, a consumable item, an edible item, a beverage, a precious metal, an item of jewelry, a gemstone, an item of intellectual property, an intellectual property right, a contractual right, an antique, a fixture, an item of furniture, an item of equipment, a tool, an item of machinery, and an item of personal property. Collateral may include more than one item or types of items.

[0233] A collateral item may describe an asset, a property, a value or other item defined as a security for a loan or a transaction. A set of collateral items may be defined, and within that set substitution, removal or addition of collateral items may be affected. For example, a collateral item may be, without limitation: a vehicle, a ship, a plane, a building, a home, real estate property, undeveloped land, a farm, a crop, a municipal facility, a warehouse, a set of inventory, a commodity, a security, a currency, a token of value, a ticket, a cryptocurrency, a consumable item, an edible item, a beverage, a precious metal, an item of jewelry, a gemstone, an item of intellectual property, an intellectual property right, a contractual right, an antique, a fixture, an item of furniture, an item of equipment, a tool, an item of machinery, or an item of personal property, or the like. If a set or plurality of collateral items is defined, substitution, removal or addition of collateral items may be affected, such as substituting, removing or adding a collateral item to or from a set of collateral items. Without limitation to any other aspect or description of the present disclosure, a collateral item or set of collateral items may also be used in conjunction with other terms to an agreement or loan, such as a representation, a warranty, an indemnity, a covenant, a balance of debt, a fixed interest rate, a variable interest rate, a payment amount, a payment schedule, a balloon payment schedule, a specification of collateral, a specification of substitutability of collateral, a security, a personal guarantee, a lien, a duration, a foreclose condition, a default condition, and a consequence of default. In certain embodiments, a smart contract may calculate whether a borrower has satisfied conditions or covenants and in cases where the borrower has not satisfied such conditions or covenants, may enable automated action or trigger another conditions or terms that may affect the status, ownership or transfer of a collateral item, or initiate the substitution, removal or addition of collateral items to a set of collateral for a loan. One of skill in the art, having the benefit of the disclosure herein and knowledge about collateral items, can readily determine the purposes and use of collateral items in various embodiments and contexts disclosed herein, including the substitution, removal and addition thereof.

[0234] While specific examples of loan collateral are described herein for purposes of illustration, any system benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein, are specifically contemplated within the scope of the present disclosure.

[0235] The term smart contract services (and similar terms) as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, a smart contract service includes any service or application that manages a smart contract or a smart lending contract. For example, the smart contract service may specify terms and conditions of a smart contract, such as in a rules database, or process output from a set of valuation services and assign items of collateral sufficient to provide security for a loan. Smart contract services may automatically execute a set of rules or conditions that embody the smart contract, wherein the execution may be based on or take advantage of collected data. Smart contract services may automatically initiate a demand for payment of a loan, automatically initiate a foreclosure process, automatically initiate an action to claim substitute or backup collateral or transfer ownership of collateral, automatically initiate an inspection process, automatically change a payment or interest rate term that is based on the collateral, and may also configure smart contracts to automatically undertake a loan-related action. Smart contracts may govern at least one of loan terms and conditions, loan-related events and loan-related activities. Smart contracts may be agreements that are encoded as computer protocols and may facilitate, verify, or enforce the negotiation or performance of a smart contract. Smart contracts may or may not be one or more of partially or fully self-executing, or partially or fully self-enforcing.

[0236] Certain processes may not be considered to be smart-contract related individually, but may be considered smart-contract related in an aggregated system—for example automatically undertaking a loan-related action may not be smart contract-related in one instance, but in another instance, may be governed by terms of a smart contract. Accordingly, the benefits of the present disclosure may be applied in a wide variety of processes systems, and any such processes or systems may be considered a smart contract or smart contract service herein, while in certain embodiments a given service may not be considered a smart contract service herein.

[0237] One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system ordinarily available to that person, can readily determine which aspects of the present disclosure will benefit a particular system and how to combine processes and systems from the present disclosure to implement a smart contract service and/or enhance operations of the contemplated system. Certain considerations for the person of skill in the art, in determining whether a contemplated system includes a smart contract service or smart contract and/or whether aspects of the present disclosure can benefit or enhance the contemplated system include, without limitation: ability to transfer ownership of collateral automatically in response to an event; automated actions available upon a finding of covenant compliance (or lack of compliance); the amenity of the collateral to clustering, re-balancing, distribution, addition, substitution, and removal of items from collateral; the modification parameters of an aspect of a loan in response to an event (e.g., timing, complexity, suitability for the loan type, etc.); the complexity of terms and conditions of loans for the system, including benefits from rapid determination and/or predictions of changes to entities (e.g., in the collateral, a financial condition of a party, offset collateral, and/or in an industry related to a party) related to the loan; the suitability of automated generation of terms and conditions and/or execution of terms and conditions for the types of loans, parties, and/or industries contemplated for the system; and the like. While specific examples of smart contract services and considerations are described herein for purposes of illustration, any system benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein, are specifically contemplated within the scope of the present disclosure.

[0238] The term IoT system (and similar terms) as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, an IoT system includes any system of uniquely identified and interrelated computing devices, mechanical and digital machines, sensors and objects that are able to transfer data over a network without intervention. Certain components may not be considered an IoT system individually, but may be considered an IoT system in an aggregated system—for example a single networked.

[0239] The sensor, smart speaker, and/or medical device may be not an IoT system, but may be a part of a larger system and/or be accumulated with a number of other similar components to be considered an IoT system and/or a part of an IoT system. In certain embodiments, a system may be considered an IoT system for some purposes but not for other purposes—for example a smart speaker may be considered part of an IoT system for certain operations, such as for providing surround sound, or the like, but not part of an IoT system for other operations such as directly streaming content from a single, locally networked source. Additionally, in certain embodiments, otherwise similar looking systems may be differentiated in determining whether such systems are IoT systems, and/or which type of IoT system. For example, one group of medical devices may not, at a given time, be sharing to an aggregated HER database, while another group of medical devices may be sharing data to an aggregate HER for the purposes of a clinical study, and accordingly one group of medical devices may be an IoT system, while the other is not. Accordingly, the benefits of the present disclosure may be applied in a wide variety of systems, and any such systems may be considered an IoT system herein, while in certain embodiments a given system may not be considered an IoT system herein. One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system ordinarily available to that person, can readily determine which aspects of the present disclosure will benefit a particular system, how to combine processes and systems from the present disclosure to enhance operations of the contemplated system, and which circuits, controllers, and/or devices include an IoT system for the contemplated system. Certain considerations for the person of skill in the art, in determining whether a contemplated system is an IoT system and/or whether aspects of the present disclosure can benefit or enhance the contemplated system include, without limitation: the transmission environment of the system (e.g., availability of low power, inter-device networking); the shared data storage of a group of devices; establishment of a geofence by a group of devices; service as blockchain nodes; the performance of asset, collateral, or entity monitoring; the relay of data between devices; ability to aggregate data from a plurality of sensors or monitoring devices, and the like. While specific examples of IoT systems and considerations are described herein for purposes of illustration, any system benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein, are specifically contemplated within the scope of the present disclosure.

[0240] The term data collection services (and similar terms) as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, a data collection service includes any service that collects data or information, including any circuit, controller, device, or application that may store, transmit, transfer, share, process, organize, compare, report on and/or aggregate data. The data collection service may include data collection devices (e.g., sensors) and/or may be in communication with data collection devices. The data collection service may monitor entities, such as to identify data or information for collection. The data collection service may be event-driven, run on a periodic basis, or retrieve data from an application at particular points in the application's execution. Certain processes may not be considered to be a data collection service individually, but may be considered a data collection service in an aggregated system—for example a networked storage device may be a component of a data collection service in one instance, but in another instance, may have stand-alone functionality. Accordingly, the benefits of the present disclosure may be applied in a wide variety of processes systems, and any such processes or systems may be considered a data collection service herein, while in certain embodiments a given service may not be considered a data collection service herein. One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system ordinarily available to that person, can readily determine which aspects of the present disclosure will benefit a particular system and how to combine processes and systems from the present disclosure implement a data collection service and/or to enhance operations of the contemplated system. Certain considerations for the person of skill in the art, in determining whether a contemplated system is a data collection service and/or whether aspects of the present disclosure can benefit or enhance the contemplated system include, without limitation: ability to modify a business rule on the fly and alter a data collection protocol; perform real-time monitoring of events; connection of a device for data collection to a monitoring infrastructure, execution of computer readable instructions that cause a processor to log or track events; use of an automated inspection system; occurrence of sales at a networked point-of-sale; need for data from one or more distributed sensors or cameras; and the like. While specific examples of data collection services and considerations are described herein for purposes of illustration, any system benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein, are specifically contemplated within the scope of the present disclosure.

[0241] The term data integration services (and similar terms) as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, a data integration service includes any service that integrates data or information, including any device or application that may extract, transform, load, normalize, compress, decompress, encode, decode, and otherwise process data packets, signals, and other information. The data integration service may monitor entities, such as to identify data or information for integration. The data integration service may integrate data regardless of required frequency, communication protocol, or business rules needed for intricate integration patterns. Accordingly, the benefits of the present disclosure may be applied in a wide variety of processes systems, and any such processes or systems may be considered a data integration service herein, while in certain embodiments a given service may not be considered a data integration service herein. One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system ordinarily available to that person, can readily determine which aspects of the present disclosure will benefit a particular system and how to combine processes and systems from the present disclosure to implement a data integration service and/or enhance operations of the contemplated system. Certain considerations for the person of skill in the art, in determining whether a contemplated system is a data integration service and/or whether aspects of the present disclosure can benefit or enhance the contemplated system include, without limitation: ability to modify a business rule on the fly and alter a data integration protocol; communication with third party databases to pull in data to integrate with; synchronization of data across disparate platforms; connection to a central data warehouse; data storage capacity, processing capacity, and/or communication capacity distributed throughout the system; the connection of separate, automated workflows; and the like. While specific examples of data integration services and considerations are described herein for purposes of illustration, any system benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein, are specifically contemplated within the scope of the present disclosure.

[0242] The term computational services (and similar terms) as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, computational services may be included as a part of one or more services, platforms, or microservices, such as blockchain services, data collection services, data integration services, valuation services, smart contract services, data monitoring services, data mining, and/or any service that facilitates collection, access, processing, transformation, analysis, storage, visualization, or sharing of data. Certain processes may not be considered to be a computational service. For example, a process may not be considered a computational service depending on the sorts of rules governing the service, an end product of the service, or the intent of the service. Accordingly, the benefits of the present disclosure may be applied in a wide variety of processes systems, and any such processes or systems may be considered a computational service herein, while in certain embodiments a given service may not be considered a computational service herein. One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system ordinarily available to that person, can readily determine which aspects of the present disclosure will benefit a particular system and how to combine processes and systems from the present disclosure to implement one or more computational service, and/or to enhance operations of the contemplated system. Certain considerations for the person of skill in the art, in determining whether a contemplated system is a computational service and/or whether aspects of the present disclosure can benefit or enhance the contemplated system include, without limitation: agreement-based access to the service; mediate an exchange between different services; provides on demand computational power to a web service; accomplishes one or more of monitoring, collection, access, processing, transformation, analysis, storage, integration, visualization, mining, or sharing of data. While specific examples of computational services and considerations are described herein for purposes of illustration, any system benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein, are specifically contemplated within the scope of the present disclosure.

[0243] The term sensor as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, a sensor may be a device, module, machine, or subsystem that detects or measures a physical quality, event or change. In embodiments, may record, indicate, transmit, or otherwise respond to the detection or measurement. Examples of sensors may be sensors for sensing movement of entities, for sensing temperatures, pressures or other attributes about entities or their environments, cameras that capture still or video images of entities, sensors that collect data about collateral or assets, such as, for example, regarding the location, condition (health, physical, or otherwise), quality, security, possession, or the like. In embodiments, sensors may be sensitive to, but not influential on, the property to be measured but insensitive to other properties. Sensors may be analog or digital. Sensors may include processors, transmitters, transceivers, memory, power, sensing circuit, electrochemical fluid reservoirs, light sources, and the like. Further examples of sensors contemplated for use in the system include biosensors, chemical sensors, black silicon sensor, IR sensor, acoustic sensor, induction sensor, motion sensor, optical sensor, opacity sensor, proximity sensor, inductive sensor, Eddy-current sensor, passive infrared proximity sensor, radar, capacitance sensor, capacitive displacement sensor, hall-effect sensor, magnetic sensor, GPS sensor, thermal imaging sensor, thermocouple, thermistor, photoelectric sensor, ultrasonic sensor, infrared laser sensor, inertial motion sensor, MEMS internal motion sensor, ultrasonic 3D motion sensor, accelerometer, inclinometer, force sensor, piezoelectric sensor, rotary encoders, linear encoders, ozone sensor, smoke sensor, heat sensor, magnetometer, carbon dioxide detector, carbon monoxide detector, oxygen sensor, glucose sensor, smoke detector, metal detector, rain sensor, altimeter, GPS, detection of being outside, detection of context, detection of activity, object detector (e.g. collateral), marker detector (e.g. geo-location marker), laser rangefinder, sonar, capacitance, optical response, heart rate sensor, or an RF/micropower impulse radio (MIR) sensor. In certain embodiments, a sensor may be a virtual sensor—for example determining a parameter of interest as a calculation based on other sensed parameters in the system. In certain embodiments, a sensor may be a smart sensor—for example reporting a sensed value as an abstracted communication (e.g., as a network communication) of the sensed value. In certain embodiments, a sensor may provide a sensed value directly (e.g., as a voltage level, frequency parameter, etc.) to a circuit, controller, or other device in the system. One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system ordinarily available to that person, can readily determine which aspects of the present disclosure will benefit from a sensor. Certain considerations for the person of skill in the art, in determining whether a contemplated device is a sensor and/or whether aspects of the present disclosure can benefit from or be enhanced by the contemplated sensor include, without limitation: the conditioning of an activation/deactivation of a system to an environmental quality; the conversion of electrical output into measured quantities; the ability to enforce a geofence; the automatic modification of a loan in response to change in collateral; and the like. While specific examples of sensors and considerations are described herein for purposes of illustration, any system benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein, are specifically contemplated within the scope of the present disclosure.

[0244] The term storage condition and similar terms, as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, storage condition includes an environment, physical location, environmental quality, level of exposure, security measures, maintenance description, accessibility description, and the like related to the storage of an asset, collateral, or an entity specified and monitored in a contract, loan, or agreement or backing the contract, loan or other agreement, and the like. Based on a storage condition of a collateral, an asset, or entity, actions may be taken to, maintain, improve, and/or confirm a condition of the asset or the use of that asset as collateral. Based on a storage condition, actions may be taken to alter the terms or conditions of a loan or bond. Storage condition may be classified in accordance with various rules, thresholds, conditional procedures, workflows, model parameters, and the like and may be based on self-reporting or on data from Internet of Things devices, data from a set of environmental condition sensors, data from a set of social network analytic services and a set of algorithms for querying network domains, social media data, crowdsourced data, and the like. The storage condition may be tied to a geographic location relating to the collateral, the issuer, the borrower, the distribution of the funds or other geographic locations. Examples of IoT data may include images, sensor data, location data, and the like. Examples of social media data or crowdsourced data may include behavior of parties to the loan, financial condition of parties, adherence to a party's a term or condition of the loan, or bond, or the like. Parties to the loan may include issuers of a bond, related entities, lender, borrower, 3rd parties with an interest in the debt. Storage condition may relate to an asset or type of collateral such as a municipal asset, a vehicle, a ship, a plane, a building, a home, real estate property, undeveloped land, a farm, a crop, a municipal facility, a warehouse, a set of inventory, a commodity, a security, a currency, a token of value, a ticket, a cryptocurrency, a consumable item, an edible item, a beverage, a precious metal, an item of jewelry, a gemstone, an item of intellectual property, an intellectual property right, a contractual right, an antique, a fixture, an item of furniture, an item of equipment, a tool, an item of machinery, and an item of personal property. The storage condition may include an environment where environment may include an environment selected from among a municipal environment, a corporate environment, a securities trading environment, a real property environment, a commercial facility, a warehousing facility, a transportation environment, a manufacturing environment, a storage environment, a home, and a vehicle. Actions based on the storage condition of a collateral, an asset or an entity may include managing, reporting on, altering, syndicating, consolidating, terminating, maintaining, modifying terms and/or conditions, foreclosing an asset, or otherwise handling a loan, contract, or agreement. One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated storage condition, can readily determine which aspects of the present disclosure will benefit a particular application for a storage condition. Certain considerations for the person of skill in the art, or embodiments of the present disclosure in choosing an appropriate storage condition to manage and/or monitor, include, without limitation: the legality of the condition given the jurisdiction of the transaction, the data available for a given collateral, the anticipated transaction type (loan, bond or debt), the specific type of collateral, the ratio of the loan to value, the ratio of the collateral to the loan, the gross transaction/loan amount, the credit scores of the borrower and the lender, ordinary practices in the industry, and other considerations. While specific examples of storage conditions are described herein for purposes of illustration, any embodiment benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein are specifically contemplated within the scope of the present disclosure.

[0245] The term geolocation and similar terms, as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, geolocation includes the identification or estimation of the real-world geographic location of an object, including the generation of a set of geographic coordinates (e.g. latitude and longitude) and/or street address. Based on a geolocation of a collateral, an asset, or entity, actions may be taken to maintain or improve a condition of the asset or the use of that asset as collateral. Based on a geolocation, actions may be taken to alter the terms or conditions of a loan or bond. Based on a geolocation, determinations or predictions related to a transaction may be performed—for example based upon the weather, civil unrest in a particular area, and/or local disasters (e.g., an earthquake, flood, tornado, hurricane, industrial accident, etc.). Geolocations may be determined in accordance with various rules, thresholds, conditional procedures, workflows, model parameters, and the like and may be based on self-reporting or on data from Internet of Things devices, data from a set of environmental condition sensors, data from a set of social network analytic services and a set of algorithms for querying network domains, social media data, crowdsourced data, and the like. Examples of geolocation data may include GPS coordinates, images, sensor data, street address, and the like. Geolocation data may be quantitative (e.g., longitude/latitude, relative to a plat map, etc.) and/or qualitative (e.g., categorical such as “coastal”, “rural”, etc.; “within New York City”, etc.). Geolocation data may be absolute (e.g., GPS location) or relative (e.g., within 100 yards of an expected location). Examples of social media data or crowdsourced data may include behavior of parties to the loan as inferred by their geolocation, financial condition of parties inferred by geolocation, adherence of parties to a term or condition of the loan, or bond, or the like. Geolocation may be determined for an asset or type of collateral such as a municipal asset, a vehicle, a ship, a plane, a building, a home, real estate property, undeveloped land, a farm, a crop, a municipal facility, a warehouse, a set of inventory, a commodity, a security, a currency, a token of value, a ticket, a consumable item, an edible item, a beverage, a precious metal, an item of jewelry, a gemstone, an antique, a fixture, an item of furniture, an item of equipment, a tool, an item of machinery, and an item of personal property. Geolocation may be determined for an entity such as one of the parties, a third-party (e.g., an inspection service, maintenance service, cleaning service, etc. relevant to a transaction), or any other entity related to a transaction. The geolocation may include an environment selected from among a municipal environment, a corporate environment, a securities trading environment, a real property environment, a commercial facility, a warehousing facility, a transportation environment, a manufacturing environment, a storage environment, a home, and a vehicle. Actions based on the geolocation of a collateral, an asset or an entity may include managing, reporting on, altering, syndicating, consolidating, terminating, maintaining, modifying terms and/or conditions, foreclosing an asset, or otherwise handling a loan, contract, or agreement. One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system, can readily determine which aspects of the present disclosure will benefit a particular application for a geolocation, and which location aspect of an item is a geolocation for the contemplated system. Certain considerations for the person of skill in the art, or embodiments of the present disclosure in choosing an appropriate geolocation to manage, include, without limitation: the legality of the geolocation given the jurisdiction of the transaction, the data available for a given collateral, the anticipated transaction type (loan, bond or debt), the specific type of collateral, the ratio of the loan to value, the ratio of the collateral to the loan, the gross transaction/loan amount, the frequency of travel of the borrower to certain jurisdictions and other considerations, the mobility of the collateral, and/or a likelihood of location-specific event occurrence relevant to the transaction (e.g., weather, location of a relevant industrial facility, availability of relevant services, etc.). While specific examples of geolocation are described herein for purposes of illustration, any embodiment benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein are specifically contemplated within the scope of the present disclosure.

[0246] The term jurisdictional location and similar terms, as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, jurisdictional location refers to the laws and legal authority governing a loan entity. The jurisdictional location may be based on a geolocation of an entity, a registration location of an entity (e.g. a ship's flag state, a state of incorporation for a business, and the like), a granting state for certain rights such as intellectual priority, and the like. In certain embodiments, a jurisdictional location may be one or more of the geolocations for an entity in the system. In certain embodiments, a jurisdictional location may not be the same as the geolocation of any entity in the system (e.g., where an agreement specifies some other jurisdiction). In certain embodiments, a jurisdictional location may vary for entities in the system (e.g., borrower at A, lender at B, collateral positioned at C, agreement enforced at D, etc.). In certain embodiments, a jurisdictional location for a given entity may vary during the operations of the system (e.g., due to movement of collateral, related data, changes in terms and conditions, etc.). In certain embodiments, a given entity of the system may have more than one jurisdictional location (e.g., due to operations of the relevant law, and/or options available to one or more parties), and/or may have distinct jurisdictional locations for different purposes. A jurisdictional location of an item of collateral, an asset, or entity, actions may dictate certain terms or conditions of a loan or bond, and/or may indicate different obligations for notices to parties, foreclosure and/or default execution, treatment of collateral and/or debt security, and/or treatment of various data within the system. While specific examples of jurisdictional location are described herein for purposes of illustration, any embodiment benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein are specifically contemplated within the scope of the present disclosure.

[0247] The terms token of value, token, and variations such as cryptocurrency token, and the like, as utilized herein, in the context of increments of value, may be understood broadly to describe either: (a) a unit of currency or cryptocurrency (e.g. a cryptocurrency token), and (b) may also be used to represent a credential that can be exchanged for a good, service, data or other valuable consideration (e.g. a token of value). Without limitation to any other aspect or description of the present disclosure, in the former case, a token may also be used in conjunction with investment applications, token-trading applications, and token-based marketplaces. In the latter case, a token can also be associated with rendering consideration, such as providing goods, services, fees, access to a restricted area or event, data or other valuable benefit. Tokens can be contingent (e.g. contingent access token) or not contingent. For example, a token of value may be exchanged for accommodations, (e.g. hotel rooms), dining/food goods and services, space (e.g. shared space, workspace, convention space, etc.), fitness/wellness goods or services, event tickets or event admissions, travel, flights or other transportation, digital content, virtual goods, license keys, or other valuable goods, services, data or consideration. Tokens in various forms may be included where discussing a unit of consideration, collateral, or value, whether currency, cryptocurrency or any other form of value such as goods, services, data or other benefits. One of skill in the art, having the benefit of the disclosure herein and knowledge about a token, can readily determine the value symbolized or represented by a token, whether currency, cryptocurrency, good, service, data or other value. While specific examples of tokens are described herein for purposes of illustration, any embodiment benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein, are specifically contemplated within the scope of the present disclosure.

[0248] The term pricing data as utilized herein may be understood broadly to describe a quantity of information such as a price or cost, of one or more items in a marketplace. Without limitation to any other aspect or description of the present disclosure, pricing data may also be used in conjunction with spot market pricing, forward market pricing, pricing discount information, promotional pricing, and other information relating to the cost or price of items. Pricing data may satisfy one or more conditions, or may trigger application of one or more rules of a smart contract. Pricing data may be used in conjunction with other forms of data such as market value data, accounting data, access data, asset and facility data, worker data, event data, underwriting data, claims data or other forms of data. Pricing data may be adjusted for the context of the valued item (e.g., condition, liquidity, location, etc.) and/or for the context of a particular party. One of skill in the art, having the benefit of the disclosure herein and knowledge about pricing data, can readily determine the purposes and use of pricing data in various embodiments and contexts disclosed herein.

[0249] Without limitation to any other aspect or description of the present disclosure, a token includes any token including, without limitation, a token of value, such as collateral, an asset, a reward, such as in a token serving as representation of value, such as a value holding voucher that can be exchanged for goods or services. Certain components may not be considered tokens individually, but may be considered tokens in an aggregated system—for example, a value placed on an asset may not be in itself be a token, but the value of an asset may be placed in a token of value, such as to be stored, exchanged, traded, and the like. For instance, in a non-limiting example, a blockchain circuit may be structured to provide lenders a mechanism to store the value of assets, where the value attributed to the token is stored in a distributed ledger of the blockchain circuit, but the token itself, assigned the value, may be exchanged or traded such as through a token marketplace. In certain embodiments, a token may be considered a token for some purposes but not for other purposes—for example a token may be used as an indication of ownership of an asset, but this use of a token would not be traded as a value where a token including the value of the asset might. Accordingly, the benefits of the present disclosure may be applied in a wide variety of systems, and any such systems may be considered a token herein, while in certain embodiments a given system may not be considered a token herein. One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system ordinarily available to that person, can readily determine which aspects of the present disclosure will benefit a particular system, and/or how to combine processes and systems from the present disclosure to enhance operations of the contemplated system. Certain considerations for the person of skill in the art, in determining whether a contemplated system is a token and/or whether aspects of the present disclosure can benefit or enhance the contemplated system include, without limitation, access data such as relating to rights of access, tickets, and tokens; use in an investment application such as for investment in shares, interests, and tokens; a token-trading application; a token-based marketplace; forms of consideration such as monetary rewards and tokens; translating the value of a resources in tokens; a cryptocurrency token; indications of ownership such as identity information, event information, and token information; a blockchain-based access token traded in a marketplace application; pricing application such as for setting and monitoring pricing for contingent access rights, underlying access rights, tokens, and fees; trading applications such as for trading or exchanging contingent access rights or underlying access rights or tokens; tokens created and stored on a blockchain for contingent access rights resulting in an ownership (e.g., a ticket); and the like.

[0250] The term financial data as utilized herein may be understood broadly to describe a collection of financial information about an asset, collateral or other item or items. Financial data may include revenues, expenses, assets, liabilities, equity, bond ratings, default, return on assets (ROA), return on investment (ROI), past performance, expected future performance, earnings per share (EPS), internal rate of return (IRR), earnings announcements, ratios, statistical analysis of any of the foregoing (e.g. moving averages), and the like. Without limitation to any other aspect or description of the present disclosure, financial data may also be used in conjunction with pricing data and market value data. Financial data may satisfy one or more conditions, or may trigger application of one or more rules of a smart contract. Financial data may be used in conjunction with other forms of data such as market value data, pricing data, accounting data, access data, asset and facility data, worker data, event data, underwriting data, claims data or other forms of data. One of skill in the art, having the benefit of the disclosure herein and knowledge about financial data, can readily determine the purposes and use of pricing data in various embodiments and contexts disclosed herein.

[0251] The term covenant as utilized herein may be understood broadly to describe a term, agreement or promise, such as performance of some action or inaction. For example, a covenant may relate to behavior of a party or legal status of a party. Without limitation to any other aspect or description of the present disclosure, a covenant may also be used in conjunction with other related terms to an agreement or loan, such as a representation, a warranty, an indemnity, a balance of debt, a fixed interest rate, a variable interest rate, a payment amount, a payment schedule, a balloon payment schedule, a specification of collateral, a specification of substitutability of collateral, a party, a guarantee, a guarantor, a security, a personal guarantee, a lien, a duration, a foreclose condition, a default condition, and a consequence of default. A covenant or lack of performance of a covenant may satisfy one or more conditions, or may trigger collection, breach or other terms and conditions. In certain embodiments, a smart contract may calculate whether a covenant is satisfied and in cases where the covenant is not satisfied, may enable automated action or trigger other conditions or terms. One of skill in the art, having the benefit of the disclosure herein and knowledge about covenants, can readily determine the purposes and use of covenants in various embodiments and contexts disclosed herein.

[0252] The term entity as utilized herein may be understood broadly to describe a party, a third-party (e.g., an auditor, regulator, service provider, etc.), and/or an identifiable related object such as an item of collateral related to a transaction. Example entities include an individual, partnership, corporation, limited liability company or other legal organization. Other example entities include an identifiable item of collateral, offset collateral, potential collateral, or the like. For example, an entity may be a given party, such as an individual, to an agreement or loan. Data or other terms herein may be characterized as having a context relating to an entity, such as entity-oriented data. An entity may be characterized with a specific context or application, such as a human entity, physical entity, transactional entity or a financial entity, without limitation. An entity may have representatives that represent or act on its behalf. Without limitation to any other aspect or description of the present disclosure, an entity may also be used in conjunction with other related entities or terms to an agreement or loan, such as a representation, a warranty, an indemnity, a covenant, a balance of debt, a fixed interest rate, a variable interest rate, a payment amount, a payment schedule, a balloon payment schedule, a specification of collateral, a specification of substitutability of collateral, a party, a guarantee, a guarantor, a security, a personal guarantee, a lien, a duration, a foreclose condition, a default condition, and a consequence of default. An entity may have a set of attributes such as: a publicly stated valuation, a set of property owned by the entity as indicated by public records, a valuation of a set of property owned by the entity, a bankruptcy condition, a foreclosure status, a contractual default status, a regulatory violation status, a criminal status, an export controls status, an embargo status, a tariff status, a tax status, a credit report, a credit rating, a website rating, a set of customer reviews for a product of an entity, a social network rating, a set of credentials, a set of referrals, a set of testimonials, a set of behavior, a location, and a geolocation, without limitation. In certain embodiments, a smart contract may calculate whether an entity has satisfied conditions or covenants and in cases where the entity has not satisfied such conditions or covenants, may enable automated action or trigger other conditions or terms. One of skill in the art, having the benefit of the disclosure herein and knowledge about entities, can readily determine the purposes and use of entities in various embodiments and contexts disclosed herein.

[0253] The term party as utilized herein may be understood broadly to describe a member of an agreement, such as an individual, partnership, corporation, limited liability company or other legal organization. For example, a party may be a primary lender, a secondary lender, a lending syndicate, a corporate lender, a government lender, a bank lender, a secured lender, a bond issuer, a bond purchaser, an unsecured lender, a guarantor, a provider of security, a borrower, a debtor, an underwriter, an inspector, an assessor, an auditor, a valuation professional, a government official, an accountant or other entities having rights or obligations to an agreement, transaction or loan. A party may characterize a different term, such as transaction as in the term multi-party transaction, where multiple parties are involved in a transaction, or the like, without limitation. A party may have representatives that represent or act on its behalf In certain embodiments, the term party may reference a potential party or a prospective party—for example an intended lender or borrower interacting with a system, that may not yet be committed to an actual agreement during the interactions with the system. Without limitation to any other aspect or description of the present disclosure, an party may also be used in conjunction with other related parties or terms to an agreement or loan, such as a representation, a warranty, an indemnity, a covenant, a balance of debt, a fixed interest rate, a variable interest rate, a payment amount, a payment schedule, a balloon payment schedule, a specification of collateral, a specification of substitutability of collateral, an entity, a guarantee, a guarantor, a security, a personal guarantee, a lien, a duration, a foreclose condition, a default condition, and a consequence of default. A party may have a set of attributes such as: an identity, a creditworthiness, an activity, a behavior, a business practice, a status of performance of a contract, information about accounts receivable, information about accounts payable, information about the value of collateral, and other types of information, without limitation. In certain embodiments, a smart contract may calculate whether a party has satisfied conditions or covenants and in cases where the party has not satisfied such conditions or covenants, may enable automated action or trigger other conditions or terms. One of skill in the art, having the benefit of the disclosure herein and knowledge about parties, can readily determine the purposes and use of parties in various embodiments and contexts disclosed herein.

[0254] The term party attribute, entity attribute, or party/entity attribute as utilized herein may be understood broadly to describe a value, characteristic, or status of a party or entity. For example, attributes of a party or entity may be, without limitation: value, quality, location, net worth, price, physical condition, health condition, security, safety, ownership, identity, creditworthiness, activity, behavior, business practice, status of performance of a contract, information about accounts receivable, information about accounts payable, information about the value of collateral, and other types of information, and the like. In certain embodiments, a smart contract may calculate values, status or conditions associated with attributes of a party or entity, and in cases where the party or entity has not satisfied such conditions or covenants, may enable automated action or trigger other conditions or terms. One of skill in the art, having the benefit of the disclosure herein and knowledge about attributes of a party or entity, can readily determine the purposes and use of these attributes in various embodiments and contexts disclosed herein.

[0255] The term lender as utilized herein may be understood broadly to describe a party to an agreement offering an asset for lending, proceeds of a loan, and may include an individual, partnership, corporation, limited liability company, or other legal organization. For example, a lender may be a primary lender, a secondary lender, a lending syndicate, a corporate lender, a government lender, a bank lender, a secured lender, an unsecured lender, or other party having rights or obligations to an agreement, transaction or loan offering a loan to a borrower, without limitation. A lender may have representatives that represent or act on its behalf. Without limitation to any other aspect or description of the present disclosure, an party may also be used in conjunction with other related parties or terms to an agreement or loan, such as a borrower, a guarantor, a representation, a warranty, an indemnity, a covenant, a balance of debt, a fixed interest rate, a variable interest rate, a payment amount, a payment schedule, a balloon payment schedule, a specification of collateral, a specification of substitutability of collateral, a security, a personal guarantee, a lien, a duration, a foreclose condition, a default condition, and a consequence of default. In certain embodiments, a smart contract may calculate whether a lender has satisfied conditions or covenants and in cases where the lender has not satisfied such conditions or covenants, may enable automated action, a notification or alert, or trigger other conditions or terms. One of skill in the art, having the benefit of the disclosure herein and knowledge about a lender, can readily determine the purposes and use of a lender in various embodiments and contexts disclosed herein.

[0256] The term crowdsourcing services as utilized herein may be understood broadly to describe services offered or rendered in conjunction with a crowdsourcing model or transaction, wherein a large group of people or entities supply contributions to fulfill a need, such as a loan, for the transaction. Crowdsourcing services may be provided by a platform or system, without limitation. A crowdsourcing request may be communicated to a group of information suppliers and by which responses to the request may be collected and processed to provide a reward to at least one successful information supplier. The request and parameters may be configured to obtain information related to the condition of a set of collateral for a loan. The crowdsourcing request may be published. In certain embodiments, without limitation, crowdsourcing services may be performed by a smart contract, wherein the reward is managed by a smart contract that processes responses to the crowdsourcing request and automatically allocates a reward to information that satisfies a set of parameter configured for the crowdsourcing request. One of skill in the art, having the benefit of the disclosure herein and knowledge about crowdsourcing services, can readily determine the purposes and use of crowdsourcing services in various embodiments and contexts disclosed herein.

[0257] The term publishing services as utilized herein may be understood to describe a set of services to publish a crowdsourcing request. Publishing services may be provided by a platform or system, without limitation. In certain embodiments, without limitation, publishing services may be performed by a smart contract, wherein the crowdsourcing request is published or publication is initiated by the smart contract. One of skill in the art, having the benefit of the disclosure herein and knowledge about publishing services, can readily determine the purposes and use of publishing services in various embodiments and contexts disclosed herein.

[0258] The term interface as utilized herein may be understood broadly to describe a component by which interaction or communication is achieved, such as a component of a computer, which may be embodied in software, hardware or a combination thereof. For example, an interface may serve a number of different purposes or be configured for different applications or contexts, such as, without limitation: an application programming interface, a graphic user interface, user interface, software interface, marketplace interface, demand aggregation interface, crowdsourcing interface, secure access control interface, network interface, data integration interface or a cloud computing interface, or combinations thereof. An interface may serve to act as a way to enter, receive or display data, within the scope of lending, refinancing, collection, consolidation, factoring, brokering or foreclosure, without limitation. An interface may serve as an interface for another interface. Without limitation to any other aspect or description of the present disclosure, an interface may be used in conjunction with applications, processes, modules, services, layers, devices, components, machines, products, sub-systems, interfaces, connections, or as part of a system. In certain embodiments, an interface may be embodied in software, hardware or a combination thereof, as well as stored on a medium or in memory. One of skill in the art, having the benefit of the disclosure herein and knowledge about an interface, can readily determine the purposes and use of an interface in various embodiments and contexts disclosed herein.

[0259] The term graphical user interface as utilized herein may be understood as a type of interface to allow a user to interact with a system, computer or other interfaces, in which interaction or communication is achieved through graphical devices or representations. A graphical user interface may be a component of a computer, which may be embodied in computer readable instructions, hardware, or a combination thereof. A graphical user interface may serve a number of different purposes or be configured for different applications or contexts. Such an interface may serve to act as a way to receive or display data using visual representation, stimulus or interactive data, without limitation. A graphical user interface may serve as an interface for another graphical user interface or other interfaces. Without limitation to any other aspect or description of the present disclosure, a graphical user interface may be used in conjunction with applications, processes, modules, services, layers, devices, components, machines, products, sub-systems, interfaces, connections, or as part of a system. In certain embodiments, a graphical user interface may be embodied in computer readable instructions, hardware or a combination thereof, as well as stored on a medium or in memory. Graphical user interfaces may be configured for any input types, including keyboards, a mouse, a touch screen, and the like. Graphical user interfaces may be configured for any desired user interaction environments, including for example a dedicated application, a web page interface, or combinations of these. One of skill in the art, having the benefit of the disclosure herein and knowledge about a graphical user interface, can readily determine the purposes and use of a graphical user interface in various embodiments and contexts disclosed herein.

[0260] The term user interface as utilized herein may be understood as a type of interface to allow a user to interact with a system, computer or other apparatus, in which interaction or communication is achieved through graphical devices or representations. A user interface may be a component of a computer, which may be embodied in software, hardware or a combination thereof. The user interface may be stored on a medium or in memory. User interfaces may include drop-down menus, tables, forms, or the like with default, templated, recommended, or pre-configured conditions. In certain embodiments, a user interface may include voice interaction. Without limitation to any other aspect or description of the present disclosure, a user interface may be used in conjunction with applications, circuits, controllers, processes, modules, services, layers, devices, components, machines, products, sub-systems, interfaces, connections, or as part of a system. User interfaces may serve a number of different purposes or be configured for different applications or contexts. For example, a lender-side user interface may include features to view a plurality of customer profiles, but may be restricted from making certain changes. A debtor-side user interface may include features to view details and make changes to a user account. A 3rd party neutral-side interface (e.g. a 3rd party not having an interest in an underlying transaction, such as a regulator, auditor, etc.) may have features that enable a view of company oversight and anonymized user data without the ability to manipulate any data, and may have scheduled access depending upon the 3rd party and the purpose for the access. A 3rd party interested-side interface (e.g. a 3rd party that may have an interest in an underlying transaction, such as a collector, debtor advocate, investigator, partial owner, etc.) may include features enabling a view of particular user data with restrictions on making changes. Many more features of these user interfaces may be available to implements embodiments of the systems and/or procedures described throughout the present disclosure. Accordingly, the benefits of the present disclosure may be applied in a wide variety of processes and systems, and any such processes or systems may be considered a service herein. One of skill in the art, having the benefit of the disclosure herein and knowledge about a user interface, can readily determine the purposes and use of a user interface in various embodiments and contexts disclosed herein. Certain considerations for the person of skill in the art, in determining whether a contemplated interface is a user interface and/or whether aspects of the present disclosure can benefit or enhance the contemplated system include, without limitation: configurable views, ability to restrict manipulation or views, report functions, ability to manipulate user profile and data, implement regulatory requirements, provide the desired user features for borrowers, lenders, and 3rd parties, and the like.

[0261] Interfaces and dashboards as utilized herein may further be understood broadly to describe a component by which interaction or communication is achieved, such as a component of a computer, which may be embodied in software, hardware or a combination thereof. Interfaces and dashboards may acquire, receive, present or otherwise administrate an item, service, offering or other aspects of a transaction or loan. For example, interfaces and dashboards may serve a number of different purposes or be configured for different applications or contexts, such as, without limitation: an application programming interface, a graphic user interface, user interface, software interface, marketplace interface, demand aggregation interface, crowdsourcing interface, secure access control interface, network interface, data integration interface or a cloud computing interface, or combinations thereof. An interface or dashboard may serve to act as a way to receive or display data, within the context of lending, refinancing, collection, consolidation, factoring, brokering or foreclosure, without limitation. An interface or dashboard may serve as an interface or dashboard for another interface or dashboard. Without limitation to any other aspect or description of the present disclosure, an interface may be used in conjunction with applications, circuits, controllers, processes, modules, services, layers, devices, components, machines, products, sub-systems, interfaces, connections, or as part of a system. In certain embodiments, an interface or dashboard may be embodied in computer readable instructions, hardware or a combination thereof, as well as stored on a medium or in memory. One of skill in the art, having the benefit of the disclosure herein and knowledge ordinarily available about a contemplated system, can readily determine the purposes and use of interfaces and/or dashboards in various embodiments and contexts disclosed herein.

[0262] The term domain as utilized herein may be understood broadly to describe a scope or context of a transaction and/or communications related to a transaction. For example, a domain may serve a number of different purposes or be configured for different applications or contexts, such as, without limitation: a domain for execution, a domain for a digital asset, domains to which a request will be published, domains to which social network data collection and monitoring services will be applied, domains to which Internet of Things data collection and monitoring services will be applied, network domains, geolocation domains, jurisdictional location domains, and time domains. Without limitation to any other aspect or description of the present disclosure, one or more domains may be utilized relative to any applications, circuits, controllers, processes, modules, services, layers, devices, components, machines, products, sub-systems, interfaces, connections, or as part of a system. In certain embodiments, a domain may be embodied in computer readable instructions, hardware, or a combination thereof, as well as stored on a medium or in memory. One of skill in the art, having the benefit of the disclosure herein and knowledge about a domain, can readily determine the purposes and use of a domain in various embodiments and contexts disclosed herein.

[0263] The term request (and variations) as utilized herein may be understood broadly to describe the action or instance of initiating or asking for a thing (e.g. information, a response, an object, and the like) to be provided. A specific type of request may also serve a number of different purposes or be configured for different applications or contexts, such as, without limitation: a formal legal request (e.g. a subpoena), a request to refinance (e.g. a loan), or a crowdsourcing request. Systems may be utilized to perform requests as well as fulfill requests. Requests in various forms may be included where discussing a legal action, a refinancing of a loan, or a crowdsourcing service, without limitation. One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system, can readily determine the value of a request implemented in an embodiment. While specific examples of requests are described herein for purposes of illustration, any embodiment benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein, are specifically contemplated within the scope of the present disclosure.

[0264] The term reward (and variations) as utilized herein may be understood broadly to describe a thing or consideration received or provided in response to an action or stimulus. Rewards can be of a financial type, or non-financial type, without limitation. A specific type of reward may also serve a number of different purposes or be configured for different applications or contexts, such as, without limitation: a reward event, claims for rewards, monetary rewards, rewards captured as a data set, rewards points, and other forms of rewards. Rewards may be triggered, allocated, generated for innovation, provided for the submission of evidence, requested, offered, selected, administrated, managed, configured, allocated, conveyed, identified, without limitation, as well as other actions. Systems may be utilized to perform the aforementioned actions. Rewards in various forms may be included where discussing a particular behavior, or encouragement of a particular behavior, without limitation. In certain embodiments herein, a reward may be utilized as a specific incentive (e.g., rewarding a particular person that responds to a crowdsourcing request) or as a general incentive (e.g., providing a reward responsive to a successful crowdsourcing request, in addition to or alternatively to a reward to the particular person that responded). One of skill in the art, having the benefit of the disclosure herein and knowledge about a reward, can readily determine the value of a reward implemented in an embodiment. While specific examples of rewards are described herein for purposes of illustration, any embodiment benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein, are specifically contemplated within the scope of the present disclosure.

[0265] The term robotic process automation system as utilized herein may be understood broadly to describe a system capable of performing tasks or providing needs for a system of the present disclosure. For example, a robotic process automation system, without limitation, can be configured for: negotiation of a set of terms and conditions for a loan, negotiation of refinancing of a loan, loan collection, consolidating a set of loans, managing a factoring loan, brokering a mortgage loan, training for foreclosure negotiations, configuring a crowdsourcing request based on a set of attributes for a loan, setting a reward, determining a set of domains to which a request will be published, configuring the content of a request, configuring a data collection and monitoring action based on a set of attributes of a loan, determining a set of domains to which the Internet of Things data collection and monitoring services will be applied, and iteratively training and improving based on a set of outcomes. A robotic process automation system may include: a set of data collection and monitoring services, an artificial intelligence system, and another robotic process automation system which is a component of the higher level robotic process automation system. The robotic process automation system may include: at least one of the set of mortgage loan activities and the set of mortgage loan interactions includes activities among marketing activity, identification of a set of prospective borrowers, identification of property, identification of collateral, qualification of borrower, title search, title verification, property assessment, property inspection, property valuation, income verification, borrower demographic analysis, identification of capital providers, determination of available interest rates, determination of available payment terms and conditions, analysis of existing mortgage, comparative analysis of existing and new mortgage terms, completion of application workflow, population of fields of application, preparation of mortgage agreement, completion of schedule to mortgage agreement, negotiation of mortgage terms and conditions with capital provider, negotiation of mortgage terms and conditions with borrower, transfer of title, placement of lien and closing of mortgage agreement. Example and non-limiting robotic process automation systems may include one or more user interfaces, interfaces with circuits and/or controllers throughout the system to provide, request, and/or share data, and/or one or more artificial intelligence circuits configured to iteratively improve one or more operations of the robotic process automation system. One of skill in the art, having the benefit of the disclosure herein and knowledge ordinarily available about a contemplated robotic process automation system, can readily determine the circuits, controllers, and/or devices to include to implement a robotic process automation system performing the selected functions for the contemplated system. While specific examples of robotic process automation systems are described herein for purposes of illustration, any embodiment benefitting from the disclosures herein, and any considerations understood.

[0266] The term loan-related action (and other related terms such as loan-related event and loan-related activity) are utilized herein and may be understood broadly to describe one or multiple actions, events or activities relating to a transaction that includes a loan within the transaction. The action, event or activity may occur in many different contexts of loans, such as lending, refinancing, consolidation, factoring, brokering, foreclosure, administration, negotiating, collecting, procuring, enforcing and data processing (e.g. data collection), or combinations thereof, without limitation. A loan-related action may be used in the form of a noun (e.g. a notice of default has been communicated to the borrower with formal notice, which could be considered a loan-related action). A loan-related action, event, or activity may refer to a single instance, or may characterize a group of actions, events or activities. For example, a single action such as providing a specific notice to a borrower of an overdue payment may be considered a loan-related action. Similarly, a group of actions from start to finish relating to a default may also be considered a single loan-related action. Appraisal, inspection, funding and recording, without limitation, may all also be considered loan-related actions that have occurred, as well as events relating to the loan, and may also be loan-related events. Similarly, these activities of completing these actions may also be considered loan-related activities (e.g. appraising, inspecting, funding, recording, etc.), without limitation. In certain embodiments, a smart contract or robotic process automation system may perform loan-related actions, loan-related events, or loan-related activities for one or more of the parties, and process appropriate tasks for completion of the same. In some cases the smart contract or robotic process automation system may not complete a loan-related action, and depending upon such outcome this may enable an automated action or may trigger other conditions or terms. One of skill in the art, having the benefit of the disclosure herein and knowledge about loan-related actions, events, and activities can readily determine the purposes and use of this term in various forms and embodiments as described throughout the present disclosure.

[0267] The term loan-related action, events, and activities, as noted herein, may also more specifically be utilized to describe a context for calling of a loan. A calling of a loan is an action wherein the lender can demand the loan be repaid, usually triggered by some other condition or term, such as delinquent payment(s). For example, a loan-related action for calling of the loan may occur when a borrower misses three payments in a row, such that there is a severe delinquency in the loan payment schedule, and the loan goes into default. In such a scenario, a lender may be initiating loan-related actions for calling of the loan to protect its rights. In such a scenario, perhaps the borrower pays a sum to cure the delinquency and penalties, which may also be considered as a loan-related action for calling of the loan. In some circumstances, a smart contract or robotic process automation system may initiate, administrate or process loan-related actions for calling of the loan, which without limitation, may including providing notice, researching and collecting payment history, or other tasks performed as a part of the calling of the loan. One of skill in the art, having the benefit of the disclosure herein and knowledge about loan-related actions for calling of the loan, or other forms of the term and its various forms, can readily determine the purposes and use of this term in the context of an event or other various embodiments and contexts disclosed herein.

[0268] The term loan-related action, events, and activities, as noted herein, may also more specifically be utilized to describe a context for payment of a loan. Typically in transactions involving loans, without limitation, a loan is repaid on a payment schedule. Various actions may be taken to provide a borrower with information to pay back the loan, as well as actions for a lender to receive payment for the loan. For example, if a borrower makes a payment on the loan, a loan-related action for payment of the loan may occur. Without limitation, such a payment may comprise several actions that may occur with respect to the payment on the loan, such as: the payment being tendered to the lender, the loan ledger or accounting reflecting that a payment has been made, a receipt provided to the borrower of the payment made, and the next payment being requested of the borrower. In some circumstances, a smart contract or robotic process automation system may initiate, administrate or process such loan-related actions for payment of the loan, which without limitation, may including providing notice to the lender, researching and collecting payment history, providing a receipt to the borrower, providing notice of the next payment due to the borrower, or other actions associated with payment of the loan. One of skill in the art, having the benefit of the disclosure herein and knowledge about loan-related actions for payment of a loan, or other forms of the term and its various forms, can readily determine the purposes and use of this term in the context of an event or other various embodiments and contexts disclosed herein.

[0269] The term loan-related action, events, and activities, as noted herein, may also more specifically be utilized to describe a context for a payment schedule or alternative payment schedule. Typically in transactions involving loans, without limitation, a loan is repaid on a payment schedule, which may be modified over time. Or, such a payment schedule may be developed and agreed in the alternative, with an alternative payment schedule. Various actions may be taken in the context of a payment schedule or alternate payment schedule for the lender or the borrower, such as: the amount of such payments, when such payments are due, what penalties or fees may attach to late payments, or other terms. For example, if a borrower makes an early payment on the loan, a loan-related action for payment schedule and alternative payment schedule of the loan may occur; in such case, perhaps the payment is applied as principal, with the regular payment still being due. Without limitation, loan-related actions for a payment schedule and alternative payment schedule may comprise several actions that may occur with respect to the payment on the loan, such as: the payment being tendered to the lender, the loan ledger or accounting reflecting that a payment has been made, a receipt provided to the borrower of the payment made, a calculation if any fees are attached or due, and the next payment being requested of the borrower. In certain embodiments, an activity to determine a payment schedule or alternative payment schedule may be a loan-related action, event, or activity. In certain embodiments, an activity to communicate the payment schedule or alternative payment schedule (e.g., to the borrower, the lender, or a 3rd party) may be a loan-related action, event, or activity. In some circumstances, a smart contract circuit or robotic process automation system may initiate, administrate, or process such loan-related actions for payment schedule and alternative payment schedule, which without limitation, may include providing notice to the lender, researching and collecting payment history, providing a receipt to the borrower, calculating the next due date, calculating the final payment amount and date, providing notice of the next payment due to the borrower, determining the payment schedule or an alternate payment schedule, communicating the payment scheduler or an alternate payment schedule, or other actions associated with payment of the loan. One of skill in the art, having the benefit of the disclosure herein and knowledge about loan-related actions for payment schedule and alternative payment schedule, or other forms of the term and its various forms, can readily determine the purposes and use of this term in the context of an event or other various embodiments and contexts disclosed herein.

[0270] The term regulatory notice requirement (and any derivatives) as utilized herein may be understood broadly to describe an obligation or condition to communicate a notification or message to another party or entity. The regulatory notice requirement may be required under one or more conditions that are triggered, or generally required. For example, a lender may have a regulatory notice requirement to provide notice to a borrower of a default of a loan, or change of an interest rate of a loan, or other notifications relating to a transaction or loan. The regulatory aspect of the term may be attributed to jurisdiction-specific laws, rules, or codes that require certain obligations of communication. In certain embodiments, a policy directive may be treated as a regulatory notice requirement—for example where a lender has an internal notice policy that may exceed the regulatory requirements of one or more of the jurisdictional locations related to a transaction. The notice aspect generally relates to formal communications, which may take many different forms, but may specifically be specified as a particular form of notice, such as a certified mail, facsimile, email transmission, or other physical or electronic form, a content for the notice, and/or a timing requirement related to the notice. The requirement aspect relates to the necessity of a party to complete its obligation to be in compliance with laws, rules, codes, policies, standard practices, or terms of an agreement or loan. In certain embodiments, a smart contract may process or trigger regulatory notice requirements and provide appropriate notice to a borrower. This may be based on location of at least one of: the lender, the borrower, the funds provided via the loan, the repayment of the loan, and the collateral of the loan, or other locations as designated by the terms of the loan, transaction, or agreement. In cases where a party or entity has not satisfied such regulatory notice requirements, certain changes in the rights or obligations between the parties may be triggered—for example where a lender provides a non-compliant notice to the borrower, an automated action or trigger based on the terms and conditions of the loan, and/or based on external information (e.g., a regulatory prescription, internal policy of the lender, etc.) may be affected by a smart contract circuit and/or robotic process automation system may be implemented. One of skill in the art, having the benefit of the disclosure herein and knowledge ordinarily available about a contemplated system, can readily determine the purposes and use of regulatory notice requirements in various embodiments and contexts disclosed herein.

[0271] The term regulatory notice requirement may also be utilized herein to describe an obligation or condition to communicate a notification or message to another party or entity based upon a general or specific policy, rather than based on a particular jurisdiction, or laws, rules, or codes of a particular location (as in regulatory notice requirement that may be jurisdiction-specific). The regulatory notice requirement may be prudent or suggested, rather than obligatory or required, under one or more conditions that are triggered, or generally required. For example, a lender may have a regulatory notice requirement that is policy based to provide notice to a borrower of a new informational website, or will experience a change of an interest rate of a loan in the future, or other notifications relating to a transaction or loan that are advisory or helpful, rather than mandatory (although mandatory notices may also fall under a policy basis). Thus, in policy based uses of the regulatory notice requirement term, a smart contract circuit may process or trigger regulatory notice requirements and provide appropriate notice to a borrower which may or may not necessarily be required by a law, rule or code. The basis of the notice or communication may be out of prudence, courtesy, custom, or obligation.

[0272] The term regulatory notice may also be utilized herein to describe an obligation or condition to communicate a notification or message to another party or entity specifically, such as a lender or borrower. The regulatory notice may be specifically directed toward any party or entity, or a group of parties or entities. For example, a particular notice or communication may be advisable or required to be provided to a borrower, such as on circumstances of a borrower's failure to provide scheduled payments on a loan resulting in a default. As such, such a regulatory notice directed to a particular user, such as a lender or borrower, may be as a result of a regulatory notice requirement that is jurisdiction-specific or policy-based, or otherwise. Thus, in some circumstances a smart contract may process or trigger a regulatory notice and provide appropriate notice to a specific party such as a borrower, which may or may not necessarily be required by a law, rule or code, but may otherwise be provided out of prudence, courtesy or custom. In cases where a party or entity has not satisfied such regulatory notice requirements to a specific party or parties, it may create circumstances where certain rights may be forgiven by one or more parties or entities, or may enable automated action or trigger other conditions or terms. One of skill in the art, having the benefit of the disclosure herein and knowledge ordinarily available about a contemplated system, can readily determine the purposes and use of regulatory notice requirements based in various embodiments and contexts disclosed herein.

[0273] The term regulatory foreclosure requirement (and any derivatives) as utilized herein may be understood broadly to describe an obligation or condition in order to trigger, process or complete default of a loan, foreclosure or recapture of collateral, or other related foreclosure actions. The regulatory foreclosure requirement may be required under one or more conditions that are triggered, or generally required. For example, a lender may have a regulatory foreclosure requirement to provide notice to a borrower of a default of a loan, or other notifications relating to the default of a loan prior to foreclosure. The regulatory aspect of the term may be attributed to jurisdiction-specific laws, rules, or codes that require certain obligations of communication. The foreclosure aspect generally relates to the specific remedy of foreclosure, or a recapture of collateral property and default of a loan, which may take many different forms, but may be specified in the terms of the loan. The requirement aspect relates to the necessity of a party to complete its obligation in order to be in compliance or performance of laws, rules, codes or terms of an agreement or loan. In certain embodiments, a smart contract circuit may process or trigger regulatory foreclosure requirements and process appropriate tasks relating to such a foreclosure action. This may be based on a jurisdictional location of at least one of the lender, the borrower, the fund provided via the loan, the repayment of the loan, and the collateral of the loan, or other locations as designated by the terms of the loan, transaction, or agreement. In cases where a party or entity has not satisfied such regulatory foreclosure requirements, certain rights may be forgiven by the party or entity (e.g. a lender), or such a failure to comply with the regulatory notice requirement may enable automated action or trigger other conditions or terms. One of skill in the art, having the benefit of the disclosure herein and knowledge ordinarily available about a contemplated system, can readily determine the purposes and use of regulatory foreclosure requirements in various embodiments and contexts disclosed herein.

[0274] The term regulatory foreclosure requirement may also be utilized herein to describe an obligation or in order to trigger, process or complete default of a loan, foreclosure or recapture of collateral, or other related foreclosure actions. based upon a general or specific policy rather than based on a particular jurisdiction, or laws, rules, or codes of a particular location (as in regulatory foreclosure requirement that may be jurisdiction-specific). The regulatory foreclosure requirement may be prudent or suggested, rather than obligatory or required, under one or more conditions that are triggered, or generally required. For example, a lender may have a regulatory foreclosure requirement that is policy based to provide notice to a borrower of a default of a loan, or other notifications relating to a transaction or loan that are advisory or helpful, rather than mandatory (although mandatory notices may also fall under a policy basis). Thus, in policy based uses of the regulatory foreclosure requirement term, a smart contract may process or trigger regulatory foreclosure requirements and provide appropriate notice to a borrower which may or may not necessarily be required by a law, rule or code. The basis of the notice or communication may be out of prudence, courtesy, custom, industry practice, or obligation.

[0275] The term regulatory foreclosure requirements may also be utilized herein to describe an obligation or condition that is to be performed with regard to a specific user, such as a lender or a borrower. The regulatory notice may be specifically directed toward any party or entity, or a group of parties or entities. For example, a particular notice or communication may be advisable or required to be provided to a borrower, such as on circumstances of a borrower's failure to provide scheduled payments on a loan resulting in a default. As such, such a regulatory foreclosure requirement is directed to a particular user, such as a lender or borrower, and may be a result of a regulatory foreclosure requirement that is jurisdiction-specific or policy-based, or otherwise. For example, the foreclosure requirement may be related to a specific entity involved with a transaction (e.g., the current borrower has been a customer for 30 years, so s/he receives unique treatment), or to a class of entities (e.g., “preferred” borrowers, or “first time default” borrowers). Thus, in some circumstances a smart contract circuit may process or trigger an obligation or action that must be taken pursuant to a foreclosure, where the action is directed or from a specific party such as a lender or a borrower, which may or may not necessarily be required by a law, rule or code, but may otherwise be provided out of prudence, courtesy, or custom. In certain embodiments, the obligation or condition that is to be performed with regard to the specific user may form a part of the terms and conditions or otherwise be known to the specific user to which it applies (e.g., an insurance company or bank that advertises a specific practice with regard to a specific class of customers, such as first-time default customers, first-time accident customers, etc.), and in certain embodiments the obligation or condition that is to be performed with regard to the specific user may be unknown to the specific user to which it applies (e.g., a bank has a policy relating to a class of users to which the specific user belongs, but the specific user is not aware of the classification).

[0276] The terms value, valuation, valuation model (and similar terms) as utilized herein should be understood broadly to describe an approach to evaluate and determine the estimated value for collateral. Without limitation to any other aspect or description of the present disclosure, a valuation model may be used in conjunction with: collateral (e.g. a secured property), artificial intelligence services (e.g. to improve a valuation model), data collection and monitoring services (e.g. to set a valuation amount), valuation services (e.g. the process of informing, using, and/or improving a valuation model), and/or outcomes relating to transactions in collateral (e.g. as a basis of improving the valuation model). “Jurisdiction-specific valuation model” is also used as a valuation model used in a specific geographic/jurisdictional area or region; wherein, the jurisdiction can be specific to jurisdiction of the lender, the borrower, the delivery of funds, the payment of the loan or the collateral of the loan, or combinations thereof. In certain embodiments, a jurisdiction-specific valuation model considers jurisdictional effects on a valuation of collateral, including at least: rights and obligations for borrowers and lenders in the relevant jurisdiction(s); jurisdictional effects on the ability to move, import, export, substitute, and/or liquidate the collateral; jurisdictional effects on the timing between default and foreclosure or collection of collateral; and/or jurisdictional effects on the volatility and/or sensitivity of collateral value determinations. In certain embodiments, a geolocation-specific valuation model considers geolocation effects on a valuation of the collateral, which may include a similar list of considerations relative jurisdictional effects (although the jurisdictional location(s) may be distinct from the geolocation(s)), but may also include additional effects, such as: weather-related effects; distance of the collateral from monitoring, maintenance, or seizure services; and/or proximity of risk phenomenon (e.g., fault lines, industrial locations, a nuclear plant, etc.). A valuation model may utilize a valuation of offset collateral (e.g., a similar item of collateral, a generic value such as a market value of similar or fungible collateral, and/or a value of an item that correlates with a value of the collateral) as a part of the valuation of the collateral. In certain embodiments, an artificial intelligence circuit includes one or more machine learning and/or artificial intelligence algorithms, to improve a valuation model, including, for example, utilizing information over time between multiple transactions involving similar or offset collateral, and/or utilizing outcome information (e.g., where loan transactions are completed successfully or unsuccessfully, and/or in response to collateral seizure or liquidation events that demonstrate real-world collateral valuation determinations) from the same or other transactions to iteratively improve the valuation model. In certain embodiments, an artificial intelligence circuit is trained on a collateral valuation data set, for example previously determined valuations and/or through interactions with a trainer (e.g., a human, accounting valuations, and/or other valuation data). In certain embodiments, the valuation model and/or parameters of the valuation model (e.g., assumptions, calibration values, etc.) may be determined and/or negotiated as a part of the terms and conditions of the transaction (e.g., a loan, a set of loans, and/or a subset of the set of loans). One of skill in the art, having the benefit of the disclosure herein and knowledge ordinarily available about a contemplated system, can readily determine which aspects of the present disclosure will benefit a particular application for a valuation model, and how to choose or combine valuation models to implement an embodiment of a valuation model. Certain considerations for the person of skill in the art, or embodiments of the present disclosure in choosing an appropriate valuation model, include, without limitation: the legal considerations of a valuation model given the jurisdiction of the collateral; the data available for a given collateral; the anticipated transaction/loan type(s); the specific type of collateral; the ratio of the loan to value; the ratio of the collateral to the loan; the gross transaction/loan amount; the credit scores of the borrower; accounting practices for the loan type and/or related industry; uncertainties related to any of the foregoing; and/or sensitivities related to any of the foregoing. While specific examples of valuation models and considerations are described herein for purposes of illustration, any embodiment benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein, are specifically contemplated within the scope of the present disclosure

[0277] The term market value data, or marketplace information, (and other forms or variations) as utilized herein may be understood broadly to describe data or information relating to the valuation of a property, asset, collateral or other valuable items which may be used as the subject of a loan, collateral or transaction. Market value data or marketplace information may change from time to time, and may be estimated, calculated, or objectively or subjectively determined from various sources of information. Market value data or marketplace information may be related directly to an item of collateral or to an off-set item of collateral. Market value data or marketplace information may include financial data, market ratings, product ratings, customer data, market research to understand customer needs or preferences, competitive intelligence re. competitors, suppliers, and the like, entities sales, transactions, customer acquisition cost, customer lifetime value, brand awareness, churn rate, and the like. The term may occur in many different contexts of contracts or loans, such as lending, refinancing, consolidation, factoring, brokering, foreclosure, and data processing (e.g. data collection), or combinations thereof, without limitation. Market value data or marketplace information may be used as a noun to identify a single figure or a plurality of figures or data. For example, market value data or marketplace information may be utilized by a lender to determine if a property or asset will serve as collateral for a secured loan, or may alternatively be utilized in the determination of foreclosure if a loan is in default, without limitation to these circumstances in use of the term. Marketplace value data or marketplace information may also be used to determine loan-to-value figures or calculations. In certain embodiments, a collection service, smart contract circuit, and/or robotic process automation system may estimate or calculate market value data or marketplace information from one or more sources of data or information. In some cases market data value or marketplace information, depending upon the data/information contained therein, may enable automated action or trigger other conditions or terms. One of skill in the art, having the benefit of the disclosure herein and knowledge ordinarily available about a contemplated system and available relevant marketplace information, can readily determine the purposes and use of this term in various forms, embodiments and contexts disclosed herein.

[0278] The terms similar collateral, similar to collateral, off-set collateral, and other forms or variations as utilized herein may be understood broadly to describe a property, asset or valuable item that may be like in nature to a collateral (e.g. an article of value held in security) regarding a loan or other transaction. Similar collateral may refer to a property, asset, collateral or other valuable item which may be aggregated, substituted, or otherwise referred to in conjunction with other collateral, whether the similarity comes in the form of a common attribute such as type of item of collateral, category of the item of collateral, an age of the item of collateral, a condition of the item of collateral, a history of the item of collateral, an ownership of the item of collateral, a caretaker of the item of collateral, a security of the item of collateral, a condition of an owner of the item of collateral, a lien on the item of collateral, a storage condition of the item of collateral, a geolocation of the item of collateral, and a jurisdictional location of the item of collateral, and the like. In certain embodiments, an offset collateral references an item that has a value correlation with an item of collateral—for example an offset collateral may exhibit similar price movements, volatility, storage requirements, or the like for an item of collateral. In certain embodiments, similar collateral may be aggregated to form a larger security interest or collateral for an additional loan or distribution, or transaction. In certain embodiments, offset collateral may be utilized to inform a valuation of the collateral. In certain embodiments, a smart contract circuit or robotic process automation system may estimate or calculate figures, data or information relating to similar collateral, or may perform a function with respect to aggregating similar collateral. One of skill in the art, having the benefit of the disclosure herein and knowledge ordinarily available about a contemplated system can readily determine the purposes and use of similar collateral, offset collateral, or related terms as they relate to collateral in various forms, embodiments, and contexts disclosed herein.

[0279] The term restructure (and other forms such as restructuring) as utilized herein may be understood broadly to describe a modification of terms or conditions, properties, collateral, or other considerations affecting a loan or transaction. Restructuring may result in a successful outcome where amended terms or conditions are adopted between parties, or an unsuccessful outcome where no modification or restructure occurs, without limitation. Restructuring can occur in many contexts of contracts or loans, such as application, lending, refinancing, collection, consolidation, factoring, brokering, foreclosure, and combinations thereof, without limitation. Debt may also be restructured, which may indicate that debts owed to a party are modified as to timing, amounts, collateral, or other terms. For example, a borrower may restructure debt of a loan to accommodate a change of financial conditions, or a lender may offer to a borrower the restructuring of a debt for its own needs or prudence. In certain embodiments, a smart contract circuit or robotic process automation system may automatically or manually restructure debt based on a monitored condition, or create options for restructuring a debt, administrate the process of negotiating or effecting the restructuring of a debt, or other actions in connection with restructuring or modifying terms of a loan or transaction. One of skill in the art, having the benefit of the disclosure herein and knowledge ordinarily available about a contemplated system, can readily determine the purposes and use of this term, whether in the context of debt or otherwise, in various embodiments and contexts disclosed herein.

[0280] The term social network data collection, social network monitoring services, and social network data collection and monitoring services (and its various forms or derivatives) as utilized herein may be understood broadly to describe services relating to the acquisition, organizing, observing, or otherwise acting upon data or information derived from one or more social networks. The social network data collection and monitoring services may be a part of a related system of services or a standalone set of services. Social network data collection and monitoring services may be provided by a platform or system, without limitation. Social network data collection and monitoring services may be used in a variety of contexts such as lending, refinancing, negotiation, collection, consolidation, factoring, brokering, foreclosure, and combinations thereof, without limitation. Requests of social network data collection and monitoring, with configuration parameters, may be requested by other services, automatically initiated or triggered to occur based on conditions or circumstances that occur. An interface may be provided to configure, initiate, display or otherwise interact with social network data collection and monitoring services. Social networks, as utilized herein, reference any mass platform where data and communications occur between individuals and/or entities, where the data and communications are at least partially accessible to an embodiment system. In certain embodiments, the social network data includes publicly available (e.g., accessible without any authorization) information. In certain embodiments, the social network data includes information that is properly accessible to an embodiment system, but may include subscription access or other access to information that is not freely available to the public, but may be accessible (e.g., consistent with a privacy policy of the social network with its users). A social network may be primarily social in nature, but may additionally or alternatively include professional networks, alumni networks, industry related networks, academically oriented networks, or the like. In certain embodiments, a social network may be a crowdsourcing platform, such as a platform configured to accept queries or requests directed to users (and/or a subset of users, potentially meeting specified criteria), where users may be aware that certain communications will be shared and accessible to requestors, at least a portion of users of the platform, and/or publicly available. In certain embodiments, without limitation, social network data collection and monitoring services may be performed by a smart contract circuit or a robotic process automation system. One of skill in the art, having the benefit of the disclosure herein and knowledge ordinarily available about a contemplated system, can readily determine the purposes and use of social network data collection and monitoring services in various embodiments and contexts disclosed herein.

[0281] The term crowdsource and social network information as utilized herein may further be understood broadly to describe information acquired or provided in conjunction with a crowdsourcing model or transaction, or information acquired or provided on or in conjunction with a social network. Crowdsource and social network information may be provided by a platform or system, without limitation. Crowdsource and social network information may be acquired, provided or communicated to or from a group of information suppliers and by which responses to the request may be collected and processed. Crowdsource and social network information may provide information, conditions or factors relating to a loan or agreement. Crowdsource and social network information may be private or published, or combinations thereof, without limitation. In certain embodiments, without limitation, crowdsource and social network information may be acquired, provided, organized or processed, without limitation, by a smart contract circuit, wherein the crowdsource and social network information may be managed by a smart contract circuit that processes the information to satisfy a set of configured parameters. One of skill in the art, having the benefit of the disclosure herein and knowledge ordinarily available about a contemplated system can readily determine the purposes and use of this term in various embodiments and contexts disclosed herein.

[0282] The term negotiate (and other forms such as negotiating or negotiation) as utilized herein may be understood broadly to describe discussions or communications to bring about or obtain a compromise, outcome, or agreement between parties or entities. Negotiation may result in a successful outcome where terms are agreed between parties, or an unsuccessful outcome where the parties do not agree to specific terms, or combinations thereof, without limitation. A negotiation may be successful in one aspect or for a particular purpose, and unsuccessful in another aspect or for another purpose. Negotiation can occur in many contexts of contracts or loans, such as lending, refinancing, collection, consolidation, factoring, brokering, foreclosure, and combinations thereof, without limitation. For example, a borrower may negotiate an interest rate or loan terms with a lender. In another example, a borrower in default may negotiate an alternative resolution to avoid foreclosure with a lender. In certain embodiments, a smart contract circuit or robotic process automation system may negotiate for one or more of the parties, and process appropriate tasks for completing or attempting to complete a negotiation of terms. In some cases negotiation by the smart contract or robotic process automation system may not complete or be successful. Successful negotiation may enable automated action or trigger other conditions or terms to be implemented by the smart contract circuit or robotic process automation system. One of skill in the art, having the benefit of the disclosure herein and knowledge ordinarily available about a contemplated system, can readily determine the purposes and use of negotiation in various embodiments and contexts disclosed herein.

[0283] The term negotiate in various forms may more specifically be utilized herein in verb form (e.g. to negotiate) or in noun forms (e.g. a negotiation), or other forms to describe a context of mutual discussion leading to an outcome. For example, a robotic process automation system may negotiate terms and conditions on behalf of a party, which would be a use as a verb clause. In another example, a robotic process automation system may be negotiating terms and conditions for modification of a loan, or negotiating a consolidation offer, or other terms. As a noun clause, a negotiation (e.g. an event) may be performed by a robotic process automation system. Thus, in some circumstances a smart contract circuit or robotic process automation system may negotiate (e.g. as a verb clause) terms and conditions, or the description of doing so may be considered a negotiation (e.g. as a noun clause). One of skill in the art, having the benefit of the disclosure herein and knowledge about negotiating and negotiation, or other forms of the word negotiate, can readily determine the purposes and use of this term in various embodiments and contexts disclosed herein.

[0284] The term negotiate in various forms may also specifically be utilized to describe an outcome, such as a mutual compromise or completion of negotiation leading to an outcome. For example, a loan may, by robotic process automation system or otherwise, be considered negotiated as a successful outcome that has resulted in an agreement between parties, where the negotiation has reached completion. Thus, in some circumstances a smart contract circuit or robotic process automation system may have negotiated to completion a set of terms and conditions, or a negotiated loan. One of skill in the art, having the benefit of the disclosure herein and knowledge ordinarily available for a contemplated system, can readily determine the purposes and use of this term as it relates to a mutually agreed outcome through completion of negotiation in various embodiments and contexts disclosed herein.

[0285] The term negotiate in various forms may also specifically be utilized to characterize an event such as a negotiating event, or an event negotiation, including reaching a set of agreeable terms between parties. An event requiring mutual agreement or compromise between parties may be considered a negotiating event, without limitation. For example, during the procurement of a loan, the process of reaching a mutually acceptable set of terms and conditions between parties could be considered a negotiating event. Thus, in some circumstances a smart contract circuit or robotic process automation system may accommodate the communications, actions, or behaviors of the parties for a negotiated event.

[0286] The term collection (and other forms such as collect or collecting) as utilized herein may be understood broadly to describe the acquisition of a tangible (e.g. physical item), intangible (e.g. data, a license, or a right), or monetary (e.g. payment) item, or other obligation or asset from a source. The term generally may relate to the entire prospective acquisition of such an item from related tasks in early stages to related tasks in late stages or full completion of the acquisition of the item. Collection may result in a successful outcome where the item is tendered to a party, or may or an unsuccessful outcome where the item is not tendered or acquired to a party, or combinations thereof (e.g., a late or otherwise deficient tender of the item), without limitation. Collection may occur in many different contexts of contracts or loans, such as lending, refinancing, consolidation, factoring, brokering, foreclosure, and data processing (e.g. data collection), or combinations thereof, without limitation. Collection may be used in the form of a noun (e.g. data collection or the collection of an overdue payment where it refers to an event or characterizes an event), may refer as a noun to an assortment of items (e.g. a collection of collateral for a loan where it refers to a number of items in a transaction), or may be used in the form of a verb (e.g. collecting a payment from the borrower). For example, a lender may collect an overdue payment from a borrower through an online payment, or may have a successful collection of overdue payments acquired through a customer service telephone call. In certain embodiments, a smart contract circuit or robotic process automation system may perform collection for one or more of the parties, and process appropriate tasks for completing or attempting collection for one or more items (e.g., an overdue payment). In some cases negotiation by the smart contract or robotic process automation system may not complete or be successful, and depending upon such outcomes this may enable automated action or trigger other conditions or terms. One of skill in the art, having the benefit of the disclosure herein and knowledge ordinarily available about a contemplated system, can readily determine the purposes and use of collection in various forms, embodiments, and contexts disclosed herein.

[0287] The term collection in various forms may also more specifically be utilized herein in noun form to describe a context for an event or thing, such as a collection event, or a collection payment. For example, a collection event may refer to a communication to a party or other activity that relates to acquisition of an item in such an activity, without limitation. A collection payment, for example, may relate to a payment made by a borrower that has been acquired through the process of collection, or through a collection department with a lender. Although not limited to an overdue, delinquent or defaulted loan, collection may characterize an event, payment or department, or other noun associated with a transaction or loan, as being a remedy for something that has become overdue. Thus, in some circumstances a smart contract circuit or robotic process automation system may collect a payment or installment from a borrower, and the activity of doing so may be considered a collection event, without limitation.

[0288] The term collection in various forms may also more specifically be utilized herein as an adjective or other forms to describe a context relating to litigation, such as the outcome of a collection litigation (e.g. litigation regarding overdue or default payments on a loan). For example, the outcome of a collection litigation may be related to delinquent payments which are owed by a borrower or other party, and collection efforts relating to those delinquent payments may be litigated by parties. Thus, in some circumstances a smart contract circuit or robotic process automation system may receive, determine or otherwise administrate the outcome of collection litigation.

[0289] The term collection in various forms may also more specifically be utilized herein as an adjective or other forms to describe a context relating to an action of acquisition, such as a collection action (e.g. actions to induce tendering or acquisition of overdue or default payments on a loan or other obligation). The terms collection yield, financial yield of collection, and/or collection financial yield may be used. The result of such a collection action may or may not have a financial yield. For example, a collection action may result in the payment of one or more outstanding payments on a loan, which may render a financial yield to another party such as the lender. Thus, in some circumstances a smart contract circuit or robotic process automation system may render a financial yield from a collection action, or otherwise administrate or in some manner assist in a financial yield of a collection action. In embodiments, a collection action may include the need for collection litigation.

[0290] The term collection in various forms (collection ROI, ROI on collection, ROI on collection activity, collection activity ROI, and the like) may also more specifically be utilized herein to describe a context relating to an action of receiving value, such as a collection action (e.g. actions to induce tendering or acquisition of overdue or default payments on a loan or other obligation), wherein there is a return on investment (ROI). The result of such a collection action may or may not have an ROI, either with respect to the collection action itself (as an ROI on the collection action) or as an ROI on the broader loan or transaction that is the subject of the collection action. For example, an ROI on a collection action may be prudent or not with respect to a default loan, without limitation, depending upon whether the ROI will be provided to a party such as the lender. A projected ROI on collection may be estimated, or may also be calculated given real events that transpire. In some circumstances, a smart contract circuit or robotic process automation system may render an estimated ROI for a collection action or collection event, or may calculate an ROI for actual events transpiring in a collection action or collection event, without limitation. In embodiments, such a ROI may be a positive or negative figure, whether estimated or actual.

[0291] The term reputation, measure of reputation, lender reputation, borrower reputation, entity reputation, and the like may include general, widely held beliefs, opinions, and/or perceptions that are generally held about an individual, entity, collateral, and the like. A measure for reputation may be determined based on social data including likes/dislikes, review of entity or products and services provided by the entity, rankings of the company or product, current and historic market and financial data include price, forecast, buy/sell recommendations, financial news regarding entity, competitors, and partners. Reputations may be cumulative in that a product reputation and the reputation of a company leader or lead scientist may influence the overall reputation of the entity. Reputation of an institute associated with an entity (e.g. a school being attended by a student) may influence the reputation of the entity. In some circumstances, a smart contract circuit or robotic process automation system may collect or initiate collection of data related to the above and determine a measure or ranking of reputation. A measure or ranking of an entity's reputation may be used by a smart contract circuit or robotic process automation system in determining whether to enter into an agreement with the entity, determination of terms and conditions of a loan, interest rates, and the like. In certain embodiments, indicia of a reputation determination may be related to outcomes of one or more transactions (e.g., a comparison of “likes” on a particular social media data set to an outcome index, such as successful payments, successful negotiation outcomes, ability to liquidate a particular type of collateral, etc.) to determine the measure or ranking of an entity's reputation. One of skill in the art, having the benefit of the disclosure herein and knowledge ordinarily available about a contemplated system, can readily determine the purposes and use of the reputation, a measure or ranking of the reputation, and/or utilization of the reputation in negotiations, determination of terms and conditions, determination of whether to proceed with a transaction, and other various embodiments and contexts disclosed herein.

[0292] The term collection in various forms (e.g. collector) may also more specifically be utilized herein to describe a party or entity that induces, administrates, or facilitates a collection action, collection event, or other collection related context. The measure of reputation of a party involved, such as a collector, or during the context of a collection, may be estimated or calculated using objective, subjective, or historical metrics or data. For example, a collector may be involved in a collection action, and the reputation of that collector may be used to determine decisions, actions or conditions. Similarly, a collection may be also used to describe objective, subjective or historical metrics or data to measure the reputation of a party involved, such as a lender, borrower or debtor. In some circumstances, a smart contract circuit or robotic process automation system may render a collection or measures, or implement a collector, within the context of a transaction or loan.

[0293] The term collection and data collection in various forms, including data collection systems, may also more specifically be utilized herein to describe a context relating to the acquisition, organization, or processing of data, or combinations thereof, without limitation. The result of such a data collection may be related or wholly unrelated to a collection of items (e.g., grouping of the items, either physically or logically), or actions taken for delinquent payments (e.g., collection of collateral, a debt, or the like), without limitation. For example, a data collection may be performed by a data collection system, wherein data is acquired, organized or processed for decision-making, monitoring, or other purposes of prospective or actual transaction or loan. In some circumstances, a smart contract or robotic process automation system may incorporate data collection or a data collection system, to perform portions or entire tasks of data collection, without limitation. One of skill in the art, having the benefit of the disclosure herein and knowledge ordinarily available for a contemplated system, can readily determine and distinguish the purposes and use of collection in the context of data or information as used herein.

[0294] The terms refinance, refinancing activity(ies), refinancing interactions, refinancing outcomes, and similar terms, as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure refinance and refinancing activities include replacing an existing mortgage, loan, bond, debt transaction, or the like with a new mortgage, loan, bond, or debt transaction that pays off or ends the previous financial arrangement. In certain embodiments, any change to terms and conditions of a loan, and/or any material change to terms and conditions of a loan, may be considered a refinancing activity. In certain embodiments, a refinancing activity is considered only those changes to a loan agreement that result in a different financial outcome for the loan agreement. Typically, the new loan should be advantageous to the borrower or issuer, and/or mutually agreeable (e.g., improving a raw financial outcome of one, and a security or other outcome for the other). Refinancing may be done to reduce interest rates, lower regular payments, change the loan term, change the collateral associated with the loan, consolidate debt into a single loan, restructure debt, change a type of loan (e.g. variable rate to fixed rate), pay off a loan that is due, in response to an improved credit score, to enlarge the loan, and/or in response to a change in market conditions (e.g. interest rates, value of collateral, and the like).

[0295] Refinancing activity may include initiating an offer to refinance, initiating a request to refinance, configuring a refinancing interest rate, configuring a refinancing payment schedule, configuring a refinancing balance in a response to the amount or terms of the refinanced loan, configuring collateral for a refinancing including changes in collateral used, changes in terms and conditions for the collateral, a change in the amount of collateral and the like, managing use of proceeds of a refinancing, removing or placing a lien on different items of collateral as appropriate given changes in terms and conditions as part of a refinancing, verifying title for a new or existing item of collateral to be used to secure the refinanced loan, managing an inspection process title for a new or existing item of collateral to be used to secure the refinanced loan, populating an application to refinance a loan, negotiating terms and conditions for a refinanced loan and closing a refinancing. Refinance and refinancing activities may be disclosed in the context of data collection and monitoring services that collect a training set of interactions between entities for a set of loan refinancing activities. Refinance and refinancing activities may be disclosed in the context of an artificial intelligence system that is trained using the collected training set of interactions that includes both refinancing activities and outcomes. The trained artificial intelligence may then be used to recommend a refinance activity, evaluate a refinance activity, make a prediction around an expected outcome of refinancing activity, and the like. Refinance and refinancing activities may be disclosed in the context of smart contract systems which may automate a subset of the interactions and activities of refinancing. In an example, a smart contract system may automatically adjust an interest rate for a loan based on information collected via at least one of an Internet of Things system, a crowdsourcing system, a set of social network analytic services and a set of data collection and monitoring services. The interest rate may be adjusted based on rules, thresholds, model parameters that determine, or recommend, an interest rate for refinancing a loan based on interest rates available to the lender from secondary lenders, risk factors of the borrower (including predicted risk based on one or more predictive models using artificial intelligence), marketing factors (such as competing interest rates offered by other lenders), and the like. Outcomes and events of a refinancing activity may be recorded in a distributed ledger. Based on the outcome of a refinance activity, a smart contract for the refinance loan may be automatically reconfigured to define the terms and conditions for the new loan such as a principal amount of debt, a balance of debt, a fixed interest rate, a variable interest rate, a payment amount, a payment schedule, a balloon payment schedule, a specification of collateral, a specification of substitutability of collateral, a party, a guarantee, a guarantor, a security, a personal guarantee, a lien, a duration, a covenant, a foreclose condition, a default condition, and a consequence of default.

[0296] One of skill in the art, having the benefit of the disclosure herein and knowledge ordinarily available about a contemplated system can readily determine which aspects of the present disclosure will benefit from a particular application of a refinance activity, how to choose or combine refinance activities, how to implement systems, services, or circuits to automatically perform of one or more (or all) aspects of a refinance activity, and the like. Certain considerations for the person of skill in the art, or embodiments of the present disclosure in choosing an appropriate training sets of interactions with which to train an artificial intelligence to take action, recommend or predict the outcome of certain refinance activities. While specific examples of refinance and refinancing activities are described herein for purposes of illustration, any embodiment benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein, are specifically contemplated within the scope of the present disclosure.

[0297] The terms consolidate, consolidation activity(ies), loan consolidation, debt consolidation, consolidation plan, and similar terms, as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure consolidate, consolidation activity(ies), loan consolidation, debt consolidation, or consolidation plan are related to the use of a single large loan to pay off several smaller loans, and/or the use of one or more of a set of loans to pay off at least a portion of one or more of a second set of loans. In embodiments, loan consolidation may be secured (i.e., backed by collateral) or unsecured. Loans may be consolidated to obtain a lower interest rate than one or more of the current loans, to reduce total monthly loan payments, and/or to bring a debtor into compliance on the consolidated loans or other debt obligations of the debtor. Loans that may be classified as candidates for consolidation may be determined based on a model that processes attributes of entities involved in the set of loans including identity of a party, interest rate, payment balance, payment terms, payment schedule, type of loan, type of collateral, financial condition of party, payment status, condition of collateral, and value of collateral. Consolidation activities may include managing at least one of identification of loans from a set of candidate loans, preparation of a consolidation offer, preparation of a consolidation plan, preparation of content communicating a consolidation offer, scheduling a consolidation offer, communicating a consolidation offer, negotiating a modification of a consolidation offer, preparing a consolidation agreement, executing a consolidation agreement, modifying collateral for a set of loans, handling an application workflow for consolidation, managing an inspection, managing an assessment, setting an interest rate, deferring a payment requirement, setting a payment schedule, and closing a consolidation agreement. In embodiments, there may be systems, circuits, and/or services configured to create, configure (such as using one or more templates or libraries), modify, set, or otherwise handle (such as in a user interface) various rules, thresholds, conditional procedures, workflows, model parameters, and the like to determine, or recommend, a consolidation action or plan for a lending transaction or a set of loans based on one or more events, conditions, states, actions, or the like. In embodiments, a consolidation plan may be based on various factors, such as the status of payments, interest rates of the set of loans, prevailing interest rates in a platform marketplace or external marketplace, the status of the borrowers of a set of loans, the status of collateral or assets, risk factors of the borrower, the lender, one or more guarantors, market risk factors and the like. Consolidation and consolidation activities may be disclosed in the context of data collection and monitoring services that collect a training set of interactions between entities for a set of loan consolidation activities. consolidation and consolidation activities may be disclosed in the context of an artificial intelligence system that is trained using the collected training set of interactions that includes both consolidation activities and outcomes associated with those activities. The trained artificial intelligence may then be used to recommend a consolidation activity, evaluate a consolidation activity, make a prediction around an expected outcome of consolidation activity, and the like based models including status of debt, condition of collateral or assets used to secure or back a set of loans, the state of a business or business operation (e.g., receivables, payables, or the like), conditions of parties (such as net worth, wealth, debt, location, and other conditions), behaviors of parties (such as behaviors indicating preferences, behaviors indicating debt preferences), and others. Debt consolidation, loan consolidation and associated consolidation activities may be disclosed in the context of smart contract systems which may automate a subset of the interactions and activities of consolidation. In embodiments, consolidation may include consolidation with respect to terms and conditions of sets of loans, selection of appropriate loans, configuration of payment terms for consolidated loans, configuration of payoff plans for pre-existing loans, communications to encourage consolidation, and the like. In embodiments, the artificial intelligence of a smart contract may automatically recommend or set rules, thresholds, actions, parameters and the like (optionally by learning to do so based on a training set of outcomes over time), resulting in a recommended consolidation plan, which may specify a series of actions required to accomplish a recommended or desired outcome of consolidation (such as within a range of acceptable outcomes), which may be automated and may involve conditional execution of steps based on monitored conditions and/or smart contract terms, which may be created, configured, and/or accounted for by the consolidation plan. Consolidation plans may be determined and executed based at least one part on market factors (such as competing interest rates offered by other lenders, values of collateral, and the like) as well as regulatory and/or compliance factors. Consolidation plans may be generated and/or executed for creation of new consolidated loans, for secondary loans related to consolidated loans, for modifications of existing loans related to consolidation, for refinancing terms of a consolidated loan, for foreclosure situations (e.g., changing from secured loan rates to unsecured loan rates), for bankruptcy or insolvency situations, for situations involving market changes (e.g., changes in prevailing interest rates) and others. consolidation.

[0298] Certain of the activities related to loans, collateral, entities and the like may apply to a wide variety of loans and may not apply explicitly to consolidation activities. The categorization of the activities as consolidation activities may be based on the context of the loan for which the activities are taking place. However, one of skill in the art, having the benefit of the disclosure herein and knowledge ordinarily available about a contemplated system can readily determine which aspects of the present disclosure will benefit from a particular application of a consolidation activity, how to choose or combine consolidation activities, how to implement selected services, circuits, and/or systems described herein to perform certain loan consolidation operations, and the like. While specific examples of consolidation and consolidation activities are described herein for purposes of illustration, any embodiment benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein, are specifically contemplated within the scope of the present disclosure.

[0299] The terms factoring a loan, factoring a loan transaction, factors, factoring a loan interaction, factoring assets or sets of assets used for factoring and similar terms, as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure factoring may be applied to factoring assets such as invoices, inventory, accounts receivable, and the like, where the realized value of the item is in the future. For example, the accounts receivable is worth more when it has been paid and there is less risk of default. Inventory and Work in Progress (WIP) may be worth more as final product rather than components. References to accounts receivable should be understood to encompass these terms and not be limiting. Factoring may include a sale of accounts receivable at a discounted rate for value in the present (often cash). Factoring may also include the use of accounts receivable as collateral for a short term loan. In both cases the value of the accounts receivable or invoices may be discounted for multiple reasons including the future value of money, a term of the accounts receivable (e.g., 30 day net payment vs. 90 day net payment), a degree of default risk on the accounts receivable, a status of receivables, a status of work-in-progress (WIP), a status of inventory, a status of delivery and/or shipment, financial condition(s) of parties owing against the accounts receivable, a status of shipped and/or billed, a status of payments, a status of the borrower, a status of inventory, a risk factor of a borrower, a lender, one or more guarantors, market risk factors, a status of debt (are there other liens present on the accounts receivable or payment owed on the inventory, a condition of collateral assets (e.g. the condition of the inventory—is it current or out of date, are invoices in arrears), a state of a business or business operation, a condition of a party to the transaction (such as net worth, wealth, debt, location, and other conditions), a behavior of a party to the transaction (such as behaviors indicating preferences, behaviors indicating negotiation styles, and the like), current interest rates, any current regulatory and compliance issues associated with the inventory or accounts receivable (e.g. if inventory is being factored, has the intended product received appropriate approvals), and there legal actions against the borrower, and many others, including predicted risk based on one or more predictive models using artificial intelligence). A factor is an individual, business, entity, or groups thereof which agree to provide value in exchange for either the outright acquisition of the invoices in a sale or the use of the invoices as collateral for a loan for the value. Factoring a loan may include the identification of candidates (both lenders and borrowers) for factoring, a plan for factoring specifying the proposed receivables (e.g. all, some, only those meeting certain criteria), and a proposed discount factor, communication of the plan to potential parties, proffering an offer and receiving an offer, verification of quality of receivables, conditions regarding treatment of the receivables for the term of the loan. While specific examples of factoring and factoring activities are described herein for purposes of illustration, any embodiment benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein, are specifically contemplated within the scope of the present disclosure.

[0300] The terms mortgage, brokering a mortgage, mortgage collateral, mortgage loan activities, and/or mortgage related activities as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, a mortgage is an interaction where a borrower provides the title or a lien on the title of an item of value, typically property, to a lender as security in exchange for money or another item of value, to be repaid, typically with interest, to the lender. The exchange includes the condition that, upon repayment of the loan, the title reverts to the borrower and/or the lien on the property is removed. The brokering of a mortgage may include the identification of potential properties, lenders, and other parties to the loan, and arranging or negotiating the terms of the mortgage. Certain components or activities may not be considered mortgage related individually, but may be considered mortgage related when used in conjunction with a mortgage, act upon a mortgage, are related to an entity or party to a mortgage, and the like. For example, brokering may apply to the offering of a variety of loans including unsecured loans, outright sale of property and the like. Mortgage activities and mortgage interactions may include mortgage marketing activity, identification of a set of prospective borrowers, identification of property to mortgage, identification of collateral property to mortgage, qualification of borrower, title search and/or title verification for prospective mortgage property, property assessment, property inspection, or property valuation for prospective mortgage property, income verification, borrower demographic analysis, identification of capital providers, determination of available interest rates, determination of available payment terms and conditions, analysis of existing mortgage(s), comparative analysis of existing and new mortgage terms, completion of application workflow (e.g. keep the application moving forward by initiating next steps in the process as appropriate), population of fields of application, preparation of mortgage agreement, completion of schedule for mortgage agreement, negotiation of mortgage terms and conditions with capital provider, negotiation of mortgage terms and conditions with borrower, transfer of title, placement of lien on mortgaged property and closing of mortgage agreement, and similar terms, as utilized herein should be understood broadly. While specific examples of mortgages and mortgage brokering are described herein for purposes of illustration, any embodiment benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein, are specifically contemplated within the scope of the present disclosure.

[0301] The terms debt management, debt transactions, debt actions, debt terms and conditions, syndicating debt, consolidating debt, and/or debt portfolios, as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure a debt includes something of monetary value that is owed to another. A loan typically results in the borrower holding the debt (e.g. the money that must be paid back according to the terms of the loan, which may include interest). Consolidation of debt includes the use of a new, single loan to pay back multiple loans (or various other configurations of debt structuring as described herein, and as understood to one of skill in the art). Often the new loan may have better terms or lower interest rates. Debt portfolios include a number of pieces or groups of debt, often having different characteristics including term, risk, and the like. Debt portfolio management may involve decisions regarding the quantity and quality of the debt being held and how best to balance the various debts to achieve a desired risk/reward position based on: investment policy, return on risk determinations for individual pieces of debt, or groups of debt. Debt may be syndicated where multiple lenders fund a single loan (or set of loans) to a borrower. Debt portfolios may be sold to a third party (e.g., at a discounted rate). Debt compliance includes the various measures taken to ensure that debt is repaid. Demonstrating compliance may include documentation of the actions taken to repay the debt.

[0302] Transactions related to a debt (debt transactions) and actions related to the debt (debt actions) may include offering a debt transaction, underwriting a debt transaction, setting an interest rate, deferring a payment requirement, modifying an interest rate, validating title, managing inspection, recording a change in title, assessing the value of an asset, calling a loan, closing a transaction, setting terms and conditions for a transaction, providing notices required to be provided, foreclosing on a set of assets, modifying terms and conditions, setting a rating for an entity, syndicating debt, and/or consolidating debt. Debt terms and conditions may include a balance of debt, a principal amount of debt, a fixed interest rate, a variable interest rate, a payment amount, a payment schedule, a balloon payment schedule, a specification of assets that back the bond, a specification of substitutability of assets, a party, an issuer, a purchaser, a guarantee, a guarantor, a security, a personal guarantee, a lien, a duration, a covenant, a foreclose condition, a default condition, and a consequence of default. While specific examples of debt management and debt management activities are described herein for purposes of illustration, any embodiment benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein, are specifically contemplated within the scope of the present disclosure.

[0303] The terms condition, condition classification, classification models, condition management, and similar terms, as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure condition, condition classification, classification models, condition management, include classifying or determining a condition of an asset, issuer, borrower, loan, debt, bond, regulatory status, term or condition for a bond, loan or debt transaction that is specified and monitored in the contract, and the like. Based on a classified condition of an asset, condition management may include actions to maintain or improve a condition of the asset or the use of that asset as collateral. Based on a classified condition of an issuer, borrower, party regulatory status, and the like, condition management may include actions to alter the terms or conditions of a loan or bond. Condition classification may include various rules, thresholds, conditional procedures, workflows, model parameters, and the like to classify a condition of an asset, issuer, borrower, loan, debt, bond, regulatory status, term or condition for a bond, loan or debt transaction, and the like based on data from Internet of Things devices, data from a set of environmental condition sensors, data from a set of social network analytic services and a set of algorithms for querying network domains, social media data, crowdsourced data, and the like. Condition classification may include grouping or labeling entities, or clustering the entities, as similarly positioned with regard to some aspect of the classified condition (e.g., a risk, quality, ROI, likelihood for recovery, likelihood to default, or some other aspect of the related debt).

[0304] Various classification models are disclosed where the classification and classification model may be tied to a geographic location relating to the collateral, the issuer, the borrower, the distribution of the funds or other geographic locations. Classification and classification models are disclosed where artificial intelligence is used to improve a classification model (e.g. refine a model by making refinements using artificial intelligence data). Thus artificial intelligence may be considered, in some instances, as a part of a classification model and vice versa. Classification and classification models are disclosed where social media data, crowdsourced data, or IoT data is used as input for refining a model, or as input to a classification model. Examples of IoT data may include images, sensor data, location data, and the like. Examples of social media data or crowdsourced data may include behavior of parties to the loan, financial condition of parties, adherence to a parties to a term or condition of the loan, or bond, or the like. Parties to the loan may include issuers of a bond, related entities, lender, borrower, 3rd parties with an interest in the debt. Condition management may be discussed in connection with smart contract services which may include condition classification, data collection and monitoring, and bond, loan and debt transaction management. Data collection and monitoring services are also discussed in conjunction with classification and classification models which are related when classifying an issuer of a bond issuer, an asset or collateral asset related to the bond, collateral assets backing the bond, parties to the bond, and sets of the same. In some embodiments a classification model may be included when discussing bond types. Specific steps, factors or refinements may be considered a part of a classification model. In various embodiments, the classification model may change both in an embodiment, or in the same embodiment which is tied to a specific jurisdiction. Different classification models may use different data sets (e.g. based on the issuer, the borrower, the collateral assets, the bond type, the loan type, and the like) and multiple classification models may be used in a single classification. For example, one type of bond, such as a municipal bond, may allow a classification model that is based on bond data from municipalities of similar size and economic prosperity, whereas another classification model may emphasize data from IoT sensors associated with a collateral asset. Accordingly, different classification models will offer benefits or risks over other classification models, depending upon the embodiment and the specifics of the bond, loan or debt transaction. A classification model includes an approach or concept for classification. Conditions classified for a bond, loan, or debt transaction may include a principal amount of debt, a balance of debt, a fixed interest rate, a variable interest rate, a payment amount, a payment schedule, a balloon payment schedule, a specification of assets that back the bond, loan or debt transaction, a specification of substitutability of assets, a party, an issuer, a purchaser, a guarantee, a guarantor, a security, a personal guarantee, a lien, a duration, a covenant, a foreclose condition, a default condition, and/or a consequence of default. Conditions classified may include type of bond issuer such as a municipality, a corporation, a contractor, a government entity, a non-governmental entity, and a non-profit entity. Entities may include a set of issuers, a set of bonds, a set of parties, and/or a set of assets. Conditions classified may include an entity condition such as net worth, wealth, debt, location, and other conditions), behaviors of parties (such as behaviors indicating preferences, behaviors indicating debt preferences), and the like. Conditions classified may include an asset or type of collateral such as a municipal asset, a vehicle, a ship, a plane, a building, a home, real estate property, undeveloped land, a farm, a crop, a municipal facility, a warehouse, a set of inventory, a commodity, a security, a currency, a token of value, a ticket, a cryptocurrency, a consumable item, an edible item, a beverage, a precious metal, an item of jewelry, a gemstone, an item of intellectual property, an intellectual property right, a contractual right, an antique, a fixture, an item of furniture, an item of equipment, a tool, an item of machinery, and an item of personal property. Conditions classified may include a bond type where bond type may include a municipal bond, a government bond, a treasury bond, an asset-backed bond, and a corporate bond. Conditions classified may include a default condition, a foreclosure condition, a condition indicating violation of a covenant, a financial risk condition, a behavioral risk condition, a policy risk condition, a financial health condition, a physical defect condition, a physical health condition, an entity risk condition and an entity health condition. Conditions classified may include an environment where environment may include an environment selected from among a municipal environment, a corporate environment, a securities trading environment, a real property environment, a commercial facility, a warehousing facility, a transportation environment, a manufacturing environment, a storage environment, a home, and a vehicle. Actions based on the condition of an asset, issuer, borrower, loan, debt, bond, regulatory status and the like, may include managing, reporting on, syndicating, consolidating, or otherwise handling a set of bonds (such as municipal bonds, corporate bonds, performance bonds, and others), a set of loans (subsidized and unsubsidized, debt transactions and the like, monitoring, classifying, predicting, or otherwise handling the reliability, quality, status, health condition, financial condition, physical condition or other information about a guarantee, a guarantor, a set of collateral supporting a guarantee, a set of assets backing a guarantee, or the like. Bond transaction activities in response to a condition of the bond may include offering a debt transaction, underwriting a debt transaction, setting an interest rate, deferring a payment requirement, modifying an interest rate, validating title, managing inspection, recording a change in title, assessing the value of an asset, calling a loan, closing a transaction, setting terms and conditions for a transaction, providing notices required to be provided, foreclosing on a set of assets, modifying terms and conditions, setting a rating for an entity, syndicating debt, and/or consolidating debt.

[0305] One of skill in the art, having the benefit of the disclosure herein and knowledge ordinarily available about a contemplated system, can readily determine which aspects of the present disclosure will benefit a particular application for a classification model, how to choose or combine classification models to arrive at a condition, and/or calculate a value of collateral given the required data. Certain considerations for the person of skill in the art, or embodiments of the present disclosure in choosing an appropriate condition to manage, include, without limitation: the legality of the condition given the jurisdiction of the transaction, the data available for a given collateral, the anticipated transaction type (loan, bond or debt), the specific type of collateral, the ratio of the loan to value, the ratio of the collateral to the loan, the gross transaction/loan amount, the credit scores of the borrower and the lender, and other considerations. While specific examples of conditions, condition classification, classification models, and condition management are described herein for purposes of illustration, any embodiment benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein, are specifically contemplated within the scope of the present disclosure.

[0306] The terms classify, classifying, classification, categorization, categorizing, categorize (and similar terms) as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, classifying a condition or item may include actions to sort the condition or item into a group or category based on some aspect, attribute, or characteristic of the condition or item where the condition or item is common or similar for all the items placed in that classification, despite divergent classifications or categories based on other aspects or conditions at the time. Classification may include recognition of one or more parameters, features, characteristics, or phenomena associated with a condition or parameter of an item, entity, person, process, item, financial construct, or the like. Conditions classified by a condition classifying system may include a default condition, a foreclosure condition, a condition indicating violation of a covenant, a financial risk condition, a behavioral risk condition, a contractual performance condition, a policy risk condition, a financial health condition, a physical defect condition, a physical health condition, an entity risk condition, and/or an entity health condition. A classification model may automatically classify or categorize items, entities, process, items, financial constructs or the like based on data received from a variety of sources. The classification model may classify items based on a single attribute or a combination of attributes, and/or may utilize data regarding the items to be classified and a model. The classification model may classify individual items, entities, financial constructs or groups of the same. A bond may be classified based on the type of bond ((e.g. municipal bonds, corporate bonds, performance bonds, and the like), rate of return, bond rating (3rd party indicator of bond quality with respect to bond issuer's financial strength, and/or ability to bap bond's principal and interest, and the like. Lenders or bond issuers may be classified based on the type of lender or issuer, permitted attributes (e.g. based on income, wealth, location (domestic or foreign), various risk factors, status of issuers, and the like. Borrowers may be classified based on permitted attributes (e.g. income, wealth, total assets, location, credit history), risk factors, current status (e.g. employed, a student), behaviors of parties (such as behaviors indicating preferences, reliability, and the like), and the like. A condition classifying system may classify a student recipient of a loan based on progress of the student toward a degree, the student's grades or standing in their classes, students' status at the school (matriculated, on probation and the like), the participation of a student in a non-profit activity, a deferment status of the student, and the participation of the student in a public interest activity. Conditions classified by a condition classifying system may include a state of a set of collateral for a loan or a state of an entity relevant to a guarantee for a loan. Conditions classified by a condition classifying system may include a medical condition of a borrower, guarantor, subsidizer or the like. Conditions classified by a condition classifying system may include compliance with at least one of a law, a regulation, or a policy related to a lending transaction or lending institute. Conditions classified by a condition classifying system may include a condition of an issuer for a bond, a condition of a bond, a rating of a loan-related entity, and the like. Conditions classified by a condition classifying system may include an identify of a machine, a component, or an operational mode. Conditions classified by a condition classifying system may include a state or context (such as a state of a machine, a process, a workflow, a marketplace, a storage system, a network, a data collector, or the like). A condition classifying system may classify a process involving a state or context (e.g., a data storage process, a network coding process, a network selection process, a data marketplace process, a power generation process, a manufacturing process, a refining process, a digging process, a boring process, and/or other process described herein. A condition classifying system may classify a set of loan refinancing actions based on a predicted outcome of the set of loan refinancing actions. A condition classifying system may classify a set of loans as candidates for consolidation based on attributes such as identity of a party, an interest rate, a payment balance, payment terms, payment schedule, a type of loan, a type of collateral, a financial condition of party, a payment status, a condition of collateral, a value of collateral, and the like. A condition classifying system may classify the entities involved in a set of factoring loans, bond issuance activities, mortgage loans, and the like. A condition classifying system may classify a set of entities based on projected outcomes from various loan management activities. A condition classifying system may classify a condition of a set of issuers based on information from Internet of Things data collection and monitoring services, a set of parameters associated with an issuer, a set of social network monitoring and analytic services, and the like. A condition classifying system may classify a set of loan collection actions, loan consolidation actions, loan negotiation actions, loan refinancing actions and the like based on a set of projected outcomes for those activities and entities.

[0307] The term subsidized loan, subsidizing a loan, (and similar terms) as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, a subsidized loan is the loan of money or an item of value wherein payment of interest on the value of the loan may be deferred, postponed or delayed, with or without accrual, such as while the borrower is in school, is unemployed, is ill, and the like. In embodiments, a loan may be subsidized when the payment of interest on a portion or subset of the loan is borne or guaranteed by someone other than the borrower. Examples of subsidized loans may include a municipal subsidized loan, a government subsidized loan, a student loan, an asset-backed subsidized loan, and a corporate subsidized loan. An example of a subsidized student loan may include student loans which may be subsidized by the government and on which interest may be deferred or not accrue based on progress of the student toward a degree, the participation of a student in a non-profit activity, a deferment status of the student, and the participation of the student in a public interest activity. An example of a government subsidized housing loan may include governmental subsidies which may exempt the borrower from paying closing costs, first mortgage payment and the like. Conditions for such subsidized loans may include location of the property (rural or urban), income of the borrower, military status of the borrower, ability of the purchased home to meet health and safety standards, a limit on the profits you can earn on the sale of your home, and the like. Certain usages of the word loan may not apply to a subsidized loan but rather to a regular loan. One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system ordinarily available to that person, can readily determine which aspects of the present disclosure will benefit from consideration of a subsidized loan (e.g., in determining the value of the loan, negotiations related to the loan, terms and conditions related to the loan, etc.) wherein the borrower may be relieved of some of the loan obligations common for non-subsidized loans, where the subsidy may include forgiveness, delay or deferment of interest on a loan, or the payment of the interest by a third party. The subsidy may include the payment of closing costs including points, first payment and the like by a person or entity other than the borrower, and/or how to combine processes and systems from the present disclosure to enhance or benefit from title validation.

[0308] The term subsidized loan management (and similar terms) as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, subsidized loan management may include a plurality of activities and solutions for managing or responding to one or more events related to a subsidized loan wherein such events may include requests for a subsidized loan, offering a subsidized loan, accepting a subsidized loan, providing underwriting information for a subsidized loan, providing a credit report on a borrower seeking a subsidized loan, deferring a required payment as part of the loan subsidy, setting an interest rate for a subsidized loan where a lower interest rate may be part of the subsidy, deferring a payment requirement as part of the loan subsidy, identifying collateral for a loan, validating title for collateral or security for a loan, recording a change in title of property, assessing the value of collateral or security for a loan, inspecting property that is involved in a loan, identifying a change in condition of an entity relevant to a loan, a change in value of an entity that is relevant to a loan, a change in job status of a borrower, a change in financial rating of a lender, a change in financial value of an item offered as a security, providing insurance for a loan, providing evidence of insurance for property related to a loan, providing evidence of eligibility for a loan, identifying security for a loan, underwriting a loan, making a payment on a loan, defaulting on a loan, calling a loan, closing a loan, setting terms and conditions for a loan, foreclosing on property subject to a loan, modifying terms and conditions for a loan, for setting terms and conditions for a loan (such as a principal amount of debt, a balance of debt, a fixed interest rate, a variable interest rate, a payment amount, a payment schedule, a balloon payment schedule, a specification of collateral, a specification of substitutability of collateral, a party, a guarantee, a guarantor, a security, a personal guarantee, a lien, a duration, a covenant, a foreclose condition, a default condition, and a consequence of default), or managing loan-related activities (such as, without limitation, finding parties interested in participating in a loan transaction, handling an application for a loan, underwriting a loan, forming a legal contract for a loan, monitoring performance of a loan, making payments on a loan, restructuring or amending a loan, settling a loan, monitoring collateral for a loan, forming a syndicate for a loan, foreclosing on a loan, collecting on a loan, consolidating a set of loans, analyzing performance of a loan, handling a default of a loan, transferring title of assets or collateral, and closing a loan transaction), and the like. In embodiments, a system for handling a subsidized loan may include classifying a set of parameters of a set of subsidized loans on the basis of data relating to those parameters obtained from an Internet of Things data collection and monitoring service. Classifying the set of parameters of the set of subsidized loans may also be on the bases of data obtained from one or more configurable data collection and monitoring services that leverage social network analytic services, crowd sourcing services, and the like for obtaining parameter data (e.g., determination that a person or entity is qualified for the subsidized loan, determining a social value of providing the subsidized loan or removing a subsidization from a loan, determining that a subsidizing entity is legitimate, determining appropriate subsidization terms based on characteristics of the buyer and/or subsidizer, etc.).

[0309] The term foreclose, foreclosure, foreclose or foreclosure condition, default foreclosure collateral, default collateral, (and similar terms) as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, foreclose condition, default and the like describe the failure of a borrower to meet the terms of a loan. Without limitation to any other aspect or description of the present disclosure foreclose and foreclosure include processes by which a lender attempts to recover, from a borrower in a foreclose or default condition, the balance of a loan or take away in lieu, the right of a borrower to redeem a mortgage held in security for the loan. Failure to meet the terms of the loan may include failure to make specified payments, failure to adhere to a payment schedule, failure to make a balloon payment, failure to appropriately secure the collateral, failure to sustain collateral in a specified condition (e.g. in good repair), acquisition of a second loan, and the like. Foreclosure may include a notification to the borrower, the public, jurisdictional authorities of the forced sale of an item collateral such as through a foreclosure auction. Upon foreclosure, an item of collateral may be placed on a public auction site (such as eBay, Ѣ or an auction site appropriate for a particular type of property. The minimum opening bid for the item of collateral may be set by the lender and may cover the balance of the loan, interest on the loan, fees associated with the foreclosure and the like. Attempts to recover the balance of the loan may include the transfer of the deed for an item of collateral in lieu of foreclosure (e.g. a real-estate mortgage where the borrower holds the deed for a property which acts as collateral for the mortgage loan). Foreclosure may include taking possession of or repossessing the collateral (e.g. a car, a sports vehicle such as a boat, ATV, ski-mobile, jewelry). Foreclosure may include securing an item of collateral associated with the loan (such as by locking a connected device, such as a smart lock, smart container, or the like that contains or secures collateral). Foreclosure may include arranging for the shipping of an item of collateral by a carrier, freight forwarder of the like. Foreclosure may include arranging for the transport of an item of collateral by a drone, a robot, or the like for transporting collateral. In embodiments, a loan may allow for the substitution of collateral or the shifting of the lien from an item of collateral initially used to secure the loan to a substitute collateral where the substitute collateral is of higher value (to the lender) than the initial collateral or is an item in which the borrower has a greater equity. The result of the substitution of collateral is that when the loan goes into foreclosure, it is the substitute collateral that may be the subject of a forced sale or seizure. Certain usages of the word default may not apply to such as to foreclose but rather to a regular or default condition of an item. One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system ordinarily available to that person, can readily determine which aspects of the present disclosure will benefit from foreclosure, and/or how to combine processes and systems from the present disclosure to enhance or benefit from foreclosure. Certain considerations for the person of skill in the art, in determining whether the term foreclosure, foreclose condition, default and the like is referring to failure of a borrower to meet the terms of a loan and the related attempts by the lender to recover the balance of the loan or obtain ownership of the collateral.

[0310] The terms validation of tile, title validation, validating title, and similar terms, as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure validation of title and title validation include any efforts to verify or confirm the ownership or interest by an individual or entity in an item of property such as a vehicle, a ship, a plane, a building, a home, real estate property, undeveloped land, a farm, a crop, a municipal facility, a warehouse, a set of inventory, a commodity, a security, a currency, a token of value, a ticket, a cryptocurrency, a consumable item, an edible item, a beverage, a precious metal, an item of jewelry, a gemstone, an item of intellectual property, an intellectual property right, a contractual right, an antique, a fixture, an item of furniture, an item of equipment, a tool, an item of machinery, and an item of personal property. Efforts to verify ownership may include reference to bills of sale, government documentation of transfer of ownership, a legal will transferring ownership, documentation of retirement of liens on the item of property, verification of assignment of Intellectual Property to the proposed borrower in the appropriate jurisdiction, and the like. For real-estate property validation may include a review of deeds and records at a courthouse of a country, a state, a county or a district in which a building, a home, real estate property, undeveloped land, a farm, a crop, a municipal facility, a vehicle, a ship, a plane, or a warehouse is located or registered. Certain usages of the word validation may not apply to validation of a title or title validation but rather to confirmation that a process is operating correctly, that an individual has been correctly identified using biometric data, that intellectual property rights are in effect, that data is correct and meaningful, and the like. One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system ordinarily available to that person, can readily determine which aspects of the present disclosure will benefit from title validation, and/or how to combine processes and systems from the present disclosure to enhance or benefit from title validation. Certain considerations for the person of skill in the art, in determining whether the term validation is referring to title validation, are specifically contemplated within the scope of the present disclosure.

[0311] Without limitation to any other aspect or description of the present disclosure, validation includes any validating system including, without limitation, validating title for collateral or security for a loan, validating conditions of collateral for security or a loan, validating conditions of a guarantee for a loan, and the like. For instance, a validation service may provide lenders a mechanism to deliver loans with more certainty, such as through validating loan or security information components (e.g., income, employment, title, conditions for a loan, conditions of collateral, and conditions of an asset). In a non-limiting example, a validation service circuit may be structured to validate a plurality of loan information components with respect to a financial entity configured to determine a loan condition for an asset. Certain components may not be considered a validating system individually, but may be considered validating in an aggregated system—for example, an Internet of Things component may not be considered a validating component on its own, however an Internet of Things component utilized for asset data collection and monitoring may be considered a validating component when applied to validating a reliability parameter of a personal guarantee for a load when the Internet of Things component is associated with a collateralized asset. In certain embodiments, otherwise similar looking systems may be differentiated in determining whether such systems are for validation. For example, a blockchain-based ledger may be used to validate identities in one instance and to maintain confidential information in another instance. Accordingly, the benefits of the present disclosure may be applied in a wide variety of systems, and any such systems may be considered a system for validation herein, while in certain embodiments a given system may not be considered a validating system herein. One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system ordinarily available to that person, can readily determine which aspects of the present disclosure will benefit a particular system, and/or how to combine processes and systems from the present disclosure to enhance operations of the contemplated system. Certain considerations for the person of skill in the art, in determining whether a contemplated system is a validating system and/or whether aspects of the present disclosure can benefit or enhance the contemplated system include, without limitation: a lending platform having a social network monitoring system for validating the reliability of a guarantee for a loan; a lending platform having an Internet of Things data collection and monitoring system for validating reliability of a guarantee for a loan; a lending platform having a crowdsourcing and automated classification system for validating conditions of an issuer for a bond; a crowdsourcing system for validating quality, title, or other conditions of collateral for a loan; a biometric identify validation application such as utilizing DNA or fingerprints; IoT devices utilized to collectively validate location and identity of a fixed asset that is tagged by a virtual asset tag; validation systems utilizing voting or consensus protocols; artificial intelligence systems trained to recognize and validate events; validating information such as title records, video footage, photographs, or witnessed statements; validation representations related to behavior, such as to validate occurrence of conditions of compliance, to validate occurrence of conditions of default, to deter improper behavior or misrepresentations, to reduce uncertainty, or to reduce asymmetries of information; and the like.

[0312] The term underwriting (and similar terms) as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, underwriting includes any underwriting, including, without limitation, relating to underwriters, providing underwriting information for a loan, underwriting a debt transaction, underwriting a bond transaction, underwriting a subsidized loan transaction, underwriting a securities transaction, and the like. Underwriting services may be provided by financial entities, such as banks, insurance or investment houses, and the like, whereby the financial entity guarantees payment in case of a determination of a loss condition (e.g., damage or financial loss) and accept the financial risk for liability arising from the guarantee. For instance, a bank may underwrite a loan through a mechanism to perform a credit analysis that may lead to a determination of a loan to be granted, such as through analysis of personal information components related to an individual borrower requesting a consumer loan (e.g., employment history, salary and financial statements publicly available information such as the borrower's credit history), analysis of business financial information components from a company requesting a commercial load (e.g., tangible net worth, ratio of debt to worth (leverage), and available liquidity (current ratio)), and the like. In a non-limiting example, an underwriting services circuit may be structured to underwrite a financial transaction including a plurality of financial information components with respect to a financial entity configured to determine a financial condition for an asset. In certain embodiments, underwriting components may be considered underwriting for some purposes but not for other purposes—for example, an artificial intelligence system to collect and analyze transaction data may be utilized in conjunction with a smart contract platform to monitor loan transactions, but alternately used to collect and analyze underwriting data, such as utilizing a model trained by human expert underwriters. Accordingly, the benefits of the present disclosure may be applied in a wide variety of systems, and any such systems may be considered underwriting herein, while in certain embodiments a given system may not be considered underwriting herein. One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system ordinarily available to that person, can readily determine which aspects of the present disclosure will benefit a particular system, and/or how to combine processes and systems from the present disclosure to enhance operations of the contemplated system. Certain considerations for the person of skill in the art, in determining whether a contemplated system is underwriting and/or whether aspects of the present disclosure can benefit or enhance the contemplated system include, without limitation: a lending platform having an underwriting system for a loan with a set of data-integrated microservices such as including data collection and monitoring services, blockchain services, artificial intelligence services, and smart contract services for underwriting lending entities and transactions; underwriting processes, operations, and services; underwriting data, such as data relating to identities of prospective and actual parties involved insurance and other transactions, actuarial data, data relating to probability of occurrence and/or extent of risk associated with activities, data relating to observed activities and other data used to underwrite or estimate risk; an underwriting application, such as, without limitation, for underwriting any insurance offering, any loan, or any other transaction, including any application for detecting, characterizing or predicting the likelihood and/or scope of a risk, an underwriting or inspection flow about an entity serving a lending solution, an analytics solution, or an asset management solution; underwriting of insurance policies, loans, warranties, or guarantees; a blockchain and smart contract platform for aggregating identity and behavior information for insurance underwriting, such as with an optional distributed ledger to record a set of events, transactions, activities, identities, facts, and other information associated with an underwriting process; a crowdsourcing platform such as for underwriting of various types of loans, and guarantees; an underwriting system for a loan with a set of data-integrated microservices including data collection and monitoring services, blockchain services, artificial intelligence services, and smart contract services for underwriting lending entities and transactions; an underwriting solution to create, configure, modify, set or otherwise handle various rules, thresholds, conditional procedures, workflows, or model parameters; an underwriting action or plan for management a set of loans of a given type or types based on one or more events, conditions, states, actions, secondary loans or transactions to back loans, for collection, consolidation, foreclosure, situations of bankruptcy of insolvency, modifications of existing loans, situations involving market changes, foreclosure activities; adaptive intelligent systems including artificial intelligent models trained on a training set of underwriting activities by experts and/or on outcomes of underwriting actions to generate a set of predictions, classifications, control instructions, plans, models; underwriting system for a loan with a set of data-integrated microservices including data collection and monitoring services, blockchain services, artificial intelligence services, and smart contract services for underwriting lending entities and transactions; and the like.

[0313] The term insuring (and similar terms) as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, insuring includes any insuring, including, without limitation, providing insurance for a loan, providing evidence of insurance for an asset related to a loan, a first entity accepting a risk or liability for another entity, and the like. Insuring, or insurance, may be a mechanism through which a holder of the insurance is provided protection from a financial loss, such as in a form of risk management against the risk of a contingent or uncertain loss. The insuring mechanism may provide for an insurance, determine the need for an insurance, determine evidence of insurance, and the like, such as related to an asset, transaction for an asset, loan for an asset, security, and the like. An entity which provides insurance may be known as an insurer, insurance company, insurance carrier, underwriter, and the like. For instance, a mechanism for insuring may provide a financial entity with a mechanism to determine evidence of insurance for an asset related to a loan. In a non-limiting example, an insurance service circuit may be structured to determine an evidence condition of insurance for an asset based on a plurality of insurance information components with respect to a financial entity configured to determine a loan condition for an asset. In certain embodiments, components may be considered insuring for some purposes but not for other purposes—for example a blockchain and smart contract platform may be utilized to manage aspects of a loan transaction such as for identity and confidentiality, but may alternately be utilized to aggregate identity and behavior information for insurance underwriting. Accordingly, the benefits of the present disclosure may be applied in a wide variety of systems, and any such systems may be considered insuring herein, while in certain embodiments a given system may not be considered insuring herein. One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system ordinarily available to that person, can readily determine which aspects of the present disclosure will benefit a particular system, and/or how to combine processes and systems from the present disclosure to enhance operations of the contemplated system. Certain considerations for the person of skill in the art, in determining whether a contemplated system is insuring and/or whether aspects of the present disclosure can benefit or enhance the contemplated system include, without limitation: insurance facilities such as branches, offices, storage facilities, data centers, underwriting operations and others; insurance claims, such as for business interruption insurance, product liability insurance, insurance on goods, facilities, or equipment, flood insurance, insurance for contract-related risks, and many others, as well as claims data relating to product liability, general liability, workers compensation, injury and other liability claims and claims data relating to contracts, such as supply contract performance claims, product delivery requirements, contract claims, claims for damages, claims to redeem points or rewards, claims of access rights, warranty claims, indemnification claims, energy production requirements, delivery requirements, timing requirements, milestones, key performance indicators and others; insurance-related lending; an insurance service, an insurance brokerage service, a life insurance service, a health insurance service, a retirement insurance service, a property insurance service, a casualty insurance service, a finance and insurance service, a reinsurance service; a blockchain and smart contract platform for aggregating identity and behavior information for insurance underwriting; identities of applicants for insurance, identities of parties that may be willing to offer insurance, information regarding risks that may be insured (of any type, without limitation, such as property, life, travel, infringement, health, home, commercial liability, product liability, auto, fire, flood, casualty, retirement, unemployment; distributed ledger may be utilized to facilitate offering and underwriting of microinsurance, such as for defined risks related to defined activities for defined time periods that are narrower than for typical insurance policies; providing insurance for a loan, providing evidence of insurance for property related to a loan; and the like.

[0314] The term aggregation (and similar terms) as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, an aggregation or to aggregate includes any aggregation including, without limitation, aggregating items together, such as aggregating or linking similar items together (e.g., collateral to provide collateral for a set of loans, collateral items for a set of loans is aggregated in real time based on a similarity in status of the set of items, and the like), collecting data together (e.g., for storage, for communication, for analysis, as training data for a model, and the like), summarizing aggregated items or data into a simpler description, or any other method for creating a whole formed by combining several (e.g., disparate) elements. Further, an aggregator may be any system or platform for aggregating, such as described. Certain components may not be considered aggregation individually but may be considered aggregation in an aggregated system—for example a collection of loans may not be considered an aggregation of loans of itself but may be an aggregation if collected as such. In a non-limiting example, an aggregation circuit may be structured to provide lenders a mechanism to aggregate loans together from a plurality of loans, such as based on a loan attribute, parameter, term or condition, financial entity, and the like, to become an aggregation of loans. In certain embodiments, an aggregation may be considered an aggregation for some purposes but not for other purposes—for example for example, an aggregation of asset collateral conditions may be collected for the purpose of aggregating loans together in one instance and for the purpose of determining a default action in another instance. Additionally, in certain embodiments, otherwise similar looking systems may be differentiated in determining whether such systems are aggregators, and/or which type of aggregating systems. For example, a first and second aggregator may both aggregate financial entity data, where the first aggregator aggregates for the sake of building a training set for an analysis model circuit and where the second aggregator aggregates financial entity data for storage in a blockchain-based distributed ledger. Accordingly, the benefits of the present disclosure may be applied in a wide variety of systems, and any such systems may be considered as aggregation herein, while in certain embodiments a given system may not be considered aggregation herein. One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system ordinarily available to that person, can readily determine which aspects of the present disclosure will benefit a particular system, and/or how to combine processes and systems from the present disclosure to enhance operations of the contemplated system. Certain considerations for the person of skill in the art, in determining whether a contemplated system is aggregation and/or whether aspects of the present disclosure can benefit or enhance the contemplated system include, without limitation forward market demand aggregation (e.g., blockchain and smart contract platform for forward market demand aggregation, interest expressed or committed in a demand aggregation interface, blockchain used to aggregate future demand in a forward market with respect to a variety of products and services, process a set of potential configurations having different parameters for a subset of configurations that are consistent with each other and the subset of configurations used to aggregate committed future demand for the offering that satisfies a sufficiently large subset at a profitable price, and the like); correlated aggregated data (including trend information) on worker ages, credentials, experience (including by process type) with data on the processes in which those workers are involved; demand for accommodations aggregated in advance and conveniently fulfilled by automatic recognition of conditions that satisfy pre-configured commitments represented on a blockchain (e.g., distributed ledger); transportation offerings aggregated and fulfilled (e.g., with a wide range of pre-defined contingencies); aggregation of goods and services on the blockchain (e.g., a distributed ledger used for demand planning); with respect to a demand aggregation interface (e.g., presented to one or more consumers); aggregation of multiple submissions; aggregating identity and behavior information (e.g., insurance underwriting); accumulation and aggregation of multiple parties; aggregation of data for a set of collateral; aggregated value of collateral or assets (e.g., based on real time condition monitoring, rea-time market data collection and integration, and the like); aggregated tranches of loans; collateral for smart contract aggregated with other similar collateral; and the like.

[0315] The term linking (and similar terms) as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, linking includes any linking, including, without limitation, linking as a relationship between two things or situations (e.g., where one thing affects the other). For instance, linking a subset of similar items such as collateral to provide collateral for a set of loans. Certain components may not be considered linked individually, but may be considered in a process of linking in an aggregated system—for example, a smart contracts circuit may be structured to operate in conjunction with a blockchain circuit as part of a loan processing platform but where the smart contracts circuit processes contracts without storing information through the blockchain circuit, however the two circuits could be linked through the smart contracts circuit linking financial entity information through a distributed ledger on the blockchain circuit. In certain embodiments, linking may be considered linking for some purposes but not for other purposes—for example, linking goods and services for users and radio frequency linking between access points are different forms of linking, where the linking of goods and services for users links thinks together while an RF link is a communications link between transceivers. Additionally, in certain embodiments, otherwise similar looking systems may be differentiated in determining whether such system are linking, and/or which type of linking. For example, linking similar data together for analysis is different from linking similar data together for graphing. Accordingly, the benefits of the present disclosure may be applied in a wide variety of systems, and any such systems may be considered linking herein, while in certain embodiments a given system may not be considered a linking herein. One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system ordinarily available to that person, can readily determine which aspects of the present disclosure will benefit a particular system, and/or how to combine processes and systems from the present disclosure to enhance operations of the contemplated system. Certain considerations for the person of skill in the art, in determining whether a contemplated system is linking and/or whether aspects of the present disclosure can benefit or enhance the contemplated system include, without limitation linking marketplaces or external marketplaces with a system or platform; linking data (e.g., data cluster including links and nodes); storage and retrieval of data linked to local processes; links (e.g. with respect to nodes) in a common knowledge graph; data linked to proximity or location (e.g., of the asset); linking to an environment (e.g., goods, services, assets, and the like); linking events (e.g., for storage such as in a blockchain, for communication or analysis); linking ownership or access rights; linking to access tokens (e.g., travel offerings linked to access tokens); links to one or more resources (e.g., secured by cryptographic or other techniques); linking a message to a smart contract; and the like.

[0316] The term indicator of interest (and similar terms) as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, an indicator of interest includes any indicator of interest including, without limitation, an indicator of interest from a user or plurality of users or parties related to a transaction and the like (e.g., parties interested in participating in a loan transaction), the recording or storing of such an interest (e.g., a circuit for recording an interest input from a user, entity, circuit, system, and the like), a circuit analyzing interest related data and setting an indicator of interest (e.g., a circuit setting or communicating an indicator based on inputs to the circuit, such as from users, parties, entities, systems, circuits, and the like), a model trained to determine an indicator of interest from input data related to an interest by one of a plurality of inputs from users, parties, or financial entities, and the like. Certain components may not be considered indicators of interest individually, but may be considered an indicator of interest in an aggregated system—for example, a party may seek information relating to a transaction such as though a translation marketplace where the party is interested in seeking information, but that may not be considered an indicator of interest in a transaction. However, when the party asserts a specific interest (e.g., through a user interface with control inputs for indicating interest) the party's interest may be recorded (e.g., in a storage circuit, in a blockchain circuit), analyzed (e.g., through an analysis circuit, a data collection circuit), monitored (e.g., through a monitoring circuit), and the like. In a non-limiting example, indicators of interest may be recorded (e.g., in a blockchain through a distributed ledger) from a set of parties with respect to the product, service, or the like, such as ones that define parameters under which a party is willing to commit to purchase a product or service. In certain embodiments, an indicator of interest may be considered an indicator of interest for some purposes but not for other purposes—for example, a user may indicate an interest for a loan transaction but that does not necessarily mean the user is indicating an interest in providing a type of collateral related to the loan transaction. For instance, a data collection circuit may record an indicator of interest for the transaction but may have a separate circuit structure for determining an indication of interest for collateral. Additionally, in certain embodiments, otherwise similar looking systems may be differentiated in determining whether such system are determining an indication of interest, and/or which type of indicator of interest exists. For example, one circuit or system may collect data from a plurality of parties to determine an indicator of interest in securing a loan and a second circuit or system may collect data from a plurality of parties to determine an indicator of interest in determining ownership rights related to a loan. Accordingly, the benefits of the present disclosure may be applied in a wide variety of systems, and any such systems may be considered an indicator of interest herein, while in certain embodiments a given system may not be considered an indicator of interest herein. One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system ordinarily available to that person, can readily determine which aspects of the present disclosure will benefit a particular system, and/or how to combine processes and systems from the present disclosure to enhance operations of the contemplated system. Certain considerations for the person of skill in the art, in determining whether a contemplated system is an indicator of interest and/or whether aspects of the present disclosure can benefit or enhance the contemplated system include, without limitation parties indicating an interest in participating in a transaction (e.g., a loan transaction), parties indicating an interest in securing in a product or service, recording or storing an indication of interest (e.g., through a storage circuit or blockchain circuit), analyzing an indication of interest (e.g., through a data collection and/or monitoring circuit), and the like.

[0317] The term accommodations (and similar terms) as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, an accommodation includes any service, activity, event, and the like such as including, without limitation, a room, group of rooms, table, seating, building, event, shared spaces offered by individuals (e.g., Airbnb spaces), bed-and-breakfasts, workspaces, conference rooms, convention spaces, fitness accommodations, health and wellness accommodations, dining accommodations, and the like, in which someone may live, stay, sit, reside, participate, and the like. As such, an accommodation may be purchased (e.g., a ticket through a sports ticketing application), reserved or booked (e.g., a reservation through a hotel reservation application), provided as a reward or gift, traded or exchanged (e.g., through a marketplace), provided as an access right (e.g., offering by way of an aggregation demand), provided based on a contingency (e.g., a reservation for a room being contingent on the availability of a nearby event), and the like. Certain components may not be considered an accommodation individually but may be considered an accommodation in an aggregated system—for example, a resource such as a room in a hotel may not in itself be considered an accommodation but a reservation for the room may be. For instance, a blockchain and smart contract platform for forward market rights for accommodations may provide a mechanism to provide access rights with respect to accommodations. In a non-limiting example, a blockchain circuit may be structured to store access rights in a forward demand market, where the access rights may be stored in a distributed ledger with related shared access to a plurality of actionable entities. In certain embodiments, an accommodation may be considered an accommodation for some purposes but not for other purposes—for example, a reservation for a room may be an accommodation on its own, but may not be accommodation that is satisfied if a related contingency is not met as agreed upon at the time of the e.g. reservation. Additionally, in certain embodiments, otherwise similar looking systems may be differentiated in determining whether such systems are related to an accommodation, and/or which type of accommodation. For example, an accommodation offering may be made based on different systems, such as one where the accommodation offering is determined by a system collecting data related to forward demand and a second one where the accommodation offering is provided as a reward based on a system processing a performance parameter. Accordingly, the benefits of the present disclosure may be applied in a wide variety of systems, and any such systems may be considered as related to an accommodation herein, while in certain embodiments a given system may not be considered related to an accommodation herein. One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system ordinarily available to that person, can readily determine which aspects of the present disclosure will benefit a particular system, and/or how to combine processes and systems from the present disclosure to enhance operations of the contemplated system. Certain considerations for the person of skill in the art, in determining whether a contemplated system is related to accommodation and/or whether aspects of the present disclosure can benefit or enhance the contemplated system include, without limitation accommodations provided as determined through a service circuit, trading or exchanging services (e.g., through an application and/or user interface), as an accommodation offering such as with respect to a combination of products, services, and access rights, processed (e.g., aggregation demand for the offering in a forward market), accommodation through booking in advance, accommodation through booking in advance upon meeting a certain condition (e.g., relating to a price within a given time window), and the like.

[0318] The term contingencies (and similar terms) as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, a contingency includes any contingency including, without limitation, any action that is dependent upon a second action. For instance, a service may be provided as contingent on a certain parameter value, such as collecting data as condition upon an asset tag indication from an Internet of Things circuit. In another instance, an accommodation such as a hotel reservation may be contingent upon a concert (local to the hotel and at the same time as the reservation) proceeding as scheduled. Certain components may not be considered as relating to a contingency individually, but may be considered related to a contingency in an aggregated system—for example, a data input collected from a data collection service circuit may be stored, analyzed, processed, and the like, and not be considered with respect to a contingency, however a smart contracts service circuit may apply a contract term as being contingent upon the collected data. For instance, the data may indicate a collateral status with respect to a loan transaction, and the smart contracts service circuit may apply that data to a term of contract that depends upon the collateral. In certain embodiments, a contingency may be considered contingency for some purposes but not for other purposes—for example, a delivery of contingent access rights for a future event may be contingent upon a loan condition being satisfied, but the loan condition on its own may not be considered a contingency in the absence of the contingency linkage between the condition and the access rights. Additionally, in certain embodiments, otherwise similar looking systems may be differentiated in determining whether such systems are related to a contingency, and/or which type of contingency. For example, two algorithms may both create a forward market event access right token, but where the first algorithm creates the token free of contingencies and the second algorithm creates a token with a contingency for delivery of the token. Accordingly, the benefits of the present disclosure may be applied in a wide variety of systems, and any such systems may be considered a contingency herein, while in certain embodiments a given system may not be considered a contingency herein. One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system ordinarily available to that person, can readily determine which aspects of the present disclosure will benefit a particular system, and/or how to combine processes and systems from the present disclosure to enhance operations of the contemplated system. Certain considerations for the person of skill in the art, in determining whether a contemplated system is a contingency and/or whether aspects of the present disclosure can benefit or enhance the contemplated system include, without limitation a forward market operated within or by the platform may be a contingent forward market, such as one where a future right is vested, is triggered, or emerges based on the occurrence of an event, satisfaction of a condition, or the like; a blockchain used to make a contingent market in any form of event or access token by securely storing access rights on a distributed ledger; setting and monitoring pricing for contingent access rights, underlying access rights, tokens, fees and the like; optimizing offerings, timing, pricing, or the like, to recognize and predict patterns, to establish rules and contingencies; exchanging contingent access rights or underlying access rights or tokens access tokens and/or contingent access tokens; creating a contingent forward market event access right token where a token may be created and stored on a blockchain for contingent access right that could result in the ownership of a ticket; discovery and delivery of contingent access rights to future events; contingencies that influence or represent future demand for an offering, such as including a set of products, services, or the like; pre-defined contingencies; optimized offerings, timing, pricing, or the like, to recognize and predict patterns, to establish rules and contingencies; creation of a contingent future offering within the dashboard; contingent access rights that may result in the ownership of the virtual good or each smart contract to purchase the virtual good if and when it becomes available under defined conditions; and the like.

[0319] The term level of service (and similar terms) as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, a level of service includes any level of service including, without limitation, any qualitative or quantitative measure of the extent to which a service is provided, such as, and without limitation, a first class vs. business class service (e.g., travel reservation or postal delivery), the degree to which a resource is available (e.g., service level A indicating that the resource is highly available vs. service level C indicating that the resource is constrained, such as in terms of traffic flow restrictions on a roadway), the degree to which an operational parameter is performing (e.g., a system is operating at a high state of service vs a low state of service, and the like. In embodiments, level of service may be multi-modal such that the level of service is variable where a system or circuit provides a service rating (e.g., where the service rating is used as an input to an analytical circuit for determining an outcome based on the service rating). Certain components may not be considered relative to a level of service individually, but may be considered relative to a level of service in an aggregated system—for example a system for monitoring a traffic flow rate may provide data on a current rate but not indicate a level of service, but when the determined traffic flow rate is provided to a monitoring circuit the monitoring circuit may compare the determined traffic flow rate to past traffic flow rates and determine a level of service based on the comparison. In certain embodiments, a level of service may be considered a level of service for some purposes but not for other purposes—for example, the availability of first class travel accommodation may be considered a level of service for determining whether a ticket will be purchased but not to project a future demand for the flight. Additionally, in certain embodiments, otherwise similar looking systems may be differentiated in determining whether such system utilizes a level of service, and/or which type of level of service. For example, an artificial intelligence circuit may be trained on past level of service with respect to traffic flow patterns on a certain freeway and used to predict future traffic flow patterns based on current flow rates, but a similar artificial intelligence circuit may predict future traffic flow patterns based on the time of day. Accordingly, the benefits of the present disclosure may be applied in a wide variety of systems, and any such systems may be considered with respect to levels of service herein, while in certain embodiments a given system may not be considered with respect to levels of service herein. One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system ordinarily available to that person, can readily determine which aspects of the present disclosure will benefit a particular system, and/or how to combine processes and systems from the present disclosure to enhance operations of the contemplated system. Certain considerations for the person of skill in the art, in determining whether a contemplated system is a level of service and/or whether aspects of the present disclosure can benefit or enhance the contemplated system include, without limitation transportation or accommodation offerings with predefined contingencies and parameters such as with respect to price, mode of service, and level of service; warranty or guarantee application, transportation marketplace, and the like.

[0320] The term payment (and similar terms) as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, a payment includes any payment including, without limitation, an action or process of paying (e.g., a payment to a loan) or of being paid (e.g., a payment from insurance), an amount paid or payable (e.g., a payment of $1000 being made), a repayment (e.g., to pay back a loan), a mode of payment (e.g., use of loyalty programs, rewards points, or particular currencies, including cryptocurrencies) and the like. Certain components may not be considered payments individually, but may be considered payments in an aggregated system—for example, submitting an amount of money may not be considered a payment as such, but when applied to a payment to satisfy the requirement of a loan may be considered a payment (or repayment). For instance, a data collection circuit may provide lenders a mechanism to monitor repayments of a loan. In a non-limiting example, the data collection circuit may be structured to monitor the payments of a plurality of loan components with respect to a financial loan contract configured to determine a loan condition for an asset. In certain embodiments, a payment may be considered a payment for some purposes but not for other purposes—for example a payment to a financial entity may be for a repayment amount to pay back the loan, or it may be to satisfy a collateral obligation in a loan default condition. Additionally, in certain embodiments, otherwise similar looking systems may be differentiated in determining whether such system are related to a payment, and/or which type of payment. For example, funds may be applied to reserve an accommodation or to satisfy the delivery of services after the accommodation has been satisfied. Accordingly, the benefits of the present disclosure may be applied in a wide variety of systems, and any such systems may be considered a payment herein, while in certain embodiments a given system may not be considered a payment herein. One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system ordinarily available to that person, can readily determine which aspects of the present disclosure will benefit a particular system, and/or how to combine processes and systems from the present disclosure to enhance operations of the contemplated system. Certain considerations for the person of skill in the art, in determining whether a contemplated system is a payment and/or whether aspects of the present disclosure can benefit or enhance the contemplated system include, without limitation, deferring a required payment; deferring a payment requirement; payment of a loan; a payment amount; a payment schedule; a balloon payment schedule; payment performance and satisfaction; modes of payment; and the like.

[0321] The term location (and similar terms) as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, a location includes any location including, without limitation, a particular place or position of a person, place, or item, or location information regarding the position of a person, place, or item, such as a geolocation (e.g., geolocation of a collateral), a storage location (e.g., the storage location of an asset), a location of a person (e.g., lender, borrower, worker), location information with respect to the same, and the like. Certain components may not be considered with respect to location individually, but may be considered with respect to location in an aggregated system—for example, a smart contract circuit may be structured to specify a requirement for a collateral to be stored at a fixed location but not specify the specific location for a specific collateral. In certain embodiments, a location may be considered a location for some purposes but not for other purposes—for example, the address location of a borrower may be required for processing a loan in one instance, and a specific location for processing a default condition in another instance. Additionally, in certain embodiments, otherwise similar looking systems may be differentiated in determining whether such system are a location, and/or which type of location. For example, the location of a music concert may be required to be in a concert hall seating 10,000 people in one instance but specify the location of an actual concert hall in another. Accordingly, the benefits of the present disclosure may be applied in a wide variety of systems, and any such systems may be considered with respect to a location herein, while in certain embodiments a given system may not be considered with respect to a location herein. One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system ordinarily available to that person, can readily determine which aspects of the present disclosure will benefit a particular system, and/or how to combine processes and systems from the present disclosure to enhance operations of the contemplated system. Certain considerations for the person of skill in the art, in determining whether a contemplated system is considered with respect to a location and/or whether aspects of the present disclosure can benefit or enhance the contemplated system include, without limitation a geolocation of an item or collateral; a storage location of item or asset; location information; location of a lender or a borrower; location-based product or service targeting application; a location-based fraud detection application; indoor location monitoring systems (e.g., cameras, IR systems, motion-detection systems); locations of workers (including routes taken through a location); location parameters; event location; specific location of an event; and the like.

[0322] The term route (and similar terms) as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, a route includes any route including, without limitation, a way or course taken in getting from a starting point to a destination, to send or direct along a specified course, and the like. Certain components may not be considered with respect to a route individually, but may be considered a route in an aggregated system—for example a mobile data collector may specify a requirement for a route for collecting data based on an input from a monitoring circuit, but only in receiving that input does the mobile data collector determine what route to take and begin traveling along the route. In certain embodiments, a route may be considered a route for some purposes but not for other purposes—for example possible routes through a road system may be considered differently than specific routes taken through from one location to another location. Additionally, in certain embodiments, otherwise similar looking systems may be differentiated in determining whether such systems are specified with respect to a location, and/or which types of locations. For example, routes depicted on a map may indicate possible routes or actual routes taken by individuals. Accordingly, the benefits of the present disclosure may be applied in a wide variety of systems, and any such systems may be considered with respect to a route herein, while in certain embodiments a given system may not be considered with respect to a route herein. One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system ordinarily available to that person, can readily determine which aspects of the present disclosure will benefit a particular system, and/or how to combine processes and systems from the present disclosure to enhance operations of the contemplated system. Certain considerations for the person of skill in the art, in determining whether a contemplated system is utilizing a route and/or whether aspects of the present disclosure can benefit or enhance the contemplated system include, without limitation delivery routes; routes taken through a location; heat map showing routes traveled by customers or workers within an environment; determining what resources are deployed to what routes or types of travel; direct route or multi-stop route, such as from the destination of the consumer to a specific location or to wherever an event takes place; a route for a mobile data collector; and the like.

[0323] The term future offering (and similar terms) as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, a future offing includes any offer of an item or service in the future including, without limitation, a future offer to provide an item or service, a future offer with respect to a proposed purchase, a future offering made through a forward market platform, a future offering determined by a smart contract circuit, and the like. Further, a future offering may be a contingent future offer or an offer based on conditions resulting on the offer being a future offering, such as where the future offer is contingent upon or with the conditions imposed by a predetermined condition (e.g., a security may be purchased for $1000 at a set future date contingent upon a predetermined state of a market indicator). Certain components may not be considered a future offering individually, but may be considered a future offering in an aggregated system—for example, an offer for a loan may not be considered a future offering if the offer is not authorized through a collective agreement amongst a plurality of parties related to the offer, but may be considered a future offer once a vote has been collected and stored through a distributed ledger, such as through a blockchain circuit. In certain embodiments, a future offering may be considered a future offering for some purposes but not for other purposes—for example, a future offering may be contingent upon a condition being met in the future, and so the future offering may not be considered a future offer until the condition is met. Additionally, in certain embodiments, otherwise similar looking systems may be differentiated in determining whether such systems are future offerings, and/or which type of future offerings. For example, two security offerings may be determined to be offerings to be made at a future time, however, one may have immediate contingences to be met and thus may not be considered to be a future offering but rather an immediate offering with future declarations. Accordingly, the benefits of the present disclosure may be applied in a wide variety of systems, and any such systems may be considered in association with a future offering herein, while in certain embodiments a given system may not be considered in association with a future offering herein. One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system ordinarily available to that person, can readily determine which aspects of the present disclosure will benefit a particular system, and/or how to combine processes and systems from the present disclosure to enhance operations of the contemplated system. Certain considerations for the person of skill in the art, in determining whether a contemplated system is in association with a future offering and/or whether aspects of the present disclosure can benefit or enhance the contemplated system include, without limitation a forward offering, a contingent forward offering, a forward offing in a forward market platform (e.g., for creating a future offering or contingent future offering associated with identifying offering data from a platform-operated marketplace or external marketplace); a future offering with respect to entering into a smart contract (e.g., by executing an indication of a commitment to purchase, attend, or otherwise consume a future offering), and the like.

[0324] The term access right (and derivatives or variations) as utilized herein may be understood broadly to describe an entitlement to acquire or possess a property, article, or other thing of value. A contingent access right may be conditioned upon a trigger or condition being met before such an access right becomes entitled, vested or otherwise defensible. An access right or contingent access right may also serve specific purposes or be configured for different applications or contexts, such as, without limitation, loan-related actions or any service or offering. Without limitation, notices may be required to be provided to the owner of a property, article or item of value before such access rights or contingent access rights are exercised. Access rights and contingent access rights in various forms may be included where discussing a legal action, a delinquent or defaulted loan or agreement, or other circumstances where a lender may be seeking remedy, without limitation. One of skill in the art, having the benefit of the disclosure herein and knowledge ordinarily available about a contemplated system, can readily determine the value of such rights implemented in an embodiment. While specific examples of access rights and contingent access rights are described herein for purposes of illustration, any embodiment benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein, are specifically contemplated within the scope of the present disclosure.

[0325] The term smart contract (and other forms or variations) as utilized herein may be understood broadly to describe a method, system, connected resource or wide area network offering one or more resources useful to assist or perform actions, tasks or things by embodiments disclosed herein. A smart contract may be a set of steps or a process to negotiate, administrate, restructure or implement an agreement or loan between parties. A smart contract may also be implemented as an application, website, FTP site, server, appliance or other connected component or Internet related system that renders resources to negotiate, administrate, restructure or implement an agreement or loan between parties. A smart contract may be a self-contained system, or may be part of a larger system or component that may also be a smart contract. For example, a smart contract may refer to a loan or an agreement itself, conditions or terms, or may refer to a system to implement such a loan or agreement. In certain embodiments, a smart contract circuit or robotic process automation system may incorporate or be incorporated into automatic robotic process automation system to perform one or more purposes or tasks, whether part of a loan or transaction process, or otherwise. One of skill in the art, having the benefit of the disclosure herein and knowledge ordinarily available about a contemplated system can readily determine the purposes and use of this term as it relates to a smart contract in various forms, embodiments and contexts disclosed herein.

[0326] The term allocation of reward (and variations) as utilized herein may be understood broadly to describe a thing or consideration allocated or provided as consideration, or provided for a purpose. The allocation of rewards can be of a financial type, or non-financial type, without limitation. A specific type of allocation of reward may also serve a number of different purposes or be configured for different applications or contexts, such as, without limitation: a reward event, claims for rewards, monetary rewards, rewards captured as a data set, rewards points, and other forms of rewards. Thus an allocation of rewards may be provided as a consideration within the context of a loan or agreement. Systems may be utilized to allocate rewards. The allocation of rewards in various forms may be included where discussing a particular behavior, or encouragement of a particular behavior, without limitation. An allocation of a reward may include an actual dispensation of the award, and/or a recordation of the reward. The allocation of rewards may be performed by a smart contract circuit or a robotic processing automation system. One of skill in the art, having the benefit of the disclosure herein and knowledge ordinarily available about a contemplated system, can readily determine the value of the allocation of rewards in an embodiment. While specific examples of the allocation of rewards are described herein for purposes of illustration, any embodiment benefitting from the disclosures herein, and any considerations understood to one of skill in the art having the benefit of the disclosures herein, are specifically contemplated within the scope of the present disclosure.

[0327] The term satisfaction of parameters or conditions (and other derivatives, forms or variations) as utilized herein may be understood broadly to describe completion, presence or proof of parameters or conditions that have been met. The term generally may relate to a process of determining such satisfaction of parameters or conditions, or may relate to the completion of such a process with a result, without limitation. Satisfaction may result in a successful outcome of other triggers or conditions or terms that may come into execution, without limitation. Satisfaction of parameters or conditions may occur in many different contexts of contracts or loans, such as lending, refinancing, consolidation, factoring, brokering, foreclosure, and data processing (e.g. data collection), or combinations thereof, without limitation. Satisfaction of parameters or conditions may be used in the form of a noun (e.g. the satisfaction of the debt repayment), or may be used in a verb form to describe the process of determining a result to parameters or conditions. For example, a borrower may have satisfaction of parameters by making a certain number of payments on time, or may cause satisfaction of a condition allowing access rights to an owner if a loan defaults, without limitation. In certain embodiments, a smart contract or robotic process automation system may perform or determine satisfaction of parameters or conditions for one or more of the parties and process appropriate tasks for satisfaction of parameters or conditions. In some cases satisfaction of parameters or conditions by the smart contract or robotic process automation system may not complete or be successful, and depending upon such outcomes, this may enable automated action or trigger other conditions or terms. One of skill in the art, having the benefit of the disclosure herein and knowledge ordinarily available about a contemplated system can readily determine the purposes and use of this term in various forms, embodiments and contexts disclosed herein.

[0328] The term information (and other forms such as info or informational, without limitation) as utilized herein may be understood broadly in a variety of contexts with respect to an agreement or a loan. The term generally may relate to a large context, such as information regarding an agreement or loan, or may specifically relate to a finite piece of information (e.g. a specific detail of an event that happened on a specific date). Thus, information may occur in many different contexts of contracts or loans, and may be used in the contexts, without limitation of evidence, transactions, access, and the like. Or, without limitation, information may be used in conjunction with stages of an agreement or transaction, such as lending, refinancing, consolidation, factoring, brokering, foreclosure, and information processing (e.g. data or information collection), or combinations thereof. For example, information as evidence, transaction, access, etc. may be used in the form of a noun (e.g. the information was acquired from the borrower), or may refer as a noun to an assortment of informational items (e.g. the information about the loan may be found in the smart contract), or may be used in the form of characterizing as an adjective (e.g. the borrower was providing an information submission). For example, a lender may collect an overdue payment from a borrower through an online payment, or may have a successful collection of overdue payments acquired through a customer service telephone call. In certain embodiments, a smart contract circuit or robotic process automation system may perform collection, administration, calculating, providing, or other tasks for one or more of the parties and process appropriate tasks relating to information (e.g. providing notice of an overdue payment). In some cases information by the smart contract circuit or robotic process automation system may be incomplete, and depending upon such outcomes this may enable automated action or trigger other conditions or terms. One of skill in the art, having the benefit of the disclosure herein and knowledge ordinarily available about a contemplated system can readily determine the purposes and use of information as evidence, transaction, access, etc. in various forms, embodiments and contexts disclosed herein.

[0329] Information may be linked to external information (e.g. external sources). The term more specifically may relate to the acquisition, parsing, receiving, or other relation to an external origin or source, without limitation. Thus, information linked to external information or sources may be used in conjunction with stages of an agreement or transaction, such as lending, refinancing, consolidation, factoring, brokering, foreclosure, and information processing (e.g. data or information collection), or combinations thereof. For example, information linked to external information may change as the external information changes, such as a borrower's credit score, which is based on an external source. In certain embodiments, a smart contract circuit or robotic process automation system may perform acquisition, administration, calculating, receiving, updating, providing or other tasks for one or more of the parties and process appropriate tasks relating to information that is linked to external information. In some cases information that is linked to external information by the smart contract or robotic process automation system may be incomplete, and depending upon such outcomes this may enable automated action or trigger other conditions or terms. One of skill in the art, having the benefit of the disclosure herein and knowledge ordinarily available about a contemplated system can readily determine the purposes and use of this term in various forms, embodiments and contexts disclosed herein.

[0330] Information that is a part of a loan or agreement may be separated from information presented in an access location. The term more specifically may relate to the characterization that information can be apportioned, split, restricted, or otherwise separated from other information within the context of a loan or agreement. Thus, information presented or received on an access location may not necessarily be the whole information available for a given context. For example, information provided to a borrower may be different information received by a lender from an external source, and may be different than information received or presented from an access location. In certain embodiments, a smart contract circuit or robotic process automation system may perform separation of information or other tasks for one or more of the parties and process appropriate tasks. One of skill in the art, having the benefit of the disclosure herein and knowledge ordinarily available about a contemplated system, can readily determine the purposes and use of this term in various forms, embodiments and contexts disclosed herein.

[0331] The term encryption of information and control of access (and other related terms) as utilized herein may be understood broadly to describe generally whether a party or parties may observe or possess certain information, actions, events or activities relating to a transaction or loan. Encryption of information may be utilized to prevent a party from accessing, observing or receiving information, or may alternatively be used to prevent parties outside the transaction or loan from being able to access, observe or receive confidential (or other) information. Control of access to information relates to the determination of whether a party is entitled to such access of information. Encryption of information or control of access may occur in many different contexts of loans, such as lending, refinancing, consolidation, factoring, brokering, foreclosure, administration, negotiating, collecting, procuring, enforcing, and data processing (e.g., data collection), or combinations thereof, without limitation. An encryption of information or control of access to information may refer to a single instance, or may characterize a larger amount of information, actions, events or activities, without limitation. For example, a borrower or lender may have access to information about a loan, but other parties outside the loan or agreement may not be able to access the loan information due to encryption of the information, or a control of access to the loan details. In certain embodiments, a smart contract circuit or robotic process automation system may perform encryption of information or control of access to information for one or more of the parties and process appropriate tasks for encryption or control of access of information. One of skill in the art, having the benefit of the disclosure herein and knowledge ordinarily available about a contemplated system can readily determine the purposes and use of this term in various forms, embodiments and contexts disclosed herein.

[0332] The term potential access party list (and other related terms) as utilized herein may be understood broadly to describe generally whether a party or parties may observe or possess certain information, actions, events or activities relating to a transaction or loan. A potential access party list may be utilized to authorize one or more parties to access, observe or receive information, or may alternatively be used to prevent parties from being able to do so. A potential access party list information relates to the determination of whether a party (either on the potential access party list or not on the list) is entitled to such access of information. A potential access party list may occur in many different contexts of loans, such as lending, refinancing, consolidation, factoring, brokering, foreclosure, administration, negotiating, collecting, procuring, enforcing and data processing (e.g. data collection), or combinations thereof, without limitation. A potential access party list may refer to a single instance, or may characterize a larger amount of parties or information, actions, events or activities, without limitation. For example, a potential access party list may grant (or deny) access to information about a loan, but other parties outside potential access party list may not be able to (or may be granted) access the loan information. In certain embodiments, a smart contract circuit or robotic process automation system may perform administration or enforcement of a potential access party list for one or more of the parties and process appropriate tasks for encryption or control of access of information. One of skill in the art, having the benefit of the disclosure herein and knowledge ordinarily available about a contemplated system can readily determine the purposes and use of this term in various forms, embodiments and contexts disclosed herein.

[0333] The term offering, making an offer, and similar terms as utilized herein should be understood broadly. Without limitation to any other aspect or description of the present disclosure, an offering includes any offer of an item or service including, without limitation, an insurance offering, a security offering, an offer to provide an item or service, an offer with respect to a proposed purchase, an offering made through a forward market platform, a future offering, a contingent offering, offers related to lending (e.g. lending, refinancing, collection, consolidation, factoring, brokering, foreclosure), an offering determined by a smart contract circuit, an offer directed to a customer/debtor, an offering directed to a provider/lender, a 3rd party offer (e.g. regulator, auditor, partial owner, tiered provider) and the like. Offerings may include physical goods, virtual goods, software, physical services, access rights, entertainment content, accommodations, or many other items, services, solutions, or considerations. In an example, a third party offer may be to schedule a band instead of just an offer of tickets for sale. Further, an offer may be based on pre-determined conditions or contingencies. Certain components may not be considered an offering individually, but may be considered an offering in an aggregated system—for example, an offer for insurance may not be considered an offering if the offer is not approved by one or more parties related to the offer, however once approval has been granted, it may be considered an offer. Accordingly, the benefits of the present disclosure may be applied in a wide variety of systems, and any such systems may be considered in association with an offering herein, while in certain embodiments a given system may not be considered in association with an offering herein. One of skill in the art, having the benefit of the disclosure herein and knowledge about a contemplated system ordinarily available to that person, can readily determine which aspects of the present disclosure will benefit a particular system, and/or how to combine processes and systems from the present disclosure to enhance operations of the contemplated system. Certain considerations for the person of skill in the art, in determining whether a contemplated system is in association with an offering and/or whether aspects of the present disclosure can benefit or enhance the contemplated system include, without limitation the item or service being offered, a contingency related to the offer, a way of tracking if a contingency or condition has been met, an approval of the offering, an execution of an exchange of consideration for the offering, and the like.

[0334] The term artificial intelligence (AI) solution should be understood broadly. Without limitation to any other aspect of the present disclosure, an AI solution includes a coordinated group of AI related aspects to perform one or more tasks or operations as set forth throughout the present disclosure. An example AI solution includes one or more AI components, including any AI components set forth herein, including at least a neural network, an expert system, and/or a machine learning component. The example AI solution may include as an aspect the types of components of the solution, such as a heuristic AI component, a model based AI component, a neural network of a selected type (e.g., recursive, convolutional, perceptron, etc.), and/or an AI component of any type having a selected processing capability (e.g., signal processing, frequency component analysis, auditory processing, visual processing, speech processing, text recognition, etc.). Without limitation to any other aspect of the present disclosure, a given AI solution may be formed from the number and type of AI components of the AI solution, the connectivity of the AI components (e.g., to each other, to inputs from a system including or interacting with the AI solution, and/or to outputs to the system including or interacting with the AI solution). The given AI solution may additionally be formed from the connection of the AI components to each other within the AI solution, and to boundary elements (e.g., inputs, outputs, stored intermediary data, etc.) in communication with the AI solution. The given AI solution may additionally be formed from a configuration of each of the AI components of the AI solution, where the configuration may include aspects such as: model calibrations for an AI component; connectivity and/or flow between AI components (e.g., serial and/or parallel coupling, feedback loops, logic junctions, etc.); the number, selected input data, and/or input data processing of inputs to an AI component; a depth and/or complexity of a neural network or other components; a training data description of an AI component (e.g., training data parameters such as content, amount of training data, statistical description of valid training data, etc.); and/or a selection and/or hybrid description of a type for an AI component. An AI solution includes a selection of AI elements, flow connectivity of those AI elements, and/or configuration of those AI elements.

[0335] One of skill in the art, having the benefit of the present disclosure, can readily determine an AI solution for a given system, and/or configure operations to perform a selection and/or configuration operation for an AI solution for a given system. Certain considerations to determining an AI solution, and/or configuring operations to perform a selection and/or configuration operation for an AI solution include, without limitation: an availability of AI components and/or component types for a given implementation; an availability of supporting infrastructure to implement given AI components (e.g., data input values available, including data quality, level of service, resolution, sampling rate, etc.; availability of suitable training data for a given AI solution; availability of expert inputs, such as for an expert system and/or to develop a model training data set; regulatory and/or policy based considerations including permitted action by the AI solution, requirements for acquisition and/or retention of sensitive data, difficult to obtain data, and/or expensive data); operational considerations for a system including or interacting with the AI solution, including response time specifications, safety considerations, liability considerations, etc.; available computing resources such as processing capability, network communication capability, and/or memory storage capability (e.g., to support initial data, training data, input data such as cached, buffered, or stored input data, iterative improvement state data, output data such as cached, buffered, or stored output data, and/or intermediate data storage, such as data to support ongoing calculations, historical data, and/or accumulation data); the types of tasks to be performed by the AI solution, and the suitability of AI components for those tasks, sensitivity of AI components performing the tasks (e.g., variability of the output space relative to a disturbance size of the input space); the interactions of AI components within the entire AI solution (e.g., a low capability rationality AI component may be coupled with a higher capability AI component that may provide high sensitivity and/or unbounded response to inputs); and/or model implementation considerations (e.g., requirements to re-calibrate, aging constraints of a model, etc.).

[0336] A selected and/or configured AI solution may be utilized with any of the systems, procedures, and/or aspects of embodiments as set forth throughout the present disclosure. For example, a system utilizing an expert system may include the expert system as all or a part of a selected, configured AI solution. In another example, a system utilizing a neural network, and/or a combination of neural networks, may include the neural network(s) as all or a part of a selected, configured AI solution. The described aspects of an AI solution, including the selection and configuration of the AI solution, are non-limiting illustrations.

[0337] Referring to FIGS. 1-2B, a set of systems, methods, components, modules, machines, articles, blocks, circuits, services, programs, applications, hardware, software and other elements are provided, collectively referred to herein interchangeably as the system 100 or the platform 100, The platform 100 enables a wide range of improvements of and for various machines, systems, and other components that enable transactions involving the exchange of value (such as using currency, cryptocurrency, tokens, rewards or the like, as well as a wide range of in-kind and other resources) in various markets, including current or spot markets 170, forward markets 130 and the like, for various goods, services, and resources. As used herein, “currency” should be understood to encompass fiat currency issued or regulated by governments, cryptocurrencies, tokens of value, tickets, loyalty points, rewards points, coupons, and other elements that represent or may be exchanged for value. Resources, such as ones that may be exchanged for value in a marketplace, should be understood to encompass goods, services, natural resources, energy resources, computing resources, energy storage resources, data storage resources, network bandwidth resources, processing resources and the like, including resources for which value is exchanged and resources that enable a transaction to occur (such as necessary computing and processing resources, storage resources, network resources, and energy resources that enable a transaction). The platform 100 may include a set of forward purchase and sale machines 110, each of which may be configured as an expert system or automated intelligent agent for interaction with one or more of the set of spot markets 170 and forward markets 130. Enabling the set of forward purchase and sale machines 110 are an intelligent resource purchasing system 164 having a set of intelligent agents for purchasing resources in spot and forward markets; an intelligent resource allocation and coordination system 168 for the intelligent sale of allocated or coordinated resources, such as compute resources, energy resources, and other resources involved in or enabling a transaction; an intelligent sale engine 172 for intelligent coordination of a sale of allocated resources in spot and futures markets; and an automated spot market testing and arbitrage transaction execution engine 194 for performing spot testing of spot and forward markets, such as with micro-transactions and, where conditions indicate favorable arbitrage conditions, automatically executing transactions in resources that take advantage of the favorable conditions. Each of the engines may use model-based or rule-based expert systems, such as based on rules or heuristics, as well as deep learning systems by which rules or heuristics may be learned over trials involving a large set of inputs. The engines may use any of the expert systems and artificial intelligence capabilities described throughout this disclosure. Interactions within the platform 100, including of all platform components, and of interactions among them and with various markets, may be tracked and collected, such as by a data aggregation system 144, such as for aggregating data on purchases and sales in various marketplaces by the set of machines described herein. Aggregated data may include tracking and outcome data that may be fed to artificial intelligence and machine learning systems, such as to train or supervise the same. The various engines may operate on a range of data sources, including aggregated data from marketplace transactions, tracking data regarding the behavior of each of the engines, and a set of external data sources 182, which may include social media data sources 180 (such as social networking sites like Facebook™ and Twitter™), Internet of Things (IoT) data sources (including from sensors, cameras, data collectors, and instrumented machines and systems), such as IoT sources that provide information about machines and systems that enable transactions and machines and systems that are involved in production and consumption of resources. External data sources 182 may include behavioral data sources, such as automated agent behavioral data sources 188 (such as tracking and reporting on behavior of automated agents that are used for conversation and dialog management, agents used for control functions for machines and systems, agents used for purchasing and sales, agents used for data collection, agents used for advertising, and others), human behavioral data sources (such as data sources tracking online behavior, mobility behavior, energy consumption behavior, energy production behavior, network utilization behavior, compute and processing behavior, resource consumption behavior, resource production behavior, purchasing behavior, attention behavior, social behavior, and others), and entity behavioral data sources 190 (such as behavior of business organizations and other entities, such as purchasing behavior, consumption behavior, production behavior, market activity, merger and acquisition behavior, transaction behavior, location behavior, and others). The IoT, social and behavioral data from and about sensors, machines, humans, entities, and automated agents may collectively be used to populate expert systems, machine learning systems, and other intelligent systems and engines described throughout this disclosure, such as being provided as inputs to deep learning systems and being provided as feedback or outcomes for purposes of training, supervision, and iterative improvement of systems for prediction, forecasting, classification, automation and control. The data may be organized as a stream of events. The data may be stored in a distributed ledger or other distributed system. The data may be stored in a knowledge graph where nodes represent entities and links represent relationships. The external data sources may be queried via various database query functions. The data sources 182 may be accessed via APIs, brokers, connectors, protocols like REST and SOAP, and other data ingestion and extraction techniques. Data may be enriched with metadata and may be subject to transformation and loading into suitable forms for consumption by the engines, such as by cleansing, normalization, de-duplication and the like.

[0338] The platform 100 may include a set of intelligent forecasting engines 192 for forecasting events, activities, variables, and parameters of spot markets 170, forward markets 130, resources that are traded in such markets, resources that enable such markets, behaviors (such as any of those tracked in the external data sources 182), transactions, and the like. The forecasting engines 192 may operate on data from the data aggregation system 144 about elements of the platform 100 and on data from the external data sources 182. The platform may include a set of intelligent transaction engines 136 for automatically executing transactions in spot markets 170 and forward markets 130. This may include executing intelligent cryptocurrency transactions with an intelligent cryptocurrency execution engine 183 as described in more detail below. The platform 100 may make use of asset of improved distributed ledgers 113 and improved smart contracts 103, including ones that embed and operate on proprietary information, instruction sets and the like that enable complex transactions to occur among individuals with reduced (or without) reliance on intermediaries. These and other components are described in more detail throughout this disclosure.

[0339] Referring to the block diagrams of FIGS. 2A-2B, further details and additional components of the platform 100 and interactions among them are depicted. The set of forward purchase and sale machines 110 may include a regeneration capacity allocation engine 102 (such as for allocating energy generation or regeneration capacity, such as within a hybrid vehicle or system that includes energy generation or regeneration capacity, a renewable energy system that has energy storage, or other energy storage system, where energy is allocated for one or more of sale on a forward market 130, sale in a spot market 170, use in completing a transaction (e.g., mining for cryptocurrency), or other purposes. For example, the regeneration capacity allocation engine 102 may explore available options for use of stored energy, such as sale in current and forward energy markets that accept energy from producers, keeping the energy in storage for future use, or using the energy for work (which may include processing work, such as processing activities of the platform like data collection or processing, or processing work for executing transactions, including mining activities for cryptocurrencies).

[0340] The set of forward purchase and sale machines 110 may include an energy purchase and sale machine 104 for purchasing or selling energy, such as in an energy spot market 148 or an energy forward market 122. The energy purchase and sale machine 104 may use an expert system, neural network or other intelligence to determine timing of purchases, such as based on current and anticipated state information with respect to pricing and availability of energy and based on current and anticipated state information with respect to needs for energy, including needs for energy to perform computing tasks, cryptocurrency mining, data collection actions, and other work, such as work done by automated agents and systems and work required for humans or entities based on their behavior. For example, the energy purchase machine may recognize, by machine learning, that a business is likely to require a block of energy in order to perform an increased level of manufacturing based on an increase in orders or market demand and may purchase the energy at a favorable price on a futures market, based on a combination of energy market data and entity behavioral data. Continuing the example, market demand may be understood by machine learning, such as by processing human behavioral data sources 184, such as social media posts, e-commerce data and the like that indicate increasing demand. The energy purchase and sale machine 104 may sell energy in the energy spot market 148 or the energy forward market 122. Sale may also be conducted by an expert system operating on the various data sources described herein, including with training on outcomes and human supervision.

[0341] The set of forward purchase and sale machines 110 may include a renewable energy credit (REC) purchase and sale machine 108, which may purchase renewable energy credits, pollution credits, and other environmental or regulatory credits in a spot market 150 or forward market 124 for such credits. Purchasing may be configured and managed by an expert system operating on any of the external data sources 182 or on data aggregated by the set of data aggregations systems 144 for the platform. Renewable energy credits and other credits may be purchased by an automated system using an expert system, including machine learning or other artificial intelligence, such as where credits are purchased with favorable timing based on an understanding of supply and demand that is determined by processing inputs from the data sources. The expert system may be trained on a data set of outcomes from purchases under historical input conditions. The expert system may be trained on a data set of human purchase decisions and/or may be supervised by one or more human operators. The renewable energy credit (REC) purchase and sale machine 108 may also sell renewable energy credits, pollution credits, and other environmental or regulatory credits in a spot market 150 or forward market 124 for such credits. Sale may also be conducted by an expert system operating on the various data sources described herein, including with training on outcomes and human supervision.

[0342] The set of forward purchase and sale machines 110 may include an attention purchase and sale machine 112, which may purchase one or more attention-related resources, such as advertising space, search listing, keyword listing, banner advertisements, participation in a panel or survey activity, participation in a trial or pilot, or the like in a spot market for attention 152 or a forward market for attention 128. Attention resources may include the attention of automated agents, such as bots, crawlers, dialog managers, and the like that are used for searching, shopping and purchasing. Purchasing of attention resources may be configured and managed by an expert system operating on any of the external data sources 182 or on data aggregated by the set of data aggregations systems 144 for the platform. Attention resources may be purchased by an automated system using an expert system, including machine learning or other artificial intelligence, such as where resources are purchased with favorable timing, such as based on an understanding of supply and demand, that is determined by processing inputs from the various data sources. For example, the attention purchase machine 112 may purchase advertising space in a forward market for advertising based on learning from a wide range of inputs about market conditions, behavior data, and data regarding activities of agent and systems within the platform 100. The expert system may be trained on a data set of outcomes from purchases under historical input conditions. The expert system may be trained on a data set of human purchase decisions and/or may be supervised by one or more human operators. The attention purchase and sale machine 112 may also sell one or more attention-related resources, such as advertising space, search listing, keyword listing, banner advertisements, participation in a panel or survey activity, participation in a trial or pilot, or the like in a spot market for attention 152 or a forward market for attention 128, which may include offering or selling access to, or attention or, one or more automated agents of the platform 100. Sale may also be conducted by an expert system operating on the various data sources described herein, including with training on outcomes and human supervision.

[0343] The set of forward purchase and sale machines 110 may include a compute purchase and sale machine 114, which may purchase one or more computation-related resources, such as processing resources, database resources, computation resources, server resources, disk resources, input/output resources, temporary storage resources, memory resources, virtual machine resources, container resources, and others in a spot market for compute 154 or a forward market for compute 132. Purchasing of compute resources may be configured and managed by an expert system operating on any of the external data sources 182 or on data aggregated by the set of data aggregations systems 144 for the platform. Compute resources may be purchased by an automated system using an expert system, including machine learning or other artificial intelligence, such as where resources are purchased with favorable timing, such as based on an understanding of supply and demand, that is determined by processing inputs from the various data sources. For example, the compute purchase machine 114 may purchase or reserve compute resources on a cloud platform in a forward market for compute resources based on learning from a wide range of inputs about market conditions, behavior data, and data regarding activities of agent and systems within the platform 100, such as to obtain such resources at favorable prices during surge periods of demand for computing. The expert system may be trained on a data set of outcomes from purchases under historical input conditions. The expert system may be trained on a data set of human purchase decisions and/or may be supervised by one or more human operators. The compute purchase and sale machine 114 may also sell one or more computation-related resources that are connected to, part of, or managed by the platform 100, such as processing resources, database resources, computation resources, server resources, disk resources, input/output resources, temporary storage resources, memory resources, virtual machine resources, container resources, and others in a spot market for compute 154 or a forward market for compute 132. Sale may also be conducted by an expert system operating on the various data sources described herein, including with training on outcomes and human supervision.

[0344] The set of forward purchase and sale machines 110 may include a data storage purchase and sale machine 118, which may purchase one or more data-related resources, such as database resources, disk resources, server resources, memory resources, RAM resources, network attached storage resources, storage attached network (SAN) resources, tape resources, time-based data access resources, virtual machine resources, container resources, and others in a spot market for storage 158 or a forward market for data storage 134. Purchasing of data storage resources may be configured and managed by an expert system operating on any of the external data sources 182 or on data aggregated by the set of data aggregations systems 144 for the platform. Data storage resources may be purchased by an automated system using an expert system, including machine learning or other artificial intelligence, such as where resources are purchased with favorable timing, such as based on an understanding of supply and demand, that is determined by processing inputs from the various data sources. For example, the compute purchase machine 114 may purchase or reserve compute resources on a cloud platform in a forward market for compute resources based on learning from a wide range of inputs about market conditions, behavior data, and data regarding activities of agent and systems within the platform 100, such as to obtain such resources at favorable prices during surge periods of demand for storage. The expert system may be trained on a data set of outcomes from purchases under historical input conditions. The expert system may be trained on a data set of human purchase decisions and/or may be supervised by one or more human operators. The data storage purchase and sale machine 118 may also sell one or more data storage-related resources that are connected to, part of, or managed by the platform 100 in a spot market for storage resources 158 or a forward market for storage 134. Sale may also be conducted by an expert system operating on the various data sources described herein, including with training on outcomes and human supervision.

[0345] The set of forward purchase and sale machines 110 may include a bandwidth purchase and sale machine 120, which may purchase one or more bandwidth-related resources, such as cellular bandwidth, Wi-Fi bandwidth, radio bandwidth, access point bandwidth, beacon bandwidth, local area network bandwidth, wide area network bandwidth, enterprise network bandwidth, server bandwidth, storage input/output bandwidth, advertising network bandwidth, market bandwidth, or other bandwidth, in a spot market for bandwidth 160 or a forward market for bandwidth 138. Purchasing of bandwidth resources may be configured and managed by an expert system operating on any of the external data sources 182 or on data aggregated by the set of data aggregations systems 144 for the platform. Bandwidth resources may be purchased by an automated system using an expert system, including machine learning or other artificial intelligence, such as where resources are purchased with favorable timing, such as based on an understanding of supply and demand, that is determined by processing inputs from the various data sources. For example, the bandwidth purchase and sale machine 120 may purchase or reserve bandwidth on a network resource for a future networking activity managed by the platform based on learning from a wide range of inputs about market conditions, behavior data, and data regarding activities of agent and systems within the platform 100, such as to obtain such resources at favorable prices during surge periods of demand for bandwidth. The expert system may be trained on a data set of outcomes from purchases under historical input conditions. The expert system may be trained on a data set of human purchase decisions and/or may be supervised by one or more human operators. The bandwidth purchase and sale machine 120 may also sell one or more bandwidth-related resources that are connected to, part of, or managed by the platform 100 in a spot market for bandwidth resources 160 or a forward market for bandwidth 138. Sale may also be conducted by an expert system operating on the various data sources described herein, including with training on outcomes and human supervision.

[0346] The set of forward purchase and sale machines 110 may include a spectrum purchase and sale machine 142, which may purchase one or more spectrum-related resources, such as cellular spectrum, 3G spectrum, 4G spectrum, LTE spectrum, 5G spectrum, cognitive radio spectrum, peer-to-peer network spectrum, emergency responder spectrum and the like in a spot market for spectrum 162 or a forward market for spectrum 140. Purchasing of spectrum resources may be configured and managed by an expert system operating on any of the external data sources 182 or on data aggregated by the set of data aggregations systems 144 for the platform. Spectrum resources may be purchased by an automated system using an expert system, including machine learning or other artificial intelligence, such as where resources are purchased with favorable timing, such as based on an understanding of supply and demand, that is determined by processing inputs from the various data sources. For example, the spectrum purchase and sale machine 142 may purchase or reserve spectrum on a network resource for a future networking activity managed by the platform based on learning from a wide range of inputs about market conditions, behavior data, and data regarding activities of agent and systems within the platform 100, such as to obtain such resources at favorable prices during surge periods of demand for spectrum. The expert system may be trained on a data set of outcomes from purchases under historical input conditions. The expert system may be trained on a data set of human purchase decisions and/or may be supervised by one or more human operators. The spectrum purchase and sale machine 142 may also sell one or more spectrum-related resources that are connected to, part of, or managed by the platform 100 in a spot market for spectrum resources 162 or a forward market for bandwidth 140. Sale may also be conducted by an expert system operating on the various data sources described herein, including with training on outcomes and human supervision.

[0347] In embodiments, the intelligent resource coordination and allocation engine 168, including the resource purchasing engine 164, the sale engine 172 and the testing and arbitrate engine 194, may provide coordinated and automated allocation of resources and coordinated execution of transactions across the various forward markets 130 and spot markets 170 by coordinating the various purchase and sale machines, such as by an expert system, such as a machine learning system (which may model-based or a deep learning system, and which may be trained on outcomes and/or supervised by humans). For example, the coordination and allocation engine 168 may coordinate purchasing of resources for a set of assets and coordinated sale of resources available from a set of assets, such as a fleet of vehicles, a data center of processing and data storage resources, an information technology network (on premises, cloud, or hybrids), a fleet of energy production systems (renewable or non-renewable), a smart home or building (including appliances, machines, infrastructure components and systems, and the like thereof that consume or produce resources), and the like. The platform 100 may optimize allocation of resource purchasing, sale and utilization based on data aggregated in the platform, such as by tracking activities of various engines and agents, as well as by taking inputs from external data sources 182. In embodiments, outcomes may be provided as feedback for training the intelligent resource coordination and allocation engine 168, such as outcomes based on yield, profitability, optimization of resources, optimization of business objectives, satisfaction of goals, satisfaction of users or operators, or the like. For example, as the energy for computational tasks becomes a significant fraction of an enterprise's energy usage, the platform 100 may learn to optimize how a set of machines that have energy storage capacity allocate that capacity among computing tasks (such as for cryptocurrency mining, application of neural networks, computation on data and the like), other useful tasks (that may yield profits or other benefits), storage for future use, or sale to the provider of an energy grid. The platform 100 may be used by fleet operators, enterprises, governments, municipalities, military units, first responder units, manufacturers, energy producers, cloud platform providers, and other enterprises and operators that own or operate resources that consume or provide energy, computation, data storage, bandwidth, or spectrum. The platform 100 may also be used in connection with markets for attention, such as to use available capacity of resources to support attention-based exchanges of value, such as in advertising markets, micro-transaction markets, and others.

[0348] Referring still to FIGS. 2A-2B, the platform 100 may include a set of intelligent forecasting engines 192 that forecast one or more attributes, parameters, variables, or other factors, such as for use as inputs by the set of forward purchase and sale machines, the intelligent transaction engines 126 (such as for intelligent cryptocurrency execution) or for other purposes. Each of the set of intelligent forecasting engines 192 may use data that is tracked, aggregated, processed, or handled within the platform 100, such as by the data aggregation system 144, as well as input data from external data sources 182, such as social media data sources 180, automated agent behavioral data sources 188, human behavioral data sources 184, entity behavioral data sources 190 and IoT data sources 198. These collective inputs may be used to forecast attributes, such as using a model (e.g., Bayesian, regression, or other statistical model), a rule, or an expert system, such as a machine learning system that has one or more classifiers, pattern recognizers, and predictors, such as any of the expert systems described throughout this disclosure. In embodiments, the set of intelligent forecasting engines 192 may include one or more specialized engines that forecast market attributes, such as capacity, demand, supply, and prices, using particular data sources for particular markets. These may include an energy price forecasting engine 215 that bases its forecast on behavior of an automated agent, a network spectrum price forecasting engine 217 that bases its forecast on behavior of an automated agent, a REC price forecasting engine 219 that bases its forecast on behavior of an automated agent, a compute price forecasting engine 221 that bases its forecast on behavior of an automated agent, a network spectrum price forecasting engine 223 that bases its forecast on behavior of an automated agent. In each case, observations regarding the behavior of automated agents, such as ones used for conversation, for dialog management, for managing electronic commerce, for managing advertising and others may be provided as inputs for forecasting to the engines. The intelligent forecasting engines 192 may also include a range of engines that provide forecasts at least in part based on entity behavior, such as behavior of business and other organizations, such as marketing behavior, sales behavior, product offering behavior, advertising behavior, purchasing behavior, transactional behavior, merger and acquisition behavior, and other entity behavior. These may include an energy price forecasting engine 225 using entity behavior, a network spectrum price forecasting engine 227 using entity behavior, a REC price forecasting engine 229 using entity behavior, a compute price forecasting engine 231 using entity behavior, and a network spectrum price forecasting engine 233 using entity behavior.

[0349] The intelligent forecasting engines 192 may also include a range of engines that provide forecasts at least in part based on human behavior, such as behavior of consumers and users, such as purchasing behavior, shopping behavior, sales behavior, product interaction behavior, energy utilization behavior, mobility behavior, activity level behavior, activity type behavior, transactional behavior, and other human behavior. These may include an energy price forecasting engine 235 using human behavior, a network spectrum price forecasting engine 237 using human behavior, a REC price forecasting engine 239 using human behavior, a compute price forecasting engine 241 using human behavior, and a network spectrum price forecasting engine 243 using human behavior.

[0350] Referring still to FIGS. 2A-2B, the platform 100 may include a set of intelligent transaction engines 136 that automate execution of transactions in forward markets 130 and/or spot markets 170 based on determination that favorable conditions exist, such as by the intelligent resource allocation and coordination engine 168 and/or with use of forecasts form the intelligent forecasting engines 192. The intelligent transaction engines 136 may be configured to automatically execute transactions, using available market interfaces, such as APIs, connectors, ports, network interfaces, and the like, in each of the markets noted above. In embodiments, the intelligent transaction engines may execute transactions based on event streams that come from external data sources, such as IoT data sources 198 and social media data sources 180. The engines may include, for example, an IoT forward energy transaction engine 195 and/or an IoT compute market transaction engine 106, either or both of which may use data from the Internet of Things to determine timing and other attributes for market transaction in a market for one or more of the resources described herein, such as an energy market transaction, a compute resource transaction or other resource transaction. IoT data may include instrumentation and controls data for one or more machines (optionally coordinated as a fleet) that use or produce energy or that use or have compute resources, weather data that influences energy prices or consumption (such as wind data influencing production of wind energy), sensor data from energy production environments, sensor data from points of use for energy or compute resources (such as vehicle traffic data, network traffic data, IT network utilization data, Internet utilization and traffic data, camera data from work sites, smart building data, smart home data, and the like), and other data collected by or transferred within the Internet of Things, including data stored in IoT platforms and of cloud services providers like Amazon, IBM, and others. The engines 136 may include engines that use social data to determine timing of other attributes for a market transaction in one or more of the resources described herein, such as a social data forward energy transaction engine 199 and/or a social data compute market transaction engine 116. Social data may include data from social networking sites (e.g., Facebook™, YouTube™ Twitter™, Snapchat™, Instagram™, and others, data from websites, data from e-commerce sites, and data from other sites that contain information that may be relevant to determining or forecasting behavior of users or entities, such as data indicating interest or attention to particular topics, goods or services, data indicating activity types and levels (such as may be observed by machine processing of image data showing individuals engaged in activities, including travel, work activities, leisure activities, and the like. Social data may be supplied to machine learning, such as for learning user behavior or entity behavior, and/or as an input to an expert system, a model, or the like, such as one for determining, based on the social data, the parameters for a transaction. For example, an event or set of events in a social data stream may indicate the likelihood of a surge of interest in an online resource, a product, or a service, and compute resources, bandwidth, storage, or like may be purchased in advance (avoiding surge pricing) to accommodate the increased interest reflected by the social data stream.

[0351] Referring to FIG. 3, the platform 100 may include capabilities for transaction execution that involve one or more distributed ledgers 113 and one or more smart contracts 103, where the distributed ledgers 113 and smart contracts 103 are configured to enable specialized transaction features for specific transaction domains. One such domain is intellectual property, which transactions are highly complex, involving licensing terms and conditions that are somewhat difficult to manage, as compared to more straightforward sales of goods or services. In embodiments, a smart contract wrapper 105, such as wrapper aggregating intellectual property, is provided, using a distributed ledger, wherein the smart contract embeds IP licensing terms for intellectual property that is embedded in the distributed ledger and wherein executing an operation on the distributed ledger provides access to the intellectual property and commits the executing party to the IP licensing terms. Licensing terms for a wide range of goods and services, including digital goods like video, audio, video game, video game element, music, electronic book and other digital goods may be managed by tracking transactions involving them on a distributed ledger, whereby publishers may verify a chain of licensing and sublicensing. The distributed ledger may be configured to add each licensee to the ledger, and the ledger may be retrieved at the point of use of a digital item, such as in a streaming platform, to validate that licensing has occurred.

[0352] In embodiments, an improved distributed ledger is provided with the smart contract wrapper 105, such as an IP wrapper, container, smart contract or similar mechanism for aggregating intellectual property licensing terms, wherein a smart contract wrapper on the distributed ledger allows an operation on the ledger to add intellectual property to an aggregate stack of intellectual property. In many cases, intellectual property builds on other intellectual property, such as where software code is derived from other code, where trade secrets or know-how for elements of a process are combined to enable a larger process, where patents covering sub-components of a system or steps in a process are pooled, where elements of a video game include sub-component assets from different creators, where a book contains contributions from multiple authors, and the like. In embodiments, a smart IP wrapper aggregates licensing terms for different intellectual property items (including digital goods, including ones embodying different types of intellectual property rights, and transaction data involving the item, as well as optionally one or more portions of the item corresponding to the transaction data, are stored in a distributed ledger that is configured to enable validation of agreement to the licensing terms (such as at appoint of use) and/or access control to the item. In embodiments, a royalty apportionment wrapper 115 may be provided in a system having a distributed ledger for aggregating intellectual property licensing terms, wherein a smart contract wrapper on the distributed ledger allows an operation on the ledger to add intellectual property and to agree to an apportionment of royalties among the parties in the ledger. Thus, a ledger may accumulate contributions to the ledger along with evidence of agreement to the apportionment of any royalties among the contributors of the IP that is embedded in and/or controlled by the ledger. The ledger may record licensing terms and automatically vary them as new contributions are made, such as by one or more rules. For example, contributors may be given a share of a royalty stack according to a rule, such as based on a fractional contribution, such as based on lines of code contributed, lines of authorship, contribution to components of a system, and the like. In embodiments, a distributed ledger may be forked into versions that represent varying combinations of sub-components of IP, such as to allow users to select combinations that are of most use, thereby allowing contributors who have contributed the most value to be rewarded. Variation and outcome tracking may be iteratively improved, such as by machine learning.

[0353] In embodiments, a distributed ledger is provided for aggregating intellectual property licensing terms, wherein a smart contract wrapper on the distributed ledger allows an operation on the ledger to add intellectual property to an aggregate stack of intellectual property.

[0354] In embodiments, the platform 100 may have an improved distributed ledger for aggregating intellectual property licensing terms, wherein a smart contract wrapper on the distributed ledger allows an operation on the ledger to commit a party to a contract term via an IP transaction wrapper 119 of the ledger. This may include operations involving cryptocurrencies, tokens, or other operations, as well as conventional payments and in-kind transfers, such as of various resources described herein. The ledger may accumulate evidence of commitments to IP transactions by parties, such as entering into royalty terms, revenue sharing terms, IP ownership terms, warranty and liability terms, license permissions and restrictions, field of use terms, and many others.

[0355] In embodiments, improved distributed ledgers may include ones having a tokenized instruction set, such that operation on the distributed ledger provides provable access to the instruction set. A party wishing to share permission to know how, a trade secret or other valuable instructions may thus share the instruction set via a distributed ledger that captures and stores evidence of an action on the ledger by a third party, thereby evidencing access and agreement to terms and conditions of access. In embodiments, the platform 100 may have a distributed ledger that tokenizes executable algorithmic logic 121, such that operation on the distributed ledger provides provable access to the executable algorithmic logic. A variety of instruction sets may be stored by a distributed ledger, such as to verify access and verify agreement to terms (such as smart contract terms). In embodiments, instruction sets that embody trade secrets may be separated into sub-components, so that operations must occur on multiple ledgers to get (provable) access to a trade secret. This may permit parties wishing to share secrets, such as with multiple sub-contractors or vendors, to main provable access control, while separating components among different vendors to avoid sharing an entire set with a single party. Various kinds of executable instruction sets may be stored on specialized distributed ledgers that may include smart wrappers for specific types of instruction sets, such that provable access control, validation of terms, and tracking of utilization may be performed by operations on the distributed ledger (which may include triggering access controls within a content management system or other systems upon validation of actions taken in a smart contract on the ledger. In embodiments, the platform 100 may have a distributed ledger that tokenizes a 3D printer instruction set 123, such that operation on the distributed ledger provides provable access to the instruction set.

[0356] In embodiments, the platform 100 may have a distributed ledger that tokenizes an instruction set for a coating process 125, such that operation on the distributed ledger provides provable access to the instruction set.

[0357] In embodiments, the platform 100 may have a distributed ledger that tokenizes an instruction set for a semiconductor fabrication process 129, such that operation on the distributed ledger provides provable access to the fabrication process.

[0358] In embodiments, the platform 100 may have a distributed ledger that tokenizes a firmware program 131, such that operation on the distributed ledger provides provable access to the firmware program.

[0359] In embodiments, the platform 100 may have a distributed ledger that tokenizes an instruction set for an FPGA 133, such that operation on the distributed ledger provides provable access to the FPGA.

[0360] In embodiments, the platform 100 may have a distributed ledger that tokenizes serverless code logic 135, such that operation on the distributed ledger provides provable access to the serverless code logic.

[0361] In embodiments, the platform 100 may have a distributed ledger that tokenizes an instruction set for a crystal fabrication system 139, such that operation on the distributed ledger provides provable access to the instruction set.

[0362] In embodiments, the platform 100 may have a distributed ledger that tokenizes an instruction set for a food preparation process 141, such that operation on the distributed ledger provides provable access to the instruction set.

[0363] In embodiments, the platform 100 may have a distributed ledger that tokenizes an instruction set for a polymer production process 143, such that operation on the distributed ledger provides provable access to the instruction set.

[0364] In embodiments, the platform 100 may have a distributed ledger that tokenizes an instruction set for chemical synthesis process 145, such that operation on the distributed ledger provides provable access to the instruction set.

[0365] In embodiments, the platform 100 may have a distributed ledger that tokenizes an instruction set for a biological production process 149, such that operation on the distributed ledger provides provable access to the instruction set.

[0366] In embodiments, the platform 100 may have a distributed ledger that tokenizes a trade secret with an expert wrapper 151, such that operation on the distributed ledger provides provable access to the trade secret and the wrapper provides validation of the trade secret by the expert. An interface may be provided by which an expert accesses the trade secret on the ledger and verifies that the information is accurate and sufficient to allow a third party to use the secret.

[0367] In embodiments, the platform 100 may have a distributed ledger that aggregates views of a trade secret into a chain that proves which and how many parties have viewed the trade secret. Views may be used to allocate value to creators of the trade secret, to operators of the platform 100, or the like.

[0368] In embodiments, the platform 100 may have a distributed ledger that tokenizes an instruction set 111, such that operation on the distributed ledger provides provable access 155 to the instruction set and execution of the instruction set on a system results in recording a transaction in the distributed ledger.

[0369] In embodiments, the platform 100 may have a distributed ledger that tokenizes an item of intellectual property and a reporting system that reports an analytic result based on the operations performed on the distributed ledger or the intellectual property.

[0370] In embodiments, the platform 100 may have a distributed ledger that aggregates a set of instructions, where an operation on the distributed ledger adds at least one instruction to a pre-existing set of instructions 161 to provide a modified set of instructions.

[0371] Referring still to FIG. 3, an intelligent cryptocurrency execution engine 183 may provide intelligence for the timing, location and other attributes of a cryptocurrency transaction, such as a mining transaction, an exchange transaction, a storage transaction, a retrieval transaction, or the like. Cryptocurrencies like Bitcoin™ are increasingly widespread, with specialized coins having emerged for a wide variety of purposes, such as exchanging value in various specialized market domains. Initial offerings of such coins, or ICOs, are increasingly subject to regulations, such as securities regulations, and in some cases to taxation. Thus, while cryptocurrency transactions typically occur within computer networks, jurisdictional factors may be important in determining where, when and how to execute a transaction, store a cryptocurrency, exchange it for value. In embodiments, intelligent cryptocurrency execution engine 183 may use features embedded in or wrapped around the digital object representing a coin, such as features that cause the execution of transactions in the coin to be undertaken with awareness of various conditions, including geographic conditions, regulatory conditions, tax conditions, market conditions, and the like.

[0372] In embodiments, the platform 100 may include a tax aware coin 165 or smart wrapper for a cryptocurrency coin that directs execution of a transaction involving the coin to a geographic location based on tax treatment of at least one of the coin and the transaction in the geographic location.

[0373] In embodiments, the platform 100 may include a location-aware coin 169 or smart wrapper that enables a self-executing cryptocurrency coin that commits a transaction upon recognizing a location-based parameter that provides favorable tax treatment.

[0374] In embodiments, the platform 100 may include an expert system or AI agent 171 that uses machine learning to optimize the execution of cryptocurrency transactions based on tax status. Machine learning may use one or more models or heuristics, such as populated with relevant jurisdictional tax data, may be trained on a training set of human trading operations, may be supervised by human supervisors, and/or may use a deep learning technique based on outcomes over time, such as when operating on a wide range of internal system data and external data sources 182 as described throughout this disclosure.

[0375] In embodiments, the platform 100 may include regulation aware coin 173 having a coin, a smart wrapper, and/or an expert system that aggregates regulatory information covering cryptocurrency transactions and automatically selects a jurisdiction for an operation based on the regulatory information. Machine learning may use one or more models or heuristics, such as populated with relevant jurisdictional regulatory data, may be trained on a training set of human trading operations, may be supervised by human supervisors, and/or may use a deep learning technique based on outcomes over time, such as when operating on a wide range of internal system data and external data sources 182 as described throughout this disclosure.

[0376] In embodiments, the platform 100 may include an energy price-aware coin 175, wrapper, or expert system that uses machine learning to optimize the execution of a cryptocurrency transaction based on real time energy price information for an available energy source. Cryptocurrency transactions, such as coin mining and blockchain operations, may be highly energy intensive. An energy price-aware coin may be configured to time such operations based on energy price forecasts, such as with one or more of the forecasting engines 192 described throughout this disclosure.

[0377] In embodiments, the platform 100 may include an energy source aware coin 179, wrapper, or expert system that uses machine learning to optimize the execution of a cryptocurrency transaction based on an understanding of available energy sources to power computing resources to execute the transaction. For example, coin mining may be performed only when renewable energy sources are available. Machine learning for optimization of a transaction may use one or more models or heuristics, such as populated with relevant energy source data (such as may be captured in a knowledge graph, which may contain energy source information by type, location and operating parameters), may be trained on a training set of input-output data for human-initiated transactions, may be supervised by human supervisors, and/or may use a deep learning technique based on outcomes over time, such as when operating on a wide range of internal system data and external data sources 182 as described throughout this disclosure.

[0378] In embodiments, the platform 100 may include a charging cycle aware coin 181, wrapper, or an expert system that uses machine learning to optimize charging and recharging cycle of a rechargeable battery system to provide energy for execution of a cryptocurrency transaction. For example, a battery may be discharged for a cryptocurrency transaction only if a minimum threshold of battery charge is maintained for other operational use, if re-charging resources are known to be readily available, or the like. Machine learning for optimization of charging and recharging may use one or more models or heuristics, such as populated with relevant battery data (such as may be captured in a knowledge graph, which may contain energy source information by type, location and operating parameters), may be trained on a training set of human operations, may be supervised by human supervisors, and/or may use a deep learning technique based on outcomes over time, such as when operating on a wide range of internal system data and external data sources 182 as described throughout this disclosure.

[0379] Optimization of various intelligent coin operations may occur with machine learning that is trained on outcomes, such as financial profitability. Any of the machine learning systems described throughout this disclosure may be used for optimization of intelligent cryptocurrency transaction management.

[0380] In embodiments, compute resources, such as those mentioned throughout this disclosure, may be allocated to perform a range of computing tasks, both for operations that occur within the platform 100, ones that are managed by the platform, and ones that involve the activities, workflows and processes of various assets that may be owned, operated or managed in conjunction with the platform, such as sets or fleets of assets that have or use computing resources. Examples of compute tasks include, without limitation, cryptocurrency mining, distributed ledger calculations and storage, forecasting tasks, transaction execution tasks, spot market testing tasks, internal data collection tasks, external data collection, machine learning tasks, and others. As noted above, energy, compute resources, bandwidth, spectrum, and other resources may be coordinated, such as by machine learning, for these tasks. Outcome and feedback information may be provided for the machine learning, such as outcomes for any of the individual tasks and overall outcomes, such as yield and profitability for business or other operations involving the tasks.

[0381] In embodiments, networking resources, such as those mentioned throughout this disclosure, may be allocated to perform a range of networking tasks, both for operations that occur within the platform 100, ones that are managed by the platform, and ones that involve the activities, workflows and processes of various assets that may be owned, operated or managed in conjunction with the platform, such as sets or fleets of assets that have or use networking resources. Examples of networking tasks include cognitive network coordination, network coding, peer bandwidth sharing (including, for example cost-based routing, value-based routing, outcome-based routing and the like), distributed transaction execution, spot market testing, randomization (e.g., using genetic programming with outcome feedback to vary network configurations and transmission paths), internal data collection and external data collection. As noted above, energy, compute resources, bandwidth, spectrum, and other resources may be coordinated, such as by machine learning, for these networking tasks. Outcome and feedback information may be provided for the machine learning, such as outcomes for any of the individual tasks and overall outcomes, such as yield and profitability for business or other operations involving the tasks.

[0382] In embodiments, data storage resources, such as those mentioned throughout this disclosure, may be allocated to perform a range of data storage tasks, both for operations that occur within the platform 100, ones that are managed by the platform, and ones that involve the activities, workflows and processes of various assets that may be owned, operated or managed in conjunction with the platform, such as sets or fleets of assets that have or use networking resources. Examples of data storage tasks include distributed ledger storage, storage of internal data (such as operational data with the platform), cryptocurrency storage, smart wrapper storage, storage of external data, storage of feedback and outcome data, and others. As noted above, data storage, energy, compute resources, bandwidth, spectrum, and other resources may be coordinated, such as by machine learning, for these data storage tasks. Outcome and feedback information may be provided for the machine learning, such as outcomes for any of the individual tasks and overall outcomes, such as yield and profitability for business or other operations involving the tasks.

[0383] In embodiments, smart contracts, such as ones embodying terms relating to intellectual property, trade secrets, know how, instruction sets, algorithmic logic, and the like may embody or include contract terms, which may include terms and conditions for options, royalty stacking terms, field exclusivity, partial exclusivity, pooling of intellectual property, standards terms (such as relating to essential and non-essential patent usage), technology transfer terms, consulting service terms, update terms, support terms, maintenance terms, derivative works terms, copying terms, and performance-related rights or metrics, among many others.

[0384] In embodiments where an instruction set is embodied in digital form, such as contained in or managed by a distributed ledger transactions system, various systems may be configured with interfaces that allow them to access and use the instruction sets. In embodiments, such systems may include access control features that validate proper licensing by inspection of a distributed ledger, a key, a token, or the like that indicates the presence of access rights to an instruction set. Such systems that execute distributed instruction sets may include systems for 3D printing, crystal fabrication, semiconductor fabrication, coating items, producing polymers, chemical synthesis and biological production, among others.

[0385] Networking capabilities and network resources should be understood to include a wide range of networking systems, components and capabilities, including infrastructure elements for 3G, 4G, LTE, 5G and other cellular network types, access points, routers, and other Wi-Fi elements, cognitive networking systems and components, mobile networking systems and components, physical layer, MAC layer and application layer systems and components, cognitive networking components and capabilities, peer-to-peer networking components and capabilities, optical networking components and capabilities, and others.

[0386] Building blocks on expert systems and AI

[0387] Neural Net Systems

[0388] Referring to FIG. 4 through FIG. 31, embodiments of the present disclosure, including ones involving expert systems, self-organization, machine learning, artificial intelligence, and the like, may benefit from the use of a neural net, such as a neural net trained for pattern recognition, for classification of one or more parameters, characteristics, or phenomena, for support of autonomous control, and other purposes. References to a neural net throughout this disclosure should be understood to encompass a wide range of different types of neural networks, machine learning systems, artificial intelligence systems, and the like, such as feed forward neural networks, radial basis function neural networks, self-organizing neural networks (e.g., Kohonen self-organizing neural networks), recurrent neural networks, modular neural networks, artificial neural networks, physical neural networks, multi-layered neural networks, convolutional neural networks, hybrids of neural networks with other expert systems (e.g., hybrid fuzzy logic—neural network systems), Autoencoder neural networks, probabilistic neural networks, time delay neural networks, convolutional neural networks, regulatory feedback neural networks, radial basis function neural networks, recurrent neural networks, Hopfield neural networks, Boltzmann machine neural networks, self-organizing map (SOM) neural networks, learning vector quantization (LVQ) neural networks, fully recurrent neural networks, simple recurrent neural networks, echo state neural networks, long short-term memory neural networks, bi-directional neural networks, hierarchical neural networks, stochastic neural networks, genetic scale RNN neural networks, committee of machines neural networks, associative neural networks, physical neural networks, instantaneously trained neural networks, spiking neural networks, neocognitron neural networks, dynamic neural networks, cascading neural networks, neuro-fuzzy neural networks, compositional pattern-producing neural networks, memory neural networks, hierarchical temporal memory neural networks, deep feed forward neural networks, gated recurrent unit (GCU) neural networks, auto encoder neural networks, variational auto encoder neural networks, de-noising auto encoder neural networks, sparse auto-encoder neural networks, Markov chain neural networks, restricted Boltzmann machine neural networks, deep belief neural networks, deep convolutional neural networks, de-convolutional neural networks, deep convolutional inverse graphics neural networks, generative adversarial neural networks, liquid state machine neural networks, extreme learning machine neural networks, echo state neural networks, deep residual neural networks, support vector machine neural networks, neural Turing machine neural networks, and/or holographic associative memory neural networks, or hybrids or combinations of the foregoing, or combinations with other expert systems, such as rule-based systems, model-based systems (including ones based on physical models, statistical models, flow-based models, biological models, biomimetic models, and the like).

[0389] In embodiments, FIGS. 5 through 31 depict exemplary neural networks and FIG. 4 depicts a legend showing the various components of the neural networks depicted throughout FIGS. 5 to 31. FIG. 4 depicts various neural net components depicted in cells that are assigned functions and requirements. In embodiments, the various neural net examples may include back fed data/sensor cells, data/sensor cells, noisy input cells, and hidden cells. The neural net components also include probabilistic hidden cells, spiking hidden cells, output cells, match input/output cells, recurrent cells, memory cells, different memory cells, kernels, and convolution or pool cells.

[0390] In embodiments, FIG. 5 depicts an exemplary perceptron neural network that may connect to, integrate with, or interface with the platform 100. The platform may also be associated with further neural net systems such as a feed forward neural network (FIG. 6), a radial basis neural network (FIG. 7), a deep feed forward neural network (FIG. 8), a recurrent neural network (FIG. 9), a long/short term neural network (FIG. 10), and a gated recurrent neural network (FIG. 11). The platform may also be associated with further neural net systems such as an auto encoder neural network (FIG. 12), a variational neural network (FIG. 13), a denoising neural network (FIG. 14), a sparse neural network (FIG. 15), a Markov chain neural network (FIG. 16), and a Hopfield network neural network (FIG. 17). The platform may further be associated with additional neural net systems such as a Boltzmann machine neural network (FIG. 18), a restricted BM neural network (FIG. 19), a deep belief neural network (FIG. 20), a deep convolutional neural network (FIG. 21), a deconvolutional neural network (FIG. 22), and a deep convolutional inverse graphics neural network (FIG. 23). The platform may also be associated with further neural net systems such as a generative adversarial neural network (FIG. 24), a liquid state machine neural network (FIG. 25), an extreme learning machine neural network (FIG. 26), an echo state neural network (FIG. 27), a deep residual neural network (FIG. 28), a Kohonen neural network (FIG. 29), a support vector machine neural network (FIG. 30), and a neural Turing machine neural network (FIG. 31).

[0391] The foregoing neural networks may have a variety of nodes or neurons, which may perform a variety of functions on inputs, such as inputs received from sensors or other data sources, including other nodes. Functions may involve weights, features, feature vectors, and the like. Neurons may include perceptrons, neurons that mimic biological functions (such as of the human senses of touch, vision, taste, hearing, and smell), and the like. Continuous neurons, such as with sigmoidal activation, may be used in the context of various forms of neural net, such as where back propagation is involved.

[0392] In many embodiments, an expert system or neural network may be trained, such as by a human operator or supervisor, or based on a data set, model, or the like. Training may include presenting the neural network with one or more training data sets that represent values, such as sensor data, event data, parameter data, and other types of data (including the many types described throughout this disclosure), as well as one or more indicators of an outcome, such as an outcome of a process, an outcome of a calculation, an outcome of an event, an outcome of an activity, or the like. Training may include training in optimization, such as training a neural network to optimize one or more systems based on one or more optimization approaches, such as Bayesian approaches, parametric Bayes classifier approaches, k-nearest-neighbor classifier approaches, iterative approaches, interpolation approaches, Pareto optimization approaches, algorithmic approaches, and the like. Feedback may be provided in a process of variation and selection, such as with a genetic algorithm that evolves one or more solutions based on feedback through a series of rounds.

[0393] In embodiments, a plurality of neural networks may be deployed in a cloud platform that receives data streams and other inputs collected (such as by mobile data collectors) in one or more transactional environments and transmitted to the cloud platform over one or more networks, including using network coding to provide efficient transmission. In the cloud platform, optionally using massively parallel computational capability, a plurality of different neural networks of various types (including modular forms, structure-adaptive forms, hybrids, and the like) may be used to undertake prediction, classification, control functions, and provide other outputs as described in connection with expert systems disclosed throughout this disclosure. The different neural networks may be structured to compete with each other (optionally including use evolutionary algorithms, genetic algorithms, or the like), such that an appropriate type of neural network, with appropriate input sets, weights, node types and functions, and the like, may be selected, such as by an expert system, for a specific task involved in a given context, workflow, environment process, system, or the like.

[0394] In embodiments, methods and systems described herein that involve an expert system or self-organization capability may use a feed forward neural network, which moves information in one direction, such as from a data input, like a data source related to at least one resource or parameter related to a transactional environment, such as any of the data sources mentioned throughout this disclosure, through a series of neurons or nodes, to an output. Data may move from the input nodes to the output nodes, optionally passing through one or more hidden nodes, without loops. In embodiments, feed forward neural networks may be constructed with various types of units, such as binary McCulloch-Pitts neurons, the simplest of which is a perceptron.

[0395] In embodiments, methods and systems described herein that involve an expert system or self-organization capability may use a capsule neural network, such as for prediction, classification, or control functions with respect to a transactional environment, such as relating to one or more of the machines and automated systems described throughout this disclosure.

[0396] In embodiments, methods and systems described herein that involve an expert system or self-organization capability may use a radial basis function (RBF) neural network, which may be preferred in some situations involving interpolation in a multi-dimensional space (such as where interpolation is helpful in optimizing a multi-dimensional function, such as for optimizing a data marketplace as described here, optimizing the efficiency or output of a power generation system, a factory system, or the like, or other situation involving multiple dimensions. In embodiments, each neuron in the RBF neural network stores an example from a training set as a “prototype.” Linearity involved in the functioning of this neural network offers RBF the advantage of not typically suffering from problems with local minima or maxima.

[0397] In embodiments, methods and systems described herein that involve an expert system or self-organization capability may use a radial basis function (RBF) neural network, such as one that employs a distance criterion with respect to a center (e.g., a Gaussian function). A radial basis function may be applied as a replacement for a hidden layer, such as a sigmoidal hidden layer transfer, in a multi-layer perceptron. An RBF network may have two layers, such as where an input is mapped onto each RBF in a hidden layer. In embodiments, an output layer may comprise a linear combination of hidden layer values representing, for example, a mean predicted output. The output layer value may provide an output that is the same as or similar to that of a regression model in statistics. In classification problems, the output layer may be a sigmoid function of a linear combination of hidden layer values, representing a posterior probability. Performance in both cases is often improved by shrinkage techniques, such as ridge regression in classical statistics. This corresponds to a prior belief in small parameter values (and therefore smooth output functions) in a Bayesian framework. RBF networks may avoid local minima, because the only parameters that are adjusted in the learning process are the linear mapping from hidden layer to output layer. Linearity ensures that the error surface is quadratic and therefore has a single minimum. In regression problems, this may be found in one matrix operation. In classification problems, the fixed non-linearity introduced by the sigmoid output function may be handled using an iteratively re-weighted least squares function or the like. RBF networks may use kernel methods such as support vector machines (SVM) and Gaussian processes (where the RBF is the kernel function). A non-linear kernel function may be used to project the input data into a space where the learning problem may be solved using a linear model.

[0398] In embodiments, an RBF neural network may include an input layer, a hidden layer, and a summation layer. In the input layer, one neuron appears in the input layer for each predictor variable. In the case of categorical variables, N−1 neurons are used, where N is the number of categories. The input neurons may, in embodiments, standardize the value ranges by subtracting the median and dividing by the interquartile range. The input neurons may then feed the values to each of the neurons in the hidden layer. In the hidden layer, a variable number of neurons may be used (determined by the training process). Each neuron may consist of a radial basis function that is centered on a point with as many dimensions as a number of predictor variables. The spread (e.g., radius) of the RBF function may be different for each dimension. The centers and spreads may be determined by training. When presented with the vector of input values from the input layer, a hidden neuron may compute a Euclidean distance of the test case from the neuron's center point and then apply the RBF kernel function to this distance, such as using the spread values. The resulting value may then be passed to the summation layer. In the summation layer, the value coming out of a neuron in the hidden layer may be multiplied by a weight associated with the neuron and may add to the weighted values of other neurons. This sum becomes the output. For classification problems, one output is produced (with a separate set of weights and summation units) for each target category. The value output for a category is the probability that the case being evaluated has that category. In training of an RBF, various parameters may be determined, such as the number of neurons in a hidden layer, the coordinates of the center of each hidden-layer function, the spread of each function in each dimension, and the weights applied to outputs as they pass to the summation layer. Training may be used by clustering algorithms (such as k-means clustering), by evolutionary approaches, and the like.

[0399] In embodiments, a recurrent neural network may have a time-varying, real-valued (more than just zero or one) activation (output). Each connection may have a modifiable real-valued weight. Some of the nodes are called labeled nodes, some output nodes, and others hidden nodes. For supervised learning in discrete time settings, training sequences of real-valued input vectors may become sequences of activations of the input nodes, one input vector at a time. At each time step, each non-input unit may compute its current activation as a nonlinear function of the weighted sum of the activations of all units from which it receives connections. The system may explicitly activate (independent of incoming signals) some output units at certain time steps.

[0400] In embodiments, methods and systems described herein that involve an expert system or self-organization capability may use a self-organizing neural network, such as a Kohonen self-organizing neural network, such as for visualization of views of data, such as low-dimensional views of high-dimensional data. The self-organizing neural network may apply competitive learning to a set of input data, such as from one or more sensors or other data inputs from or associated with a transactional environment, including any machine or component that relates to the transactional environment. In embodiments, the self-organizing neural network may be used to identify structures in data, such as unlabeled data, such as in data sensed from a range of data sources about or sensors in or about in a transactional environment, where sources of the data are unknown (such as where events may be coming from any of a range of unknown sources). The self-organizing neural network may organize structures or patterns in the data, such that they may be recognized, analyzed, and labeled, such as identifying market behavior structures as corresponding to other events and signals.

[0401] In embodiments, methods and systems described herein that involve an expert system or self-organization capability may use a recurrent neural network, which may allow for a bi-directional flow of data, such as where connected units (e.g., neurons or nodes) form a directed cycle. Such a network may be used to model or exhibit dynamic temporal behavior, such as involved in dynamic systems, such as a wide variety of the automation systems, machines and devices described throughout this disclosure, such as an automated agent interacting with a marketplace for purposes of collecting data, testing spot market transactions, execution transactions, and the like, where dynamic system behavior involves complex interactions that a user may desire to understand, predict, control and/or optimize. For example, the recurrent neural network may be used to anticipate the state of a market, such as one involving a dynamic process or action, such as a change in state of a resource that is traded in or that enables a marketplace of transactional environment. In embodiments, the recurrent neural network may use internal memory to process a sequence of inputs, such as from other nodes and/or from sensors and other data inputs from or about the transactional environment, of the various types described herein. In embodiments, the recurrent neural network may also be used for pattern recognition, such as for recognizing a machine, component, agent, or other item based on a behavioral signature, a profile, a set of feature vectors (such as in an audio file or image), or the like. In a non-limiting example, a recurrent neural network may recognize a shift in an operational mode of a marketplace or machine by learning to classify the shift from a training data set consisting of a stream of data from one or more data sources of sensors applied to or about one or more resources.

[0402] In embodiments, methods and systems described herein that involve an expert system or self-organization capability may use a modular neural network, which may comprise a series of independent neural networks (such as ones of various types described herein) that are moderated by an intermediary. Each of the independent neural networks in the modular neural network may work with separate inputs, accomplishing subtasks that make up the task the modular network as whole is intended to perform. For example, a modular neural network may comprise a recurrent neural network for pattern recognition, such as to recognize what type of machine or system is being sensed by one or more sensors that are provided as input channels to the modular network and an RBF neural network for optimizing the behavior of the machine or system once understood. The intermediary may accept inputs of each of the individual neural networks, process them, and create output for the modular neural network, such an appropriate control parameter, a prediction of state, or the like.

[0403] Combinations among any of the pairs, triplets, or larger combinations, of the various neural network types described herein, are encompassed by the present disclosure. This may include combinations where an expert system uses one neural network for recognizing a pattern (e.g., a pattern indicating a problem or fault condition) and a different neural network for self-organizing an activity or work flow based on the recognized pattern (such as providing an output governing autonomous control of a system in response to the recognized condition or pattern). This may also include combinations where an expert system uses one neural network for classifying an item (e.g., identifying a machine, a component, or an operational mode) and a different neural network for predicting a state of the item (e.g., a fault state, an operational state, an anticipated state, a maintenance state, or the like). Modular neural networks may also include situations where an expert system uses one neural network for determining a state or context (such as a state of a machine, a process, a work flow, a marketplace, a storage system, a network, a data collector, or the like) and a different neural network for self-organizing a process involving the state or context (e.g., a data storage process, a network coding process, a network selection process, a data marketplace process, a power generation process, a manufacturing process, a refining process, a digging process, a boring process, or other process described herein).

[0404] In embodiments, methods and systems described herein that involve an expert system or self-organization capability may use a physical neural network where one or more hardware elements is used to perform or simulate neural behavior. In embodiments, one or more hardware neurons may be configured to stream voltage values, current values, or the like that represent sensor data, such as to calculate information from analog sensor inputs representing energy consumption, energy production, or the like, such as by one or more machines providing energy or consuming energy for one or more transactions. One or more hardware nodes may be configured to stream output data resulting from the activity of the neural net. Hardware nodes, which may comprise one or more chips, microprocessors, integrated circuits, programmable logic controllers, application-specific integrated circuits, field-programmable gate arrays, or the like, may be provided to optimize the machine that is producing or consuming energy, or to optimize another parameter of some part of a neural net of any of the types described herein. Hardware nodes may include hardware for acceleration of calculations (such as dedicated processors for performing basic or more sophisticated calculations on input data to provide outputs, dedicated processors for filtering or compressing data, dedicated processors for de-compressing data, dedicated processors for compression of specific file or data types (e.g., for handling image data, video streams, acoustic signals, thermal images, heat maps, or the like), and the like. A physical neural network may be embodied in a data collector, including one that may be reconfigured by switching or routing inputs in varying configurations, such as to provide different neural net configurations within the data collector for handling different types of inputs (with the switching and configuration optionally under control of an expert system, which may include a software-based neural net located on the data collector or remotely). A physical, or at least partially physical, neural network may include physical hardware nodes located in a storage system, such as for storing data within a machine, a data storage system, a distributed ledger, a mobile device, a server, a cloud resource, or in a transactional environment, such as for accelerating input/output functions to one or more storage elements that supply data to or take data from the neural net. A physical, or at least partially physical, neural network may include physical hardware nodes located in a network, such as for transmitting data within, to or from an industrial environment, such as for accelerating input/output functions to one or more network nodes in the net, accelerating relay functions, or the like. In embodiments, of a physical neural network, an electrically adjustable resistance material may be used for emulating the function of a neural synapse. In embodiments, the physical hardware emulates the neurons, and software emulates the neural network between the neurons. In embodiments, neural networks complement conventional algorithmic computers. They are versatile and may be trained to perform appropriate functions without the need for any instructions, such as classification functions, optimization functions, pattern recognition functions, control functions, selection functions, evolution functions, and others.

[0405] In embodiments, methods and systems described herein that involve an expert system or self-organization capability may use a multilayered feed forward neural network, such as for complex pattern classification of one or more items, phenomena, modes, states, or the like. In embodiments, a multilayered feed forward neural network may be trained by an optimization technique, such as a genetic algorithm, such as to explore a large and complex space of options to find an optimum, or near-optimum, global solution. For example, one or more genetic algorithms may be used to train a multilayered feed forward neural network to classify complex phenomena, such as to recognize complex operational modes of machines, such as modes involving complex interactions among machines (including interference effects, resonance effects, and the like), modes involving non-linear phenomena, modes involving critical faults, such as where multiple, simultaneous faults occur, making root cause analysis difficult, and others. In embodiments, a multilayered feed forward neural network may be used to classify results from monitoring of a marketplace, such as monitoring systems, such as automated agents, that operate within the marketplace, as well as monitoring resources that enable the marketplace, such as computing, networking, energy, data storage, energy storage, and other resources.

[0406] In embodiments, methods and systems described herein that involve an expert system or self-organization capability may use a feed-forward, back-propagation multi-layer perceptron (MLLP) neural network, such as for handling one or more remote sensing applications, such as for taking inputs from sensors distributed throughout various transactional environments. In embodiments, the MLP neural network may be used for classification of transactional environments and resource environments, such as spot markets, forward markets, energy markets, renewable energy credit (REC) markets, networking markets, advertising markets, spectrum markets, ticketing markets, rewards markets, compute markets, and others mentioned throughout this disclosure, as well as physical resources and environments that produce them, such as energy resources (including renewable energy environments, mining environments, exploration environments, drilling environments, and the like, including classification of geological structures (including underground features and above ground features), classification of materials (including fluids, minerals, metals, and the like), and other problems. This may include fuzzy classification.

[0407] In embodiments, methods and systems described herein that involve an expert system or self-organization capability may use a structure-adaptive neural network, where the structure of a neural network is adapted, such as based on a rule, a sensed condition, a contextual parameter, or the like. For example, if a neural network does not converge on a solution, such as classifying an item or arriving at a prediction, when acting on a set of inputs after some amount of training, the neural network may be modified, such as from a feed forward neural network to a recurrent neural network, such as by switching data paths between some subset of nodes from unidirectional to bi-directional data paths. The structure adaptation may occur under control of an expert system, such as to trigger adaptation upon occurrence of a trigger, rule or event, such as recognizing occurrence of a threshold (such as an absence of a convergence to a solution within a given amount of time) or recognizing a phenomenon as requiring different or additional structure (such as recognizing that a system is varying dynamically or in a non-linear fashion). In one non-limiting example, an expert system may switch from a simple neural network structure like a feed forward neural network to a more complex neural network structure like a recurrent neural network, a convolutional neural network, or the like upon receiving an indication that a continuously variable transmission is being used to drive a generator, turbine, or the like in a system being analyzed.

[0408] In embodiments, methods and systems described herein that involve an expert system or self-organization capability may use an autoencoder, autoassociator or Diabolo neural network, which may be similar to a multilayer perceptron (MLP) neural network, such as where there may be an input layer, an output layer and one or more hidden layers connecting them. However, the output layer in the auto-encoder may have the same number of units as the input layer, where the purpose of the MLP neural network is to reconstruct its own inputs (rather than just emitting a target value). Therefore, the auto encoders may operate as an unsupervised learning model. An auto encoder may be used, for example, for unsupervised learning of efficient codings, such as for dimensionality reduction, for learning generative models of data, and the like. In embodiments, an auto-encoding neural network may be used to self-learn an efficient network coding for transmission of analog sensor data from a machine over one or more networks or of digital data from one or more data sources. In embodiments, an auto-encoding neural network may be used to self-learn an efficient storage approach for storage of streams of data.

[0409] In embodiments, methods and systems described herein that involve an expert system or self-organization capability may use a probabilistic neural network (PNN), which, in embodiments, may comprise a multi-layer (e.g., four-layer) feed forward neural network, where layers may include input layers, hidden layers, pattern/summation layers and an output layer. In an embodiment of a PNN algorithm, a parent probability distribution function (PDF) of each class may be approximated, such as by a Parzen window and/or a non-parametric function. Then, using the PDF of each class, the class probability of a new input is estimated, and Bayes' rule may be employed, such as to allocate it to the class with the highest posterior probability. A PNN may embody a Bayesian network and may use a statistical algorithm or analytic technique, such as Kernel Fisher discriminant analysis technique. The PNN may be used for classification and pattern recognition in any of a wide range of embodiments disclosed herein. In one non-limiting example, a probabilistic neural network may be used to predict a fault condition of an engine based on collection of data inputs from sensors and instruments for the engine.

[0410] In embodiments, methods and systems described herein that involve an expert system or self-organization capability may use a time delay neural network (TDNN), which may comprise a feed forward architecture for sequential data that recognizes features independent of sequence position. In embodiments, to account for time shifts in data, delays are added to one or more inputs, or between one or more nodes, so that multiple data points (from distinct points in time) are analyzed together. A time delay neural network may form part of a larger pattern recognition system, such as using a perceptron network. In embodiments, a TDNN may be trained with supervised learning, such as where connection weights are trained with back propagation or under feedback. In embodiments, a TDNN may be used to process sensor data from distinct streams, such as a stream of velocity data, a stream of acceleration data, a stream of temperature data, a stream of pressure data, and the like, where time delays are used to align the data streams in time, such as to help understand patterns that involve understanding of the various streams (e.g., changes in price patterns in spot or forward markets).

[0411] In embodiments, methods and systems described herein that involve an expert system or self-organization capability may use a convolutional neural network (referred to in some cases as a CNN, a ConvNet, a shift invariant neural network, or a space invariant neural network), wherein the units are connected in a pattern similar to the visual cortex of the human brain. Neurons may respond to stimuli in a restricted region of space, referred to as a receptive field. Receptive fields may partially overlap, such that they collectively cover the entire (e.g., visual) field. Node responses may be calculated mathematically, such as by a convolution operation, such as using multilayer perceptrons that use minimal preprocessing. A convolutional neural network may be used for recognition within images and video streams, such as for recognizing a type of machine in a large environment using a camera system disposed on a mobile data collector, such as on a drone or mobile robot. In embodiments, a convolutional neural network may be used to provide a recommendation based on data inputs, including sensor inputs and other contextual information, such as recommending a route for a mobile data collector. In embodiments, a convolutional neural network may be used for processing inputs, such as for natural language processing of instructions provided by one or more parties involved in a workflow in an environment. In embodiments, a convolutional neural network may be deployed with a large number of neurons (e.g., 100,000, 500,000 or more), with multiple (e.g., 4, 5, 6 or more) layers, and with many (e.g., millions) of parameters. A convolutional neural net may use one or more convolutional nets.

[0412] In embodiments, methods and systems described herein that involve an expert system or self-organization capability may use a regulatory feedback network, such as for recognizing emergent phenomena (such as new types of behavior not previously understood in a transactional environment).

[0413] In embodiments, methods and systems described herein that involve an expert system or self-organization capability may use a self-organizing map (SOM), involving unsupervised learning. A set of neurons may learn to map points in an input space to coordinates in an output space. The input space may have different dimensions and topology from the output space, and the SOM may preserve these while mapping phenomena into groups.

[0414] In embodiments, methods and systems described herein that involve an expert system or self-organization capability may use a learning vector quantization neural net (LVQ). Prototypical representatives of the classes may parameterize, together with an appropriate distance measure, in a distance-based classification scheme.

[0415] In embodiments, methods and systems described herein that involve an expert system or self-organization capability may use an echo state network (ESN), which may comprise a recurrent neural network with a sparsely connected, random hidden layer. The weights of output neurons may be changed (e.g., the weights may be trained based on feedback). In embodiments, an ESN may be used to handle time series patterns, such as, in an example, recognizing a pattern of events associated with a market, such as the pattern of price changes in response to stimuli.

[0416] In embodiments, methods and systems described herein that involve an expert system or self-organization capability may use a Bi-directional, recurrent neural network (BRNN), such as using a finite sequence of values (e.g., voltage values from a sensor) to predict or label each element of the sequence based on both the past and the future context of the element. This may be done by adding the outputs of two RNNs, such as one processing the sequence from left to right, the other one from right to left. The combined outputs are the predictions of target signals, such as ones provided by a teacher or supervisor. A bi-directional RNN may be combined with a long short-term memory RNN.

[0417] In embodiments, methods and systems described herein that involve an expert system or self-organization capability may use a hierarchical RNN that connects elements in various ways to decompose hierarchical behavior, such as into useful subprograms. In embodiments, a hierarchical RNN may be used to manage one or more hierarchical templates for data collection in a transactional environment.

[0418] In embodiments, methods and systems described herein that involve an expert system or self-organization capability may use a stochastic neural network, which may introduce random variations into the network. Such random variations may be viewed as a form of statistical sampling, such as Monte Carlo sampling.

[0419] In embodiments, methods and systems described herein that involve an expert system or self-organization capability may use a genetic scale recurrent neural network. In such embodiments, an RNN (often an LSTM) is used where a series is decomposed into a number of scales where every scale informs the primary length between two consecutive points. A first order scale consists of a normal RNN, a second order consists of all points separated by two indices and so on. The Nth order RNN connects the first and last node. The outputs from all the various scales may be treated as a committee of members, and the associated scores may be used genetically for the next iteration.

[0420] In embodiments, methods and systems described herein that involve an expert system or self-organization capability may use a committee of machines (CoM), comprising a collection of different neural networks that together “vote” on a given example. Because neural networks may suffer from local minima, starting with the same architecture and training, but using randomly different initial weights often gives different results. A CoM tends to stabilize the result.

[0421] In embodiments, methods and systems described herein that involve an expert system or self-organization capability may use an associative neural network (ASNN), such as involving an extension of a committee of machines that combines multiple feed forward neural networks and a k-nearest neighbor technique. It may use the correlation between ensemble responses as a measure of distance amid the analyzed cases for the kNN. This corrects the bias of the neural network ensemble. An associative neural network may have a memory that may coincide with a training set. If new data become available, the network instantly improves its predictive ability and provides data approximation (self-learns) without retraining. Another important feature of ASNN is the possibility to interpret neural network results by analysis of correlations between data cases in the space of models.

[0422] In embodiments, methods and systems described herein that involve an expert system or self-organization capability may use an instantaneously trained neural network (ITNN), where the weights of the hidden and the output layers are mapped directly from training vector data.

[0423] In embodiments, methods and systems described herein that involve an expert system or self-organization capability may use a spiking neural network, which may explicitly consider the timing of inputs. The network input and output may be represented as a series of spikes (such as a delta function or more complex shapes). SNNs may process information in the time domain (e.g., signals that vary over time, such as signals involving dynamic behavior of markets or transactional environments). They are often implemented as recurrent networks.

[0424] In embodiments, methods and systems described herein that involve an expert system or self-organization capability may use a dynamic neural network that addresses nonlinear multivariate behavior and includes learning of time-dependent behavior, such as transient phenomena and delay effects. Transients may include behavior of shifting market variables, such as prices, available quantities, available counterparties, and the like.

[0425] In embodiments, cascade correlation may be used as an architecture and supervised learning algorithm, supplementing adjustment of the weights in a network of fixed topology. Cascade-correlation may begin with a minimal network, then automatically trains and add new hidden units one by one, creating a multi-layer structure. Once a new hidden unit has been added to the network, its input-side weights may be frozen. This unit then becomes a permanent feature-detector in the network, available for producing outputs or for creating other, more complex feature detectors. The cascade-correlation architecture may learn quickly, determine its own size and topology, and retain the structures it has built even if the training set changes and requires no back-propagation.

[0426] In embodiments, methods and systems described herein that involve an expert system or self-organization capability may use a neuro-fuzzy network, such as involving a fuzzy inference system in the body of an artificial neural network. Depending on the type, several layers may simulate the processes involved in a fuzzy inference, such as fuzzification, inference, aggregation and defuzzification. Embedding a fuzzy system in a general structure of a neural net as the benefit of using available training methods to find the parameters of a fuzzy system.

[0427] In embodiments, methods and systems described herein that involve an expert system or self-organization capability may use a compositional pattern-producing network (CPPN), such as a variation of an associative neural network (ANN) that differs the set of activation functions and how they are applied. While typical ANNs often contain only sigmoid functions (and sometimes Gaussian functions), CPPNs may include both types of functions and many others. Furthermore, CPPNs may be applied across the entire space of possible inputs, so that they may represent a complete image. Since they are compositions of functions, CPPNs in effect encode images at infinite resolution and may be sampled for a particular display at whatever resolution is optimal.

[0428] This type of network may add new patterns without re-training. In embodiments, methods and systems described herein that involve an expert system or self-organization capability may use a one-shot associative memory network, such as by creating a specific memory structure, which assigns each new pattern to an orthogonal plane using adjacently connected hierarchical arrays.

[0429] In embodiments, methods and systems described herein that involve an expert system or self-organization capability may use a hierarchical temporal memory (HTM) neural network, such as involving the structural and algorithmic properties of the neocortex. HTM may use a biomimetic model based on memory-prediction theory. HTM may be used to discover and infer the high-level causes of observed input patterns and sequences.

[0430] Holographic Associative Memory

[0431] In embodiments, methods and systems described herein that involve an expert system or self-organization capability may use a holographic associative memory (HAM) neural network, which may comprise an analog, correlation-based, associative, stimulus-response system. Information may be mapped onto the phase orientation of complex numbers. The memory is effective for associative memory tasks, generalization and pattern recognition with changeable attention.

[0432] In embodiments, various embodiments involving network coding may be used to code transmission data among network nodes in a neural net, such as where nodes are located in one or more data collectors or machines in a transactional environment.

[0433] Integrated Circuit Building Blocks

[0434] In embodiments, one or more of the controllers, circuits, systems, data collectors, storage systems, network elements, or the like as described throughout this disclosure may be embodied in or on an integrated circuit, such as an analog, digital, or mixed signal circuit, such as a microprocessor, a programmable logic controller, an application-specific integrated circuit, a field programmable gate array, or other circuits, such as embodied on one or more chips disposed on one or more circuit boards, such as to provide in hardware (with potentially accelerated speed, energy performance, input-output performance, or the like) one or more of the functions described herein. This may include setting up circuits with up to billions of logic gates, flip-flops, multiplexers, and other circuits in a small space, facilitating high speed processing, low power dissipation, and reduced manufacturing cost compared with board-level integration. In embodiments, a digital IC, typically a microprocessor, digital signal processor, microcontroller, or the like may use Boolean algebra to process digital signals to embody complex logic, such as involved in the circuits, controllers, and other systems described herein. In embodiments, a data collector, an expert system, a storage system, or the like may be embodied as a digital integrated circuit, such as a logic IC, memory chip, interface IC (e.g., a level shifter, a serializer, a deserializer, and the like), a power management IC and/or a programmable device; an analog integrated circuit, such as a linear IC, RF IC, or the like, or a mixed signal IC, such as a data acquisition IC (including A/D converters, D/A converter, digital potentiometers) and/or a clock/timing IC.

[0435] With reference to FIG. 32, the environment includes an intelligent energy and compute facility (such as a large scale facility hosting many compute resources and having access to a large energy source, such as a hydropower source), as well as a host intelligent energy and compute facility resource management platform, referred to in some cases for convenience as the energy and information technology platform (with networking, data storage, data processing and other resources as described herein), a set of data sources, a set of expert systems, interfaces to a set of market platforms and external resources, and a set of user (or client) systems and devices.

[0436] Intelligent Energy and Compute Facility

[0437] A facility may be configured to access an inexpensive (at least during some time periods) power source (such as a hydropower dam, a wind farm, a solar array, a nuclear power plant, or a grid), to contain a large set of networked information technology resources, including processing units, servers, and the like that are capable of flexible utilization (such as by switching inputs, switching configurations, switching programming and the like), and to provide a range of outputs that can also be flexibly configured (such as passing through power to a smart grid, providing computational results (such as for cryptocurrency mining, artificial intelligence, or analytics). A facility may include a power storage system, such as for large scale storage of available power.

[0438] Intelligent Energy and Compute Facility Resource Management Platform

[0439] In operation, a user can access the energy and information technology platform to initiate and manage a set of activities that involve optimizing energy and computing resources among a diverse set of available tasks. Energy resources may include hydropower, nuclear power, wind power, solar power, grid power and the like, as well as energy storage resources, such as batteries, gravity power, and storage using thermal materials, such as molten salts. Computing resources may include GPUs, FPGAs, servers, chips, Asics, processors, data storage media, networking resources, and many others. Available tasks may include cryptocurrency hash processing, expert system processing, computer vision processing, NLP, path optimization, applications of models such as for analytics, etc.

[0440] In embodiments, the platform may include various subsystems that may be implemented as micro services, such that other subsystems of the system access the functionality of a subsystem providing a micro service via application programming interface API. In some embodiments, the various services that are provided by the subsystems may be deployed in bundles that are integrated, such as by a set of APIs. Each of the subsystems is described in greater detail with respect to FIG. 130.

[0441] The External Data Sources can include any system or device that can provide data to the platform. Examples of data sources can include market data sources (e.g., for financial markets, commercial markets (including e-commerce), advertising markets, energy markets, telecommunication markets, and many others). The energy and computing resource platform accesses external data sources via a network (e.g., the Internet) in any suitable manner (e.g., crawlers, extract-transform-load (ETL) systems, gateways, brokers, application programming interfaces (APIs), spiders, distributed database queries, and the like).

[0442] A facility is a facility that has an energy resource (e.g., a hydro power resource) and a set of compute resource (e.g., a set of flexible computing resources that can be provisioned and managed to perform computing tasks, such as GPUs, FPGAs and many others, a set of flexible networking resources that can similarly be provisioned and managed, such as by adjusting network coding protocols and parameters), and the like.

[0443] User and client systems and devices can include any system or device that may consume one or more computing or energy resource made available by the energy and computing resource platform. Examples include cryptocurrency systems (e.g., for Bitcoin and other cryptocurrency mining operations), expert and artificial intelligence systems (such as neural networks and other systems, such as for computer vision, natural language processing, path determination and optimization, pattern recognition, deep learning, supervised learning, decision support, and many others), energy management systems (such as smart grid systems), and many others. User and client systems may include user devices, such as smartphones, tablet computer devices, laptop computing devices, personal computing devices, smart televisions, gaming consoles, and the like.

[0444] Energy and computing resource platform Components in FIG. 130.

[0445] FIG. 130 illustrates an example energy and computing resource platform according to some embodiments of the present disclosure. In embodiments, the energy and computing resource platform may include a processing system 13002, a storage system 13004, and a communication system 13006.

[0446] The processing system 13002 may include one or more processors and memory. The processors may operate in an individual or distributed manner. The processors may be in the same physical device or in separate devices, which may or may not be located in the same facility. The memory may store computer-executable instructions that are executed by the one or more processors. In embodiments, the processing system 13002 may execute the facility management system 13008, the data acquisition system 13010, the cognitive processes system 13012, the lead generation system 13014, the content generation system 13016, and the workflow system 13018.

[0447] The storage system 13004 may include one or more computer-readable storage mediums. The computer-readable storage mediums may be located in the same physical device or in separate devices, which may or may not be located in the same facility, which may or may not be located in the same facility. The computer-readable storage mediums may include flash devices, solid-state memory devices, hard disk drives, and the like. In embodiments, the storage system 13004 stores one or more of a facility data store 13020, a person data store 13022, and an external data store 13024.

[0448] The communication system 13006 may include one or more transceivers that are configured to effectuate wireless or wired communication with one or more external devices, including user devices and/or servers, via a network (e.g., the Internet and/or a cellular network). The communication system 13006 may implement any suitable communication protocol. For example, the communication system xxx may implement an IEEE 801.11 wireless communication protocol and/or any suitable cellular communication protocol to effectuate wireless communication with external devices and external data stores 13024 via a wireless network.

[0449] Energy and Computing Resource Management Platform

[0450] Discovers, provisions, manages and optimizes energy and compute resources using artificial intelligence and expert systems with sensitivity to market and other conditions by learning on a set of outcomes. Discovers and facilitates cataloging of resources, optionally by user entry and/or automated detection (including peer detection). May implement a graphical user interface to receive relevant information regarding the energy and compute resources that are available. This may include a “digital twin” of an energy and compute facility that allows modeling, prediction and the like. May generate a set of data record that define the facility or a set of facilities under common ownership or operation by a host. The data record may have any suitable schema. In some embodiments (e.g., FIG. 131), the facility data records may include a facility identifier (e.g., a unique identifier that corresponds to the facility), a facility type (e.g., energy system and capabilities, compute systems and capabilities, networking systems and capabilities), facility attributes (e.g., name of the facility, name of the facility initiator, description of the facility, keywords of the facility, goals of the facility, timing elements, schedules, and the like), participants/potential participants in the facility (e.g., identifiers of owners, operators, hosts, service providers, consumers, clients, users, workers, and others), and any suitable metadata (e.g., creation date, launch date, scheduled requirements and the like). May generate content, such as a document, message, alert, report, webpage and/or application page based on the contents of the data record. For example, may obtain the data record of the facility and may populate a webpage template with the data contained therein. In addition, there can be management of existing facilities, updates the data record of a facility, determinations of outcomes (e.g., energy produced, compute tasks completed, processing outcomes achieved, financial outcomes achieved, service levels met and many others), and sending of information (e.g., updates, alerts, requests, instructions, and the like) to individuals and systems.

[0451] Data Acquisition Systems can acquire various types of data from different data sources and organizes that data into one or more data structures. In embodiments, the data acquisition system receives data from users via a user interface (e.g., user types in profile information). In embodiments, the data acquisition system can retrieve data from passive electronic sources. In embodiments, the data acquisition system can implement crawlers to crawl different websites or applications. In embodiments, the data acquisition system can implement an API to retrieve data from external data sources or user devices (e.g., various contact lists from user's phone or email account). In embodiments, the data acquisition system can structure the obtained data into appropriate data structures. In embodiments, the data acquisition system generates and maintains person records based on data collected regarding individuals. In embodiments, a person datastore stores person records. In some of these embodiments, the person datastore may include one or more databases, indexes, tables, and the like. Each person record may correspond to a respective individual and may be organized according to any suitable schema.

[0452] FIG. 132 illustrates an example schema of a person record. In the example, each person record may include a unique person identifier (e.g., username or value), and may define all data relating to a person, including a person's name, facilities they are a part of or associated with (e.g., a list of facility identifiers), attributes of the person (age, location, job, company, role, skills, competencies, capabilities, education history, job history, and the like), a list of contacts or relationships of the person (e.g., in a role hierarchy or graph), and any suitable metadata (e.g., date joined, dates actions were taken, dates input was received, and the like).

[0453] In embodiments, the data acquisition system generates and maintains one or more graphs based on the retrieved data. In some embodiments, a graph datastore may store the one or more graphs. The graph may be specific to a facility or may be a global graph. The graph may be used in many different applications (e.g., identifying a set of roles, such as for authentication, for approvals, and the like for persons, or identifying system configurations, capabilities, or the like, such as hierarchies of energy producing, computing, networking, or other systems, subsystems and/or resources).

[0454] In embodiments, a graph may be stored in a graph database, where data is stored in a collection of nodes and edges. In some embodiments, a graph has nodes representing entities and edges representing relationships, each node may have a node type (also referred to as an entity type) and an entity value, each edge may have a relationship type and may define a relationship between two entities. For example, a person node may include a person ID that identifies the individual represented by the node and a company node may include a company identifier that identifies a company. A “works for” edge that is directed from a person node to a company node may denote that the person represented by the edge node works for the company represented by the company node. In another example, a person node may include a person ID that identifies the individual represented by the node and a facility node may include a facility identifier that identifies a facility. A “manages” edge that is directed from a person node to a facility node may denote that the person represented by the person node is a manager of the facility represented by the facility node. Furthermore in embodiments, an edge or node may contain or reference additional data. For example, a “manages” edge may include a function that indicates a specific function within a facility that is managed by a person. The graph(s) can be used in a number of different applications, which are discussed with respect to the cognitive processing system.

[0455] In embodiments, validated Identity information may be imported from one or more identity information providers, as well as data from LinkedIn™ and other social network sources regarding data acquisition and structuring data. In embodiments, the data acquisition system may include an identity management system (not shown in Figs) of the platform may manage identity stitching, identity resolution, identity normalization, and the like, such as determining where an individual represented across different social networking sites and email contacts is in fact the same person. In embodiments, the data acquisition system may include a profile aggregation system (not shown in Figs) that finds and aggregates disparate pieces of information to generate a comprehensive profile for a person. The profile aggregation system may also deduplicate individuals.

[0456] Cognitive Processing Systems

[0457] The cognitive processing system 13312 may implement one or more of machine learning processes, artificial intelligence processes, analytics processes, natural language processing processes, and natural language generation processes. FIG. 133 illustrates an example cognitive processing system according to some embodiments of the present disclosure. In this example, the cognitive processing system may include a machine learning system 13302, an artificial intelligence (AI) system 13304, an analytics system 13306, a natural language processing system 13308, and a natural language generation system 13310.

[0458] Machine Learning System

[0459] In embodiments, the machine learning system may train models, such as predictive models (e.g., various types of neural networks, regression based models, and other machine-learned models). In embodiments, training can be supervised, semi-supervised, or unsupervised. In embodiments, training can be done using training data, which may be collected or generated for training purposes.

[0460] A facility output model (or prediction model) may be a model that receive facility attributes and outputs one or more predictions regarding the production or other output of a facility. Examples of predictions may be the amount of energy a facility will produce, the amount of processing the facility will undertake, the amount of data a network will be able to transfer, the amount of data that can be stored, the price of a component, service or the like (such as supplied to or provided by a facility), a profit generated by accomplishing a given tasks, the cost entailed in performing an action, and the like. In each case, the machine learning system optionally trains a model based on training data. In embodiments, the machine learning system may receive vectors containing facility attributes (e.g., facility type, facility capability, objectives sought, constraints or rules that apply to utilization of resources or the facility, or the like), person attributes (e.g., role, components managed, and the like), and outcomes (e.g., energy produced, computing tasks completed, and financial results, among many others). Each vector corresponds to a respective outcome and the attributes of the respective facility and respective actions that led to the outcome. The machine learning system takes in the vectors and generates predictive model based thereon. In embodiments, the machine learning system may store the predictive models in the model datastore.

[0461] In embodiments, training can also be done based on feedback received by the system, which is also referred to as “reinforcement learning.” In embodiments, the machine learning system may receive a set of circumstances that led to a prediction (e.g., attributes of facility, attributes of a model, and the like) and an outcome related to the facility and may update the model according to the feedback.

[0462] In embodiments, training may be provided from a training data set that is created by observing actions of a set of humans, such as facility managers managing facilities that have various capabilities and that are involved in various contexts and situations. This may include use of robotic process automation to learn on a training data set of interactions of humans with interfaces, such as graphical user interfaces, of one or more computer programs, such as dashboards, control systems, and other systems that are used to manage an energy and compute management facility.

[0463] Artificial Intelligence (AI) Systems

[0464] In embodiments, the AI system leverages the predictive models to make predictions regarding facilities. Examples of predictions include ones related to inputs to a facility (e.g., available energy, cost of energy, cost of compute resources, networking capacity and the like, as well as various market information, such as pricing information for end use markets), ones related to components or systems of a facility (including performance predictions, maintenance predictions, uptime/downtime predictions, capacity predictions and the like), ones related to functions or workflows of the facility (such as ones that involved conditions or states that may result in following one or more distinct possible paths within a workflow, a process, or the like), ones related to outputs of the facility, and others. In embodiments, the AI system receives a facility identifier. In response to the facility identifier, the AI system may retrieve attributes corresponding to the facility. In some embodiments, the AI system may obtain the facility attributes from a graph. Additionally or alternatively, the AI system may obtain the facility attributes from a facility record corresponding to the facility identifier, and the person attributes from a person record corresponding to the person identifier.

[0465] Examples of additional attributes that can be used to make predictions about a facility or a related process of system include: related facility information; owner goals (including financial goals); client goals; and many more additional or alternative attributes. In embodiments, the AI system may output scores for each possible prediction, where each prediction corresponds to a possible outcome. For example, in using a prediction model used to determine a likelihood that a hydroelectric source for a facility will produce 5 MW of power, the prediction model can output a score for a “will produce” outcome and a score for a “will not produce” outcome. The AI system may then select the outcome with the highest score as the prediction. Alternatively, the AI system may output the respective scores to a requesting system.

[0466] Clustering Systems

[0467] In embodiments, a clustering system clusters records or entities based on attributes contained herein. For example, similar facilities, resources, people, clients, or the like may be clustered. The clustering system may implement any suitable clustering algorithm. For example, when clustering people records to identify a list of customer leads corresponding to resources that can be sold by a facility, the clustering system may implement k-nearest neighbors clustering, whereby the clustering system identifies k people records that most closely relate to the attributes defined for the facility. In another example, the clustering system may implement k-means clustering, such that the clustering system identifies k different clusters of people records, whereby the clustering system or another system selects items from the cluster.

[0468] Analytics System

[0469] In embodiments, an analytics system may perform analytics relating to various aspects of the energy and computing resource platform. The analytics system may analyze certain communications to determine which configurations of a facility produce the greatest yield, what conditions tend to indicate potential faults or problems, and the like.

[0470] Lead Generation System

[0471] FIG. 134 shows the manner by which the lead generation system generates a lead list. Lead generation system receives a list of potential leads 13402 (such as for consumers of available products or resources). The lead generation system may provide the list of leads to the clustering system 13404. The clustering system clusters the profile of the lead with the clusters of facility attributes 13406 to identify one or more clusters. In embodiments, the clustering system returns a list of leads 13410. In other embodiments, the clustering system returns the clusters 13408, and the lead generation system selects the list of leads 13410 from the cluster to which a prospect belongs.

[0472] FIG. 135 illustrates the manner by which the lead generation system determines facility outputs for leads identified in the list of leads. In embodiments, the lead generation system provides a lead identifier of a respective lead to the AI system (step 13502). The AI system may then obtain the lead attributes of the lead and facility attributes of the facility and may feed the respective attributes into a prediction model (step 13504). The prediction model outputs a prediction, which may be scores associated with each possible outcome, or a single predicted outcome that was selected based on its respective score (e.g., the outcome having the highest score) (step 13506). The lead generation system may iterate in this manner for each lead in the lead list. For example, the lead generation system may generate leads that are consumers of compute capabilities, energy capabilities, predictions and forecasts, optimization results, and others.

[0473] In embodiments, the lead generation system categorizes the lead (step 13508) and generates a lead list (step 13512) which it provides to the facility operator or host of the systems, including an indicator of the reason why a lead may be willing to engage the facility, such as, for example, that the lead is an intensive user of computing resources, such as to forecast behavior of a complex, multi-variable market, or to mine for cryptocurrency. In embodiments, where more leads are stored and/or categorized, the lead generation system continues checking the lead list (step 13510).

[0474] Content Generation Systems

[0475] In embodiments, a content generation system of the platform generates content for a contact event, such as an email, text message, or a post to a network, or a machine-to-machine message, such as communicating via an API or a peer-to-peer system. In embodiments, the content is customized using artificial intelligence based on the attributes of the facility, attributes of a recipient (e.g., based on the profile of a person, the role of a person, or the like), and/or relating to the project or activity to which the facility relates. The content generation system may be seeded with a set of templates, which may be customized, such as by training the content generation system on a training set of data created by human writers, and which may be further trained by feedback based on outcomes tracked by the platform, such as outcomes indicating success of particular forms of communication in generating donations to a facility, as well as other indicators as noted throughout this disclosure. The content generation system may customize content based on attributes of the facility, a project, and/or one or more people, and the like. For example, a facility manager may receive short messages about events related to facility operations, including codes, acronyms and jargon, while an outside consumer of outputs from the facility may receive a more formal report relating to the same event.

[0476] FIG. 136 illustrates a manner by which the content generation system may generate personalized content. The content generation system receives a recipient id, a sender id (which may be a person or a system, among others), and a facility id (step 13602). The content generation system may determine the appropriate template (step 13604) to use based on the relationships among the recipient, sender and facility and/or based on other considerations (e.g., a recipient who is a busy manager is more likely to respond to less formal messages or more formal messages). The content generation system may provide the template (or an identifier thereof) to the natural language generation system, along with the recipient id, the sender id, and the facility id. The natural language generation system may obtain facility attributes based on the facility id, and person attributes corresponding to the recipient or sender based on their identities (step 13606). The natural language generation system may then generate the personalized or customized content (step 13608) based on the selected template, the facility parameters, and/or other attributes of the various types described herein. The natural language generation system may output the generated content (step 13610) to the content generation system.

[0477] In embodiments, a person, such as a facility manager, may approve the generated content provided by the content generation system and/or make edits to the generated content, then send the content, such as via email and/or other channels. In embodiments, the platform tracks the contact event.

[0478] Referring to FIG. 137, an adaptive intelligence system 13704 may include an artificial intelligence system 13748, a digital twin system 13720, and an adaptive device (or edge) intelligence system 13730. The artificial intelligence system 13748 may define a machine learning model 13702 for performing analytics, simulation, decision making, and prediction making related to data processing, data analysis, simulation creation, and simulation analysis of one or more of the transaction entities. The machine learning model 13702 is an algorithm and/or statistical model that performs specific tasks without using explicit instructions, relying instead on patterns and inference. The machine learning model 13702 builds one or more mathematical models based on training data to make predictions and/or decisions without being explicitly programmed to perform the specific tasks. The machine learning model 13702 may receive inputs of sensor data as training data, including event data 13724 and state data 13772 related to one or more of the transaction entities through data collection systems 13718 and monitoring systems 13706 and connectivity facilities 13716. The event data 13724 and state data 13772 may be stored in a data storage system 13710 The sensor data input to the machine learning model 13702 may be used to train the machine learning model 13702 to perform the analytics, simulation, decision making, and prediction making relating to the data processing, data analysis, simulation creation, and simulation analysis of the one or more of the transaction entities. The machine learning model 13702 may also use input data from a user or users of the information technology system. The machine learning model 13702 may include an artificial neural network, a decision tree, a support vector machine, a Bayesian network, a genetic algorithm, any other suitable form of machine learning model, or a combination thereof. The machine learning model 13702 may be configured to learn through supervised learning, unsupervised learning, reinforcement learning, self-learning, feature learning, sparse dictionary learning, anomaly detection, association rules, a combination thereof, or any other suitable algorithm for learning.

[0479] The artificial intelligence system 13748 may also define the digital twin system 13720 to create a digital replica of one or more of the transaction entities. The digital replica of the one or more of the transaction entities may use substantially real-time sensor data to provide for substantially real-time virtual representation of the transaction entity and provides for simulation of one or more possible future states of the one or more transaction entities. The digital replica exists simultaneously with the one or more transaction entities being replicated. The digital replica provides one or more simulations of both physical elements and properties of the one or more transaction entities being replicated and the dynamics thereof, in embodiments, throughout the lifestyle of the one or more transaction entities being replicated. The digital replica may provide a hypothetical simulation of the one or more transaction entities, for example during a design phase before the one or more transaction entities are constructed or fabricated, or during or after construction or fabrication of the one or more transaction entities by allowing for hypothetical extrapolation of sensor data to simulate a state of the one or more transaction entities, such as during high stress, after a period of time has passed during which component wear may be an issue, during maximum throughput operation, after one or more hypothetical or planned improvements have been made to the one or more transaction entities, or any other suitable hypothetical situation. In some embodiments, the machine learning model 13702 may automatically predict hypothetical situations for simulation with the digital replica, such as by predicting possible improvements to the one or more transaction entities, predicting when one or more components of the one or more transaction entities may fail, and/or suggesting possible improvements to the one or more transaction entities, such as changes to timing settings, arrangement, components, or any other suitable change to the transaction entities. The digital replica allows for simulation of the one or more transaction entities during both design and operation phases of the one or more transaction entities, as well as simulation of hypothetical operation conditions and configurations of the one or more transaction entities. The digital replica allows for invaluable analysis and simulation of the one or more transaction entities, by facilitating observation and measurement of nearly any type of metric, including temperature, wear, light, vibration, etc. not only in, on, and around each component of the one or more transaction entities, but in some embodiments within the one or more transaction entities. In some embodiments, the machine learning model 13702 may process the sensor data including the event data 13724 and the state data 13772 to define simulation data for use by the digital twin system 13720. The machine learning model 13702 may, for example, receive state data 13772 and event data 13724 related to a particular transaction entity of the plurality of transaction entities and perform a series of operations on the state data 13772 and the event data 13724 to format the state data 13772 and the event data 13724 into a format suitable for use by the digital twin system 13720 in creation of a digital replica of the transaction entity. For example, one or more transaction entities may include a robot configured to augment products on an adjacent assembly line. The machine learning model 13702 may collect data from one or more sensors positioned on, near, in, and/or around the robot. The machine learning model 13702 may perform operations on the sensor data to process the sensor data into simulation data and output the simulation data to the digital twin system 13720. The digital twin system 13720 simulation may use the simulation data to create one or more digital replicas of the robot, the simulation including for example metrics including temperature, wear, speed, rotation, and vibration of the robot and components thereof. The simulation may be a substantially real-time simulation, allowing for a human user of the information technology to view the simulation of the robot, metrics related thereto, and metrics related to components thereof, in substantially real time. The simulation may be a predictive or hypothetical situation, allowing for a human user of the information technology to view a predictive or hypothetical simulation of the robot, metrics related thereto, and metrics related to components thereof.

[0480] In some embodiments, the machine learning model 13702 and the digital twin system 13720 may process sensor data and create a digital replica of a set of transaction entities of the plurality of transaction entities to facilitate design, real-time simulation, predictive simulation, and/or hypothetical simulation of a related group of transaction entities. The digital replica of the set of transaction entities may use substantially real-time sensor data to provide for substantially real-time virtual representation of the set of transaction entities and provide for simulation of one or more possible future states of the set of transaction entities. The digital replica exists simultaneously with the set of transaction entities being replicated. The digital replica provides one or more simulations of both physical elements and properties of the set of transaction entities being replicated and the dynamics thereof, in embodiments throughout the lifestyle of the set of transaction entities being replicated. The one or more simulations may include a visual simulation, such as a wire-frame virtual representation of the one or more transaction entities that may be viewable on a monitor, using an augmented reality (AR) apparatus, or using a virtual reality (VR) apparatus. The visual simulation may be able to be manipulated by a human user of the information technology system, such as zooming or highlighting components of the simulation and/or providing an exploded view of the one or more transaction entities. The digital replica may provide a hypothetical simulation of the set of transaction entities, for example during a design phase before the one or more transaction entities are constructed or fabricated, or during or after construction or fabrication of the one or more transaction entities by allowing for hypothetical extrapolation of sensor data to simulate a state of the set of transaction entities, such as during high stress, after a period of time has passed during which component wear may be an issue, during maximum throughput operation, after one or more hypothetical or planned improvements have been made to the set of transaction entities, or any other suitable hypothetical situation. In some embodiments, the machine learning model 13702 may automatically predict hypothetical situations for simulation with the digital replica, such as by predicting possible improvements to the set of transaction entities, predicting when one or more components of the set of transaction entities may fail, and/or suggesting possible improvements to the set of transaction entities, such as changes to timing settings, arrangement, components, or any other suitable change to the transaction entities. The digital replica allows for simulation of the set of transaction entities during both design and operation phases of the set of transaction entities, as well as simulation of hypothetical operation conditions and configurations of the set of transaction entities. The digital replica allows for invaluable analysis and simulation of the one or more transaction entities, by facilitating observation and measurement of nearly any type of metric, including temperature, wear, light, vibration, etc. not only in, on, and around each component of the set of transaction entities, but in some embodiments within the set of transaction entities. In some embodiments, the machine learning model 13702 may process the sensor data including the event data 13724 and the state data 13772 to define simulation data for use by the digital twin system 13720. The machine learning model 13702 may, for example, receive state data 13772 and event data 13724 related to a particular transaction entity of the plurality of transaction entities and perform a series of operations on the state data 13772 and the event data 13724 to format the state data 13772 and the event data 13724 into a format suitable for use by the digital twin system 13720 in the creation of a digital replica of the set of transaction entities. For example, a set of transaction entities may include a die machine configured to place products on a conveyor belt, the conveyor belt on which the die machine is configured to place the products, and a plurality of robots configured to add parts to the products as they move along the assembly line. The machine learning model 13702 may collect data from one or more sensors positioned on, near, in, and/or around each of the die machines, the conveyor belt, and the plurality of robots. The machine learning model 13702 may perform operations on the sensor data to process the sensor data into simulation data and output the simulation data to the digital twin system 13720. The digital twin system 13720 simulation may use the simulation data to create one or more digital replicas of the die machine, the conveyor belt, and the plurality of robots, the simulation including for example metrics including temperature, wear, speed, rotation, and vibration of the die machine, the conveyor belt, and the plurality of robots and components thereof. The simulation may be a substantially real-time simulation, allowing for a human user of the information technology to view the simulation of the die machine, the conveyor belt, and the plurality of robots, metrics related thereto, and metrics related to components thereof, in substantially real time. The simulation may be a predictive or hypothetical situation, allowing for a human user of the information technology to view a predictive or hypothetical simulation of the die machine, the conveyor belt, and the plurality of robots, metrics related thereto, and metrics related to components thereof.

[0481] In some embodiments, the machine learning model 13702 may prioritize collection of sensor data for use in digital replica simulations of one or more of the transaction entities. The machine learning model 13702 may use sensor data and user inputs to train, thereby learning which types of sensor data are most effective for creation of digital replicate simulations of one or more of the transaction entities. For example, the machine learning model 13702 may find that a particular transaction entity has dynamic properties such as component wear and throughput affected by temperature, humidity, and load. The machine learning model 13702 may, through machine learning, prioritize collection of sensor data related to temperature, humidity, and load, and may prioritize processing sensor data of the prioritized type into simulation data for output to the digital twin system 13720. In some embodiments, the machine learning model 13702 may suggest to a user of the information technology system that more and/or different sensors of the prioritized type be implemented in the information technology near and around the transaction entity being simulation such that more and/or better data of the prioritized type may be used in simulation of the transaction entity via the digital replica thereof.

[0482] In some embodiments, the machine learning model 13702 may be configured to learn to determine which types of sensor data are to be processed into simulation data for transmission to the digital twin system 13720 based on one or both of a modeling goal and a quality or type of sensor data. A modeling goal may be an objective set by a user of the information technology system or may be predicted or learned by the machine learning model 13702. Examples of modeling goals include creating a digital replica capable of showing dynamics of throughput on an assembly line, which may include collection, simulation, and modeling of, e.g., thermal, electrical power, component wear, and other metrics of a conveyor belt, an assembly machine, one or more products, and other components of the transaction ecosystem. The machine learning model 137102 may be configured to learn to determine which types of sensor data are necessary to be processed into simulation data for transmission to the digital twin system 13720 to achieve such a model. In some embodiments, the machine learning model 13702 may analyze which types of sensor data are being collected, the quality and quantity of the sensor data being collected, and what the sensor data being collected represents, and may make decisions, predictions, analyses, and/or determinations related to which types of sensor data are and/or are not relevant to achieving the modeling goal and may make decisions, predictions, analyses, and/or determinations to prioritize, improve, and/or achieve the quality and quantity of sensor data being processed into simulation data for use by the digital twin system 13720 in achieving the modeling goal.

[0483] In some embodiments, a user of the information technology system may input a modeling goal into the machine learning model 13702. The machine learning model 13702 may learn to analyze training data to output suggestions to the user of the information technology system regarding which types of sensor data are most relevant to achieving the modeling goal, such as one or more types of sensors positioned in, on, or near a transaction entity or a plurality of transaction entities that is relevant to the achievement of the modeling goal is and/or are not sufficient for achieving the modeling goal, and how a different configuration of the types of sensors, such as by adding, removing, or repositioning sensors, may better facilitate achievement of the modeling goal by the machine learning model 13702 and the digital twin system 13720. In some embodiments, the machine learning model 13702 may automatically increase or decrease collection rates, processing, storage, sampling rates, bandwidth allocation, bitrates, and other attributes of sensor data collection to achieve or better achieve the modeling goal. In some embodiments, the machine learning model 13702 may make suggestions or predictions to a user of the information technology system related to increasing or decreasing collection rates, processing, storage, sampling rates, bandwidth allocation, bitrates, and other attributes of sensor data collection to achieve or better achieve the modeling goal. In some embodiments, the machine learning model 13702 may use sensor data, simulation data, previous, current, and/or future digital replica simulations of one or more transaction entities of the plurality of transaction entities to automatically create and/or propose modeling goals. In some embodiments, modeling goals automatically created by the machine learning model 13702 may be automatically implemented by the machine learning model 13702. In some embodiments, modeling goals automatically created by the machine learning model 13702 may be proposed to a user of the information technology system, and implemented only after acceptance and/or partial acceptance by the user, such as after modifications are made to the proposed modeling goal by the user.

[0484] In some embodiments, the user may input the one or more modeling goals, for example, by inputting one or more modeling commands to the information technology system. The one or more modeling commands may include, for example, a command for the machine learning model 13702 and the digital twin system 13720 to create a digital replica simulation of one transaction entity or a set of transaction entities, may include a command for the digital replica simulation to be one or more of a real-time simulation, and a hypothetical simulation. The modeling command may also include, for example, parameters for what types of sensor data should be used, sampling rates for the sensor data, and other parameters for the sensor data used in the one or more digital replica simulations. In some embodiments, the machine learning model 13702 may be configured to predict modeling commands, such as by using previous modeling commands as training data. The machine learning model 13702 may propose predicted modeling commands to a user of the information technology system, for example, to facilitate simulation of one or more of the transaction entities that may be useful for the management of the transaction entities and/or to allow the user to easily identify potential issues with or possible improvements to the transaction entities. The system of FIG. 137 may include a transactions management platform and applications.

[0485] In some embodiments, the machine learning model 13702 may be configured to evaluate a set of hypothetical simulations of one or more of the transaction entities. The set of hypothetical simulations may be created by the machine learning model 13702 and the digital twin system 13720 as a result of one or more modeling commands, as a result of one or more modeling goals, one or more modeling commands, by prediction by the machine learning model 13702, or a combination thereof. The machine learning model 13702 may evaluate the set of hypothetical simulations based on one or more metrics defined by the user, one or more metrics defined by the machine learning model 13702, or a combination thereof. In some embodiments, the machine learning model 13702 may evaluate each of the hypothetical simulations of the set of hypothetical simulations independently of one another. In some embodiments, the machine learning model 13702 may evaluate one or more of the hypothetical simulations of the set of hypothetical simulations in relation to one another, for example by ranking the hypothetical simulations or creating tiers of the hypothetical simulations based on one or more metrics.

[0486] In some embodiments, the machine learning model 13702 may include one or more model interpretability systems to facilitate human understanding of outputs of the machine learning model 13702, as well as information and insight related to cognition and processes of the machine learning model 13702, i.e., the one or more model interpretability systems allow for human understanding of not only “what” the machine learning model 13702 is outputting, but also “why” the machine learning model 13702 is outputting the outputs thereof, and what process led to the machine learning models 13702 formulating the outputs. The one or more model interpretability systems may also be used by a human user to improve and guide training of the machine learning model 13702, to help debug the machine learning model 13702, to help recognize bias in the machine learning model 13702. The one or more model interpretability systems may include one or more of linear regression, logistic regression, a generalized linear model (GLM), a generalized additive model (GAM), a decision tree, a decision rule, RuleFit, Naive Bayes Classifier, a K-nearest neighbors algorithm, a partial dependence plot, individual conditional expectation (ICE), an accumulated local effects (ALE) plot, feature interaction, permutation feature importance, a global surrogate model, a local surrogate (LIME) model, scoped rules, i.e., anchors, Shapley values, Shapley additive explanations (SHAP), feature visualization, network dissection, or any other suitable machine learning interpretability implementation. In some embodiments, the one or more model interpretability systems may include a model dataset visualization system. The model dataset visualization system is configured to automatically provide to a human user of the information technology system visual analysis related to distribution of values of the sensor data, the simulation data, and data nodes of the machine learning model 13702.

[0487] In some embodiments, the machine learning model 13702 may include and/or implement an embedded model interpretability system, such as a Bayesian case model (BCM) or glass box. The Bayesian case model uses Bayesian case-based reasoning, prototype classification, and clustering to facilitate human understanding of data such as the sensor data, the simulation data, and data nodes of the machine learning model 13702. In some embodiments, the model interpretability system may include and/or implement a glass box interpretability method, such as a Gaussian process, to facilitate human understanding of data such as the sensor data, the simulation data, and data nodes of the machine learning model 13702.

[0488] In some embodiments, the machine learning model 13702 may include and/or implement testing with concept activation vectors (TCAV). The TCAV allows the machine learning model 13702 to learn human-interpretable concepts, such as “running,” “not running,” “powered,” “not powered,” “robot,” “human,” “truck,” or “ship” from examples by a process including defining the concept, determining concept activation vectors, and calculating directional derivatives. By learning human-interpretable concepts, objects, states, etc., TCAV may allow the machine learning model 13702 to output useful information related to the transaction entities and data collected therefrom in a format that is readily understood by a human user of the information technology system.

[0489] In some embodiments, the machine learning model 13702 may be and/or include an artificial neural network, e.g. a connectionist system configured to “learn” to perform tasks by considering examples and without being explicitly programmed with task-specific rules. The machine learning model 13702 may be based on a collection of connected units and/or nodes that may act like artificial neurons that may in some ways emulate neurons in a biological brain. The units and/or nodes may each have one or more connections to other units and/or nodes. The units and/or nodes may be configured to transmit information, e.g. one or more signals, to other units and/or nodes, process signals received from other units and/or nodes, and forward processed signals to other units and/or nodes. One or more of the units and/or nodes and connections therebetween may have one or more numerical “weights” assigned. The assigned weights may be configured to facilitate learning, i.e., training, of the machine learning model 13702. The weights assigned weights may increase and/or decrease one or more signals between one or more units and/or nodes, and in some embodiments may have one or more thresholds associated with one or more of the weights. The one or more thresholds may be configured such that a signal is only sent between one or more units and/or nodes if a signal and/or aggregate signal crosses the threshold. In some embodiments, the units and/or nodes may be assigned to a plurality of layers, each of the layers having one or both of inputs and outputs. A first layer may be configured to receive training data, transform at least a portion of the training data, and transmit signals related to the training data and transformation thereof to a second layer. A final layer may be configured to output an estimate, conclusion, product, or other consequence of processing of one or more inputs by the machine learning model 13702. Each of the layers may perform one or more types of transformations, and one or more signals may pass through one or more of the layers one or more times. In some embodiments, the machine learning model 13702 may employ deep learning and being at least partially modeled and/or configured as a deep neural network, a deep belief network, a recurrent neural network, and/or a convolutional neural network, such as by being configured to include one or more hidden layers.

[0490] In some embodiments, the machine learning model 13702 may be and/or include a decision tree, e.g. a tree-based predictive model configured to identify one or more observations and determine one or more conclusions based on an input. The observations may be modeled as one or more “branches” of the decision tree, and the conclusions may be modeled as one or more “leaves” of the decision tree. In some embodiments, the decision tree may be a classification tree. the classification tree may include one or more leaves representing one or more class labels, and one or more branches representing one or more conjunctions of features configured to lead to the class labels. In some embodiments, the decision tree may be a regression tree. The regression tree may be configured such that one or more target variables may take continuous values.

[0491] In some embodiments, the machine learning model 13702 may be and/or include a support vector machine, e.g. a set of related supervised learning methods configured for use in one or both of classification and regression-based modeling of data. The support vector machine may be configured to predict whether a new example falls into one or more categories, the one or more categories being configured during training of the support vector machine.

[0492] In some embodiments, the machine learning model 13702 may be configured to perform regression analysis to determine and/or estimate a relationship between one or more inputs and one or more features of the one or more inputs. Regression analysis may include linear regression, wherein the machine learning model 13702 may calculate a single line to best fit input data according to one or more mathematical criteria.

[0493] In embodiments, inputs to the machine learning model 13702 (such as a regression model, Bayesian network, supervised model, or other type of model) may be tested, such as by using a set of testing data that is independent from the data set used for the creation and/or training of the machine learning model, such as to test the impact of various inputs to the accuracy of the model 13702. For example, inputs to the regression model may be removed, including single inputs, pairs of inputs, triplets, and the like, to determine whether the absence of inputs creates a material degradation of the success of the model 13702. This may assist with recognition of inputs that are in fact correlated (e.g., are linear combinations of the same underlying data), that are overlapping, or the like. Comparison of model success may help select among alternative input data sets that provide similar information, such as to identify the inputs (among several similar ones) that generate the least “noise” in the model, that provide the most impact on model effectiveness for the lowest cost, or the like. Thus, input variation and testing of the impact of input variation on model effectiveness may be used to prune or enhance model performance for any of the machine learning systems described throughout this disclosure.

[0494] In some embodiments, the machine learning model 13702 may be and/or include a Bayesian network. The Bayesian network may be a probabilistic graphical model configured to represent a set of random variables and conditional independence of the set of random variables. The Bayesian network may be configured to represent the random variables and conditional independence via a directed acyclic graph. The Bayesian network may include one or both of a dynamic Bayesian network and an influence diagram.

[0495] In some embodiments, the machine learning model 13702 may be defined via supervised learning, i.e., one or more algorithms configured to build a mathematical model of a set of training data containing one or more inputs and desired outputs. The training data may consist of a set of training examples, each of the training examples having one or more inputs and desired outputs, i.e., a supervisory signal. Each of the training examples may be represented in the machine learning model 13702 by an array and/or a vector, i.e., a feature vector. The training data may be represented in the machine learning model 13702 by a matrix. The machine learning model 13702 may learn one or more functions via iterative optimization of an objective function, thereby learning to predict an output associated with new inputs. Once optimized, the objective function may provide the machine learning model 13702 with the ability to accurately determine an output for inputs other than inputs included in the training data. In some embodiments, the machine learning model 13702 may be defined via one or more supervised learning algorithms such as active learning, statistical classification, regression analysis, and similarity learning. Active learning may include interactively querying, by the machine learning model 13702, a user and/or an information source to label new data points with desired outputs. Statistical classification may include identifying, by the machine learning model 13702, to which a set of subcategories, i.e., subpopulations, a new observation belongs based on a training set of data containing observations having known categories. Regression analysis may include estimating, by the machine learning model 13702 relationships between a dependent variable, i.e., an outcome variable, and one or more independent variables, i.e., predictors, covariates, and/or features. Similarity learning may include learning, by the machine learning model 13702, from examples using a similarity function, the similarity function being designed to measure how similar or related two objects are.

[0496] In some embodiments, the machine learning model 13702 may be defined via unsupervised learning, i.e., one or more algorithms configured to build a mathematical model of a set of data containing only inputs by finding structure in the data such as grouping or clustering of data points. In some embodiments, the machine learning model 13702 may learn from test data, i.e., training data, that has not been labeled, classified, or categorized. The unsupervised learning algorithm may include identifying, by the machine learning model 13702, commonalities in the training data and learning by reacting based on the presence or absence of the identified commonalities in new pieces of data. In some embodiments, the machine learning model 13702 may generate one or more probability density functions. In some embodiments, the machine learning model 13702 may learn by performing cluster analysis, such as by assigning a set of observations into subsets, i.e., clusters, according to one or more predesignated criteria, such as according to a similarity metric of which internal compactness, separation, estimated density, and/or graph connectivity are factors.

[0497] In some embodiments, the machine learning model 13702 may be defined via semi-supervised learning, i.e., one or more algorithms using training data wherein some training examples may be missing training labels. The semi-supervised learning may be weakly supervised learning, wherein the training labels may be noisy, limited, and/or imprecise. The noisy, limited, and/or imprecise training labels may be cheaper and/or less labor intensive to produce, thus allowing the machine learning model 13702 to train on a larger set of training data for less cost and/or labor.

[0498] In some embodiments, the machine learning model 13702 may be defined via reinforcement learning, such as one or more algorithms using dynamic programming techniques such that the machine learning model 13702 may train by taking actions in an environment in order to maximize a cumulative reward. In some embodiments, the training data is represented as a Markov Decision Process.

[0499] In some embodiments, the machine learning model 13702 may be defined via self-learning, wherein the machine learning model 13702 is configured to train using training data with no external rewards and no external teaching, such as by employing a Crossbar Adaptive Array (CAA). The CAA may compute decisions about actions and/or emotions about consequence situations in a crossbar fashion, thereby driving teaching of the machine learning model 13702 by interactions between cognition and emotion.

[0500] In some embodiments, the machine learning model 13702 may be defined via feature learning, i.e., one or more algorithms designed to discover increasingly accurate and/or apt representations of one or more inputs provided during training, e.g. training data. Feature learning may include training via principal component analysis and/or cluster analysis. Feature learning algorithms may include attempting, by the machine learning model 13702, to preserve input training data while also transforming the input training data such that the transformed input training data is useful. In some embodiments, the machine learning model 13702 may be configured to transform the input training data prior to performing one or more classifications and/or predictions of the input training data. Thus, the machine learning model 13702 may be configured to reconstruct input training data from one or more unknown data-generating distributions without necessarily conforming to implausible configurations of the input training data according to the distributions. In some embodiments, the feature learning algorithm may be performed by the machine learning model 13702 in a supervised, unsupervised, or semi-supervised manner.

[0501] In some embodiments, the machine learning model 13702 may be defined via anomaly detection, i.e., by identifying rare and/or outlier instances of one or more items, events and/or observations. The rare and/or outlier instances may be identified by the instances differing significantly from patterns and/or properties of a majority of the training data. Unsupervised anomaly detection may include detecting of anomalies, by the machine learning model 13702, in an unlabeled training data set under an assumption that a majority of the training data is “normal.” Supervised anomaly detection may include training on a data set wherein at least a portion of the training data has been labeled as “normal” and/or “abnormal.”

[0502] In some embodiments, the machine learning model 13702 may be defined via robot learning. Robot learning may include generation, by the machine learning model 13702, of one or more curricula, the curricula being sequences of learning experiences, and cumulatively acquiring new skills via exploration guided by the machine learning model 13702 and social interaction with humans by the machine learning model 13702. Acquisition of new skills may be facilitated by one or more guidance mechanisms such as active learning, maturation, motor synergies, and/or imitation.

[0503] In some embodiments, the machine learning model 13702 can be defined via association rule learning. Association rule learning may include discovering relationships, by the machine learning model 13702, between variables in databases, in order to identify strong rules using some measure of “interestingness.” Association rule learning may include identifying, learning, and/or evolving rules to store, manipulate and/or apply knowledge. The machine learning model 13702 may be configured to learn by identifying and/or utilizing a set of relational rules, the relational rules collectively representing knowledge captured by the machine learning model 13702. Association rule learning may include one or more of learning classifier systems, inductive logic programming, and artificial immune systems. Learning classifier systems are algorithms that may combine a discovery component, such as one or more genetic algorithms, with a learning component, such as one or more algorithms for supervised learning, reinforcement learning, or unsupervised learning. Inductive logic programming may include rule-learning, by the machine learning model 13702, using logic programming to represent one or more of input examples, background knowledge, and hypothesis determined by the machine learning model 13702 during training. The machine learning model 13702 may be configured to derive a hypothesized logic program entailing all positive examples given an encoding of known background knowledge and a set of examples represented as a logical database of facts.

[0504] Referring to FIG. 138, a compliance system 13800 that facilitates the licensing of personality rights using a distributed ledger and cryptocurrency is depicted. As used herein, personality rights may refer to an entity's ability to control the use of his, her, or its identity for commercial purposes. The term entity, as used herein, may refer to an individual or an organization (e.g., a university, a school, a team, a corporation, or the like) that agrees to license its personality rights, unless context suggests otherwise. This may include an entity's ability to control the use of its name, image, likeness, voice, or the like. For example, an individual exercising their personality rights for commercial purposes may include appearing in a commercial, television show, or movie, making a sponsored social media post (e.g., Instagram post, Facebook post, Twitter tweet, or the like), having their name appear on clothing (e.g., a jersey, t-shirts, sweatshirts, or the like) or other goods, appearing in a video game, or the like. In embodiments, individuals may refer to student athletes or professional athletes, but may include other classes of individuals as well. While the current description makes reference to the NCAA, the system may be used to monitor and facilitate transactions relating to other individuals and organizations. For example, the system may be used in the context of professional sports, where organizations may use sponsorships and other licensing deals to circumvent salary caps or other league rules (e.g., FIFA fair play rules).

[0505] In embodiments, the compliance system 13800 maintains one or more digital ledgers that record transactions relating to the licensing of personality rights of entities. In embodiments, a digital ledger may be a distributed ledger that is distributed amongst a set of computing devices 13870, 13880, 13890 (also referred to as nodes) and/or may be encrypted. Put another way, each participating node may store a copy of the distributed ledger. An example of the digital ledger is a Blockchain ledger. In some embodiments, a distributed ledger is stored across a set of public nodes. In other embodiments, a distributed ledger is stored across a set of whitelisted participant nodes (e.g., on the servers of participating universities or teams). In some embodiments, the digital ledger is privately maintained by the compliance system 13800. The latter configuration provides a more energy efficient means of maintaining a digital ledger; while the former configurations (e.g., distributed ledgers) provide a more secure/verifiable means of maintaining a digital ledger.

[0506] In embodiments, a distributed ledger may store tokens. The tokens may be cryptocurrency tokens that are transferrable to licensors and licensees. In some embodiments, a distributed ledger may store the ownership data of each token. A token (or a portion thereof) may be owned by the compliance system, the governing organization (e.g., the NCAA), a licensor, a licensee, a team, an institution, an individual or the like. In embodiments, the distributed ledger may store event records. Event records may store information relating to events associated with the entities involved with the compliance system. For example, an event record may record an agreement entered into by two parties, the completion of an obligation by a licensor, the distribution of funds to a licensor from a license, the non-completion of an obligation by a licensor, the distribution of funds to entities associated with the licensee (e.g., teammates, institution, team, etc.), and the like.

[0507] In embodiments, the digital ledger may store smart contracts that govern agreements between licensors and licensees. As used herein, a licensee may be an organization or person that wishes to enter an agreement to license a licensor's personality rights. Examples of licensees may include, but are not limited to, a car dealership that wants a star student athlete to appear in a print ad, a company that wants the likeness of a licensor (e.g., an athlete and/or a team) to appear in a commercial, a video game maker that wants to use team names, team apparel, player names and/or numbers in a video game, a shoe maker that wants an athlete to endorse a sneaker, a television show producer that wants an athlete to appear in the television show, or the like. In embodiments, the compliance system 13800 generates a smart contract that memorializes an agreement between the individual and a licensee and facilitates the transfer of consideration (e.g., money) when the parties agree that the individual has performed his or her requirements as put forth in the agreement. For example, an athlete may agree to appear in a commercial on behalf of a local car dealership. The smart contract in this example may include an identifier of the athlete (e.g., an individual ID and/or an individual account ID), an identifier of the organization (e.g., an organization ID and/or an organization account ID), the requirements of the individual (e.g., to appear in a commercial, to make a sponsored social media post, to appear at an autograph signing, or the like), and the consideration (e.g., a monetary amount). In embodiments, the smart contract may include additional terms. In embodiments, the additional terms may include an allocation rule that defines a manner by which the consideration is allocated to the athlete and one or more other parties (e.g., agent, manager, university, team, teammates, or the like). For example, in the context of a student athlete, a smart contract may define a split between the licensing athlete, the athletic department of the student athlete's university, and the student athlete's teammates. In a specific example, a university may have a policy that requires a player appearing in any advertisement to split the funds according to a 60/20/20 split, whereby 60% of the funds are allocated to the student athlete appearing in the commercial, 20% of the funds are allocated to the athletic department, and 20% of the funds are allocated to the student athlete's teammates. When a smart contract verifies that the athlete has performed his or her duties with respect to the smart contract (e.g., appeared for the commercial), the smart contract can transfer the agreed upon amount from an account of the licensee to an account of the athlete and accounts of any other entities that may be allocated a percentage of the funds in the smart contract (e.g., athletic department and teammates).

[0508] In embodiments, the compliance system 13800 utilizes cryptocurrency to facilitate the transfer of funds. In embodiments, the cryptocurrency is mined by participant nodes and/or generated by the compliance system. The cryptocurrency can be an established type of cryptocurrency (e.g., Bitcoin, Ethereum, Litecoin, or the like) or may be a proprietary cryptocurrency. In some embodiments, the cryptocurrency is a pegged cryptocurrency that is pegged to a particular fiat currency (e.g., pegged to the US dollar. British Pound, Euro, or the like). For example, a single unit of cryptocurrency (also referred to as a “coin”) may be pegged to a single unit of fiat currency (e.g., a US dollar). In embodiments, a licensee may exchange fiat currency for a corresponding amount of cryptocurrency. For example, if the cryptocurrency is pegged to the dollar, the licensee may exchange an amount of US dollars for a corresponding amount of cryptocurrency. In embodiments, the compliance system 13800 may keep a percentage of the real-world currency as a transaction fee (e.g., 5%). For example, in exchanging $10,000, the compliance system 13800 may distribute $9,500 dollars' worth of cryptocurrency to an account of the licensee and may keep the $5,000 dollars as a transaction fee. Once the cryptocurrency is deposited in an account of a licensee, the licensee may enter into transactions with individuals.

[0509] In embodiments, the compliance system 13800 may allow organizations to create smart contract templates that define one or more conditions/restrictions on the contract. For example, an organization may predefine the allocation between the licensee, the organization, and any other individuals (e.g., coaches, teammates, representatives). Additionally or alternatively, the organization may place minimum and/or maximum amounts of agreements. Additionally or alternatively, the organization may place restrictions on when an agreement can be entered into and/or performed. For example, players may be restricted from appearing in commercials or advertisements during the season and/or during exam periods. These details may be stored in an organization datastore 13856A Organizations may place other conditions/restrictions in a smart contract. In these embodiments, an individual and licensee wishing to enter to an agreement must use a smart contract template provided by the organization to which the individual belongs. In other words, the compliance system 13800 may only allow an individual that has an active relationship with an organization (e.g., plays on a team of a university) to participate in a smart contract if the smart contract is defined by or otherwise approved by the organization.

[0510] In embodiments, the compliance system 13800 manages a clearinghouse process that approves potential licensees. Before a licensee can participate in agreements facilitated by the compliance system 13800, the licensee can provide information relating to the licensee. This may include a tax ID number, an entity name, incorporation information (e.g., state and type), a list of key personnel (e.g., directors, executives, board members, approved decision makers, and/or the like), and any other suitable information. In embodiments, the potential licensee may be required to sign (e.g., eSign or wet ink signature) a document indicating that the organization will not willingly use the compliance system 13800 to circumvent any rules, laws, or regulations (e.g., they will not circumvent NCAA regulations). In embodiments, the compliance system 13800 or another entity (e.g., the NCAA) may verify the licensee. Once verified, the information is stored in a licensee datastore 13856B and the licensee may participate in transactions.

[0511] In embodiments, the compliance system 13800 may create accounts for licensors once they have joined an organization (e.g., signed an athletic scholarship with a university). Once a licensor is verified as being affiliated with the organization, the compliance system 13800 may create an account for the licensor and may create a relationship between the individual and the organization, whereby the licensor may be required to use smart contracts that are approved or provided by the organization. Should the licensor join another organization (e.g., transfers to another school), the compliance system 13800 may sever the relationship with the previous organization and may create a new relationship with the other organization. Similarly, once a licensor is no longer affiliated with any organization (e.g., the player graduates, enters a professional league, retires, or the like), the compliance system 13800 may prevent the licensor from participating in transactions on the compliance system 13800.

[0512] In embodiments, the compliance system 13800 may provide a graphical user interface that allows users to create smart contracts governing personality rights licenses. In these embodiments, the compliance system allows a user (e.g., a licensor) to select a smart contract template. In some embodiments, the compliance system 13800 may restrict the user to only select a smart contract template that is associated with an institution of the licensor. In embodiments, the graphical user interface allows a user to define certain terms (e.g., the type or types of obligations placed on the licensor, an amount of funds to paid, a date by which the obligations of the licensor must be completed by, a location at which the obligation is completed, and/or other suitable terms). Upon a user providing input for parameterizing a smart contract template, the compliance system 13800 may generate a smart contract by parameterizing one or more variables in the smart contract with the provided input. Upon parameterizing an instance of a smart contract, the compliance system 13800 may deploy the smart contract. In some embodiments, the compliance system 13800 may deploy the smart contract by broadcasting the parameterized smart contract to the participant nodes, which in turn may update each respective instance of the distributed ledger with the new smart contract. In some embodiments, an institution of the licensor must approve the parameterized smart contract before the parameterized smart contract may be deployed to the distributed ledger.

[0513] In embodiments, the compliance system 13800 may provide a graphical user interface to verify performance of an obligation by a licensor. In some of these embodiments, the compliance system 13800 may include an application that is accessed by licensors, that allows a licensor to prove that he or she performed an obligation. In some of these embodiments, the application may allow a user to record locations that the licensor went to (e.g., locations of film or photo shoots), to upload records (e.g., screen shots of social media posts) or to provide other corroborating evidence that the licensor has performed his or her obligations with respect to a licensing transaction. In this way, the licensor can prove that he or she performed the tasks required by the licensing deal. In some embodiments, the application may interact with a wearable device or may capture other digital exhaust, such as social media posts of the user (e.g., licensor) to collect evidence that supports or disproves a licensor's claim that he or she performed the obligations under the transaction agreement. In embodiments, the corroborating evidence collected by the application may be recorded by the application and stored on the distributed ledger as a licensor datastore 13856C.

[0514] In embodiments, the compliance system 13800 (or a smart contract issued in connection with the compliance system 13800) may complete transactions pertaining to a smart contract governing the licensing of the personality rights of a licensor upon verification that licensor has performed his or her obligations defined in the agreement. As mentioned, the licensor may use an application to provide evidence of satisfaction of the obligations of the agreement. Additionally or alternatively, the licensee may provide verification that the licensor has performed his or her obligations (e.g., using an application). In embodiments, the smart contract governing the agreement may receive verification that the licensor has performed his or her obligations defined by the agreement. In response the smart contract may release (or initiate the release of) the cryptocurrency amount defined in the smart contract. The cryptocurrency amount may be distributed to the accounts of the licensor and any other parties defined in the agreement (e.g., teammates of the licensor, the program of the licensor, the regulating body, or the like).

[0515] In embodiments, the compliance system 13800 is configured to perform analytics and provide reports to a regulatory body and/or other entities (e.g., the other organizations). In these embodiments, the analytics may be used to identify individuals that are potentially circumventing the rules and regulations of the regulatory body. Furthermore, in some embodiments, transaction records may be maintained on a distributed ledger, whereby different organizations may be able to view agreements entered into by individuals affiliated with other organizations such that added levels of transparency and oversight may disincentivize individuals, organizations, and/or licensees from circumventing rules and regulations.

[0516] In embodiments, the compliance system 13800 may train and/or leverage machine-learned models to identify potential instances of circumvention of rules or regulations. In these embodiments, the compliance system 13800 may train machine-learned models using outcome data. Examples of outcome data may include data relating to a set of transactions where an organization (e.g., a team or university), licensee (e.g., a company), and/or licensor (e.g., an athlete) were determined to be circumventing rules or regulations and data relating to a set of transactions where an organization, licensee, and/or licensor were found to be in compliance with the rules and regulations. Examples of machine-learned models include neural networks, regression-based models, decisions trees, random forests, Hidden Markov Models, Bayesian Models, and the like. In embodiments, the compliance system 13800 may leverage a machine-learned model by obtaining a set of records relating to transactions a licensee, a licensor, and/or an organization (e.g., a team or university) from the distributed ledger. The compliance system may extract relevant features, such as the amount paid to a particular licensor by a licensee, amounts paid to other licensors on other teams, affiliations of the licensor, amounts paid to a licensor by other licensees, and the like, and may feed the features to the machine-learned model. The machine-learned model may issue a score that indicates a likelihood that the transaction was legitimate (or illegitimate) based on the extracted features. In embodiments, the compliance system 13800 may provide notifications to relevant parties (e.g., regulators) when the output of a machine-learned model indicates that a transaction was likely illegitimate.

[0517] FIG. 139 illustrates an example system 13900 configured for electronically facilitating licensing of one or more personality rights of a licensor, in accordance with some embodiments of the present disclosure. In some embodiments, the system 13900 may include one or more computing platforms 13902. Computing platform(s) 13902 may be configured to communicate with one or more remote platforms 13904 according to a client/server architecture, a peer-to-peer architecture, and/or other architectures. Remote platform(s) 13904 may be configured to communicate with other remote platforms via computing platform(s) 13902 and/or according to a client/server architecture, a peer-to-peer architecture, and/or other architectures. Users may access system 13900 via remote platform(s) 13904.

[0518] In embodiments, computing platform(s) 13902 may be configured by machine-readable instructions 13906. Machine-readable instructions 13906 may include one or more instruction modules. The instruction modules may include computer program modules. The instruction modules may include one or more of an access module 13108, a fund management module 13112, a ledger management module 13116, a verification module 13118, an analytics module 13120, and/or other instruction modules.

[0519] In embodiments, the access module 13108 may be configured to receive an access request from a licensee to obtain approval to license personality rights from a set of available licensors. In embodiments, the access module 13108 may be configured to selectively grant access to the licensee based on the access request. For example, the access module 13108 may receive a name of a potential licensee (e.g., corporate name), a list of principals (e.g., executives and/or owners) of the potential licensee, a location of the licensee, affiliations of the licensee and the principals thereof, and the like. In embodiments, the access module 13108 may provide this information to a human that grants access and/or may feed this information into an artificial intelligence system that vets potential licensees. In embodiments, the access module 13108 is configured to selectively grant access to a licensor by verifying that the licensee is permitted to engage with a set of licensors including the licensor based on the set of affiliations. Selectively granting access to the licensor may include, in response to verifying that the licensee is permitted to engage with the set of licensors, granting the licensee approval to engage with the set of licensees. The set of affiliations of the licensee may include organizations to which the licensee or a principal associated with the licensee donates to or owns.

[0520] In embodiments, the fund management module 13112 may be configured to receive confirmation of a deposit of an amount of funds from the licensee. In some embodiments, the fund management module 13112 may be configured to issue an amount of cryptocurrency corresponding to the amount of funds deposited by the licensee to an account of the licensee. In embodiments, the fund management module 13112 may be configured to escrow the consideration amount of cryptocurrency from the account of the licensee until the funds are released by a smart contract.

[0521] In embodiments, the ledger management module 13116 may be configured to receive a smart contract request to create a smart contract governing the licensing of the one or more personality rights of the licensor by the licensee. In embodiments, the ledger management module 13116 may be configured to generate the smart contract based on the smart contract request. The smart contract may be generated using a smart contract template provided by an interested third party (e.g., a university, a governing body, or the like) and by one or more parameters provided by a user (e.g., the licensor, the team of the licensor, an institution, and/or licensee) By way of non-limiting example, the interested third party may be one of a university, a sports team, or a collegiate athletics governance organization. The smart contract request may indicate one or more terms including a consideration amount of cryptocurrency to be paid to the licensor in exchange for one or more obligations on the licensor. In embodiments, the ledger management module 13116 may be configured to deploy the smart contract to a distributed ledger. The distributed ledger may be auditable by a set of third parties, including the interested third party. The distributed ledger may be a public ledger. The distributed ledger may be a private ledger that is only hosted on computing devices associated with interested third parties. In embodiments, the distributed ledger may be a blockchain.

[0522] In embodiments, the verification module 13118 may be configured to verify that the licensor has performed the one or more obligation. In some embodiments, verifying that a licensor has performed the one or more obligations may include receiving location data from a wearable device associated with the licensor and verifying that the licensor has performed the one or more obligations based on the location data, whereby the location may be used to show that the licensor was at a particular location at a particular time (e.g., a photoshoot or a filming). In embodiments, verifying that the licensor may have performed the one or more obligations includes receiving social media data from a social media website and verifying that the licensor has performed the one or more obligations based on the social media data, whereby the social media data may be used to show that the licensor has made a required social media posting. In embodiments, verifying that the licensor may have performed the one or more obligations includes receiving media content from an external data source and verifying that the licensor has performed the one or more obligations based on the media content, whereby a licensor and/or licensee may upload the media content to prove that the licensor has appeared in the media content. By way of non-limiting example, the media content may be one of a video, a photograph, or an audio recording. In embodiments, the verification module 13118 may generate and output an event record to the participating nodes upon verifying that a licensor has performed its obligations. In embodiments, the verification module 13118 may generate and output an event record to the participating nodes that indicates that the compliance system 13100 has received corroborating evidence (e.g., social media data, location data, and/or media contents) that show that the licensor has performed his or her obligations. In embodiments, the verification module 13118 may be configured to output an event record indicating completion of a licensing transaction defined by the smart contract to the distributed ledger.

[0523] In embodiments, the verification module 13118 may be configured to verify, by the smart contract, that the licensor has performed the one or more obligations. In embodiments, the verification module 13118 and/or a smart contract may be configured to, in response to receiving verification that the licensor has performed the one or more obligations, release at least a portion of the consideration amount of cryptocurrency into a licensor account of the licensor. Releasing the at least a portion of the consideration amount of cryptocurrency into a licensee account of the licensee may include identifying an allocation smart contract associated with the licensee and distributing the consideration amount of the cryptocurrency in accordance with the allocation rules. By way of non-limiting example, the additional entities may include one or more of teammates of the licensor, coaches of the licensor, a team of the licensor, a university of the licensee, and a governing body (e.g., the NCAA).

[0524] In embodiments, an analytics module 13120 may be configured to obtain a set of records indicating completion of a set of respective transactions from the distributed ledger. The set of records may include the record indicating the completion of the transaction defined by the smart contract. In embodiments, the analytics module 13120 may be configured to determine whether an organization associated with the licensor is likely in violation of one or more regulations based on the set of records and a fraud detection model. The fraud detection model may be trained using training data that indicates permissible transactions and fraudulent transactions.

[0525] In some implementations, the allocation smart contract may define allocation rules governing a manner by which funds resulting from licensing the one or more personality rights are to be distributed amongst the licensor and one or more additional entities.

[0526] In some implementations, by way of non-limiting example, the regulations may be provided by one of NCAA, FIFA, NBA, MLB, NFL, MLS, NHL, and the like.

[0527] In some implementations, computing platform(s) 13902, remote platform(s) 13904, and/or external resources 13934 may be operatively linked via one or more electronic communication links. For example, such electronic communication links may be established, at least in part, via a network such as the Internet and/or other networks. It will be appreciated that this is not intended to be limiting, and that the scope of this disclosure includes implementations in which computing platform(s) 13902, remote platform(s) 13904, and/or external resources 13934 may be operatively linked via some other communication media.

[0528] A given remote platform 13904 may include one or more processors configured to execute computer program modules. The computer program modules may be configured to enable an expert or user associated with the given remote platform 13904 to interface with compliance system 13100 and/or external resources 13934, and/or provide other functionality attributed herein to remote platform(s). 13904. By way of non-limiting example, a given remote platform 13904 and/or a given computing platform 13902 may include one or more of a server, a desktop computer, a laptop computer, a handheld computer, a tablet computing platform, a Netbook, a Smartphone, a gaming console, and/or other computing platforms.

[0529] External resources 13934 may include sources of information outside of compliance system 13100, external entities participating with compliance system 13100, and/or other resources. In some implementations, some or all of the functionality attributed herein to external resources 13934 may be provided by resources included in compliance system 13100.

[0530] Computing platform(s) 202 may include electronic storage 13936, one or more processors 13938, and/or other components. Computing platform(s) 1202 may include communication lines, or ports to enable the exchange of information with a network and/or other computing platforms. Illustration of computing platform(s) 13902 in FIG. 139 is not intended to be limiting. Computing platform(s) 13902 may include a plurality of hardware, software, and/or firmware components operating together to provide the functionality attributed herein to computing platform(s) 13902. For example, computing platform(s) 13902 may be implemented by a cloud of computing platforms operating together as computing platform(s) 13902.

[0531] Electronic storage 13936 may comprise non-transitory storage media that electronically stores information. The electronic storage media of electronic storage 13936 may include one or both of system storage that is provided integrally (i.e., substantially non-removable) with computing platform(s) 13902 and/or removable storage that is removably connectable to computing platform(s) 13902 via, for example, a port (e.g., a USB port, a firewire port, etc.) or a drive (e.g., a disk drive, etc.). Electronic storage 13936 may include one or more of optically readable storage media (e.g., optical disks, etc.), magnetically readable storage media (e.g., magnetic tape, magnetic hard drive, floppy drive, etc.), electrical charge-based storage media (e.g., EEPROM, RAM, etc.), solid-state storage media (e.g., flash drive, etc.), and/or other electronically readable storage media. Electronic storage 13936 may include one or more virtual storage resources (e.g., cloud storage, a virtual private network, and/or other virtual storage resources). Electronic storage 13936 may store software algorithms, information determined by processor(s) 13938, information received from computing platform(s) 13902, information received from remote platform(s) 13904, and/or other information that enables computing platform(s) 13902 to function as described herein.

[0532] Processor(s) 13938 may be configured to provide information processing capabilities in computing platform(s) 13902. As such, processor(s) 13938 may include one or more of a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and/or other mechanisms for electronically processing information. Although processor(s) 13938 is shown in FIG. 139 as a single entity, this is for illustrative purposes only. In some implementations, processor(s) 13938 may include a plurality of processing units. These processing units may be physically located within the same device, or processor(s) 13938 may represent processing functionality of a plurality of devices operating in coordination. Processor(s) 13938 may be configured to execute modules 13108, 13112, 13116, 13118, 13120, and/or other modules. Processor(s) 13938 may be configured to execute modules 13108, 13112, 13116, 13118, 13120, and/or other modules by software; hardware; firmware; some combination of software, hardware, and/or firmware; and/or other mechanisms for configuring processing capabilities on processor(s) 13938. As used herein, the term “module” may refer to any component or set of components that perform the functionality attributed to the module. This may include one or more physical processors during execution of processor readable instructions, the processor readable instructions, circuitry, hardware, storage media, or any other components.

[0533] It should be appreciated that although modules 13108, 13112, 13116, 13118, and 13120 are illustrated in FIG. 139 as being implemented within a single processing unit, in implementations in which processor(s) 13938 includes multiple processing units, one or more of modules 13108, 13112, 13116, 13118, and 13120 may be implemented remotely from the other modules. The description of the functionality provided by the different modules 13108, 13112, 13116, 13118, and 13120 described below is for illustrative purposes, and is not intended to be limiting, as any of modules 13108, 13112, 13116, 13118, and/or 13120 may provide more or less functionality than is described. For example, one or more of modules 13108, 13112, 13116, 13118, and/or 13120 may be eliminated, and some or all of its functionality may be provided by other ones of modules 13108, 13112, 13116, 13118, and/or 13120. As another example, processor(s) 13938 may be configured to execute one or more additional modules that may perform some or all of the functionality attributed below to one of modules 13108, 13112, 13116, 13118, and/or 13120.

[0534] FIGS. 140 and/or 141 illustrates an example method 14000 for electronically facilitating licensing of one or more personality rights of a licensor, in accordance with some embodiments of the present disclosure. The operations of method 14000 presented below are intended to be illustrative. In some embodiments, method 14000 may be accomplished with one or more additional operations not described, and/or without one or more of the operations discussed. Additionally, the order in which the operations of method 14000 are illustrated in FIGS. 140 and/or 141 and described below is not intended to be limiting.

[0535] In some implementations, method 14000 may be implemented in one or more processing devices (e.g., a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and/or other mechanisms for electronically processing information). The one or more processing devices may include one or more devices executing some or all of the operations of method 14000 in response to instructions stored electronically on an electronic storage medium. The one or more processing devices may include one or more devices configured through hardware, firmware, and/or software to be specifically designed for execution of one or more of the operations of method 14000.

[0536] FIG. 140 illustrates method 14000, in accordance with one or more implementations of the present disclosure.

[0537] At 14002, the method includes receiving an access request from a licensee to obtain approval to license personality rights from a set of available licensors. Operation 14002 may be performed by one or more hardware processors configured by machine-readable instructions including a module that is the same as or similar to access module 13108, in accordance with one or more implementations.

[0538] At 14004, the method includes selectively granting access to the licensee based on the access request. Operation 14004 may be performed by one or more hardware processors configured by machine-readable instructions including a module that is the same as or similar to access module 13108, in accordance with one or more implementations.

[0539] At 14006, the method includes receiving confirmation of a deposit of an amount of funds from the licensee. Operation 14006 may be performed by one or more hardware processors configured by machine-readable instructions including a module that is the same as or similar to fund management module 13112, in accordance with one or more implementations.

[0540] At 14008, the method includes issuing an amount of cryptocurrency corresponding to the amount of funds deposited by the licensee to an account of the licensee. Operation 14008 may be performed by one or more hardware processors configured by machine-readable instructions including a module that is the same as or similar to fund management module 13112, in accordance with one or more implementations.

[0541] FIG. 141 illustrates method 14100, in accordance with one or more implementations of the present disclosure.

[0542] At 14122, the method includes receiving a smart contract request to create a smart contract governing the licensing of the one or more personality rights of the licensor by the licensee. The smart contract request may indicate one or more terms including a consideration amount of cryptocurrency to be paid to the licensor in exchange for one or more obligations on the licensor. Operation 14122 may be performed by one or more hardware processors configured by machine-readable instructions including a module that is the same as or similar to the ledger management module 13116, in accordance with one or more implementations.

[0543] At 14124, the method includes generating the smart contract based on the smart contract request. Operation 14124 may be performed by one or more hardware processors configured by machine-readable instructions including a module that is the same as or similar to ledger management module 13116, in accordance with one or more implementations.

[0544] At 14126, the method includes escrowing the consideration amount of cryptocurrency from the account of the licensee. Operation 14126 may be performed by one or more hardware processors configured by machine-readable instructions including a module that is the same as or similar to fund management module 13112, in accordance with one or more implementations.

[0545] At 14128, the method includes deploying the smart contract to a distributed ledger. Operation 14128 may be performed by one or more hardware processors configured by machine-readable instructions including a module that is the same as or similar to ledger management module 13116, in accordance with one or more implementations.

[0546] At 14130, the method includes verifying, by the smart contract, that the licensor has performed the one or more obligations. Operation 14130 may be performed by one or more hardware processors configured by machine-readable instructions including a module that is the same as or similar to verification module 13118, in accordance with one or more implementations.

[0547] At 14132, the method includes in response to receiving verification that the licensor has performed the one or more obligations, releasing at least a portion of the consideration amount of cryptocurrency into a licensor account of the licensor. Operation 14132 may be performed by one or more hardware processors configured by machine-readable instructions including a module that is the same as or similar to the verification module 13118, in accordance with one or more implementations.

[0548] At 14134, the method includes outputting a record indicating a completion of a licensing transaction defined by the smart contract to the distributed ledger. Operation 14134 may be performed by one or more hardware processors configured by machine-readable instructions including a module that is the same as or similar to the verification module 13118 and/or the ledger management module 13116, in accordance with one or more implementations.

[0549] FIG. 142 illustrates method 14200, in accordance with one or more implementations.

[0550] At 14202, the method includes obtaining a set of records indicating completion of a set of respective transactions from the distributed ledger. The set of records may include the record indicating the completion of the transaction defined by the smart contract. Operation 14202 may be performed by one or more hardware processors configured by machine-readable instructions including a module that is the same as or similar to the analytics module 13120, in accordance with one or more implementations.

[0551] At 14204, the method includes determining whether an organization associated with the licensor is likely in violation of one or more regulations based on the set of records and a fraud detection model. Operation 14204 may be performed by one or more hardware processors configured by machine-readable instructions including a module that is the same as or similar to the analytics module 13120, in accordance with one or more implementations.

[0552] Referring to FIG. 143, a computer-implemented method 14300 for selecting an AI solution for use in a robotic or automated process is depicted. The computer-implemented method may include receiving one or more functional media 14302. The functional media may include information indicative of brain activity of a worker engaged in a task to be automated. The functional media may be functional imaging, such an MRI, an FMRI, and the like from which an area of neocortex activity may be identified. The functional media may be an image, a video stream, an audio stream, and the like, from which a type of brain activity may be inferred. The functional media may be acquired while the worker is performing the work or while performing a simulation of the work, for example in an augmented reality, a virtual reality environment, or on a model of the equipment and/or environment. After being received, the functional media(s) are analyzed 14304 to identify an activity level in at least one brain region 14306. Based on the activity level, a brain region parameter and/or an activity parameter are identified 14308. The brain region parameter may represent a specific region of the neocortex such as frontal, parietal, occipital, and temporal lobes of the neocortex, including primary visual cortex and the primary auditory cortex, or subdivisions of the neocortex, including ventrolateral prefrontal cortex (Broca's area), and orbitofrontal cortex. The activity parameter may represent functional areas of the brain, such as visual processing, inductive reasoning, audio processing, olfactory processing, muscle control, and the like. An activity parameter may be representative of a type of activity in which the worker is engaged such as visual processing (looking) audio processing (listening), olfactory processing (smelling), motion activity, listening to the sound of the equipment, watching another negotiator, and the like. An activity level may be representative of a strength or level of activity, such as an extent of the brain region involved, a signal strength, whether a brain region is engaged or unengaged, and the like.

[0553] Based on one or more of the brain region parameter, the activity parameter, or the activity level, an action parameter may be identified 14310. An action parameter may provide additional information regarding the activity parameter. For example, activity parameter is indicative of motion, an action parameter may describe a range of motion, a speed of motion, a repetition of motion, a use of muscle memory, a smoothness of motion, a flow of motion, a timing of motion, and the like. Based on one or more of the brain region parameter, the activity parameter, or the activity level, a component to be incorporated in the final AI solution may be selected 14312. The component may include one or more of a model, an expert system, a neural network, and the like. After the component for the AI solution has been selected, configuration parameters may be determined 14314. The configuration parameters may be based, in part, on the type of component selected, the brain region parameter, the activity parameter, the activity level, or the action parameter. Configuring and configuration parameters may include selecting an input for a machine learning process, identifying an output to be provided by the machine learning process, identifying an input for an operational solution process 14316, identifying an output an operational solution process, tuning a learning parameter, identifying a change rates, identifying a weighting factor, identifying a parameter for inclusion, identifying a parameter for exclusion of a parameter, setting a threshold for input data, setting an output threshold for the operational robotic process, or setting a parameter threshold. Additionally, analysis of the functional media 14304 may include identifying a second brain region parameter or a second activity parameter 14318. The component of the AI solution may be revised 14320 based on the second brain region parameter or the second activity parameter. A second component of the AI solution may be selected 14322 based on the second brain region parameter or the second activity parameter. The final AI solution may be assembled from the component 14324 or the second component 14326. In embodiments, the final AI solution may be assembled from the component and the second components, optionally along with any standard or mandatory components that enable operation.

[0554] Referring to FIG. 144, a computer-implemented method 14400 for selecting an AI solution for use in a robotic or automated process is depicted. The method may include receiving a user-related input 14402 comprising a timestamp and analyzing the user-related input 14404. The user-related input may include an audio feed, a motion sensor, a video feed, a heartbeat monitor, an eye tracker, a biosensor (e.g., galvanic skin response), and the like. The analysis may enable the identification of a series of user actions and associated activity parameters 14406. A component for an AI solution may be selected based on a user action of the series of user actions 14408. The analysis may enable the identification of a second user action of the series of user actions 14410. Based on the second user action, the selected component for the AI solution may be revised 14412. A second component for the AI solution may be selected 14414 based on the second user action. An action parameter may be identified 14416 based on the user action and/or the associated activity parameters. For example, if the user action is motion, an action parameter may include a range of motion, a speed of motion, a repetition of motion, a use of muscle memory, a smoothness of motion, a flow of motion, a timing of motion, and the like. The selected component of the AI solution may be configured 14418 based on the action parameter. In embodiments, at least one device input performed by the user may be received (14420). The device input may be synchronized with the user actions based on the timestamp and a correlation between the device input and the user action determined 14419. The component may be revised 14423 based on the correlation. The selection of the component of the AI solution may be partially based on the correlation between the device input and the user-related input 14421. The AI solution may be assembled 14422 from the component. The AI solution may be assembled from the second component 14424. In embodiments, the AI may be assembled from both the component and the second component, optionally along with any standard or mandatory components that enable operation.

[0555] Referring to FIG. 145, an illustrative and non-limiting example of an assembled AI solution 14502 is shown. The assembled AI solution 14502 may include the selected component 14504 and a second selected component 14506, as well as other components 14508. Configuration data 14514 for the first selected component and configuration data 14512 for the second selected component may be provided. Runtime input data 14510 may be specified as part of the component configuration process. Components may be structured to run serially (such as the selected component 14504 and the second selected component 14506 which received input from the selected component 14504) or in parallel (such as the second component 14506 and the other component(s) 14508). Some of the components may provide input for other components (such as the selected component 14504 providing input to the second selected component 14506). Multiple components may provide various portions of the overall AI solution output 14518 (such as the second selected component 14506 and the other components 14508). This depiction is not meant to be limiting and the final solution may include a varying number of components, configuration data and input, as well as other components (e.g., sensors, voice modulators, and the like) and may be interconnected in a variety of configurations.

[0556] Referring to FIGS. 146-147, a computer-implemented method for selecting an AI solution for use in a robotic or automated process is depicted. The method may include receiving temporal biometric measurement data 14602 of a worker performing a task and receiving spatial-temporal environmental data 14604 experienced by the worker performing the task. Using the received data, a spatial-temporal activity pattern may be identified 14606. Based on the spatial-temporal activity pattern, an active area of the worker's neocortex may be identified 14608. A type of reasoning used when performing the task may be identified 14610 based on the active area of the neocortex and/or the biometric measurement data, or the spatial-temporal environmental data. A component may be selected 14612 for use in the AI solution to replicate the type of reasoning. The component of the AI solution may be configured 14614 based on the spatial-temporal environmental input. A determination may be made as to whether a serial or parallel AI solution is optimal 14616. A set of configuration inputs to the component may be identified 14618 and an ordered set of inputs to the component of the AI solution may be identified 14620. Training the machine may include providing various subsets of the spatial-temporal environmental input to determine appropriate input weightings and identify efficiencies from combinations of spatial-temporal environmental input 14622. Desirable or undesirable combinations of the spatial-temporal environmental data may also be identified 14624. Based on the identified required input, input environmental data may be processed to reduce input noise 14626 (e.g. improve signal to noise for a signal of interest), filtered to provide the appropriate input signals to the component, and the like.

[0557] Continuing with reference to FIG. 147, a second temporal biometric measurement data of the same worker performing the task may be received 14702 and a plurality of performed tasks identified from the biometric measurements 14704. A performance parameter may be extracted from the biometric measurements 14706 (e.g. worker heartrate, galvanic skin response, and the like). In some embodiments, the component may be configured based on the performance parameter 14707. In some embodiments, the second temporal biometric measurements may be provided to the configuration module as a training set 14709. Results data related to the task may be received 14708 and the second temporal biometric measurement data may be correlated with the received results data 14710. In some embodiments, the component may be selected based, at least in part, on the correlation 14711. A series of time intervals between each of the plurality of performed tasks may be identified 14712 and the component of the AI solution configured based on at least one of the time intervals 14714. For example, if the worker inspects an object for a long period of time before moving on to the next action, this may indicate complex visual processing as well as mental processing and may indicate that the corresponding component for the task be configured for in-depth, fine detail processing and the like.

[0558] Referring to FIG. 148, an AI solution selection and configuration system 14802 is depicted. An example selection and configuration system 14802 may include a media input module 14804 structured to receive user-related functional media 14814. The user-related functional media 14814 may include images of a person engaged in a task to be automated, audio recordings, video feeds, biometric data (e.g., heartbeat data, galvanic skin response data, and the like), motion data, and the like. A media analysis module 14806 may analyze the received media and identify an action parameter. The action parameter may be representative of a type of activity in which the person appears to be engaged such as watching, listening, moving, thinking, and the like. In some embodiments, the functional media is indicative of a type of brain activity of a human engaged in the task to be automated and the media analysis module 148206 identifies an activity level in at least one brain region and provide a brain region parameter corresponding with the activity level in the identified brain region. The media analysis module may also identify an activity parameter indicative of a level of engagement such as engaged, unengaged, level of activity, type of activity, and the like. A solution selection module 14808 may be structured to select at least one component of the AI solution for use in the automated process based, at least in part, on the action parameter, the brain region parameter, or the activity parameter. The brain region parameter or the action parameter may suggest a type of component to select and the activity parameter may suggest a level of processing required for that component. For example, an action parameter of watching would suggest selecting a component suited to visual processing. If the activity parameter was representative of olfactory procession, the input specification module may identify at least one chemical sensor as an input. If the activity parameter is representative of visual processing the input specification module 13116 may identify at least one visual sensor as a robotic input. In some embodiments, the visual sensor may be selected to be sensitive to a portion of the visible spectrum with wavelengths between about 380 to 700 nanometers. If the activity parameter is representative of auditory processing, the input specification module 13116 may identify at least one microphone as a robotic input. If the activity parameter was representative of a very high level of concentration, the solution selection module 14808 may suggest a level of processing that will be required, where the processing might occur, and the like. A component configuration module 14810 may configure the component 14812. Configuring the component may include: selecting an input for a machine learning process for the selected component, identifying an output to be provided by the machine learning process, identifying an input for an operational solution process, identifying an output an operational solution process, tuning a learning parameter, identifying a change rates, identifying a weighting factor, identifying a parameter for inclusion, identifying a parameter for exclusion of a parameter, setting a threshold for input data, setting an output threshold for the operational robotic process, setting a parameter threshold, and the like. A solution assembly module 14818 may assemble the final AI solution based on one or more selected components, configuration components, and required runtime. An input specification module 14816 may suggest input sources based on the selected component, the action parameter, brain region parameter, activity parameter, or the like.

[0559] Referring to FIG. 149, an AI solution selection and configuration system 14902 is depicted. An example selection system 14902 may include an image input module 14904 structured to receive functional images 14914 of the brain such as, such as functional MRI or other magnetic imaging, electroencephalogram (EEG), or other imaging, such as by identifying broad brain activity (e.g., wave bands of activity, such as delta, theta, alpha and gamma waves), by identifying a set of brain regions that are activated and/or inactive while the worker is performing one of the tasks to be automated. The image input module 14904 may provide a subset of the functional images 14914 to the image analysis module 14906. In some embodiments, the image input module 14904 may perform some preprocessing for the subset of functional images 14914, such as noise reduction, histogram adjustment, filtering, and the like, prior to providing the subset of functional images 14914 to the image analysis module 14906. The image analysis module 14906, may identify an activity level in at least one brain region and provide a brain region parameter based on the subset of functional images. The brain region parameter may represent a specific region of the neocortex such as frontal, parietal, occipital, and temporal lobes of the neocortex, including primary visual cortex and the primary auditory cortex, or subdivisions of the neocortex, including ventrolateral prefrontal cortex (Broca's area), and orbitofrontal cortex. The brain region parameter may represent functional areas of the brain, such as visual processing, inductive reasoning, audio processing, olfactory processing, muscle control, and the like. A solution selection module 14908 may select a component for use in an AI solution based on the brain region parameter, and provide input into a component configuration module (such as selecting an input for a machine learning process, identifying an output to be provided by the machine learning process, identifying an input for an operational solution process, identifying an output an operational solution process, tuning a learning parameter, identifying a change rates, identifying a weighting factor, identifying a parameter for inclusion, identifying a parameter for exclusion of a parameter, setting a threshold for input data, setting an output threshold for the operational robotic process, and setting a parameter threshold, and the like. The component configuration module 14910, may use the input to configure the component 14912. The solution selection module 14908 may also supply data to the input specification module 14916. A solution assembly module 14918 may combine the component, and other components, to create the AI solution. The AI solution may be set up to receive inputs as specified by the input specification module 14916. Although one iteration of selecting a component is shown in this figure, it is envisioned, that multiple components may be selected, configured and assembled as part of the AI solution

[0560] Referring to FIGS. 150-151, an AI solution selection and configuration system 15002 is depicted. An example AI solution selection and configuration system 15002 may include an input module 15004 structured to receive a variety of user-related input such as videos, audio recording, heartbeat monitors, galvanic skin response data, motion data, and the like. There may be temporal data associated with the user-related input. The input module 15004 may provide a subset of the user-related input data 15014 to the input analysis module 15006. The analysis module 15006 may include a temporal analysis module 15018 to identify timing of user-related actions. The temporal analysis module 15018 may enable identification of timing of user actions. In some embodiments the input module 15004 may perform some preprocessing for the subset of the user-related input data 15014, such as noise reduction, correlation between types of input data, and the like, prior to providing the subset of user-related input data 15014 to the input analysis module 15006. The input analysis module 15006, may identify a type of brain activity being engaged in (e.g. visual processing, auditory processing, olfactory processing, motion control, and the like) and a level of intensity of activity based on data such as heartbeat data, galvanic skin response data and the like. A component selection module 15008 may select a component for use in an AI solution based on the type of brain activity and provide input into a component configuration module 15010 which may include an ML input selection module 15102 for selecting an input for a machine learning process, an MP output identification module 15104 for identifying an output to be provided by the machine learning process, a runtime input selection module 15106 for identifying an input for an operational solution process, a runtime output identification module 15108 for identifying an output of the component, a settings module 15110 for identifying a change rate, identifying a weighting factor, setting a threshold for input data, setting an output threshold for the operational robotic process, and the like, a parameter settings module 15112 for tuning a learning parameter, identifying a parameter for inclusion, identifying a parameter for exclusion, setting a parameter threshold, and the like. The component configuration module 15010 may configure the selected component 15012. The component selection module 15008 may also supply data to the input specification module 15016. An AI solution assembly module 15020 may combine the configured component with other components, along with any standard or mandatory components, as necessary, to create the AI solution. The AI solution may be set up to receive inputs as specified by the input specification module 15016. Although one iteration of selecting a component is shown in this figure, it is envisioned, that multiple components may be selected, configured and assembled as part of the AI solution.

[0561] In embodiments, referring to FIG. 152, an AI solution selection and configuration system 15202 is depicted. An example AI solution selection and configuration system 15202 may include a data input module 15204 to receive an input stream including temporal user-related data 15214 which may include video streams, audio streams, equipment interactions (e.g. mouse clicks, mouse motion, physical input to a machine) user biometrics such as heartbeat, galvanic skin response, eye tracking, and the like. The data input module 15204 may also receive temporal environmental input data 15220 representative of environmental input the user is receiving such as a visual environment, an auditory environment, olfactory environment, equipment displays, a device user interface, and the like. The data input module 15204 may also receive temporal results input data 15203. The data input module 15204 may provide a subset of the received data 15214, 15220, 15203 to an input analysis module 15216. The data input module 15204 may process the received data 15214, 15220 15203 to reduce noise, compress the data, correlate some of the data, and the like. The analysis module 15216 may identify a plurality of user actions to provide to the component selection module 15208. The image analysis module 15216 may include a temporal analysis module 15218 to identify timing of user actions. The temporal analysis module 15218 may allow for the correlation between temporal user-related data 15214, environmental data 15220, and results data 15203. Based on the user actions, the component selection module 15208 may select a component that would simulate one or more mental processes of the user needed to perform at least one of the plurality of user actions. Factors in identifying the selected component may include the level of computational intensity needed, time sensitivity, and the like. This may dictate a type of component, a location of component (on-board, in the cloud, edge-computing, and the like. The input analysis module 15216 may also provide information regarding the user's actions and environmental data to the component configuration module 15210. This data may be used by the component configuration module as input to a machine learning algorithm, in conjunction with the results data to identify which inputs are beneficial and which are detrimental to enabling the component to reach desired results, and identify appropriate weighting of inputs, parameter settings, and the like. The component configuration module 15210 configures the component 15212 which is provided to the overall AI solution 15224 together with configuration information.

[0562] As described elsewhere herein, this disclosure concerns systems and methods for the discovery of opportunities for increased automation and intelligence, including solutions to domain-specific problems. Further, this disclosure also concerns selection and configuration of an artificial intelligence solution (e.g. neural networks, machine learning systems, expert systems, etc.) once opportunities are discovered.

[0563] Referring now to FIG. 153, a controller 15308 includes an opportunity mining module 153, an artificial intelligence configuration module 15304, and an artificial intelligence search engine 15310, optionally having a collaborative filter 15328 and a clustering engine 15330. The opportunity mining module 153 receives input 15302, such as attribute input regarding an attribute of a task, a domain, or a domain-related problem.

[0564] The input 15302 may be processed by the opportunity mining module 153 to determine whether an artificial intelligence system can be applied to the task or the domain. For example, the attribute input 15302 may include an attribute of a task, domain or problem, such as a negotiating task, a drafting task, a data entry task, an email response task, a data analysis task, a document review task, an equipment operation task, a forecasting task, an NLP task, an image recognition task, a pattern recognition task, a motion detection task, a route optimization task, and the like. The opportunity mining module 153 may determine if one or more attributes of the task are similar to other tasks that have been automated or to which an intelligence has been applied, or based on the attribute of the task, if the task is potentially automatable or suitable to have an intelligence applied to it regardless of whether it has been done previously. For example, attributes of a drafting task may include articulating a first idea, articulating a second idea, articulating a plurality of ideas, combining the plurality of ideas in a pairwise fashion, and combining the ideas in a triplicate fashion. Articulating ideas may not be suitable for automation, but the task of combining ideas pairwise or in triplicate form may be suitable for automation or to have an intelligence applied to the task.

[0565] If a determination is made that an artificial intelligence system can be applied to the task or the domain, the output 15312 regarding that determination may be used to trigger an artificial intelligence search engine 15310 to perform a search of an artificial intelligence store 157. The artificial intelligence store 157 may include a plurality of domain-specific and general artificial intelligence models 15318, and components of domain-specific and general artificial intelligence models 15318. The artificial intelligence store 157 may be organized by a category. The category may be at least one of an artificial intelligence model component type, a domain, an input type, a processing type, an output type, a computational requirement, a computational capability, a cost, a training status, or an energy usage. The artificial intelligence store may include at least one e-commerce feature. The at least one e-commerce feature may include at least one of a rating, a review, a link to relevant content, a mechanism for provisioning, a mechanism for licensing, a mechanism for delivery, or a mechanism for payment. Models 15318 may be pre-trained, or may be available for training. Components of domain-specific and general artificial intelligence models 15318 may include artificial intelligence building blocks, such as a component that detects and translates between languages, or a component that delivers highly personalized customer recommendations. One or more models 15318 and/or components of a model 15318 may be identified in a search of the artificial intelligence store 157. Components of a model 15318 may be identified either as a stand-alone element to be used in the assembly of a custom AI model 15318 or as a component of a complete, optionally pre-trained, model 15318.

[0566] The artificial intelligence store 157 may include metadata 15324 or other descriptive material indicating a suitability of an artificial intelligence system for at least one of solving a particular type of problem or operating on domain-specific inputs, data, or other entities. The metadata 15324, or other descriptive material, category, or e-commerce feature may be searched using the attribute input 15302 and/or other selection criteria 15314. For example, attributes of a task involving 2D object classification may be searched in the artificial intelligence store 157 and its metadata 15324 to reveal that an artificial intelligence model 15318 suitable for a task involving 2D object classification may be a convolutional neural network. Continuing with the example, there may be model diversity even within the class of convolutional neural networks (CNN) in the artificial intelligence store 157, such as a CNN calibrated to a certain type of 2D object recognition (e.g., straight edges) and another CNN calibrated to another kind of 2D object recognition (e.g., combo of curved and straight edges). In this example, if the further edge vs. curved attribute of the type of 2D object is searched, the artificial intelligence store 157 would present the CNN best suited to the 2D object to be classified.

[0567] In embodiments, in addition to the input 15302, at least one selection criteria 15314 may be used by the artificial intelligence search engine 15310 to search the artificial intelligence store 157 for artificial intelligence models 15318 and/or components thereof. Selection criteria used in the recommendation of an artificial intelligence model 15318 or model component may include at least one of if the model is pre-trained or not, an availability of the at least one artificial intelligence model 15318 or component thereof to execute in a user environment, an availability of the at least one artificial intelligence model 15318 or component thereof to a user, a governance principle, a governance policy, a computational factor, a network factor, a data availability, a task-specific factor, a performance factor, a quality of service factor, a model deployment consideration, a security consideration, or a human interface, which may be elsewhere described herein. For example, a governance principle, such as a requirement for an anti-bias review of pedestrian accident-avoidance systems, may be used to search an artificial intelligence store 157 for artificial intelligence models to apply to an autonomous driving task. In another example, a selection criteria for an artificial intelligence solution to be used with air traffic control system may be a requirement for having been trained on adversarial attacks and deceptive input. In yet another example, a selection criteria for an artificial intelligence solution to be used with an equities trading task may be the requirement for human oversight, and particularly, human-based final decisions.

[0568] The artificial intelligence search engine 15310 may rank one or more results of the search according to a strength or a weakness of the at least one artificial intelligence model 15318 or model component relative to the at least one selection criteria 15314. The ranked search results may be presented to a user for evaluation and consideration, and ultimately, selection. In embodiments, the artificial intelligence search engine 15310 may further include a collaborative filter 15328 that receives an indication of an element of the at least one artificial intelligence model 15318 or model component from a user that is used to filter the search results. In embodiments, the artificial intelligence search engine 15310 may further include a clustering engine 15330 structured to cluster search results comprising the at least one artificial intelligence model 15318 or model component. The clustering engine 15330 may be at least one of a similarity matrix or a k-means clustering. The clustering engine 15330 may associate at least one of similar developers, similar domain-specific problems, or similar artificial intelligence solutions in the search results.

[0569] Once an artificial intelligence model 15318 or components thereof are identified by the artificial intelligence search engine 15310, either by searching with the input 15302 alone or with both the input 15302 and a selection criteria 15314, an artificial intelligence configuration module 15304 may configure one or more data inputs 15320 to use with the at least one artificial intelligence model 15318 or model component. The artificial intelligence configuration module 15304 may, in certain embodiments, be operative in discovering and selecting what inputs 15320 may enable effective and efficient use of artificial intelligence for a given problem. In embodiments, the artificial intelligence configuration module 15304 may further configure the at least one artificial intelligence model 15318 or model component(s) in accordance with at least one configuration criteria 15322. In embodiments, individual data inputs and model components may be configured via one or more configuration criteria, while in other embodiments, a single configuration criteria governs configuration of data input, AI component assembly, and the like.

[0570] In embodiments, the at least one configuration criteria 15322 may include at least one of an availability of the at least one artificial intelligence model 15318 or model component to execute in a user environment, an availability of the at least one artificial intelligence model 15318 or model component to a user, a governance principle, a governance policy, a computational factor, a network factor, a data availability, a task-specific factor, a performance factor, a quality of service factor, a model deployment consideration, a security consideration, or a human interface. In embodiments, the at least one configuration criteria may include at least one of identifying a desired output, identifying training data, identifying parameters for exclusion or inclusion in training or operation of the model, an input data threshold, an output data threshold, a selection of a neural network type, a selection of an input model type, a setting of initial model weights, a setting of model size, a selection of computational deployment environment, a selection of input data sources for training, a selection of input data sources for operation, a selection of feedback function/outcome measures, a selection of data integration language(s) for inputs and outputs, a configuration of APIs for model training, a configuration of APIs 13114 for model inputs, a configuration of APIs 13114 for outputs, a configuration of access controls, a configuration of security parameters, a configuration of network protocols, a configuration of storage parameters, a configuration of economic factors, a configuration of data flows, a configuration of high availability, one or more fault tolerance environments, a price-based data acquisition strategy, a heuristic method, a decision to make a decision model, or a coordination of massively parallel decision making environments. In embodiments, the at least one configuration criteria may include parameters for assembly of an AI solution from a plurality of identified model components, optionally along with other standard or mandatory model components. For example, the model components may be configured to run in parallel, to run serially, or in a combination of serial and parallel.

[0571] For example, the artificial intelligence configuration module 15304 may configure an artificial intelligence model 15318 to weight one data input 15320 more heavily than another. For example, in the rain, an autonomous driving solution may weight input from a traction control system and a forward radar system more heavily than sensors targeted to increasing fuel efficiency, such as sensors measuring road slope and vehicle speed. After the rain, the weighting may be reversed.

[0572] In another example, the artificial intelligence configuration module 15304 may configure an artificial intelligence model 15318 to operate within certain thresholds of data input 15320. For example, an artificial intelligence model 15318 may be used in a combinatorial drafting task. When only two articulated ideas are provided to the model 15318, the model 15318 may not be triggered to operate. However, once the model 15318 receives a third articulated idea, its combinatorial processing of articulated ideas may commence.

[0573] The artificial intelligence configuration module 15304 may configure which sensors to use as data input 15320, how frequently to sample data, how frequently to transmit output, the weighting of various data inputs 15320, thresholds to apply to data from data inputs 15320, whether an output of one component of the model 15318 is used as input to another component of the model 15318, an order of operation of the components of the model 15318, a positioning of a model component within a workflow of a model, and the like.

[0574] The artificial intelligence configuration module 15304 may configure an artificial intelligence model 15318 from one or more model components identified by the artificial intelligence search engine 15310. For example, if the search result consisted solely of model components, the AI configuration module 15304 may configure where to place the identified 127 components in relation to one another, such as in a workflow or data flow, as well as in relation to other components that may be required for the model 15318 to function.

[0575] In embodiments, an artificial intelligence store 157 may include a set of interfaces to artificial intelligence systems, such as enabling the download of relevant artificial intelligence applications, establishment of links or other connections to artificial intelligence systems (such as links to cloud-deployed artificial intelligence systems via APIs, ports, connectors, or other interfaces) and the like.

[0576] Referring now to FIG. 154, a method of artificial intelligence model identification and selection may include receiving input regarding an attribute of a task or a domain 15402, and processing the input to determine whether an artificial intelligence system can be applied to the task or the domain 15404, performing a search of an artificial intelligence store of a plurality of domain-specific and general artificial intelligence models and model components using the input and/or at least one selection criteria to identify at least one artificial intelligence model or model component to apply to the task or the domain 15408, and configuring one or more data inputs to use with the at least one artificial intelligence model 15410 or model component. The artificial intelligence store may include metadata or other descriptive material indicating a suitability of an artificial intelligence system for at least one of solving a particular type of problem or operating on domain-specific inputs, data, or other entities.

[0577] The method may further include ranking one or more results of the search according to a strength or a weakness of the at least one artificial intelligence model relative to the at least one selection criteria 15412. The method may further include configuring the at least one artificial intelligence model or model component in accordance with at least one configuration criteria 15414. The method may further include collaborative filtering search results comprising the at least one artificial intelligence model using an element of the at least one artificial intelligence model selected or model component by a user 15416. The method may further include clustering search results comprising the at least one artificial intelligence model or model component with a clustering engine 15418.

[0578] FIG. 155 illustrates an example environment of a digital twin system 15500. In embodiments, the digital twin system 15500 generates a set of digital twins of a set of industrial environments 15520 and/or industrial entities within the set of industrial environments. In embodiments, the digital twin system 15500 maintains a set of states of the respective industrial environments 15520, such as using sensor data obtained from respective sensor systems 15530 that monitor the industrial environments 15520. In embodiments, the digital twin system 15500 may include a digital twin management system 15502, a digital twin I/O system 15504, a digital twin simulation system 15506, a digital twin dynamic model system 15508, a cognitive intelligence system 15510, and/or an environment control module 15512. In embodiments, the digital twin system 15500 may provide a real time sensor API that provides a set of capabilities for enabling a set of interfaces for the sensors of the respective sensor systems 15530. In embodiments, the digital twin system 15500 may include and/or employ other suitable APIs, brokers, connectors, bridges, gateways, hubs, ports, routers, switches, data integration systems, peer-to-peer systems, and the like to facilitate the transferring of data to and from the digital twin system 15500. In these embodiments, these connective components may allow an IoT sensor or an intermediary device (e.g., a relay, an edge device, a switch, or the like) within a sensor system 15530 to communicate data to the digital twin system 15500 and/or to receive data (e.g., configuration data, control data, or the like) from the digital twin system 15500 or another external system. In embodiments, the digital twin system 15500 may further include a digital twin datastore 15516 that stores digital twins 15518 of various industrial environments 15520 and the objects 15522, devices 15524, sensors 15526, and/or humans 15528 in the environment 15520.

[0579] A digital twin may refer to a digital representation of one or more industrial entities, such as an industrial environment 15520, a physical object 15522, a device 15524, a sensor 15526, a human 15528, or any combination thereof. Examples of industrial environments 15520 include, but are not limited to, a factory, a power plant, a food production facility (which may include an inspection facility), a commercial kitchen, an indoor growing facility, a natural resources excavation site (e.g., a mine, an oil field, etc.), and the like. Depending on the type of environment, the types of objects, devices, and sensors that are found in the environments will differ. Non-limiting examples of physical objects 15522 include raw materials, manufactured products, excavated materials, containers (e.g., boxes, dumpsters, cooling towers, vats, pallets, barrels, palates, bins, and the like), furniture (e.g., tables, counters, workstations, shelving, etc.), and the like. Non-limiting examples of devices 15524 include robots, computers, vehicles (e.g., cars, trucks, tankers, trains, forklifts, cranes, etc.), machinery/equipment (e.g., tractors, tillers, drills, presses, assembly lines, conveyor belts, etc.), and the like. The sensors 15526 may be any sensor devices and/or sensor aggregation devices that are found in a sensor system 15530 within an environment. Non-limiting examples of sensors 15526 that may be implemented in a sensor system 15530 may include temperature sensors 15532, humidity sensors 15534, vibration sensors 15536, LIDAR sensors 15538, motion sensors 15540, chemical sensors 15542, audio sensors 15544, pressure sensors 15546, weight sensors 15548, radiation sensors 15550, video sensors 15552, wearable devices 15554, relays 15556, edge devices 15558, crosspoint switches 15560, and/or any other suitable sensors. Examples of different types of physical objects 15522, devices 15524, sensors 15526, and environments 15520 are referenced throughout the disclosure.

[0580] In some embodiments, on-device sensor fusion and data storage for industrial IoT devices is supported, including on-device sensor fusion and data storage for an industrial IoT device, where data from multiple sensors is multiplexed at the device for storage of a fused data stream. For example, pressure and temperature data may be multiplexed into a data stream that combines pressure and temperature in a time series, such as in a byte-like structure (where time, pressure, and temperature are bytes in a data structure, so that pressure and temperature remain linked in time, without requiring separate processing of the streams by outside systems), or by adding, dividing, multiplying, subtracting, or the like, such that the fused data can be stored on the device. Any of the sensor data types described throughout this disclosure, including vibration data, can be fused in this manner and stored in a local data pool, in storage, or on an IoT device, such as a data collector, a component of a machine, or the like.

[0581] In some embodiments, a set of digital twins may represent an entire organization, such as energy production organizations, oil and gas organizations, renewable energy production organizations, aerospace manufacturers, vehicle manufacturers, heavy equipment manufacturers, mining organizations, drilling organizations, offshore platform organizations, and the like. In these examples, the digital twins may include digital twins of one or more industrial facilities of the organization.

[0582] In embodiments, the digital twin management system 15502 generates digital twins. A digital twin may be comprised of (e.g., via reference) other digital twins. In this way, a discrete digital twin may be comprised of a set of other discrete digital twins. For example, a digital twin of a machine may include digital twins of sensors on the machine, digital twins of components that make up the machine, digital twins of other devices that are incorporated in or integrated with the machine (such as systems that provide inputs to the machine or take outputs from it), and/or digital twins of products or other items that are made by the machine. Taking this example one step further, a digital twin of an industrial facility (e.g., a factory) may include a digital twin representing the layout of the industrial facility, including the arrangement of physical assets and systems in or around the facility, as well as digital assets of the assets within the facility (e.g., the digital twin of the machine), as well as digital twins of storage areas in the facility, digital twins of humans collecting vibration measurements from machines throughout the facility, and the like. In this second example, the digital twin of the industrial facility may reference the embedded digital twins, which may then reference other digital twins embedded within those digital twins.

[0583] In some embodiments, a digital twin may represent abstract entities, such as workflows and/or processes, including inputs, outputs, sequences of steps, decision points, processing loops, and the like that make up such workflows and processes. For example, a digital twin may be a digital representation of a manufacturing process, a logistics workflow, an agricultural process, a mineral extraction process, or the like. In these embodiments, the digital twin may include references to the industrial entities that are included in the workflow or process. The digital twin of the manufacturing process may reflect the various stages of the process. In some of these embodiments, the digital twin system 15500 receives real-time data from the industrial facility (e.g., from a sensor system 15530 of the environment 15520) in which the manufacturing process takes place and reflects a current (or substantially current) state of the process in real-time.

[0584] In embodiments, the digital representation may include a set of data structures (e.g., classes) that collectively define a set of properties of a represented physical object 15522, device 15524, sensor 15526, or environment 15520 and/or possible behaviors thereof. For example, the set of properties of a physical object 15522 may include a type of the physical object, the dimensions of the object, the mass of the object, the density of the object, the material(s) of the object, the physical properties of the material(s), the surface of the physical object, the status of the physical object, a location of the physical object, identifiers of other digital twins contained within the object, and/or other suitable properties. Examples of behavior of a physical object may include a state of the physical object (e.g., a solid, liquid, or gas), a melting point of the physical object, a density of the physical object when in a liquid state, a viscosity of the physical object when in a liquid state, a freezing point of the physical object, a density of the physical object when in a solid state, a hardness of the physical object when in a solid state, the malleability of the physical object, the buoyancy of the physical object, the conductivity of the physical object, a burning point of the physical object, the manner by which humidity affects the physical object, the manner by which water or other liquids affect the physical object, a terminal velocity of the physical object, and the like. In another example, the set of properties of a device may include a type of the device, the dimensions of the device, the mass of the device, the density of the density of the device, the material(s) of the device, the physical properties of the material(s), the surface of the device, the output of the device, the status of the device, a location of the device, a trajectory of the device, vibration characteristics of the device, identifiers of other digital twins that the device is connected to and/or contains, and the like. Examples of the behaviors of a device may include a maximum acceleration of a device, a maximum speed of a device, ranges of motion of a device, a heating profile of a device, a cooling profile of a device, processes that are performed by the device, operations that are performed by the device, and the like. Example properties of an environment may include the dimensions of the environment, the boundaries of the environment, the temperature of the environment, the humidity of the environment, the airflow of the environment, the physical objects in the environment, currents of the environment (if a body of water), and the like. Examples of behaviors of an environment may include scientific laws that govern the environment, processes that are performed in the environment, rules or regulations that must be adhered to in the environment, and the like.

[0585] In embodiments, the properties of a digital twin may be adjusted. For example, the temperature of a digital twin, a humidity of a digital twin, the shape of a digital twin, the material of a digital twin, the dimensions of a digital twin, or any other suitable parameters may be adjusted. As the properties of the digital twin are adjusted, other properties may be affected as well. For example, if the temperature of an environment 15520 is increased, the pressure within the environment may increase as well, such as a pressure of a gas in accordance with the ideal gas law. In another example, if a digital twin of a subzero environment is increased to above freezing temperatures, the properties of an embedded twin of water in a solid state (i.e., ice) may change into a liquid state over time.

[0586] Digital twins may be represented in a number of different forms. In embodiments, a digital twin may be a visual digital twin that is rendered by a computing device, such that a human user can view digital representations of an environment 15520 and/or the physical objects 15522, devices 15524, and/or the sensors 15526 within an environment. In embodiments, the digital twin may be rendered and output to a display device. In some of these embodiments, the digital twin may be rendered in a graphical user interface, such that a user may interact with the digital twin. For example, a user may “drill down” on a particular element (e.g., a physical object or device) to view additional information regarding the element (e.g., a state of a physical object or device, properties of the physical object or device, or the like). In some embodiments, the digital twin may be rendered and output in a virtual reality display. For example, a user may view a 3D rendering of an environment (e.g., using monitor or a virtual reality headset). While doing so, the user may view/inspect digital twins of physical assets or devices in the environment.

[0587] In some embodiments, a data structure of the visual digital twins (i.e., digital twins that are configured to be displayed in a 2D or 3D manner) may include surfaces (e.g., splines, meshes, polygons meshes, or the like). In some embodiments, the surfaces may include texture data, shading information, and/or reflection data. In this way, a surface may be displayed in a more realistic manner. In some embodiments, such surfaces may be rendered by a visualization engine (not shown) when the digital twin is within a field of view and/or when existing in a larger digital twin (e.g., a digital twin of an industrial environment). In these embodiments, the digital twin system 15500 may render the surfaces of digital objects, whereby a rendered digital twin may be depicted as a set of adjoined surfaces.

[0588] In embodiments, a user may provide input that controls one or more properties of a digital twin via a graphical user interface. For example, a user may provide input that changes a property of a digital twin. In response, the digital twin system 15500 can calculate the effects of the changed property and may update the digital twin and any other digital twins affected by the change of the property.

[0589] In embodiments, a user may view processes being performed with respect to one or more digital twins (e.g., manufacturing of a product, extracting minerals from a mine or well, a livestock inspection line, and the like). In these embodiments, a user may view the entire process or specific steps within a process.

[0590] In some embodiments, a digital twin (and any digital twins embedded therein) may be represented in a non-visual representation (or “data representation”). In these embodiments, a digital twin and any embedded digital twins exist in a binary representation but the relationships between the digital twins are maintained. For example, in embodiments, each digital twin and/or the components thereof may be represented by a set of physical dimensions that define a shape of the digital twin (or component thereof). Furthermore, the data structure embodying the digital twin may include a location of the digital twin. In some embodiments, the location of the digital twin may be provided in a set of coordinates. For example, a digital twin of an industrial environment may be defined with respect to a coordinate space (e.g., a Cartesian coordinate space, a polar coordinate space, or the like). In embodiments, embedded digital twins may be represented as a set of one or more ordered triples (e.g., [x coordinate, y coordinate, z coordinates] or other vector-based representations). In some of these embodiments, each ordered triple may represent a location of a specific point (e.g., center point, top point, bottom point, or the like) on the industrial entity (e.g., object, device, or sensor) in relation to the environment in which the industrial entity resides. In some embodiments, a data structure of a digital twin may include a vector that indicates a motion of the digital twin with respect to the environment. For example, fluids (e.g., liquids or gasses) or solids may be represented by a vector that indicates a velocity (e.g., direction and magnitude of speed) of the entity represented by the digital twin. In embodiments, a vector within a twin may represent a microscopic subcomponent, such as a particle within a fluid, and a digital twin may represent physical properties, such as displacement, velocity, acceleration, momentum, kinetic energy, vibrational characteristics, thermal properties, electromagnetic properties, and the like.

[0591] In some embodiments, a set of two or more digital twins may be represented by a graph database that includes nodes and edges that connect the nodes. In some implementations, an edge may represent a spatial relationship (e.g., “abuts”, “rests upon”, “contains”, and the like). In these embodiments, each node in the graph database represents a digital twin of an entity (e.g., an industrial entity) and may include the data structure defining the digital twin. In these embodiments, each edge in the graph database may represent a relationship between two entities represented by connected nodes. In some implementations, an edge may represent a spatial relationship (e.g., “abuts”, “rests upon”, “interlocks with”, “bears”, “contains”, and the like). In embodiments, various types of data may be stored in a node or an edge. In embodiments, a node may store property data, state data, and/or metadata relating to a facility, system, subsystem, and/or component. Types of property data and state data will differ based on the entity represented by a node. For example, a node representing a robot may include property data that indicates a material of the robot, the dimensions of the robot (or components thereof), a mass of the robot, and the like. In this example, the state data of the robot may include a current pose of the robot, a location of the robot, and the like. In embodiments, an edge may store relationship data and metadata data relating to a relationship between two nodes. Examples of relationship data may include the nature of the relationship, whether the relationship is permanent (e.g., a fixed component would have a permanent relationship with the structure to which it is attached or resting on), and the like. In embodiments, an edge may include metadata concerning the relationship between two entities. For example, if a product was produced on an assembly line, one relationship that may be documented between a digital twin of the product and the assembly line may be “created by”. In these embodiments, an example edge representing the “created by” relationship may include a timestamp indicating a date and time that the product was created. In another example, a sensor may take measurements relating to a state of a device, whereby one relationship between the sensor and the device may include “measured” and may define a measurement type that is measured by the sensor. In this example, the metadata stored in an edge may include a list of N measurements taken and a timestamp of each respective measurement. In this way, temporal data relating to the nature of the relationship between two entities may be maintained, thereby allowing for an analytics engine, machine-learning engine, and/or visualization engine to leverage such temporal relationship data, such as by aligning disparate data sets with a series of points in time, such as to facilitate cause-and-effect analysis used for prediction systems.

[0592] In some embodiments, a graph database may be implemented in a hierarchical manner, such that the graph database relates a set of facilities, systems, and components. For example, a digital twin of a manufacturing environment may include a node representing the manufacturing environment. The graph database may further include nodes representing various systems within the manufacturing environment, such as nodes representing an HVAC system, a lighting system, a manufacturing system, and the like, all of which may connect to the node representing the manufacturing system. In this example, each of the systems may further connect to various subsystems and/or components of the system. For example, within the HVAC system, the HVAC system may connect to a subsystem node representing a cooling system of the facility, a second subsystem node representing a heating system of the facility, a third subsystem node representing the fan system of the facility, and one or more nodes representing a thermostat of the facility (or multiple thermostats). Carrying this example further, the subsystem nodes and/or component nodes may connect to lower level nodes, which may include subsystem nodes and/or component nodes. For example, the subsystem node representing the cooling subsystem may be connected to a component node representing an air conditioner unit. Similarly, a component node representing a thermostat device may connect to one or more component nodes representing various sensors (e.g., temperature sensors, humidity sensors, and the like).

[0593] In embodiments where a graph database is implemented, a graph database may relate to a single environment or may represent a larger enterprise. In the latter scenario, a company may have various manufacturing and distribution facilities. In these embodiments, an enterprise node representing the enterprise may connect to environment nodes of each respective facility. In this way, the digital twin system 15500 may maintain digital twins for multiple industrial facilities of an enterprise.

[0594] In embodiments, the digital twin system 15500 may use a graph database to generate a digital twin that may be rendered and displayed and/or may be represented in a data representation. In the former scenario, the digital twin system 15500 may receive a request to render a digital twin, whereby the request includes one or more parameters that are indicative of a view that will be depicted. For example, the one or more parameters may indicate an industrial environment to be depicted and the type of rendering (e.g., “real-world view” that depicts the environment as a human would see it, an “infrared view” that depicts objects as a function of their respective temperature, an “airflow view” that depicts the airflow in a digital twin, or the like). In response, the digital twin system 15500 may traverse a graph database and may determine a configuration of the environment to be depicted based on the nodes in the graph database that are related (either directly or through a lower level node) to the environment node of the environment and the edges that define the relationships between the related nodes. Upon determining a configuration, the digital twin system 15500 may identify the surfaces that are to be depicted and may render those surfaces. The digital twin system 15500 may then render the requested digital twin by connecting the surfaces in accordance with the configuration. The rendered digital twin may then be output to a viewing device (e.g., VR headset, monitor, or the like). In some scenarios, the digital twin system 15500 may receive real-time sensor data from a sensor system 15530 of an environment 15520 and may update the visual digital twin based on the sensor data. For example, the digital twin system 1550 may receive sensor data (e.g., vibration data from a vibration sensor 15536) relating to a motor and its set of bearings. Based on the sensor data, the digital twin system 15500 may update the visual digital twin to indicate the approximate vibrational characteristics of the set of bearings within a digital twin of the motor.

[0595] In scenarios where the digital twin system 15500 is providing data representations of digital twins (e.g., for dynamic modeling, simulations, machine learning), the digital twin system 15500 may traverse a graph database and may determine a configuration of the environment to be depicted based on the nodes in the graph database that are related (either directly or through a lower level node) to the environment node of the environment and the edges that define the relationships between the related nodes. In some scenarios, the digital twin system 15500 may receive real-time sensor data from a sensor system 15530 of an environment 15520 and may apply one or more dynamic models to the digital twin based on the sensor data. In other scenarios, a data representation of a digital twin may be used to perform simulations, as is discussed in greater detail throughout the specification.

[0596] In some embodiments, the digital twin system 15500 may execute a digital ghost that is executed with respect to a digital twin of an industrial environment. In these embodiments, the digital ghost may monitor one or more sensors of a sensor system 15530 of an industrial environment to detect anomalies that may indicate a malicious virus or other security issues.

[0597] As discussed, the digital twin system 15500 may include a digital twin management system 15502, a digital twin I/O system 15504, a digital twin simulation system 15506, a digital twin dynamic model system 15508, a cognitive intelligence system 15510, and/or an environment control system 15512.

[0598] In embodiments, the digital twin management system 15502 creates new digital twins, maintains/updates existing digital twins, and/or renders digital twins. The digital twin management system 15502 may receive user input, uploaded data, and/or sensor data to create and maintain existing digital twins. Upon creating a new digital twin, the digital twin management system 15502 may store the digital twin in the digital twin datastore 15516. Creating, updating, and rendering digital twins are discussed in greater detail throughout the disclosure.

[0599] In embodiments, the digital twin I/O system 15504 receives input from various sources and outputs data to various recipients. In embodiments, the digital twin I/O system receives sensor data from one or more sensor systems 15530. In these embodiments, each sensor system 15530 may include one or more IoT sensors that output respective sensor data. Each sensor may be assigned an IP address or may have another suitable identifier. Each sensor may output sensor packets that include an identifier of the sensor and the sensor data. In some embodiments, the sensor packets may further include a timestamp indicating a time at which the sensor data was collected. In some embodiments, the digital twin I/O system 15504 may interface with a sensor system 15530 via the real-time sensor API 15514. In these embodiments, one or more devices (e.g., sensors, aggregators, edge devices) in the sensor system 15530 may transmit the sensor packets containing sensor data to the digital twin I/O system 15504 via the API. The digital twin I/O system may determine the sensor system 15530 that transmitted the sensor packets and the contents thereof, and may provide the sensor data and any other relevant data (e.g., time stamp, environment identifier/sensor system identifier, and the like) to the digital twin management system 15502.

[0600] In embodiments, the digital twin I/O system 15504 may receive imported data from one or more sources. For example, the digital twin system 15500 may provide a portal for users to create and manage their digital twins. In these embodiments, a user may upload one or more files (e.g., image files, LIDAR scans, blueprints, and the like) in connection with a new digital twin that is being created. In response, the digital twin I/O system 15504 may provide the imported data to the digital twin management system 15502. The digital twin I/O system 15504 may receive other suitable types of data without departing from the scope of the disclosure.

[0601] In some embodiments, the digital twin simulation system 15506 is configured to execute simulations using the digital twin. For example, the digital twin simulation system 15506 may iteratively adjust one or more parameters of a digital twin and/or one or more embedded digital twins. In embodiments, the digital twin simulation system 15506, for each set of parameters, executes a simulation based on the set of parameters and may collect the simulation outcome data resulting from the simulation. Put another way, the digital twin simulation system 15506 may collect the properties of the digital twin and the digital twins within or containing the digital twin used during the simulation as well as any outcomes stemming from the simulation. For example, in running a simulation on a digital twin of an indoor agricultural facility, the digital twin simulation system 15506 can vary the temperature, humidity, airflow, carbon dioxide and/or other relevant parameters and can execute simulations that output outcomes resulting from different combinations of the parameters. In another example, the digital twin simulation system 15506 may simulate the operation of a specific machine within an industrial facility that produces an output given a set of inputs. In some embodiments, the inputs may be varied to determine an effect of the inputs on the machine and the output thereof. In another example, the digital twin simulation system 15506 may simulate the vibration of a machine and/or machine components. In this example, the digital twin of the machine may include a set of operating parameters, interfaces, and capabilities of the machine. In some embodiments, the operating parameters may be varied to evaluate the effectiveness of the machine. The digital twin simulation system 15506 is discussed in further detail throughout the disclosure.

[0602] In embodiments, the digital twin dynamic model system 15508 is configured to model one or more behaviors with respect to a digital twin of an environment. In embodiments, the digital twin dynamic model system 15508 may receive a request to model a certain type of behavior regarding an environment or a process and may model that behavior using a dynamic model, the digital twin of the environment or process, and sensor data collected from one or more sensors that are monitoring the environment or process. For example, an operator of a machine having bearings may wish to model the vibration of the machine and bearings to determine whether the machine and/or bearings can withstand an increase in output. In this example, the digital twin dynamic model system 15508 may execute a dynamic model that is configured to determine whether an increase in output would result in adverse consequences (e.g., failures, downtime, or the like). The digital twin dynamic model system 15508 is discussed in further detail throughout the disclosure.

[0603] In embodiments, the cognitive processes system 15510 performs machine learning and artificial intelligence related tasks on behalf of the digital twin system. In embodiments, the cognitive processes system 15510 may train any suitable type of model, including but not limited to various types of neural networks, regression models, random forests, decision trees, Hidden Markov models, Bayesian models, and the like. In embodiments, the cognitive processes system 15510 trains machine learned models using the output of simulations executed by the digital twin simulation system 15506. In some of these embodiments, the outcomes of the simulations may be used to supplement training data collected from real-world environments and/or processes. In embodiments, the cognitive processes system 15510 leverages machine learned models to make predictions, identifications, classifications and provide decision support relating to the real-world environments and/or processes represented by respective digital twins.

[0604] For example, a machine-learned prediction model may be used to predict the cause of irregular vibrational patterns (e.g., a suboptimal, critical, or alarm vibration fault state) for a bearing of an engine in an industrial facility. In this example, the cognitive processes system 15510 may receive vibration sensor data from one or more vibration sensors disposed on or near the engine and may receive maintenance data from the industrial facility and may generate a feature vector based on the vibration sensor data and the maintenance data. The cognitive processes system 15510 may input the feature vector into a machine-learned model trained specifically for the engine (e.g., using a combination simulation data and real-world data of causes of irregular vibration patterns) to predict the cause of the irregular vibration patterns. In this example, the causes of the irregular vibrational patterns could be a loose bearing, a lack of bearing lubrication, a bearing that is out of alignment, a worn bearing, the phase of the bearing may be aligned with the phase of the engine, loose housing, loose bolt, and the like.

[0605] In another example, a machine-learned model may be used to provide decision support to bring a bearing of an engine in an industrial facility operating at a suboptimal vibration fault level state to a normal operation vibration fault level state. In this example, the cognitive processes system 15510 may receive vibration sensor data from one or more vibration sensors disposed on or near the engine and may receive maintenance data from the industrial facility and may generate a feature vector based on the vibration sensor data and the maintenance data. The cognitive processes system 15510 may input the feature vector into a machine-learned model trained specifically for the engine (e.g., using a combination simulation data and real-world data of solutions to irregular vibration patterns) to provide decision support in achieving a normal operation fault level state of the bearing. In this example, the decision support could be a recommendation to tighten the bearing, lubricate the bearing, re-align the bearing, order a new bearing, order a new part, collect additional vibration measurements, change operating speed of the engine, tighten housings, tighten bolts, and the like.

[0606] In another example, a machine-learned model may be used to provide decision support relating to vibration measurement collection by a worker. In this example, the cognitive processes system 15510 may receive vibration measurement history data from the industrial facility and may generate a feature vector based on the vibration measurement history data. The cognitive processes system 15510 may input the feature vector into a machine-learned model trained specifically for the engine (e.g., using a combination simulation data and real-world vibration measurement history data) to provide decision support in selecting vibration measurement locations.

[0607] In yet another example, a machine-learned model may be used to identify vibration signatures associated with machine and/or machine component problems. In this example, the cognitive processes system 15510 may receive vibration measurement history data from the industrial facility and may generate a feature vector based on the vibration measurement history data. The cognitive processes system 15510 may input the feature vector into a machine-learned model trained specifically for the engine (e.g., using a combination simulation data and real-world vibration measurement history data) to identify vibration signatures associated with a machine and/or machine component. The foregoing examples are non-limiting examples and the cognitive processes system 15510 may be used for any other suitable AI/machine-learning related tasks that are performed with respect to industrial facilities.

[0608] In embodiments, the environment control system 15512 controls one or more aspects of industrial facilities. In some of these embodiments, the environment control system 15512 may control one or more devices within an industrial environment. For example, the environment control system 15512 may control one or more machines within an environment, robots within an environment, an HVAC system of the environment, an alarm system of the environment, an assembly line in an environment, or the like. In embodiments, the environment control system 15512 may leverage the digital twin simulation system 15506, the digital twin dynamic model system 15508, and/or the cognitive processes system 15510 to determine one or more control instructions. In embodiments, the environment control system 15512 may implement a rules-based and/or a machine-learning approach to determine the control instructions. In response to determining a control instruction, the environment control system 15512 may output the control instruction to the intended device within a specific environment via the digital twin I/O system 15504.

[0609] FIG. 156 illustrates an example digital twin management system 15502 according to some embodiments of the present disclosure. In embodiments, the digital twin management system 15502 may include, but is not limited to, a digital twin creation module 15564, a digital twin update module 15566, and a digital twin visualization module 15568.

[0610] In embodiments, the digital twin creation module 15564 may create a set of new digital twins of a set of environments using input from users, imported data (e.g., blueprints, specifications, and the like), image scans of the environment, 3D data from a LIDAR device and/or SLAM sensor, and other suitable data sources. For example, a user (e.g., a user affiliated with an organization/customer account) may, via a client application 15570, provide input to create a new digital twin of an environment. In doing so, the user may upload 2D or 3D image scans of the environment and/or a blueprint of the environment. The user may also upload 3D data, such as taken by a camera, a LIDAR device, an IR scanner, a set of SLAM sensors, a radar device, an EMF scanner, or the like. In response to the provided data, the digital twin creation module 15564 may create a 3D representation of the environment, which may include any objects that were captured in the image data/detected in the 3D data. In embodiments, the cognitive processes system 15572 may analyze input data (e.g., blueprints, image scans, 3D data) to classify rooms, pathways, equipment, and the like to assist in the generation of the 3D representation. In some embodiments, the digital twin creation module 15564 may map the digital twin to a 3D coordinate space (e.g., a Cartesian space having x, y, and z axes).

[0611] In some embodiments, the digital twin creation module 15564 may output the 3D representation of the environment to a graphical user interface (GUI). In some of these embodiments, a user may identify certain areas and/or objects and may provide input relating to the identified areas and/or objects. For example, a user may label specific rooms, equipment, machines, and the like. Additionally or alternatively, the user may provide data relating to the identified objects and/or areas. For example, in identifying a piece of equipment, the user may provide a make/model number of the equipment. In some embodiments, the digital twin creation module 15564 may obtain information from a manufacturer of a device, a piece of equipment, or machinery. This information may include one or more properties and/or behaviors of the device, equipment, or machinery. In some embodiments, the user may, via the GUI, identify locations of sensors throughout the environment. For each sensor, the user may provide a type of sensor and related data (e.g., make, model, IP address, and the like). The digital twin creation module 15564 may record the locations (e.g., the x, y, z coordinates of the sensors) in the digital twin of the environment. In embodiments, the digital twin system 15500 may employ one or more systems that automate the population of digital twins. For example, the digital twin system 15500 may employ a machine vision-based classifier that classifies makes and models of devices, equipment, or sensors. Additionally or alternatively, the digital twin system 15500 may iteratively ping different types of known sensors to identify the presence of specific types of sensors that are in an environment. Each time a sensor responds to a ping, the digital twin system 15500 may extrapolate the make and model of the sensor.

[0612] In some embodiments, the manufacturer may provide or make available digital twins of their products (e.g., sensors, devices, machinery, equipment, raw materials, and the like). In these embodiments, the digital twin creation module 15564 may import the digital twins of one or more products that are identified in the environment and may embed those digital twins in the digital twin of the environment. In embodiments, embedding a digital twin within another digital twin may include creating a relationship between the embedded digital twin with the other digital twin. In these embodiments, the manufacturer of the digital twin may define the behaviors and/or properties of the respective products. For example, a digital twin of a machine may define the manner by which the machine operates, the inputs/outputs of the machine, and the like. In this way, the digital twin of the machine may reflect the operation of the machine given a set of inputs.

[0613] In embodiments, a user may define one or more processes that occur in an environment. In these embodiments, the user may define the steps in the process, the machines/devices that perform each step in the process, the inputs to the process, and the outputs of the process.

[0614] In embodiments, the digital twin creation module 15564 may create a graph database that defines the relationships between a set of digital twins. In these embodiments, the digital twin creation module 15564 may create nodes for the environment, systems and subsystems of the environment, devices in the environment, sensors in the environment, workers that work in the environment, processes that are performed in the environment, and the like. In embodiments, the digital twin creation module 15564 may write the graph database representing a set of digital twins to the digital twin datastore 15516.

[0615] In embodiments, the digital twin creation module 15564 may, for each node, include any data relating to the entity in the node representing the entity. For example, in defining a node representing an environment, the digital twin creation module 15564 may include the dimensions, boundaries, layout, pathways, and other relevant spatial data in the node. Furthermore, the digital twin creation module 15564 may define a coordinate space with respect to the environment. In the case that the digital twin may be rendered, the digital twin creation module 15564 may include a reference in the node to any shapes, meshes, splines, surfaces, and the like that may be used to render the environment. In representing a system, subsystem, device, or sensor, the digital twin creation module 15564 may create a node for the respective entity and may include any relevant data. For example, the digital twin creation module 15564 may create a node representing a machine in the environment. In this example, the digital twin creation module 15564 may include the dimensions, behaviors, properties, location, and/or any other suitable data relating to the machine in the node representing the machine. The digital twin creation module 15564 may connect nodes of related entities with an edge, thereby creating a relationship between the entities. In doing so, the created relationship between the entities may define the type of relationship characterized by the edge. In representing a process, the digital twin creation module 15564 may create a node for the entire process or may create a node for each step in the process. In some of these embodiments, the digital twin creation module 15564 may relate the process nodes to the nodes that represent the machinery/devices that perform the steps in the process. In embodiments, where an edge connects the process step nodes to the machinery/device that performs the process step, the edge or one of the nodes may contain information that indicates the input to the step, the output of the step, the amount of time the step takes, the nature of processing of inputs to produce outputs, a set of states or modes the process can undergo, and the like.

[0616] In embodiments, the digital twin update module 15566 updates sets of digital twins based on a current status of one or more industrial entities. In some embodiments, the digital twin update module 15566 receives sensor data from a sensor system 15530 of an industrial environment and updates the status of the digital twin of the industrial environment and/or digital twins of any affected systems, subsystems, devices, workers, processes, or the like. As discussed, the digital twin I/O system 15504 may receive the sensor data in one or more sensor packets. The digital twin I/O system 15504 may provide the sensor data to the digital twin update module 15566 and may identify the environment from which the sensor packets were received and the sensor that provided the sensor packet. In response to the sensor data, the digital twin update module 15566 may update a state of one or more digital twins based on the sensor data. In some of these embodiments, the digital twin update module 15566 may update a record (e.g., a node in a graph database) corresponding to the sensor that provided the sensor data to reflect the current sensor data. In some scenarios, the digital twin update module 15566 may identify certain areas within the environment that are monitored by the sensor and may update a record (e.g., a node in a graph database) to reflect the current sensor data. For example, the digital twin update module 15566 may receive sensor data reflecting different vibrational characteristics of a machine and/or machine components. In this example, the digital twin update module 15566 may update the records representing the vibration sensors that provided the vibration sensor data and/or the records representing the machine and/or the machine components to reflect the vibration sensor data. In another example, in some scenarios, workers in an industrial environment (e.g., manufacturing facility, industrial storage facility, a mine, a drilling operation, or the like) may be required to wear wearable devices (e.g., smart watches, smart helmets, smart shoes, or the like). In these embodiments, the wearable devices may collect sensor data relating to the worker (e.g., location, movement, heartrate, respiration rate, body temperature, or the like) and/or the environment surrounding the worker and may communicate the collected sensor data to the digital twin system 15500 (e.g., via the real-time sensor API 15514) either directly or via an aggregation device of the sensor system. In response to receiving the sensor data from the wearable device of a worker, the digital twin update module 15566 may update a digital twin of a worker to reflect, for example, a location of the worker, a trajectory of the worker, a health status of the worker, or the like. In some of these embodiments, the digital twin update module 15566 may update a node representing a worker and/or an edge that connects the node representing the environment with the collected sensor data to reflect the current status of the worker.

[0617] In some embodiments, the digital twin update module 15566 may provide the sensor data from one or more sensors to the digital twin dynamic model system 15508, which may model a behavior of the environment and/or one or more industrial entities to extrapolate additional state data.

[0618] In embodiments, the digital twin visualization module 15568 receives requests to view a visual digital twin or a portion thereof. In embodiments, the request may indicate the digital twin to be viewed (e.g., an environment identifier). In response, the digital twin visualization module 15568 may determine the requested digital twin and any other digital twins implicated by the request. For example, in requesting to view a digital twin of an environment, the digital twin visualization module 15568 may further identify the digital twins of any industrial entities within the environment. In embodiments, the digital twin visualization module 15568 may identify the spatial relationships between the industrial entities and the environment based on, for example, the relationships defined in a graph database. In these embodiments, the digital twin visualization module 15568 can determine the relative location of embedded digital twins within the containing digital twin, relative locations of adjoining digital twins, and/or the transience of the relationship (e.g., is an object fixed to a point or does the object move). The digital twin visualization module 15568 may render the requested digital twins and any other implicated digital twin based on the identified relationships. In some embodiments, the digital twin visualization module 15568 may, for each digital twin, determine the surfaces of the digital twin. In some embodiments, the surfaces of a digital may be defined or referenced in a record corresponding to the digital twin, which may be provided by a user, determined from imported images, or defined by a manufacturer of an industrial entity. In the scenario that an object can take different poses or shapes (e.g., an industrial robot), the digital twin visualization module 15568 may determine a pose or shape of the object for the digital twin. The digital twin visualization module 15568 may embed the digital twins into the requested digital twin and may output the requested digital twin to a client application.

[0619] In some of these embodiments, the request to view a digital twin may further indicate the type of view. As discussed, in some embodiments, digital twins may be depicted in a number of different view types. For example, an environment or device may be viewed in a “real-world” view that depicts the environment or device as they typically appear, in a “heat” view that depicts the environment or device in a manner that is indicative of a temperature of the environment or device, in a “vibration” view that depicts the machines and/or machine components in an industrial environment in a manner that is indicative of vibrational characteristics of the machines and/or machine components, in a “filtered” view that only displays certain types of objects within an environment or components of a device (such as objects that require attention resulting from, for example, recognition of a fault condition, an alert, an updated report, or other factor), an augmented view that overlays data on the digital twin, and/or any other suitable view types. In embodiments, digital twins may be depicted in a number of different role-based view types. For example, a manufacturing facility device may be viewed in an “operator” view that depicts the facility in a manner that is suitable for a facility operator, a “C-Suite” view that depicts the facility in a manner that is suitable for executive-level managers, a “marketing” view that depicts the facility in a manner that is suitable for workers in sales and/or marketing roles, a “board” view that depicts the facility in a manner that is suitable for members of a corporate board, a “regulatory” view that depicts the facility in a manner that is suitable for regulatory managers, and a “human resources” view that depicts the facility in a manner that is suitable for human resources personnel. In response to a request that indicates a view type, the digital twin visualization module 15568 may retrieve the data for each digital twin that corresponds to the view type. For example, if a user has requested a vibration view of a factory floor, the digital twin visualization module 15568 may retrieve vibration data for the factory floor (which may include vibration measurements taken from different machines and/or machine components and/or vibration measurements that were extrapolated by the digital twin dynamic model system 15508 and/or simulated vibration data from digital twin simulation system 15506) as well as available vibration data for any industrial entities appearing on the factory floor. In this example, the digital twin visualization module 15568 may determine colors corresponding to each machine component on a factory floor that represent a vibration fault level state (e.g., red for alarm, orange for critical, yellow for suboptimal, and green for normal operation). The digital twin visualization module 15568 may then render the digital twins of the machine components within the environment based on the determined colors. Additionally or alternatively, the digital twin visualization module 15568 may render the digital twins of the machine components within the environment with indicators having the determined colors. For instance, if the vibration fault level state of an inbound bearing of a motor is suboptimal and the outbound bearing of the motor is critical, the digital twin visualization module 15568 may render the digital twin of the inbound bearing having an indicator in a shade of yellow (e.g., suboptimal) and the outbound bearing having an indicator in a shade of orange (e.g., critical). It is noted that in some embodiments, the digital twin system 15500 may include an analytics system (not shown) that determine the manner by which the digital twin visualization system 15500 presents information to a human user. For example, the analytics system may track outcomes relating to human interactions with real-world environments or objects in response to information presented in a visual digital twin. In some embodiments, the analytics system may apply cognitive models to determine the most effective manner to display visualized information (e.g., what colors to use to denote an alarm condition, what kind of movements or animations bring attention to an alarm condition, or the like) or audio information (what sounds to use to denote an alarm condition) based on the outcome data. In some embodiments, the analytics system may apply cognitive models to determine the most suitable manner to display visualized information based on the role of the user. In embodiments, the visualization may include display of information related to the visualized digital twins, including graphical information, graphical information depicting vibration characteristics, graphical information depicting harmonic peaks, graphical information depicting peaks, vibration severity units data, vibration fault level state data, recommendations from cognitive intelligence system 15510, predictions from cognitive intelligence system 15510, probability of failure data, maintenance history data, time to failure data, cost of downtime data, probability of downtime data, cost of repair data, cost of machine replace data, probability of shutdown data, manufacturing KPIs, and the like.

[0620] In another example, a user may request a filtered view of a digital twin of a process, whereby the digital twin of the process only shows components (e.g., machine or equipment) that are involved in the process. In this example, the digital twin visualization module 15568 may retrieve a digital twin of the process, as well as any related digital twins (e.g., a digital twin of the environment and digital twins of any machinery or devices that impact the process). The digital twin visualization module 15568 may then render each of the digital twins (e.g., the environment and the relevant industrial entities) and then may perform the process on the rendered digital twins. It is noted that as a process may be performed over a period of time and may include moving items and/or parts, the digital twin visualization module 15568 may generate a series of sequential frames that demonstrate the process. In this scenario, the movements of the machines and/or devices implicated by the process may be determined according to the behaviors defined in the respective digital twins of the machines and/or devices.

[0621] As discussed, the digital twin visualization module 15568 may output the requested digital twin to a client application 15570. In some embodiments, the client application 15570 is a virtual reality application, whereby the requested digital twin is displayed on a virtual reality headset. In some embodiments, the client application 15570 is an augmented reality application, whereby the requested digital twin is depicted in an AR-enabled device. In these embodiments, the requested digital twin may be filtered such that visual elements and/or text are overlaid on the display of the AR-enabled device.

[0622] It is noted that while a graph database is discussed, the digital twin system 15500 may employ other suitable data structures to store information relating to a set of digital twins. In these embodiments, the data structures, and any related storage system, may be implemented such that the data structures provide for some degree of feedback loops and/or recursion when representing iteration of flows.

[0623] FIG. 157 illustrates an example of a digital twin I/O system 15504 that interfaces with the environment 15520, the digital twin system 15500, and/or components thereof to provide bi-directional transfer of data between coupled components according to some embodiments of the present disclosure.

[0624] In embodiments, the transferred data includes signals (e.g., request signals, command signals, response signals, etc.) between connected components, which may include software components, hardware components, physical devices, virtualized devices, simulated devices, combinations thereof, and the like. The signals may define material properties (e.g., physical quantities of temperature, pressure, humidity, density, viscosity, etc.), measured values (e.g., contemporaneous or stored values acquired by the device or system), device properties (e.g., device ID or properties of the device's design specifications, materials, measurement capabilities, dimensions, absolute position, relative position, combinations thereof, and the like), set points (e.g., targets for material properties, device properties, system properties, combinations thereof, and the like), and/or critical points (e.g., threshold values such as minimum or maximum values for material properties, device properties, system properties, etc.). The signals may be received from systems or devices that acquire (e.g., directly measure or generate) or otherwise obtain (e.g., receive, calculate, look-up, filter, etc.) the data, and may be communicated to or from the digital twin I/O system 15504 at predetermined times or in response to a request (e.g., polling) from the digital twin I/O system 15504. The communications may occur through direct or indirect connections (e.g., via intermediate modules within a circuit and/or intermediate devices between the connected components). The values may correspond to real-world elements 157302r (e.g., an input or output for a tangible vibration sensor) or virtual elements 157302v (e.g., an input or output for a digital twin 157302d and/or a simulated element 157302s that provide vibration data).

[0625] In embodiments, the real-world elements 157302r may be elements within the industrial environment 15520. The real-world elements 157302r may include, for example, non-networked objects 15522, the devices 15524 (smart or non-smart), sensors 15526, and humans 15528. The real-world elements 151302r may be process or non-process equipment within the industrial environments 15520. For example, process equipment may include motors, pumps, mills, fans, painters, welders, smelters, etc., and non-process equipment may include personal protective equipment, safety equipment, emergency stations or devices (e.g., safety showers, eyewash stations, fire extinguishers, sprinkler systems, etc.), warehouse features (e.g., walls, floor layout, etc.), obstacles (e.g., persons or other items within the environment 15520, etc.), etc.

[0626] In embodiments, the virtual elements 157302v may be digital representations of or that correspond to contemporaneously existing real-world elements 157302r. Additionally or alternatively, the virtual elements 157302v may be digital representations of or that correspond to real-world elements 157302r that may be available for later addition and implementation into the environment 15520. The virtual elements may include, for example, simulated elements 175302s and/or digital twins 157302d. In embodiments, the simulated elements 157302s may be digital representations of real-world elements 157302s that are not present within the industrial environment 15520. The simulated elements 157302s may mimic desired physical properties which may be later integrated within the environment 15520 as real-world elements 157302r (e.g., a “black box” that mimics the dimensions of a real-world elements 157302r). The simulated elements 157302s may include digital twins of existing objects (e.g., a single simulated element 151302s may include one or more digital twins 151302d for existing sensors). Information related to the simulated elements 157302s may be obtained, for example, by evaluating behavior of corresponding real-world elements 157302r using mathematical models or algorithms, from libraries that define information and behavior of the simulated elements 131302s (e.g., physics libraries, chemistry libraries, or the like).

[0627] In embodiments, the digital twin 157302d may be a digital representation of one or more real-world elements 157302r. The digital twins 157302d are configured to mimic, copy, and/or model behaviors and responses of the real-world elements 157302r in response to inputs, outputs, and/or conditions of the surrounding or ambient environment. Data related to physical properties and responses of the real-world elements 157302r may be obtained, for example, via user input, sensor input, and/or physical modeling (e.g., thermodynamic models, electrodynamic models, mechanodynamic models, etc.). Information for the digital twin 157302d may correspond to and be obtained from the one or more real-world elements 157302r corresponding to the digital twin 157302d. For example, in some embodiments, the digital twin 131302d may correspond to one real-world element 157302r that is a fixed digital vibration sensor 15536 on a machine component, and vibration data for the digital twin 131302d may be obtained by polling or fetching vibration data measured by the fixed digital vibration sensor on the machine component. In a further example, the digital twin 157302d may correspond to a plurality of real-world elements 157302r such that each of the elements can be a fixed digital vibration sensor on a machine component, and vibration data for the digital twin 157302d may be obtained by polling or fetching vibration data measured by each of the fixed digital vibration sensors on the plurality of real-world elements 157302r. Additionally or alternatively, vibration data of a first digital twin 157302d may be obtained by fetching vibration data of a second digital twin 157302d that is embedded within the first digital twin 157302d, and vibration data for the first digital twin 157302d may include or be derived from vibration data for the second digital twin 157302d. For example, the first digital twin may be a digital twin 157302d of an environment 15520 (alternatively referred to as an “environmental digital twin”) and the second digital twin 157302d may be a digital twin 157302d corresponding to a vibration sensor disposed within the environment 15520 such that the vibration data for the first digital twin 157302d is obtained from or calculated based on data including the vibration data for the second digital twin 157302d.

[0628] In embodiments, the digital twin system 15500 monitors properties of the real-world elements 157302r using the sensors 15526 within a respective environment 15520 that is or may be represented by a digital twin 157302d and/or outputs of models for one or more simulated elements 157302s. In embodiments, the digital twin system 15500 may minimize network congestion while maintaining effective monitoring of processes by extending polling intervals and/or minimizing data transfer for sensors corresponding that correspond to affected real-world elements 157302r and performing simulations (e.g., via the digital-twin simulation system 15506) during the extended interval using data that was obtained from other sources (e.g., sensors that are physically proximate to or have an effect on the affected real-world elements 157302r). Additionally or alternatively, error checking may be performed by comparing the collected sensor data with data obtained from the digital-twin simulation system 15506. For example, consistent deviations or fluctuations between sensor data obtained from the real-world element 157302r and the simulated element 157302s may indicate malfunction of the respective sensor or another fault condition.

[0629] In embodiments, the digital twin system 15500 may optimize features of the environment through use of one or more simulated elements 157302s. For example, the digital twin system 15500 may evaluate effects of the simulated elements 157302s within a digital twin of an environment to quickly and efficiently determine costs and/or benefits flowing from inclusion, exclusion, or substitution of real-world elements 157302r within the environment 15520. The costs and benefits may include, for example, increased machinery costs (e.g., capital investment and maintenance), increased efficiency (e.g., process optimization to reduce waste or increase throughput), decreased or altered footprint within the environment 15520, extension or optimization of useful lifespans, minimization of component faults, minimization of component downtime, etc.

[0630] In embodiments, the digital twin I/O system 15504 may include one or more software modules that are executed by one or more controllers of one or more devices (e.g., server devices, user devices, and/or distributed devices) to affect the described functions. The digital twin I/O system 15504 may include, for example, an input module 157304, an output module 157306, and an adapter module 157308.

[0631] In embodiments, the input module 157304 may obtain or import data from data sources in communication with the digital twin I/O system 15504, such as the sensor system 15530 and the digital twin simulation system 15506. The data may be immediately used by or stored within the digital twin system 15500. The imported data may be ingested from data streams, data batches, in response to a triggering event, combinations thereof, and the like. The input module 157304 may receive data in a format that is suitable to transfer, read, and/or write information within the digital twin system 15500.

[0632] In embodiments, the output module 157306 may output or export data to other system components (e.g., the digital twin datastore 15516, the digital twin simulation system 15506, the cognitive intelligence system 15510, etc.), devices 15524, and/or the client application 15570. The data may be output in data streams, data batches, in response to a triggering event (e.g., a request), combinations thereof, and the like. The output module 157306 may output data in a format that is suitable to be used or stored by the target element (e.g., one protocol for output to the client application and another protocol for the digital twin datastore 15516).

[0633] In embodiments, the adapter module 157308 may process and/or convert data between the input module 157304 and the output module 157306. In embodiments, the adapter module 157308 may convert and/or route data automatically (e.g., based on data type) or in response to a received request (e.g., in response to information within the data).

[0634] In embodiments, the digital twin system 15500 may represent a set of industrial workpiece elements in a digital twin, and the digital twin simulation system 15506 simulates a set of physical interactions of a worker with the workpiece elements.

[0635] In embodiments, the digital twin simulation system 15506 may determine process outcomes for the simulated physical interactions accounting for simulated human factors. For example, variations in workpiece throughput may be modeled by the digital twin system 15500 including, for example, worker response times to events, worker fatigue, discontinuity within worker actions (e.g., natural variations in human-movement speed, differing positioning times, etc.), effects of discontinuities on downstream processes, and the like. In embodiments, individualized worker interactions may be modeled using historical data that is collected, acquired, and/or stored by the digital twin system 15500. The simulation may begin based on estimated amounts (e.g., worker age, industry averages, workplace expectations, etc.). The simulation may also individualize data for each worker (e.g., comparing estimated amounts to collected worker-specific outcomes).

[0636] In embodiments, information relating to workers (e.g., fatigue rates, efficiency rates, and the like) may be determined by analyzing performance of specific workers over time and modeling said performance.

[0637] In embodiments, the digital twin system 15500 includes a plurality of proximity sensors within the sensor system 15530. The proximity sensors are or may be configured to detect elements of the environment 15520 that are within a predetermined area. For example, proximity sensors may include electromagnetic sensors, light sensors, and/or acoustic sensors.

[0638] The electromagnetic sensors are or may be configured to sense objects or interactions via one or more electromagnetic fields (e.g., emitted electromagnetic radiation or received electromagnetic radiation). In embodiments, the electromagnetic sensors include inductive sensors (e.g., radio-frequency identification sensors), capacitive sensors (e.g., contact and contactless capacitive sensors), combinations thereof, and the like.

[0639] The light sensors are or may be configured to sense objects or interactions via electromagnetic radiation in, for example, the far-infrared, near-infrared, optical, and/or ultraviolet spectra. In embodiments, the light sensors may include image sensors (e.g., charge-coupled devices and CMOS active-pixel sensors), photoelectric sensors (e.g., through-beam sensors, retroreflective sensors, and diffuse sensors), combinations thereof, and the like. Further, the light sensors may be implemented as part of a system or subsystem, such as a light detection and ranging (“LIDAR”) sensor.

[0640] The acoustic sensors are or may be configured to sense objects or interactions via sound waves that are emitted and/or received by the acoustic sensors. In embodiments, the acoustic sensors may include infrasonic, sonic, and/or ultrasonic sensors. Further, the acoustic sensors may be grouped as part of a system or subsystem, such as a sound navigation and ranging (“SONAR”) sensor.

[0641] In embodiments, the digital twin system 15500 stores and collects data from a set of proximity sensors within the environment 15520 or portions thereof. The collected data may be stored, for example, in the digital twin datastore 15516 for use by components the digital twin system 15500 and/or visualization by a user. Such use and/or visualization may occur contemporaneously with or after collection of the data (e.g., during later analysis and/or optimization of processes).

[0642] In embodiments, data collection may occur in response to a triggering condition. These triggering conditions may include, for example, expiration of a static or a dynamic predetermined interval, obtaining a value short of or in excess of a static or dynamic value, receiving an automatically generated request or instruction from the digital twin system 15500 or components thereof, interaction of an element with the respective sensor or sensors (e.g., in response to a worker or machine breaking a beam or coming within a predetermined distance from the proximity sensor), interaction of a user with a digital twin (e.g., selection of an environmental digital twin, a sensor array digital twin, or a sensor digital twin), combinations thereof, and the like.

[0643] In some embodiments, the digital twin system 15500 collects and/or stores RFID data in response to interaction of a worker with a real-world element 157302r. For example, in response to a worker interaction with a real-world environment, the digital twin will collect and/or store RFID data from RFID sensors within or associated with the corresponding environment 15520. Additionally or alternatively, worker interaction with a sensor-array digital twin will collect and/or store RFID data from RFID sensors within or associated with the corresponding sensor array. Similarly, worker interaction with a sensor digital twin will collect and/or store RFID data from the corresponding sensor. The RFID data may include suitable data attainable by RFID sensors such as proximate RFID tags, RFID tag position, authorized RFID tags, unauthorized RFID tags, unrecognized RFID tags, RFID type (e.g., active or passive), error codes, combinations thereof, and the like.

[0644] In embodiments, the digital twin system 15500 may further embed outputs from one or more devices within a corresponding digital twin. In embodiments, the digital twin system 15500 embeds output from a set of individual-associated devices into an industrial digital twin. For example, the digital twin I/O system 15504 may receive information output from one or more wearable devices 15554 or mobile devices (not shown) associated with an individual within an industrial environment. The wearable devices may include image capture devices (e.g., body cameras or augmented-reality headwear), navigation devices (e.g., GPS devices, inertial guidance systems), motion trackers, acoustic capture devices (e.g., microphones), radiation detectors, combinations thereof, and the like.

[0645] In embodiments, upon receiving the output information, the digital twin I/O system 15504 routes the information to the digital twin creation module 15564 to check and/or update the environment digital twin and/or associated digital twins within the environment (e.g., a digital twin of a worker, machine, or robot position at a given time). Further, the digital twin system 15500 may use the embedded output to determine characteristics of the environment 15520.

[0646] In embodiments, the digital twin system 15500 embeds output from a LIDAR point cloud system into an industrial digital twin. For example, the digital twin I/O system 15504 may receive information output from one or more Lidar devices 15538 within an industrial environment. The Lidar devices 15538 is configured to provide a plurality of points having associated position data (e.g., coordinates in absolute or relative x, y, and z values). Each of the plurality of points may include further LIDAR attributes, such as intensity, return number, total returns, laser color data, return color data, scan angle, scan direction, etc. The Lidar devices 15538 may provide a point cloud that includes the plurality of points to the digital twin system 15500 via, for example, the digital twin I/O system 15504. Additionally or alternatively, the digital twin system 15500 may receive a stream of points and assemble the stream into a point cloud, or may receive a point cloud and assemble the received point cloud with existing point cloud data, map data, or three dimensional (3D)-model data.

[0647] In embodiments, upon receiving the output information, the digital twin I/O system 15504 routes the point cloud information to the digital twin creation module 15564 to check and/or update the environment digital twin and/or associated digital twins within the environment (e.g., a digital twin of a worker, machine, or robot position at a given time). In some embodiments, the digital twin system 15500 is further configured to determine closed-shape objects within the received LIDAR data. For example, the digital twin system 15500 may group a plurality of points within the point cloud as an object and, if necessary, estimate obstructed faces of objects (e.g., a face of the object contacting or adjacent a floor or a face of the object contacting or adjacent another object such as another piece of equipment). The system may use such closed-shape objects to narrow search space for digital twins and thereby increase efficiency of matching algorithms (e.g., a shape-matching algorithm).

[0648] In embodiments, the digital twin system 15500 embeds output from a simultaneous location and mapping (“SLAM”) system in an environmental digital twin. For example, the digital twin I/O system 15504 may receive information output from the SLAM system, such as Slam sensor 15562, and embed the received information within an environment digital twin corresponding to the location determined by the SLAM system. In embodiments, upon receiving the output information from the SLAM system, the digital twin I/O system 15504 routes the information to the digital twin creation module 15564 to check and/or update the environment digital twin and/or associated digital twins within the environment (e.g., a digital twin of a workpiece, furniture, movable object, or autonomous object). Such updating provides digital twins of non-connected elements (e.g., furnishings or persons) automatically and without need of user interaction with the digital twin system 15500.

[0649] In embodiments, the digital twin system 15500 can leverage known digital twins to reduce computational requirements for the Slam sensor 15562 by using suboptimal map-building algorithms. For example, the suboptimal map-building algorithms may allow for a higher uncertainty tolerance using simple bounded-region representations and identifying possible digital twins. Additionally or alternatively, the digital twin system 15500 may use a bounded-region representation to limit the number of digital twins, analyze the group of potential twins for distinguishing features, then perform higher precision analysis for the distinguishing features to identify and/or eliminate categories of, groups of, or individual digital twins and, in the event that no matching digital twin is found, perform a precision scan of only the remaining areas to be scanned.

[0650] In embodiments, the digital twin system 15500 may further reduce compute required to build a location map by leveraging data captured from other sensors within the environment (e.g., captured images or video, radio images, etc.) to perform an initial map-building process (e.g., a simple bounded-region map or other suitable photogrammetry methods), associate digital twins of known environmental objects with features of the simple bounded-region map to refine the simple bounded-region map, and perform more precise scans of the remaining simple bounded regions to further refine the map. In some embodiments, the digital twin system 15500 may detect objects within received mapping information and, for each detected object, determine whether the detected object corresponds to an existing digital twin of a real-world-element. In response to determining that the detected object does not correspond to an existing real-world-element digital twin, the digital twin system 15500 may use, for example, the digital twin creation module 15564 to generate a new digital twin corresponding to the detected object (e.g., a detected-object digital twin) and add the detected-object digital twin to the real-world-element digital twins within the digital twin datastore. Additionally or alternatively, in response to determining that the detected object corresponds to an existing real-world-element digital twin, the digital twin system 15500 may update the real-world-element digital twin to include new information detected by the simultaneous location and mapping sensor, if any.

[0651] In embodiments, the digital twin system 15500 represents locations of autonomously or remotely moveable elements and attributes thereof within an industrial digital twin. Such movable elements may include, for example, workers, persons, vehicles, autonomous vehicles, robots, etc. The locations of the moveable elements may be updated in response to a triggering condition. Such triggering conditions may include, for example, expiration of a static or a dynamic predetermined interval, receiving an automatically generated request or instruction from the digital twin system 15500 or components thereof, interaction of an element with a respective sensor or sensors (e.g., in response to a worker or machine breaking a beam or coming within a predetermined distance from a proximity sensor), interaction of a user with a digital twin (e.g., selection of an environmental digital twin, a sensor array digital twin, or a sensor digital twin), combinations thereof, and the like.

[0652] In embodiments, the time intervals may be based on probability of the respective movable element having moved within a time period. For example, the time interval for updating a worker location may be relatively shorter for workers expected to move frequently (e.g., a worker tasked with lifting and carrying objects within and through the environment 15520) and relatively longer for workers expected to move infrequently (e.g., a worker tasked with monitoring a process stream). Additionally or alternatively, the time interval may be dynamically adjusted based on applicable conditions, such as increasing the time interval when no movable elements are detected, decreasing the time interval as or when the number of moveable elements within an environment increases (e.g., increasing number of workers and worker interactions), increasing the time interval during periods of reduced environmental activity (e.g., breaks such as lunch), decreasing the time interval during periods of abnormal environmental activity (e.g., tours, inspections, or maintenance), decreasing the time interval when unexpected or uncharacteristic movement is detected (e.g., frequent movement by a typically sedentary element or coordinated movement, for example, of workers approaching an exit or moving cooperatively to carry a large object), combinations thereof, and the like. Further, the time interval may also include additional, semi-random acquisitions. For example, occasional mid-interval locations may be acquired by the digital twin system 15500 to reinforce or evaluate the efficacy of the particular time interval.

[0653] In embodiments, the digital twin system 15500 may analyze data received from the digital twin I/O system 15504 to refine, remove, or add conditions. For example, the digital twin system 15500 may optimize data collection times for movable elements that are updated more frequently than needed (e.g., multiple consecutive received positions being identical or within a predetermined margin of error).

[0654] In embodiments, the digital twin system 15500 may receive, identify, and/or store a set of states 15840a-n related to the environment 15520. The states 15840a-n may be, for example, data structures that include a plurality of attributes 158404a-n and a set of identifying criteria 158406a-n to uniquely identify each respective state 15840a-n. In embodiments, the states 15840a-n may correspond to states where it is desirable for the digital twin system 15500 to set or alter conditions of real-world elements 157302r and/or the environment 15520 (e.g., increase/decrease monitoring intervals, alter operating conditions, etc.).

[0655] In embodiments, the set of states 15840a-n may further include, for example, minimum monitored attributes for each state 15840a-n, the set of identifying criteria 158406a-n for each state 15840a-n, and/or actions available to be taken or recommended to be taken in response to each state 15840a-n. Such information may be stored by, for example, the digital twin datastore 15516 or another datastore. The states 15840a-n or portions thereof may be provided to, determined by, or altered by the digital twin system 15500. Further, the set of states 15840a-n may include data from disparate sources. For example, details to identify and/or respond to occurrence of a first state may be provided to the digital twin system 15500 via user input, details to identify and/or respond to occurrence of a second state may be provided to the digital twin system 15500 via an external system, details to identify and/or respond to occurrence of a third state may be determined by the digital twin system 15500 (e.g., via simulations or analysis of process data), and details to identify and/or respond to occurrence of a fourth state may be stored by the digital twin system 15500 and altered as desired (e.g., in response to simulated occurrence of the state or analysis of data collected during an occurrence of and response to the state).

[0656] In embodiments, the plurality of attributes 158404a-n includes at least the attributes 158404a-n needed to identify the respective state 15840a-n. The plurality of attributes 158404a-n may further include additional attributes that are or may be monitored in determining the respective state 15840a-n, but are not needed to identify the respective state 15840a-n. For example, the plurality of attributes 158404a-n for a first state may include relevant information such as rotational speed, fuel level, energy input, linear speed, acceleration, temperature, strain, torque, volume, weight, etc.

[0657] The set of identifying criteria 158406a-n may include information for each of the set of attributes 158404a-n to uniquely identify the respective state. The identifying criteria 158406a-n may include, for example, rules, thresholds, limits, ranges, logical values, conditions, comparisons, combinations thereof, and the like.

[0658] The change in operating conditions or monitoring may be any suitable change. For example, after identifying occurrence of a respective state 158406a-n, the digital twin system 15500 may increase or decrease monitoring intervals for a device (e.g., decreasing monitoring intervals in response to a measured parameter differing from nominal operation) without altering operation of the device. Additionally or alternatively, the digital twin system 15500 may alter operation of the device (e.g., reduce speed or power input) without altering monitoring of the device. In further embodiments, the digital twin system 15500 may alter operation of the device (e.g., reduce speed or power input) and alter monitoring intervals for the device (e.g., decreasing monitoring intervals).

[0659] FIG. 158 illustrates an example set of identified states 15840a-n related to industrial environments that the digital twin system 15500 may identify and/or store for access by intelligent systems (e.g., the cognitive intelligence system 15510) or users of the digital twin system 15500, according to some embodiments of the present disclosure. The states 15840a-n may include operational states (e.g., suboptimal, normal, optimal, critical, or alarm operation of one or more components), excess or shortage states (e.g., supply-side or output-side quantities), combinations thereof, and the like.

[0660] In embodiments, the digital twin system 15500 may monitor attributes 158404a-n of real-world elements 157302r and/or digital twins 157302d to determine the respective state 15840a-n. The attributes 158404a-n may be, for example, operating conditions, set points, critical points, status indicators, other sensed information, combinations thereof, and the like. For example, the attributes 158404a-n may include power input 158404a, operational speed 158404b, critical speed 158404c, and operational temperature 158404d of the monitored elements. While the illustrated example illustrates uniform monitored attributes, the monitored attributes may differ by target device (e.g., the digital twin system 15500 would not monitor rotational speed for an object with no rotatable components).

[0661] Each of the states 15840a-n includes a set of identifying criteria 158406a-n meeting particular criteria that are unique among the group of monitored states 13240a-n. The digital twin system 15500 may identify the overspeed state 15540a, for example, in response to the monitored attributes 158404a-n meeting a first set of identifying criteria 158406a (e.g., operational speed 158404b being higher than the critical speed 158404c, while the operational temperature 158404d is nominal).

[0662] In response to determining that one or more states 15840a-n exists or has occurred, the digital twin system 15500 may update triggering conditions for one or more monitoring protocols, issue an alert or notification, or trigger actions of subcomponents of the digital twin system 15500. For example, subcomponents of the digital twin system 15500 may take actions to mitigate and/or evaluate impacts of the detected states 15540a-n. When attempting to take actions to mitigate impacts of the detected states 15540a-n on real-world elements 157302r, the digital twin system 15500 may determine whether instructions exist (e.g., are stored in the digital twin datastore 15516) or should be developed (e.g., developed via simulation and cognitive intelligence or via user or worker input). Further, the digital twin system 15500 may evaluate impacts of the detected states 15540a-n, for example, concurrently with the mitigation actions or in response to determining that the digital twin system 15500 has no stored mitigation instructions for the detected states 15540a-n.

[0663] In embodiments, the digital twin system 15500 employs the digital twin simulation system 15506 to simulate one or more impacts, such as immediate, upstream, downstream, and/or continuing effects, of recognized states. The digital twin simulation system 15506 may collect and/or be provided with values relevant to the evaluated states 15540a-n. In simulating the impact of the one or more states 15540a-n, the digital twin simulation system 15506 may recursively evaluate performance characteristics of affected digital twins 157302d until convergence is achieved. The digital twin simulation system 15506 may work, for example, in tandem with the cognitive intelligence system 15510 to determine response actions to alleviate, mitigate, inhibit, and/or prevent occurrence of the one or more states 15540a-n. For example, the digital twin simulation system 15506 may recursively simulate impacts of the one or more states 15540a-n until achieving a desired fit (e.g., convergence is achieved), provide the simulated values to the cognitive intelligence system 15510 for evaluation and determination of potential actions, receive the potential actions, evaluate impacts of each of the potential actions for a respective desired fit (e.g., cost functions for minimizing production disturbance, preserving critical components, minimizing maintenance and/or downtime, optimizing system, worker, user, or personal safety, etc.).

[0664] In embodiments, the digital twin simulation system 15506 and the cognitive intelligence system 15510 may repeatedly share and update the simulated values and response actions for each desired outcome until desired conditions are met (e.g., convergence for each evaluated cost function for each evaluated action). The digital twin system 15500 may store the results in the digital twin datastore 15516 for use in response to determining that one or more states 15540a-n has occurred. Additionally, simulations and evaluations by the digital twin simulation system 15506 and/or the cognitive intelligence system 15510 may occur in response to occurrence or detection of the event.

[0665] In embodiments, simulations and evaluations are triggered only when associated actions are not present within the digital twin system 15500. In further embodiments, simulations and evaluations are performed concurrently with use of stored actions to evaluate the efficacy or effectiveness of the actions in real time and/or evaluate whether further actions should be employed or whether unrecognized states may have occurred. In embodiments, the cognitive intelligence system 15510 may also be provided with notifications of instances of undesired actions with or without data on the undesired aspects or results of such actions to optimize later evaluations.

[0666] In embodiments, the digital twin system 15500 evaluates and/or represents the impact of machine downtime within a digital twin of a manufacturing facility. For example, the digital twin system 15500 may employ the digital twin simulation system 15506 to simulate the immediate, upstream, downstream, and/or continuing effects of a machine downtime state 15540b. The digital twin simulation system 15506 may collect or be provided with performance-related values such as optimal, suboptimal, and minimum performance requirements for elements (e.g., real-world elements 157302r and/or nested digital twins 157302d) within the affected digital twins 157302d, and/or characteristics thereof that are available to the affected digital twins 157302d, nested digital twins 157302d, redundant systems within the affected digital twins 157302d, combinations thereof, and the like.

[0667] In embodiments, the digital twin system 15500 is configured to: simulate one or more operating parameters for the real-world elements in response to the industrial environment being supplied with given characteristics using the real-world-element digital twins; calculate a mitigating action to be taken by one or more of the real-world elements in response to being supplied with the contemporaneous characteristics; and actuate, in response to detecting the contemporaneous characteristics, the mitigating action. The calculation may be performed in response to detecting contemporaneous characteristics or operating parameters falling outside of respective design parameters or may be determined via a simulation prior to detection of such characteristics.

[0668] Additionally or alternatively, the digital twin system 15500 may provide alerts to one or more users or system elements in response to detecting states.

[0669] In embodiments (FIG. 157), the digital twin I/O system 15504 includes a pathing module 157310. The pathing module 157310 may ingest navigational data from the elements 157302, provide and/or request navigational data to components of the digital twin system 15500 (e.g., the digital twin simulation system 15506, the digital twin behavior system, and/or the cognitive intelligence system 15510), and/or output navigational data to elements 157302 (e.g., to the wearable devices 15554). The navigational data may be collected or estimated using, for example, historical data, guidance data provided to the elements 157302, combinations thereof, and the like.

[0670] For example, the navigational data may be collected or estimated using historical data stored by the digital twin system 15500. The historical data may include or be processed to provide information such as acquisition time, associated elements 157302, polling intervals, task performed, laden or unladen conditions, whether prior guidance data was provided and/or followed, conditions of the environment 15520, other elements 157302 within the environment 15520, combinations thereof, and the like. The estimated data may be determined using one or more suitable pathing algorithms. For example, the estimated data may be calculated using suitable order-picking algorithms, suitable path-search algorithms, combinations thereof, and the like. The order-picking algorithm may be, for example, a largest gap algorithm, an s-shape algorithm, an aisle-by-aisle algorithm, a combined algorithm, combinations thereof, and the like. The path-search algorithms may be, for example, Dijkstra's algorithm, the A* algorithm, hierarchical path-finding algorithms, incremental path-finding algorithms, any angle path-finding algorithms, flow field algorithms, combinations thereof, and the like.

[0671] Additionally or alternatively, the navigational data may be collected or estimated using guidance data of the worker. The guidance data may include, for example, a calculated route provided to a device of the worker (e.g., a mobile device or the wearable device 15554). In another example, the guidance data may include a calculated route provided to a device of the worker that instructs the worker to collect vibration measurements from one or more locations on one or more machines along the route. The collected and/or estimated navigational data may be provided to a user of the digital twin system 15500 for visualization, used by other components of the digital twin system 15500 for analysis, optimization, and/or alteration, provided to one or more elements 157302, combinations thereof, and the like.

[0672] In embodiments, the digital twin system 15500 ingests navigational data for a set of workers for representation in a digital twin. Additionally or alternatively, the digital twin system 15500 ingests navigational data for a set of mobile equipment assets of an industrial environment into a digital twin.

[0673] In embodiments, the digital twin system 15500 ingests a system for modeling traffic of mobile elements in an industrial digital twin. For example, the digital twin system 15500 may model traffic patterns for workers or persons within the environment 15520, mobile equipment assets, combinations thereof, and the like. The traffic patterns may be estimated based on modeling traffic patterns from and historical data and contemporaneous ingested data. Further, the traffic patterns may be continuously or intermittently updated depending on conditions within the environment 15520 (e.g., a plurality of autonomous mobile equipment assets may provide information to the digital twin system 15500 at a slower update interval than the environment 15520 including both workers and mobile equipment assets).

[0674] The digital twin system 15500 may alter traffic patterns (e.g., by providing updated navigational data to one or more of the mobile elements) to achieve one or more predetermined criteria. The predetermined criteria may include, for example, increasing process efficiency, decreasing interactions between laden workers and mobile equipment assets, minimizing worker path length, routing mobile equipment around paths or potential paths of persons, combinations thereof, and the like.

[0675] In embodiments, the digital twin system 15500 may provide traffic data and/or navigational information to mobile elements in an industrial digital twin. The navigational information may be provided as instructions or rule sets, displayed path data, or selective actuation of devices. For example, the digital twin system 15500 may provide a set of instructions to a robot to direct the robot to and/or along a desired route for collecting vibration data from one or more specified locations on one or more specified machines along the route using a vibration sensor. The robot may communicate updates to the system including obstructions, reroutes, unexpected interactions with other assets within the environment 15520, etc.

[0676] In some embodiments, an ant-based system 15574 enables industrial entities, including robots, to lay a trail with one or more messages for other industrial entities, including themselves, to follow in later journeys. In embodiments, the messages include information related to vibration measurement collection. In embodiments, the messages include information related to vibration sensor measurement locations. In some embodiments, the trails may be configured to fade over time. In some embodiments, the ant-based trails may be experienced via an augmented reality system. In some embodiments, the ant-based trails may be experienced via a virtual reality system. In some embodiments, the ant-based trails may be experienced via a mixed reality system. In some embodiments, ant-based tagging of areas can trigger a pain-response and/or accumulate into a warning signal. In embodiments, the ant-based trails may be configured to generate an information filtering response. In some embodiments, the ant-based trails may be configured to generate an information filtering response wherein the information filtering response is a heightened sense of visual awareness. In some embodiments, the ant-based trails may be configured to generate an information filtering response wherein the information filtering response is a heightened sense of acoustic awareness. In some embodiments, the messages include vectorized data.

[0677] In embodiments, the digital twin system 15500 includes design specification information for representing a real-world element 157302r using a digital twin 157302d. The digital may correspond to an existing real-world element 157302r or a potential real-world element 157302r. The design specification information may be received from one or more sources. For example, the design specification information may include design parameters set by user input, determined by the digital twin system 15500 (e.g., the via digital twin simulation system 15506), optimized by users or the digital twin simulation system 15506, combinations thereof, and the like. The digital twin simulation system 15506 may represent the design specification information for the component to users, for example, via a display device or a wearable device. The design specification information may be displayed schematically (e.g., as part of a process diagram or table of information) or as part of an augmented reality or virtual reality display. The design specification information may be displayed, for example, in response to a user interaction with the digital twin system 15500 (e.g., via user selection of the element or user selection to generally include design specification information within displays). Additionally or alternatively, the design specification information may be displayed automatically, for example, upon the element coming within view of an augmented reality or virtual reality device. In embodiments, the displayed design specification information may further include indicia of information source (e.g., different displayed colors indicate user input versus digital twin system 15500 determination), indicia of mismatches (e.g., between design specification information and operational information), combinations thereof, and the like.

[0678] In embodiments, the digital twin system 15500 embeds a set of control instructions for a wearable device within an industrial digital twin, such that the control instructions are provided to the wearable device to induce an experience for a wearer of the wearable device upon interaction with an element of the industrial digital twin. The induced experience may be, for example, an augmented reality experience or a virtual reality experience. The wearable device, such as a headset, may be configured to output video, audio, and/or haptic feedback to the wearer to induce the experience. For example, the wearable device may include a display device and the experience may include display of information related to the respective digital twin. The information displayed may include maintenance data associated with the digital twin, vibration data associated with the digital twin, vibration measurement location data associated with the digital twin, financial data associated with the digital twin, such as a profit or loss associated with operation of the digital twin, manufacturing KPIs associated with the digital twin, information related to an occluded element (e.g., a sub-assembly) that is at least partially occluded by a foreground element (e.g., a housing), a virtual model of the occluded element overlaid on the occluded element and visible with the foreground element, operating parameters for the occluded element, a comparison to a design parameter corresponding to the operating parameter displayed, combinations thereof, and the like. Comparisons may include, for example, altering display of the operating parameter to change a color, size, and/or display period for the operating parameter.

[0679] In some embodiments, the displayed information may include indicia for removable elements that are or may be configured to provide access to the occluded element with each indicium being displayed proximate to or overlying the respective removable element. Further, the indicia may be sequentially displayed such that a first indicium corresponding to a first removable element (e.g., a housing) is displayed, and a second indicium corresponding to a second removable element (e.g., an access panel within the housing) is displayed in response to the worker removing the first removable element. In some embodiments, the induced experience allows the wearer to see one or more locations on a machine for optimal vibration measurement collection. In an example, the digital twin system 15500 may provide an augmented reality view that includes highlighted vibration measurement collection locations on a machine and/or instructions related to collecting vibration measurements. Furthering the example, the digital twin system 15500 may provide an augmented reality view that includes instructions related to timing of vibration measurement collection. Information utilized in displaying the highlighted placement locations may be obtained using information stored by the digital twin system 15500. In some embodiments, mobile elements may be tracked by the digital twin system 15500 (e.g., via observational elements within the environment 15520 and/or via pathing information communicated to the digital twin system 15500) and continually displayed by the wearable device within the occluded view of the worker. This optimizes movement of elements within the environment 15520, increases worker safety, and minimizes down time of elements resulting from damage.

[0680] In some embodiments, the digital twin system 15500 may provide an augmented reality view that displays mismatches between design parameters or expected parameters of real-world elements 157302r to the wearer. The displayed information may correspond to real-world elements 157302r that are not within the view of the wearer (e.g., elements within another room or obscured by machinery). This allows the worker to quickly and accurately troubleshoot mismatches to determine one or more sources for the mismatch. The cause of the mismatch may then be determined, for example, by the digital twin system 15500 and corrective actions ordered. In example embodiments, a wearer may be able to view malfunctioning subcomponents of machines without removing occluding elements (e.g., housings or shields). Additionally or alternatively, the wearer may be provided with instructions to repair the device, for example, including display of the removal process (e.g., location of fasteners to be removed), assemblies or subassemblies that should be transported to other areas for repair (e.g., dust-sensitive components), assemblies or subassemblies that need lubrication, and locations of objects for reassembly (e.g., storing location that the wearer has placed removed objects and directing the wearer or another wearer to the stored locations to expedite reassembly and minimize further disassembly or missing parts in the reassembled element). This can expedite repair work, minimize process impact, allow workers to disassemble and reassemble equipment (e.g., by coordinating disassembly without direct communication between the workers), increase equipment longevity and reliability (e.g., by assuring that all components are properly replaced prior to placing back in service), combinations thereof, and the like.

[0681] In some embodiments, the induced experience includes a virtual reality view or an augmented reality view that allows the wearer to see information related to existing or planned elements. The information may be unrelated to physical performance of the element (e.g., financial performance such as asset value, energy cost, input material cost, output material value, legal compliance, and corporate operations). One or more wearers may perform a virtual walkthrough or an augmented walkthrough of the industrial environment 15520.

[0682] In examples, the wearable device displays compliance information that expedites inspections or performance of work.

[0683] In further examples, the wearable device displays financial information that is used to identify targets for alteration or optimization. For example, a manager or officer may inspect the environment 15520 for compliance with updated regulations, including information regarding compliance with former regulations, “grandfathered,” and/or excepted elements. This can be used to reduce unnecessary downtime (e.g., scheduling upgrades for the least impactful times, such as during planned maintenance cycles), prevent unnecessary upgrades (e.g., replacing grandfathered or excepted equipment), and reduce capital investment.

[0684] Referring back to FIG. 155, in embodiments, the digital twin system 15500 may include, integrate, integrate with, manage, handle, link to, take input from, provide output to, control, coordinate with, or otherwise interact with a digital twin dynamic model system 15508. The digital twin dynamic model system 15508 can update the properties of a set of digital twins of a set of industrial entities and/or environments, including properties of physical industrial assets, workers, processes, manufacturing facilities, warehouses, and the like (or any of the other types of entities or environments described in this disclosure or in the documents incorporated by reference herein) in such a manner that the digital twins may represent those industrial entities and environments, and properties or attributes thereof, in real-time or very near real-time. In some embodiments, the digital twin dynamic model system 15508 may obtain sensor data received from a sensor system 15530 and may determine one or more properties of an industrial environment or an industrial entity within an environment based on the sensor data and based on one or more dynamic models.

[0685] In embodiments, the digital twin dynamic model system 15508 may update/assign values of various properties in a digital twin and/or one or more embedded digital twins, including, but not limited to, vibration values, vibration fault level states, probability of failure values, probability of downtime values, cost of downtime values, probability of shutdown values, financial values, KPI values, temperature values, humidity values, heat flow values, fluid flow values, radiation values, substance concentration values, velocity values, acceleration values, location values, pressure values, stress values, strain values, light intensity values, sound level values, volume values, shape characteristics, material characteristics, and dimensions.

[0686] In embodiments, a digital twin may be comprised of (e.g., via reference) of other embedded digital twins. For example, a digital twin of a manufacturing facility may include an embedded digital twin of a machine and one or more embedded digital twins of one or more respective motors enclosed within the machine. A digital twin may be embedded, for example, in the memory of an industrial machine that has an onboard IT system (e.g., the memory of an Onboard Diagnostic System, control system (e.g., SCADA system) or the like). Other non-limiting examples of where a digital twin may be embedded include the following: on a wearable device of a worker; in memory on a local network asset, such as a switch, router, access point, or the like; in a cloud computing resource that is provisioned for an environment or entity; and on an asset tag or other memory structure that is dedicated to an entity.

[0687] In one example, the digital twin dynamic model system 15508 can update vibration characteristics throughout an industrial environment digital twin based on captured vibration sensor data measured at one or more locations in the industrial environment and one or more dynamic models that model vibration within the industrial environment digital twin. The industrial digital twin may, before updating, already contain information about properties of the industrial entities and/or environment that can be used to feed a dynamic model, such as information about materials, shapes/volumes (e.g., of conduits), positions, connections/interfaces, and the like, such that vibration characteristics can be represented for the entities and/or environment in the digital twin. Alternatively, the dynamic models may be configured using such information.

[0688] In embodiments, the digital twin dynamic model system 15508 can update the properties of a digital twin and/or one or more embedded digital twins on behalf of a client application 15570. In embodiments, a client application 15570 may be an application relating to an industrial component or environment (e.g., monitoring an industrial facility or a component within, simulating an industrial environment, or the like). In embodiments, the client application 15570 may be used in connection with both fixed and mobile data collection systems. In embodiments, the client application 15570 may be used in connection with Industrial Internet of Things sensor system 15530.

[0689] In embodiments, the digital twin dynamic model system 15508 leverages digital twin dynamic models 155100 to model the behavior of an industrial entity and/or environment. Dynamic models 155100 may enable digital twins to represent physical reality, including the interactions of industrial entities, by using a limited number of measurements to enrich the digital representation of an industrial entity and/or environment, such as based on scientific principles. In embodiments, the dynamic models 155100 are formulaic or mathematical models. In embodiments, the dynamic models 155100 adhere to scientific laws, laws of nature, and formulas (e.g., Newton's laws of motion, second law of thermodynamics, Bernoulli's principle, ideal gas law, Dalton's law of partial pressures, Hooke's law of elasticity, Fourier's law of heat conduction, Archimedes' principle of buoyancy, and the like). In embodiments, the dynamic models are machine-learned models.

[0690] In embodiments, the digital twin system 15500 may have a digital twin dynamic model datastore 155102 for storing dynamic models 155100 that may be represented in digital twins. In embodiments, digital twin dynamic model datastore can be searchable and/or discoverable. In embodiments, digital twin dynamic model datastore can contain metadata that allows a user to understand what characteristics a given dynamic model can handle, what inputs are required, what outputs are provided, and the like. In some embodiments, digital twin dynamic model datastore 155102 can be hierarchical (such as where a model can be deepened or made more simple based on the extent of available data and/or inputs, the granularity of the inputs, and/or situational factors (such as where something becomes of high interest and a higher fidelity model is accessed for a period of time).

[0691] In embodiments, a digital twin or digital representation of an industrial entity or facility may include a set of data structures that collectively define a set of properties of a represented physical industrial asset, device, worker, process, facility, and/or environment, and/or possible behaviors thereof. In embodiments, the digital twin dynamic model system 15508 may leverage the dynamic models 155100 to inform the set of data structures that collectively define a digital twin with real-time data values. The digital twin dynamic models 155100 may receive one or more sensor measurements, Industrial Internet of Things device data, and/or other suitable data as inputs and calculate one or more outputs based on the received data and one or more dynamic models 155100. The digital twin dynamic model system 15508 then uses the one or more outputs to update the digital twin data structures.

[0692] In one example, the set of properties of a digital twin of an industrial asset that may be updated by the digital twin dynamic model system 15508 using dynamic models 155100 may include the vibration characteristics of the asset, temperature(s) of the asset, the state of the asset (e.g., a solid, liquid, or gas), the location of the asset, the displacement of the asset, the velocity of the asset, the acceleration of the asset, probability of downtime values associated with the asset, cost of downtime values associated with the asset, probability of shutdown values associated with the asset, manufacturing KPIs associated with the asset, financial information associated with the asset, heat flow characteristics associated with the asset, fluid flow rates associated with the asset (e.g., fluid flow rates of a fluid flowing through a pipe), identifiers of other digital twins embedded within the digital twin of the asset and/or identifiers of digital twins embedding the digital twin of the asset, and/or other suitable properties. Dynamic models 155100 associated with a digital twin of an asset can be configured to calculate, interpolate, extrapolate, and/or output values for such asset digital twin properties based on input data collected from sensors and/or devices disposed in the industrial setting and/or other suitable data and subsequently populate the asset digital twin with the calculated values.

[0693] In some embodiments, the set of properties of a digital twin of an industrial device that may be updated by the digital twin dynamic model system 15508 using dynamic models 155100 may include the status of the device, a location of the device, the temperature(s) of a device, a trajectory of the device, identifiers of other digital twins that the digital twin of the device is embedded within, embeds, is linked to, includes, integrates with, takes input from, provides output to, and/or interacts with and the like. Dynamic models 155100 associated with a digital twin of a device can be configured to calculate or output values for these device digital twin properties based on input data and subsequently update the device digital twin with the calculated values.

[0694] In some embodiments, the set of properties of a digital twin of an industrial worker that may be updated by the digital twin dynamic model system 15508 using dynamic models 155100 may include the status of the worker, the location of the worker, a stress measure for the worker, a task being performed by the worker, a performance measure for the worker, and the like. Dynamic models associated with a digital twin of an industrial worker can be configured to calculate or output values for such properties based on input data, which then may be used to populate industrial worker digital twin. In embodiments, industrial worker dynamic models (e.g., psychometric models) can be configured to predict reactions to stimuli, such as cues that are given to workers to direct them to undertake tasks and/or alerts or warnings that are intended to induce safe behavior. In embodiments, industrial worker dynamic models may be workflow models (Gantt charts and the like), failure mode effects analysis models (FMEA), biophysical models (such as to model worker fatigue, energy utilization, hunger), and the like.

[0695] Example properties of a digital twin of an industrial environment that may be updated by the digital twin dynamic model system 15508 using dynamic models 155100 may include the dimensions of the industrial environment, the temperature(s) of the industrial environment, the humidity value(s) of the industrial environment, the fluid flow characteristics in the industrial environment, the heat flow characteristics of the industrial environment, the lighting characteristics of the industrial environment, the acoustic characteristics of the industrial environment the physical objects in the environment, processes occurring in the industrial environment, currents of the industrial environment (if a body of water), and the like. Dynamic models associated with a digital twin of an industrial environment can be configured to calculate or output these properties based on input data collected from sensors and/or devices disposed in the industrial environment and/or other suitable data and subsequently populate the industrial environment digital twin with the calculated values.

[0696] In embodiments, dynamic models 155100 may adhere to physical limitations that define boundary conditions, constants or variables for digital twin modeling. For example, the physical characterization of a digital twin of an industrial entity or industrial environment may include a gravity constant (e.g., 9.8 m/s2), friction coefficients of surfaces, thermal coefficients of materials, maximum temperatures of assets, maximum flow capacities, and the like. Additionally or alternatively, the dynamic models may adhere to the laws of nature. For example, dynamic models may adhere to the laws of thermodynamics, laws of motion, laws of fluid dynamics, laws of buoyancy, laws of heat transfer, laws or radiation, laws of quantum dynamics, and the like. In some embodiments, dynamic models may adhere to biological aging theories or mechanical aging principles. Thus, when the digital twin dynamic model system 15508 facilitates a real-time digital representation, the digital representation may conform to dynamic models, such that the digital representations mimic real world conditions. In some embodiments, the output(s) from a dynamic model can be presented to a human user and/or compared against real-world data to ensure convergence of the dynamic models with the real world. Furthermore, as dynamic models are based partly on assumptions, the properties of a digital twin may be improved and/or corrected when a real-world behavior differs from that of the digital twin. In embodiments, additional data collection and/or instrumentation can be recommended based on the recognition that an input is missing from a desired dynamic model, that a model in operation isn't working as expected (perhaps due to missing and/or faulty sensor information), that a different result is needed (such as due to situational factors that make something of high interest), and the like.

[0697] Dynamic models may be obtained from a number of different sources. In some embodiments, a user can upload a model created by the user or a third party. Additionally or alternatively, the models may be created on the digital twin system using a graphical user interface. The dynamic models may include bespoke models that are configured for a particular environment and/or set of industrial entities and/or agnostic models that are applicable to similar types of digital twins. The dynamic models may be machine-learned models.

[0698] FIG. 159 illustrates example embodiments of a method for updating a set of properties of a digital twin and/or one or more embedded digital twins on behalf of client applications 15570. In embodiments, digital twin dynamic model system 15508 leverages one or more dynamic models 155100 to update a set of properties of a digital twin and/or one or more embedded digital twins on behalf of client application 15570 based on the impact of collected sensor data from sensor system 15530, data collected from Internet of Things connected devices 15524, and/or other suitable data in the set of dynamic models 155100 that are used to enable the industrial digital twins. In embodiments, the digital twin dynamic model system 15508 may be instructed to run specific dynamic models using one or more digital twins that represent physical industrial assets, devices, workers, processes, and/or industrial environments that are managed, maintained, and/or monitored by the client applications 15570.

[0699] In embodiments, the digital twin dynamic model system 15508 may obtain data from other types of external data sources that are not necessarily industrial-related data sources, but may provide data that can be used as input data for the dynamic models. For example, weather data, news events, social media data, and the like may be collected, crawled, subscribed to, and the like to supplement sensor data, Industrial Internet of Things device data, and/or other data that is used by the dynamic models. In embodiments, the digital twin dynamic model system 15508 may obtain data from a machine vision system. The machine vision system may use video and/or still images to provide measurements (e.g., locations, statuses, and the like) that may be used as inputs by the dynamic models.

[0700] In embodiments, the digital twin dynamic model system 15508 may feed this data into one or more of the dynamic models discussed above to obtain one or more outputs. These outputs may include calculated vibration fault level states, vibration severity unit values, vibration characteristics, probability of failure values, probability of downtime values, probability of shutdown values, cost of downtime values, cost of shutdown values, time to failure values, temperature values, pressure values, humidity values, precipitation values, visibility values, air quality values, strain values, stress values, displacement values, velocity values, acceleration values, location values, performance values, financial values, manufacturing KPI values, electrodynamic values, thermodynamic values, fluid flow rate values, and the like. The client application 15570 may then initiate a digital twin visualization event using the results obtained by the digital twin dynamic model system 15508. In embodiments, the visualization may be a heat map visualization.

[0701] In embodiments, the digital twin dynamic model system 15508 may receive requests to update one or more properties of digital twins of industrial entities and/or environments such that the digital twins represent the industrial entities and/or environments in real-time. At 159100, the digital twin dynamic model system 15508 receives a request to update one or more properties of one or more of the digital twins of industrial entities and/or environments. For example, the digital twin dynamic model system 15508 may receive the request from a client application 15570 or from another process executed by the digital twin system 15500 (e.g., a predictive maintenance process). The request may indicate the one or more properties and the digital twin or digital twins implicated by the request. Referring to FIG. 159, in step 159102, the digital twin dynamic model system 15508 determines the one or more digital twins required to fulfill the request and retrieves the one or more required digital twins, including any embedded digital twins, from digital twin datastore 15516. At 159104, digital twin dynamic model system 15508 determines one or more dynamic models required to fulfill the request and retrieves the one or more required dynamic models from digital twin dynamic model datastore 155102. At 159106, the digital twin dynamic model system 15508 selects one or more sensors from sensor system 15530, data collected from Internet of Things connected devices 15524, and/or other data sources from digital twin I/O system 15504 based on available data sources and the one or more required inputs of the dynamic model(s). In embodiments, the data sources may be defined in the inputs required by the one or more dynamic models or may be selected using a lookup table. At 159108, the digital twin dynamic model system 15508 retrieves the selected data from digital twin I/O system 15504. At 159110, digital twin dynamic model system 15508 runs the dynamic model(s) using the retrieved input data (e.g., vibration sensor data, Industrial Internet of Things device data, and the like) as inputs and determines one or more output values based on the dynamic model(s) and the input data. At 159112, the digital twin dynamic model system 15508 updates the values of one or more properties of the one or more digital twins based on the one or more outputs of the dynamic model(s).

[0702] In example embodiments, client application 15570 may be configured to provide a digital representation and/or visualization of the digital twin of an industrial entity. In embodiments, the client application 15570 may include one or more software modules that are executed by one or more server devices. These software modules may be configured to quantify properties of the digital twin, model properties of a digital twin, and/or to visualize digital twin behaviors. In embodiments, these software modules may enable a user to select a particular digital twin behavior visualization for viewing. In embodiments, these software modules may enable a user to select to view a digital twin behavior visualization playback. In some embodiments, the client application 15570 may provide a selected behavior visualization to digital twin dynamic model system 15508.

[0703] In embodiments, the digital twin dynamic model system 15508 may receive requests from client application 15570 to update properties of a digital twin in order to enable a digital representation of an industrial entity and/or environment wherein the real-time digital representation is a visualization of the digital twin. In embodiments, a digital twin may be rendered by a computing device, such that a human user can view the digital representations of real-world industrial assets, devices, workers, processes and/or environments. For example, the digital twin may be rendered and outcome to a display device. In embodiments, dynamic model outputs and/or related data may be overlaid on the rendering of the digital twin. In embodiments, dynamic model outputs and/or related information may appear with the rendering of the digital twin in a display interface. In embodiments, the related information may include real-time video footage associated with the real-world entity represented by the digital twin. In embodiments, the related information may include a sum of each of the vibration fault level states in the machine. In embodiments, the related information may be graphical information. In embodiments, the graphical information may depict motion and/or motion as a function of frequency for individual machine components. In embodiments, graphical information may depict motion and/or motion as a function of frequency for individual machine components, wherein a user is enabled to select a view of the graphical information in the x, y, and z dimensions. In embodiments, graphical information may depict motion and/or motion as a function of frequency for individual machine components, wherein the graphical information includes harmonic peaks and peaks. In embodiments, the related information may be cost data, including the cost of downtime per day data, cost of repair data, cost of new part data, cost of new machine data, and the like. In embodiments, related information may be a probability of downtime data, probability of failure data, and the like. In embodiments, related information may be time to failure data.

[0704] In embodiments, the related information may be recommendations and/or insights. For example, recommendations or insights received from the cognitive intelligence system related to a machine may appear with the rendering of the digital twin of a machine in a display interface.

[0705] In embodiments, clicking, touching, or otherwise interacting with the digital twin rendered in the display interface can allow a user to “drill down” and see underlying subsystems or processes and/or embedded digital twins. For example, in response to a user clicking on a machine bearing rendered in the digital twin of a machine, the display interface can allow a user to drill down and see information related to the bearing, view a 3D visualization of the bearing's vibration, and/or view a digital twin of the bearing.

[0706] In embodiments, clicking, touching, or otherwise interacting with information related to the digital twin rendered in the display interface can allow a user to “drill down” and see underlying information.

[0707] FIG. 160 illustrates example embodiments of a display interface that renders the digital twin of a dryer centrifuge and other information related to the dryer centrifuge.

[0708] In some embodiments, the digital twin may be rendered and output in a virtual reality display. For example, a user may view a 3D rendering of an environment (e.g., using a monitor or a virtual reality headset). The user may also inspect and/or interact with digital twins of industrial entities. In embodiments, a user may view processes being performed with respect to one or more digital twins (e.g., collecting measurements, movements, interactions, inventorying, loading, packing, shipping, and the like). In embodiments, a user may provide input that controls one or more properties of a digital twin via a graphical user interface.

[0709] In some embodiments, the digital twin dynamic model system 15508 may receive requests from client application 15570 to update properties of a digital twin in order to enable a digital representation of industrial entities and/or environments wherein the digital representation is a heat map visualization of the digital twin. In embodiments, a platform is provided having heat maps displaying collected data from the sensor system 15530, Internet of Things connected devices 15524, and data outputs from dynamic models 155100 for providing input to a display interface. In embodiments, the heat map interface is provided as an output for digital twin data, such as for handling and providing information for visualization of various sensor data, dynamic model output data, and other data (such as map data, analog sensor data, and other data), such as to another system, such as a mobile device, tablet, dashboard, computer, AR/VR device, or the like. A digital twin representation may be provided in a form factor (e.g., user device, VR-enabled device, AR-enabled device, or the like) suitable for delivering visual input to a user, such as the presentation of a map that includes indicators of levels of analog sensor data, digital sensor data, and output values from the dynamic models (such as data indicating vibration fault level states, vibration severity unit values, probability of downtime values, cost of downtime values, probability of shutdown values, time to failure values, probability of failure values, manufacturing KPIs, temperatures, levels of rotation, vibration characteristics, fluid flow, heating or cooling, pressure, substance concentrations, and many other output values). In embodiments, signals from various sensors or input sources (or selective combinations, permutations, mixes, and the like) as well as data determined by the digital twin dynamic model system 15508 may provide input data to a heat map. Coordinates may include real world location coordinates (such as geo-location or location on a map of an environment), as well as other coordinates, such as time-based coordinates, frequency-based coordinates, or other coordinates that allow for representation of analog sensor signals, digital signals, dynamic model outputs, input source information, and various combinations, in a map-based visualization, such that colors may represent varying levels of input along the relevant dimensions. For example, among many other possibilities, if an industrial machine component is at a critical vibration fault level state, the heat map interface may alert a user by showing the machine component in orange. In the example of a heat map, clicking, touching, or otherwise interacting with the heat map can allow a user to drill down and see underlying sensor, dynamic model outputs, or other input data that is used as an input to the heat map display. In other examples, such as ones where a digital twin is displayed in a VR or AR environment, if an industrial machine component is vibrating outside of normal operation (e.g., at a suboptimal, critical, or alarm vibration fault level), a haptic interface may induce vibration when a user touches a representation of the machine component, or if a machine component is operating in an unsafe manner, a directional sound signal may direct a user's attention toward the machine in digital twin, such as by playing in a particular speaker of a headset or other sound system.

[0710] In embodiments, the digital twin dynamic model system 15508 may take a set of ambient environmental data and/or other data and automatically update a set of properties of a digital twin of an industrial entity or facility based on the impact of the environmental data and/or other data in the set of dynamic models 155100 that are used to enable the digital twin. Ambient environmental data may include temperature data, pressure data, humidity data, wind data, rainfall data, tide data, storm surge data, cloud cover data, snowfall data, visibility data, water level data, and the like. Additionally or alternatively, the digital twin dynamic model system 15508 may use a set of environmental data measurements collected by a set of Internet of Things connected devices 15524 disposed in an industrial setting as inputs for the set of dynamic models 155100 that are used to enable the digital twin. For example, digital twin dynamic model system 15508 may feed the dynamic models 155100 data collected, handled or exchanged by Internet of Things connected devices 15524, such as cameras, monitors, embedded sensors, mobile devices, diagnostic devices and systems, instrumentation systems, telematics systems, and the like, such as for monitoring various parameters and features of machines, devices, components, parts, operations, functions, conditions, states, events, workflows and other elements (collectively encompassed by the term “states”) of industrial environments. Other examples of Internet of Things connected devices include smart fire alarms, smart security systems, smart air quality monitors, smart/learning thermostats, and smart lighting systems.

[0711] FIG. 161 illustrates example embodiments of a method for updating a set of vibration fault level states for a set of bearings in a digital twin of a machine. In this example, a client application 15570, which interfaces with digital twin dynamic model system 15508, may be configured to provide a visualization of the fault level states of the bearings in the digital twin of the machine.

[0712] In this example, the digital twin dynamic model system 15508 may receive requests from client application 15570 to update the vibration fault level states of the machine digital twin. At 161200, digital twin dynamic model system 15508 receives a request from client application 15570 to update one or more vibration fault level states of the machine digital twin. Next, in step 161202, digital twin dynamic model system 15508 determines the one or more digital twins required to fulfill the request and retrieves the one or more required digital twins from digital twin datastore 15516. In this example, the digital twin dynamic model system 15508 may retrieve the digital twin of the machine and any embedded digital twins, such as any embedded motor digital twins and bearing digital twins, and any digital twins that embed the machine digital twin, such as the manufacturing facility digital twin. At 161204, digital twin dynamic model system 15508 determines one or more dynamic models required to fulfill the request and retrieves the one or more required dynamic models from the digital twin dynamic model datastore 155102. At 161206, the digital twin dynamic model system 15508 selects dynamic model input data sources (e.g., one or more sensors from sensor system 15530, data from Internet of Things connected devices 15524, and any other suitable data) via digital twin I/O system 15504 based on available data sources (e.g., available sensors from a set of sensors in sensor system 15530) and the and the one or more required inputs of the dynamic model(s). In the present example, the retrieved dynamic model(s) 155100 may take one or more vibration sensor measurements from vibration sensors 15536 as inputs to the dynamic models. In embodiments, vibration sensors 15536 may be optical vibration sensors, single axis vibration sensors, tri-axial vibration sensors, and the like. At 161208, digital twin dynamic model system 15508 retrieves one or more measurements from each of the selected data sources from the digital twin I/O system 15504. Next, At 161210, digital twin dynamic model system 15508 runs the dynamic model(s), using the retrieved vibration sensor measurements as inputs, and calculates one or more outputs that represent bearing vibration fault level states. Next, At 161212, the digital twin dynamic model system 15508 updates one or more bearing fault level states of the manufacturing facility digital twin, machine digital twin, motor digital twin, and/or bearing digital twins based on the one or more outputs of the dynamic model(s). The client application 15570 may obtain vibration fault level states of the bearings and may display the obtained vibration fault level state associated with each bearing and/or display colors associated with fault level severity (e.g., red for alarm, orange for critical, yellow for suboptimal, green for normal operation) in the rendering of one or more of the digital twins on a display interface.

[0713] In another example, a client application 15570 may be an augmented reality application. In some embodiments of this example, the client application 15570 may obtain vibration fault level states of bearings in a field of view of an AR-enabled device (e.g., smart glasses) hosting the client application from the digital twin of the industrial environment (e.g., via an API of the digital twin system 15500) and may display the obtained vibration fault level states on the display of the AR-enabled device, such that the vibration fault level state displayed corresponds to the location in the field of view of the AR-enabled device. In this way, a vibration fault level state may be displayed even if there are no vibration sensors located within the field of view of the AR-enabled device.

[0714] FIG. 162 illustrates example embodiments of a method for updating a set of vibration severity unit values of bearings in a digital twin of a machine. Vibration severity units may be measured as displacement, velocity, and acceleration.

[0715] In this example, client application 15570 that interfaces with the digital twin dynamic model system 15508 may be configured to provide a visualization of the three-dimensional vibration characteristics of bearings in a digital twin of a machine.

[0716] In this example, the digital twin dynamic model system 15508 may receive requests from client application 15570 to update the vibration severity unit values for bearings in the digital twin of a machine. At 162300, digital twin dynamic model system 15508 receives a request from client application 15570 to update one or more vibration severity unit value(s) of the manufacturing facility digital twin. Next, in step 162302, digital twin dynamic model system 15508 determines the one or more digital twins required to fulfill the request and retrieves the one or more required digital twins from digital twin datastore 15516. In this example, the digital twin dynamic model system 15508 may retrieve the digital twin of the machine and any embedded digital twins (e.g., digital twins of bearings and other components). At 162304, digital twin dynamic model system 15508 determines one or more dynamic models required to fulfill the request and retrieves the one or more required dynamic models from dynamic model datastore 155102. At 162306, the digital twin dynamic model system 15508 selects dynamic model input data sources (e.g., one or more sensors from sensor system 15530, data from Internet of Things connected devices 15524, and any other suitable data) via digital twin I/O system 15504 based on available data sources (e.g., available sensors from a set of sensors in sensor system 15530) and the one or more required inputs of the dynamic model(s). In the present example, the retrieved dynamic models may be configured to take one or more vibration sensor measurements as inputs and provide severity unit values for bearings in the machine. At 162308, digital twin dynamic model system 15508 retrieves one or more measurements from each of the selected sensors. In the present example, the digital twin dynamic model system 15508 retrieves measurements from vibration sensors 15536 via digital twin I/O system 15504. At 162310, digital twin dynamic model system 15508 runs the dynamic model(s) using the retrieved vibration measurements as inputs and calculates one or more output values that represent vibration severity unit values for bearings in the machine. Next, at 162312, the digital twin dynamic model system 15508 updates one or more vibration severity unit values of the bearings in the machine digital twin and all other embedded digital twins or digital twins that embed the machine digital twin based on the one or more values output by the dynamic model(s).

[0717] FIG. 163 illustrates example embodiments of a method for updating a set of probability of failure values for machine components in the digital twin of a machine.

[0718] In this example, the digital twin dynamic model system 15508 may receive requests from client application 15570 to update the probability of failure values for components in a machine digital twin. At 156400, digital twin dynamic model system 15508 receives a request from client application 15570 to update one or more probability of failure value(s) of the machine digital twin, any embedded component digital twins, and any digital twins that embed the machine digital twin such as a manufacturing facility digital twin. Next, in step 163402, digital twin dynamic model system 15508 determines the one or more digital twins required to fulfill the request and retrieves the one or more required digital twins. In this example, the digital twin dynamic model system 15508 may retrieve the digital twin of the manufacturing facility, the digital twin of the machine, and the digital twins of machine components from digital twin datastore 15516. At 163404, digital twin dynamic model system 15508 determines one or more dynamic models required to fulfill the request and retrieves the one or more required dynamic models from dynamic model datastore 155102. At 163406, the digital twin dynamic model system 15508 selects, via digital twin I/O system 15504, dynamic model input data sources (e.g., one or more sensors from sensor system 15530, data from Internet of Things connected devices 15524, and any other suitable data) based on available data sources (e.g., available sensors from a set of sensors in sensor system 15530) and the and the one or more required inputs of the dynamic model(s). In the present example, the retrieved dynamic models may take one or more vibration measurements from vibration sensors 15536 and historical failure data as dynamic model inputs and output probability of failure values for the machine components in the digital twin of the machine. At 163408, digital twin dynamic model system 15508 retrieves data from each of the selected sensors and/or Internet of Things connected devices via digital twin I/O system 15504. At 163410, digital twin dynamic model system 15508 runs the dynamic model(s) using the retrieved vibration data and historical failure data as inputs and calculates one or more outputs that represent probability of failure values for bearings in the machine digital twin. Next, At 163412, the digital twin dynamic model system 15508 updates one or more probability of failure values of the bearings in the machine digital twin, all embedded digital twins, and all digital twins that embed the machine digital twin based on the output of the dynamic model(s).

[0719] FIG. 164 illustrates example embodiments of a method for updating a set of probability of downtime for machines in the digital twin of a manufacturing facility.

[0720] In this example, client application 15570, which interfaces with the digital twin dynamic model system 15508, may be configured to provide a visualization of the probability of downtime values of a manufacturing facility in the digital twin of the manufacturing facility.

[0721] In this example, the digital twin dynamic model system 15508 may receive requests from client application 15570 to assign probability of downtime values to machines in a manufacturing facility digital twin. At 164500, digital twin dynamic model system 16208 receives a request from client application 15570 to update one or more probability of downtime values of machines in the manufacturing facility digital twin and any embedded digital twins such as the individual machine digital twins. Next, in step 164502, digital twin dynamic model system 15508 determines the one or more digital twins required to fulfill the request and retrieves the one or more required digital twins from digital twin datastore 15516. In this example, the digital twin dynamic model system 15508 may retrieve the digital twin of the manufacturing facility and any embedded digital twins from digital twin datastore 15516. At 164504, digital twin dynamic model system 15508 determines one or more dynamic models required to fulfill the request and retrieves the one or more required dynamic models from dynamic model datastore 155102. At 164506, the digital twin dynamic model system 15508 selects dynamic model input data sources (e.g., one or more sensors from sensor system 15530, data from Internet of Things connected devices 15524, and any other suitable data) based on available data sources (e.g., available sensors from a set of sensors in sensor system 15530) and the and the one or more required inputs of the dynamic model(s) via digital twin I/O system 15504. In the present example, the dynamic model(s) may be configured to take vibration measurements from vibration sensors and historical downtime data as inputs and output probability of downtime values for different machines throughout the manufacturing facility. At 164508, digital twin dynamic model system 15508 retrieves one or more measurements from each of the selected sensors via digital twin I/O system 15504. At 164510, digital twin dynamic model system 15508 runs the dynamic model(s) using the retrieved vibration measurements and historical downtime data as inputs and calculates one or more outputs that represent probability of downtime values for machines in the manufacturing facility. Next, At 164512, the digital twin dynamic model system 15508 updates one or more probability of downtime values for machines in the manufacturing facility digital twins and all embedded digital twins based on the one or more outputs of the dynamic models.

[0722] FIG. 165 illustrates example embodiments of a method for updating one or more probability of shutdown values in the digital twin of an enterprise having a set of manufacturing facilities.

[0723] In the present example, the digital twin dynamic model system 15508 may receive requests from client application 15570 to update the probability of shutdown values for the set of manufacturing facilities within an enterprise digital twin. At 165600, digital twin dynamic model system 15508 receives a request from client application 15570 to update one or more probability of shutdown values of the enterprise digital twin and any embedded digital twins. Next, in step 165602, digital twin dynamic model system 15508 determines the one or more digital twins required to fulfill the request and retrieves the one or more required digital twins from digital twin datastore 15516. In this example, the digital twin dynamic model system 15508 may retrieve the digital twin of the enterprise and any embedded digital twins. At 165604, digital twin dynamic model system 15508 determines one or more dynamic models required to fulfill the request and retrieves the one or more required dynamic models from dynamic model datastore 155102. At 165606, the digital twin dynamic model system 15508 selects dynamic model input data sources (e.g., one or more sensors from sensor system 15530, data from Internet of Things connected devices 15524, and any other suitable data) based on available data sources (e.g., available sensors from a set of sensors in sensor system 15530) and the and the one or more required inputs of the dynamic model(s) via digital twin I/O system 15504. In the present example, the retrieved dynamic models may be configured to take one or more vibration measurements from vibration sensors 15536 and/or other suitable data as inputs and output probability of shutdown values for each manufacturing entity in the enterprise digital twin. At 165608, digital twin dynamic model system 15508 retrieves one or more vibration measurements from each of the selected vibration sensors 15536 from digital twin I/O system 15504. At 165610, digital twin dynamic model system 15508 runs the dynamic model(s) using the retrieved vibration measurements and historical shut down data as inputs and calculates one or more outputs that represent probability of shutdown values for manufacturing facilities within the enterprise digital twin. Next, at 165612, the digital twin dynamic model system 15508 updates one or more probability of shutdown values of the enterprise digital twin and all embedded digital twins based on the one or more outputs of the dynamic model(s).

[0724] FIG. 166 illustrates example embodiments of a method for updating a set of cost of downtime values in machines in the digital twin of a manufacturing facility. In the present example, the digital twin dynamic model system 15508 may receive requests from a client application 15570 to populate real-time cost of downtime values associated with machines in a manufacturing facility digital twin. At 166700, digital twin dynamic model system 15508 receives a request from the client application 15570 to update one or more cost of downtime values of the manufacturing facility digital twin and any embedded digital twins (e.g., machines, machine parts, and the like) from the client application 15570. Next, in step 166702, the digital twin dynamic model system 15508 determines the one or more digital twins required to fulfill the request and retrieves the one or more required digital twins. In this example, the digital twin dynamic model system 15508 may retrieve the digital twins of the manufacturing facility, the machines, the machine parts, and any other embedded digital twins from digital twin datastore 15516. At 166704, digital twin dynamic model system 15508 determines one or more dynamic models required to fulfill the request and retrieves the one or more required dynamic models from dynamic model datastore 155102. At 166706, the digital twin dynamic model system 15508 selects dynamic model input data sources (e.g., one or more sensors from sensor system 15530, data from Internet of Things connected devices 15524, and any other suitable data) based on available data sources (e.g., available sensors from a set of sensors in sensor system 15530) and the and the one or more required inputs of the dynamic model(s) via digital twin I/O system 15504. In the present example, the retrieved dynamic model(s) may be configured to take historical downtime data and operational data as inputs and output data representing cost of downtime per day for machines in the manufacturing facility. At 166708, digital twin dynamic model system 15508 retrieves historical downtime data and operational data from digital twin I/O system 15504. At 166710, digital twin dynamic model system 15508 runs the dynamic model(s) using the retrieved data as input and calculates one or more outputs that represent cost of downtime per day for machines in the manufacturing facility. Next, at 166712, the digital twin dynamic model system 15508 updates one or more cost of downtime values of the manufacturing facility digital twins and machine digital twins based on the one or more outputs of the dynamic model(s).

[0725] FIG. 167 illustrates example embodiments of a method for updating a set of manufacturing KPI values in the digital twin of a manufacturing facility. In embodiments, the manufacturing KPI is selected from the set of uptime, capacity utilization, on standard operating efficiency, overall operating efficiency, overall equipment effectiveness, machine downtime, unscheduled downtime, machine set up time, inventory turns, inventory accuracy, quality (e.g., percent defective), first pass yield, rework, scrap, failed audits, on-time delivery, customer returns, training hours, employee turnover, reportable health & safety incidents, revenue per employee, and profit per employee, schedule attainment, total cycle time, throughput, changeover time, yield, planned maintenance percentage, availability, and customer return rate.

[0726] In the present example, the digital twin dynamic model system 15508 may receive requests from a client application 15570 to populate real-time manufacturing KPI values in a manufacturing facility digital twin. At 167800, digital twin dynamic model system 15508 receives a request from the client application 15570 to update one or more KPI values of the manufacturing facility digital twin and any embedded digital twins (e.g., machines, machine parts, and the like) from the client application 15570. Next, in step 167802, the digital twin dynamic model system 15508 determines the one or more digital twins required to fulfill the request and retrieves the one or more required digital twins. In this example, the digital twin dynamic model system 15508 may retrieve the digital twins of the manufacturing facility, the machines, the machine parts, and any other embedded digital twins from digital twin datastore 15516. At 167804, digital twin dynamic model system 15508 determines one or more dynamic models required to fulfill the request and retrieves the one or more required dynamic models from dynamic model datastore 155102. At 167806, the digital twin dynamic model system 15508 selects dynamic model input data sources (e.g., one or more sensors from sensor system 15530, data from Internet of Things connected devices 15524, and any other suitable data) based on available data sources (e.g., available sensors from a set of sensors in sensor system 15530) and the and the one or more required inputs of the dynamic model(s) via digital twin I/O system 15504. In the present example, the retrieved dynamic model(s) may be configured to take one or more vibration measurements obtained from vibration sensors 15536 and other operational data as inputs and output one or more manufacturing KPIs for the facility. At 167808, digital twin dynamic model system 15508 retrieves one or more vibration measurements from each of the selected vibration sensors 15536 and operational data from digital twin I/O system 15504. At 167810, digital twin dynamic model system 15508 runs the dynamic model(s) using the retrieved vibration measurements and operational data as inputs and calculates one or more outputs that represent manufacturing KPIs for the manufacturing facility. Next, At 167812, the digital twin dynamic model system 15508 updates one or more KPI values of the manufacturing facility digital twins, machine digital twins, machine part digital twins, and all other embedded digital twins based on the one or more outputs of the dynamic model(s).

[0727] Further embodiments may include the following examples. FIG. 155 illustrates an example environment of a digital twin system 15500. In embodiments, the digital twin system 15500 generates a set of digital twins of a set of industrial environments 15520 and/or industrial entities within the set of industrial environments. In embodiments, the digital twin system 15500 maintains a set of states of the respective industrial environments 15520, such as using sensor data obtained from respective sensor systems 15530 that monitor the industrial environments 15520. In embodiments, the digital twin system 15500 may include a digital twin management system 15502, a digital twin I/O system 15504, a digital twin simulation system 15506, a digital twin dynamic model system 15508, a cognitive intelligence system 15510, and/or an environment control module 15512. In embodiments, the digital twin system 15500 may provide a real time sensor API that provides a set of capabilities for enabling a set of interfaces for the sensors of the respective sensor systems 15530. In embodiments, the digital twin system 15500 may include and/or employ other suitable APIs, brokers, connectors, bridges, gateways, hubs, ports, routers, switches, data integration systems, peer-to-peer systems, and the like to facilitate the transferring of data to and from the digital twin system 15500. In these embodiments, these connective components may allow an IoT sensor or an intermediary device (e.g., a relay, an edge device, a switch, or the like) within a sensor system 15530 to communicate data to the digital twin system 155300 and/or to receive data (e.g., configuration data, control data, or the like) from the digital twin system 15500 or another external system. In embodiments, the digital twin system 15500 may further include a digital twin datastore 15516 that stores digital twins 15518 of various industrial environments 15520 and the objects 15522, devices 15524, sensors 15526, and/or humans 15528 in the environment 15520.

[0728] A digital twin may refer to a digital representation of one or more industrial entities, such as an industrial environment 15520, a physical object 15522, a device 15524, a sensor 15526, a human 15528, or any combination thereof. Examples of industrial environments 15520 include, but are not limited to, a factory, a power plant, a food production facility (which may include an inspection facility), a commercial kitchen, an indoor growing facility, a natural resources excavation site (e.g., a mine, an oil field, etc.), and the like. Depending on the type of environment, the types of objects, devices, and sensors that are found in the environments will differ. Non-limiting examples of physical objects 15522 include raw materials, manufactured products, excavated materials, containers (e.g., boxes, dumpsters, cooling towers, vats, pallets, barrels, palates, bins, and the like), furniture (e.g., tables, counters, workstations, shelving, etc.), and the like. Non-limiting examples of devices 15524 include robots, computers, vehicles (e.g., cars, trucks, tankers, trains, forklifts, cranes, etc.), machinery/equipment (e.g., tractors, tillers, drills, presses, assembly lines, conveyor belts, etc.), and the like. The sensors 15526 may be any sensor devices and/or sensor aggregation devices that are found in a sensor system 15530 within an environment. Non-limiting examples of sensors 15526 that may be implemented in a sensor system 15530 may include temperature sensors 15532, humidity sensors 15534, vibration sensors 15536, LIDAR sensors 15538, motion sensors 15540, chemical sensors 15542, audio sensors 15544, pressure sensors 15546, weight sensors 15548, radiation sensors 15550, video sensors 15552, wearable devices 15554, relays 15556, edge devices 15558, crosspoint switches 15560, and/or any other suitable sensors. Examples of different types of physical objects 15522, devices 15524, sensors 15526, and environments 15520 are referenced throughout the disclosure.

[0729] In some embodiments, on-device sensor fusion and data storage for industrial IoT devices is supported, including on-device sensor fusion and data storage for an industrial IoT device, where data from multiple sensors is multiplexed at the device for storage of a fused data stream. For example, pressure and temperature data may be multiplexed into a data stream that combines pressure and temperature in a time series, such as in a byte-like structure (where time, pressure, and temperature are bytes in a data structure, so that pressure and temperature remain linked in time, without requiring separate processing of the streams by outside systems), or by adding, dividing, multiplying, subtracting, or the like, such that the fused data can be stored on the device. Any of the sensor data types described throughout this disclosure, including vibration data, can be fused in this manner and stored in a local data pool, in storage, or on an IoT device, such as a data collector, a component of a machine, or the like.

[0730] In some embodiments, a set of digital twins may represent an entire organization, such as energy production organizations, oil and gas organizations, renewable energy production organizations, aerospace manufacturers, vehicle manufacturers, heavy equipment manufacturers, mining organizations, drilling organizations, offshore platform organizations, and the like. In these examples, the digital twins may include digital twins of one or more industrial facilities of the organization.

[0731] In embodiments, the digital twin management system 15502 generates digital twins. A digital twin may be comprised of (e.g., via reference) other digital twins. In this way, a discrete digital twin may be comprised of a set of other discrete digital twins. For example, a digital twin of a machine may include digital twins of sensors on the machine, digital twins of components that make up the machine, digital twins of other devices that are incorporated in or integrated with the machine (such as systems that provide inputs to the machine or take outputs from it), and/or digital twins of products or other items that are made by the machine. Taking this example one step further, a digital twin of an industrial facility (e.g., a factory) may include a digital twin representing the layout of the industrial facility, including the arrangement of physical assets and systems in or around the facility, as well as digital assets of the assets within the facility (e.g., the digital twin of the machine), as well as digital twins of storage areas in the facility, digital twins of humans collecting vibration measurements from machines throughout the facility, and the like. In this second example, the digital twin of the industrial facility may reference the embedded digital twins, which may then reference other digital twins embedded within those digital twins.

[0732] In some embodiments, a digital twin may represent abstract entities, such as workflows and/or processes, including inputs, outputs, sequences of steps, decision points, processing loops, and the like that make up such workflows and processes. For example, a digital twin may be a digital representation of a manufacturing process, a logistics workflow, an agricultural process, a mineral extraction process, or the like. In these embodiments, the digital twin may include references to the industrial entities that are included in the workflow or process. The digital twin of the manufacturing process may reflect the various stages of the process. In some of these embodiments, the digital twin system 15500 receives real-time data from the industrial facility (e.g., from a sensor system 15530 of the environment 15520) in which the manufacturing process takes place and reflects a current (or substantially current) state of the process in real-time.

[0733] In embodiments, the digital representation may include a set of data structures (e.g., classes) that collectively define a set of properties of a represented physical object 15522, device 15524, sensor 15526, or environment 15520 and/or possible behaviors thereof. For example, the set of properties of a physical object 15522 may include a type of the physical object, the dimensions of the object, the mass of the object, the density of the object, the material(s) of the object, the physical properties of the material(s), the surface of the physical object, the status of the physical object, a location of the physical object, identifiers of other digital twins contained within the object, and/or other suitable properties. Examples of behavior of a physical object may include a state of the physical object (e.g., a solid, liquid, or gas), a melting point of the physical object, a density of the physical object when in a liquid state, a viscosity of the physical object when in a liquid state, a freezing point of the physical object, a density of the physical object when in a solid state, a hardness of the physical object when in a solid state, the malleability of the physical object, the buoyancy of the physical object, the conductivity of the physical object, a burning point of the physical object, the manner by which humidity affects the physical object, the manner by which water or other liquids affect the physical object, a terminal velocity of the physical object, and the like. In another example, the set of properties of a device may include a type of the device, the dimensions of the device, the mass of the device, the density of the density of the device, the material(s) of the device, the physical properties of the material(s), the surface of the device, the output of the device, the status of the device, a location of the device, a trajectory of the device, vibration characteristics of the device, identifiers of other digital twins that the device is connected to and/or contains, and the like. Examples of the behaviors of a device may include a maximum acceleration of a device, a maximum speed of a device, ranges of motion of a device, a heating profile of a device, a cooling profile of a device, processes that are performed by the device, operations that are performed by the device, and the like. Example properties of an environment may include the dimensions of the environment, the boundaries of the environment, the temperature of the environment, the humidity of the environment, the airflow of the environment, the physical objects in the environment, currents of the environment (if a body of water), and the like. Examples of behaviors of an environment may include scientific laws that govern the environment, processes that are performed in the environment, rules or regulations that must be adhered to in the environment, and the like.

[0734] In embodiments, the properties of a digital twin may be adjusted. For example, the temperature of a digital twin, a humidity of a digital twin, the shape of a digital twin, the material of a digital twin, the dimensions of a digital twin, or any other suitable parameters may be adjusted. As the properties of the digital twin are adjusted, other properties may be affected as well. For example, if the temperature of an environment 15520 is increased, the pressure within the environment may increase as well, such as a pressure of a gas in accordance with the ideal gas law. In another example, if a digital twin of a subzero environment is increased to above freezing temperatures, the properties of an embedded twin of water in a solid state (i.e., ice) may change into a liquid state over time.

[0735] Digital twins may be represented in a number of different forms. In embodiments, a digital twin may be a visual digital twin that is rendered by a computing device, such that a human user can view digital representations of an environment 15520 and/or the physical objects 15522, devices 15524, and/or the sensors 15526 within an environment. In embodiments, the digital twin may be rendered and output to a display device. In some of these embodiments, the digital twin may be rendered in a graphical user interface, such that a user may interact with the digital twin. For example, a user may “drill down” on a particular element (e.g., a physical object or device) to view additional information regarding the element (e.g., a state of a physical object or device, properties of the physical object or device, or the like). In some embodiments, the digital twin may be rendered and output in a virtual reality display. For example, a user may view a 3D rendering of an environment (e.g., using monitor or a virtual reality headset). While doing so, the user may view/inspect digital twins of physical assets or devices in the environment.

[0736] In some embodiments, a data structure of the visual digital twins (i.e., digital twins that are configured to be displayed in a 2D or 3D manner) may include surfaces (e.g., splines, meshes, polygons meshes, or the like). In some embodiments, the surfaces may include texture data, shading information, and/or reflection data. In this way, a surface may be displayed in a more realistic manner. In some embodiments, such surfaces may be rendered by a visualization engine (not shown) when the digital twin is within a field of view and/or when existing in a larger digital twin (e.g., a digital twin of an industrial environment). In these embodiments, the digital twin system 15500 may render the surfaces of digital objects, whereby a rendered digital twin may be depicted as a set of adjoined surfaces.

[0737] In embodiments, a user may provide input that controls one or more properties of a digital twin via a graphical user interface. For example, a user may provide input that changes a property of a digital twin. In response, the digital twin system 15500 can calculate the effects of the changed property and may update the digital twin and any other digital twins affected by the change of the property.

[0738] In embodiments, a user may view processes being performed with respect to one or more digital twins (e.g., manufacturing of a product, extracting minerals from a mine or well, a livestock inspection line, and the like). In these embodiments, a user may view the entire process or specific steps within a process.

[0739] In some embodiments, a digital twin (and any digital twins embedded therein) may be represented in a non-visual representation (or “data representation”). In these embodiments, a digital twin and any embedded digital twins exist in a binary representation but the relationships between the digital twins are maintained. For example, in embodiments, each digital twin and/or the components thereof may be represented by a set of physical dimensions that define a shape of the digital twin (or component thereof). Furthermore, the data structure embodying the digital twin may include a location of the digital twin. In some embodiments, the location of the digital twin may be provided in a set of coordinates. For example, a digital twin of an industrial environment may be defined with respect to a coordinate space (e.g., a Cartesian coordinate space, a polar coordinate space, or the like). In embodiments, embedded digital twins may be represented as a set of one or more ordered triples (e.g., [x coordinate, y coordinate, z coordinates] or other vector-based representations). In some of these embodiments, each ordered triple may represent a location of a specific point (e.g., center point, top point, bottom point, or the like) on the industrial entity (e.g., object, device, or sensor) in relation to the environment in which the industrial entity resides. In some embodiments, a data structure of a digital twin may include a vector that indicates a motion of the digital twin with respect to the environment. For example, fluids (e.g., liquids or gasses) or solids may be represented by a vector that indicates a velocity (e.g., direction and magnitude of speed) of the entity represented by the digital twin. In embodiments, a vector within a twin may represent a microscopic subcomponent, such as a particle within a fluid, and a digital twin may represent physical properties, such as displacement, velocity, acceleration, momentum, kinetic energy, vibrational characteristics, thermal properties, electromagnetic properties, and the like.

[0740] In some embodiments, a set of two or more digital twins may be represented by a graph database that includes nodes and edges that connect the nodes. In some implementations, an edge may represent a spatial relationship (e.g., “abuts”, “rests upon”, “contains”, and the like). In these embodiments, each node in the graph database represents a digital twin of an entity (e.g., an industrial entity) and may include the data structure defining the digital twin. In these embodiments, each edge in the graph database may represent a relationship between two entities represented by connected nodes. In some implementations, an edge may represent a spatial relationship (e.g., “abuts”, “rests upon”, “interlocks with”, “bears”, “contains”, and the like). In embodiments, various types of data may be stored in a node or an edge. In embodiments, a node may store property data, state data, and/or metadata relating to a facility, system, subsystem, and/or component. Types of property data and state data will differ based on the entity represented by a node. For example, a node representing a robot may include property data that indicates a material of the robot, the dimensions of the robot (or components thereof), a mass of the robot, and the like. In this example, the state data of the robot may include a current pose of the robot, a location of the robot, and the like. In embodiments, an edge may store relationship data and metadata data relating to a relationship between two nodes. Examples of relationship data may include the nature of the relationship, whether the relationship is permanent (e.g., a fixed component would have a permanent relationship with the structure to which it is attached or resting on), and the like. In embodiments, an edge may include metadata concerning the relationship between two entities. For example, if a product was produced on an assembly line, one relationship that may be documented between a digital twin of the product and the assembly line may be “created by”. In these embodiments, an example edge representing the “created by” relationship may include a timestamp indicating a date and time that the product was created. In another example, a sensor may take measurements relating to a state of a device, whereby one relationship between the sensor and the device may include “measured” and may define a measurement type that is measured by the sensor. In this example, the metadata stored in an edge may include a list of N measurements taken and a timestamp of each respective measurement. In this way, temporal data relating to the nature of the relationship between two entities may be maintained, thereby allowing for an analytics engine, machine-learning engine, and/or visualization engine to leverage such temporal relationship data, such as by aligning disparate data sets with a series of points in time, such as to facilitate cause-and-effect analysis used for prediction systems.

[0741] In some embodiments, a graph database may be implemented in a hierarchical manner, such that the graph database relates a set of facilities, systems, and components. For example, a digital twin of a manufacturing environment may include a node representing the manufacturing environment. The graph database may further include nodes representing various systems within the manufacturing environment, such as nodes representing an HVAC system, a lighting system, a manufacturing system, and the like, all of which may connect to the node representing the manufacturing system. In this example, each of the systems may further connect to various subsystems and/or components of the system. For example, within the HVAC system, the HVAC system may connect to a subsystem node representing a cooling system of the facility, a second subsystem node representing a heating system of the facility, a third subsystem node representing the fan system of the facility, and one or more nodes representing a thermostat of the facility (or multiple thermostats). Carrying this example further, the subsystem nodes and/or component nodes may connect to lower level nodes, which may include subsystem nodes and/or component nodes. For example, the subsystem node representing the cooling subsystem may be connected to a component node representing an air conditioner unit. Similarly, a component node representing a thermostat device may connect to one or more component nodes representing various sensors (e.g., temperature sensors, humidity sensors, and the like).

[0742] In embodiments where a graph database is implemented, a graph database may relate to a single environment or may represent a larger enterprise. In the latter scenario, a company may have various manufacturing and distribution facilities. In these embodiments, an enterprise node representing the enterprise may connect to environment nodes of each respective facility. In this way, the digital twin system 15500 may maintain digital twins for multiple industrial facilities of an enterprise.

[0743] In embodiments, the digital twin system 15500 may use a graph database to generate a digital twin that may be rendered and displayed and/or may be represented in a data representation. In the former scenario, the digital twin system 15500 may receive a request to render a digital twin, whereby the request includes one or more parameters that are indicative of a view that will be depicted. For example, the one or more parameters may indicate an industrial environment to be depicted and the type of rendering (e.g., “real-world view” that depicts the environment as a human would see it, an “infrared view” that depicts objects as a function of their respective temperature, an “airflow view” that depicts the airflow in a digital twin, or the like). In response, the digital twin system 15500 may traverse a graph database and may determine a configuration of the environment to be depicted based on the nodes in the graph database that are related (either directly or through a lower level node) to the environment node of the environment and the edges that define the relationships between the related nodes. Upon determining a configuration, the digital twin system 15500 may identify the surfaces that are to be depicted and may render those surfaces. The digital twin system 15500 may then render the requested digital twin by connecting the surfaces in accordance with the configuration. The rendered digital twin may then be output to a viewing device (e.g., VR headset, monitor, or the like). In some scenarios, the digital twin system 15500 may receive real-time sensor data from a sensor system 15530 of an environment 15520 and may update the visual digital twin based on the sensor data. For example, the digital twin system 15500 may receive sensor data (e.g., vibration data from a vibration sensor 15536) relating to a motor and its set of bearings. Based on the sensor data, the digital twin system 15500 may update the visual digital twin to indicate the approximate vibrational characteristics of the set of bearings within a digital twin of the motor.

[0744] In scenarios where the digital twin system 15500 is providing data representations of digital twins (e.g., for dynamic modeling, simulations, machine learning), the digital twin system 15500 may traverse a graph database and may determine a configuration of the environment to be depicted based on the nodes in the graph database that are related (either directly or through a lower level node) to the environment node of the environment and the edges that define the relationships between the related nodes. In some scenarios, the digital twin system 15500 may receive real-time sensor data from a sensor system 15530 of an environment 15520 and may apply one or more dynamic models to the digital twin based on the sensor data. In other scenarios, a data representation of a digital twin may be used to perform simulations, as is discussed in greater detail throughout the specification.

[0745] In some embodiments, the digital twin system 15500 may execute a digital ghost that is executed with respect to a digital twin of an industrial environment. In these embodiments, the digital ghost may monitor one or more sensors of a sensor system 15530 of an industrial environment to detect anomalies that may indicate a malicious virus or other security issues.

[0746] As discussed, the digital twin system 15500 may include a digital twin management system 15502, a digital twin I/O system 15504, a digital twin simulation system 15506, a digital twin dynamic model system 15508, a cognitive intelligence system 15510, and/or an environment control module 15512.

[0747] In embodiments, the digital twin management system 15502 creates new digital twins, maintains/updates existing digital twins, and/or renders digital twins. The digital twin management system 15502 may receive user input, uploaded data, and/or sensor data to create and maintain existing digital twins. Upon creating a new digital twin, the digital twin management system 15502 may store the digital twin in the digital twin datastore 15516. Creating, updating, and rendering digital twins are discussed in greater detail throughout the disclosure.

[0748] In embodiments, the digital twin I/O system 15504 receives input from various sources and outputs data to various recipients. In embodiments, the digital twin I/O system receives sensor data from one or more sensor systems 15530. In these embodiments, each sensor system 15530 may include one or more IoT sensors that output respective sensor data. Each sensor may be assigned an IP address or may have another suitable identifier. Each sensor may output sensor packets that include an identifier of the sensor and the sensor data. In some embodiments, the sensor packets may further include a timestamp indicating a time at which the sensor data was collected. In some embodiments, the digital twin I/O system 15504 may interface with a sensor system 15530 via the real-time sensor API 15514. In these embodiments, one or more devices (e.g., sensors, aggregators, edge devices) in the sensor system 15530 may transmit the sensor packets containing sensor data to the digital twin I/O system 15504 via the API. The digital twin I/O system may determine the sensor system 15530 that transmitted the sensor packets and the contents thereof, and may provide the sensor data and any other relevant data (e.g., time stamp, environment identifier/sensor system identifier, and the like) to the digital twin management system 15502.

[0749] In embodiments, the digital twin I/O system 15504 may receive imported data from one or more sources. For example, the digital twin system 15500 may provide a portal for users to create and manage their digital twins. In these embodiments, a user may upload one or more files (e.g., image files, LIDAR scans, blueprints, and the like) in connection with a new digital twin that is being created. In response, the digital twin I/O system 15504 may provide the imported data to the digital twin management system 15502. The digital twin I/O system 15504 may receive other suitable types of data without departing from the scope of the disclosure.

[0750] In some embodiments, the digital twin simulation system 15506 is configured to execute simulations using the digital twin. For example, the digital twin simulation system 15506 may iteratively adjust one or more parameters of a digital twin and/or one or more embedded digital twins. In embodiments, the digital twin simulation system 15506, for each set of parameters, executes a simulation based on the set of parameters and may collect the simulation outcome data resulting from the simulation. Put another way, the digital twin simulation system 15506 may collect the properties of the digital twin and the digital twins within or containing the digital twin used during the simulation as well as any outcomes stemming from the simulation. For example, in running a simulation on a digital twin of an indoor agricultural facility, the digital twin simulation system 15506 can vary the temperature, humidity, airflow, carbon dioxide and/or other relevant parameters and can execute simulations that output outcomes resulting from different combinations of the parameters. In another example, the digital twin simulation system 15506 may simulate the operation of a specific machine within an industrial facility that produces an output given a set of inputs. In some embodiments, the inputs may be varied to determine an effect of the inputs on the machine and the output thereof. In another example, the digital twin simulation system 15506 may simulate the vibration of a machine and/or machine components. In this example, the digital twin of the machine may include a set of operating parameters, interfaces, and capabilities of the machine. In some embodiments, the operating parameters may be varied to evaluate the effectiveness of the machine. The digital twin simulation system 15506 is discussed in further detail throughout the disclosure.

[0751] In embodiments, the digital twin dynamic model system 15508 is configured to model one or more behaviors with respect to a digital twin of an environment. In embodiments, the digital twin dynamic model system 15508 may receive a request to model a certain type of behavior regarding an environment or a process and may model that behavior using a dynamic model, the digital twin of the environment or process, and sensor data collected from one or more sensors that are monitoring the environment or process. For example, an operator of a machine having bearings may wish to model the vibration of the machine and bearings to determine whether the machine and/or bearings can withstand an increase in output. In this example, the digital twin dynamic model system 15508 may execute a dynamic model that is configured to determine whether an increase in output would result in adverse consequences (e.g., failures, downtime, or the like). The digital twin dynamic model system 15508 is discussed in further detail throughout the disclosure.

[0752] In embodiments, the cognitive processes system 15510 performs machine learning and artificial intelligence related tasks on behalf of the digital twin system. In embodiments, the cognitive processes system 15510 may train any suitable type of model, including but not limited to various types of neural networks, regression models, random forests, decision trees, Hidden Markov models, Bayesian models, and the like. In embodiments, the cognitive processes system 15510 trains machine learned models using the output of simulations executed by the digital twin simulation system 15506. In some of these embodiments, the outcomes of the simulations may be used to supplement training data collected from real-world environments and/or processes. In embodiments, the cognitive processes system 15510 leverages machine learned models to make predictions, identifications, classifications and provide decision support relating to the real-world environments and/or processes represented by respective digital twins.

[0753] For example, a machine-learned prediction model may be used to predict the cause of irregular vibrational patterns (e.g., a suboptimal, critical, or alarm vibration fault state) for a bearing of an engine in an industrial facility. In this example, the cognitive processes system 15510 may receive vibration sensor data from one or more vibration sensors disposed on or near the engine and may receive maintenance data from the industrial facility and may generate a feature vector based on the vibration sensor data and the maintenance data. The cognitive processes system 15510 may input the feature vector into a machine-learned model trained specifically for the engine (e.g., using a combination simulation data and real-world data of causes of irregular vibration patterns) to predict the cause of the irregular vibration patterns. In this example, the causes of the irregular vibrational patterns could be a loose bearing, a lack of bearing lubrication, a bearing that is out of alignment, a worn bearing, the phase of the bearing may be aligned with the phase of the engine, loose housing, loose bolt, and the like.

[0754] In another example, a machine-learned model may be used to provide decision support to bring a bearing of an engine in an industrial facility operating at a suboptimal vibration fault level state to a normal operation vibration fault level state. In this example, the cognitive processes system 15510 may receive vibration sensor data from one or more vibration sensors disposed on or near the engine and may receive maintenance data from the industrial facility and may generate a feature vector based on the vibration sensor data and the maintenance data. The cognitive processes system 15510 may input the feature vector into a machine-learned model trained specifically for the engine (e.g., using a combination simulation data and real-world data of solutions to irregular vibration patterns) to provide decision support in achieving a normal operation fault level state of the bearing. In this example, the decision support could be a recommendation to tighten the bearing, lubricate the bearing, re-align the bearing, order a new bearing, order a new part, collect additional vibration measurements, change operating speed of the engine, tighten housings, tighten bolts, and the like.

[0755] In another example, a machine-learned model may be used to provide decision support relating to vibration measurement collection by a worker. In this example, the cognitive processes system 15510 may receive vibration measurement history data from the industrial facility and may generate a feature vector based on the vibration measurement history data. The cognitive processes system 15510 may input the feature vector into a machine-learned model trained specifically for the engine (e.g., using a combination simulation data and real-world vibration measurement history data) to provide decision support in selecting vibration measurement locations.

[0756] In yet another example, a machine-learned model may be used to identify vibration signatures associated with machine and/or machine component problems. In this example, the cognitive processes system 15510 may receive vibration measurement history data from the industrial facility and may generate a feature vector based on the vibration measurement history data. The cognitive processes system 15510 may input the feature vector into a machine-learned model trained specifically for the engine (e.g., using a combination simulation data and real-world vibration measurement history data) to identify vibration signatures associated with a machine and/or machine component. The foregoing examples are non-limiting examples and the cognitive processes system 15510 may be used for any other suitable AI/machine-learning related tasks that are performed with respect to industrial facilities.

[0757] In embodiments, the environment control system 15512 controls one or more aspects of industrial facilities. In some of these embodiments, the environment control system 15512 may control one or more devices within an industrial environment. For example, the environment control system 15512 may control one or more machines within an environment, robots within an environment, an HVAC system of the environment, an alarm system of the environment, an assembly line in an environment, or the like. In embodiments, the environment control system 15512 may leverage the digital twin simulation system 15506, the digital twin dynamic model system 15508, and/or the cognitive processes system 15510 to determine one or more control instructions. In embodiments, the environment control system 15512 may implement a rules-based and/or a machine-learning approach to determine the control instructions. In response to determining a control instruction, the environment control system 15512 may output the control instruction to the intended device within a specific environment via the digital twin I/O system 15504.

[0758] FIG. 156 illustrates an example digital twin management system 15502 according to some embodiments of the present disclosure. In embodiments, the digital twin management system 15502 may include, but is not limited to, a digital twin creation module 15564, a digital twin update module 15566, and a digital twin visualization module 15568.

[0759] In embodiments, the digital twin creation module 15564 may create a set of new digital twins of a set of environments using input from users, imported data (e.g., blueprints, specifications, and the like), image scans of the environment, 3D data from a LIDAR device and/or SLAM sensor, and other suitable data sources. For example, a user (e.g., a user affiliated with an organization/customer account) may, via a client application 15570, provide input to create a new digital twin of an environment. In doing so, the user may upload 2D or 3D image scans of the environment and/or a blueprint of the environment. The user may also upload 3D data, such as taken by a camera, a LIDAR device, an IR scanner, a set of SLAM sensors, a radar device, an EMF scanner, or the like. In response to the provided data, the digital twin creation module 15564 may create a 3D representation of the environment, which may include any objects that were captured in the image data/detected in the 3D data. In embodiments, the cognitive processes system 15572 may analyze input data (e.g., blueprints, image scans, 3D data) to classify rooms, pathways, equipment, and the like to assist in the generation of the 3D representation. In some embodiments, the digital twin creation module 15564 may map the digital twin to a 3D coordinate space (e.g., a Cartesian space having x, y, and z axes).

[0760] In some embodiments, the digital twin creation module 15564 may output the 3D representation of the environment to a graphical user interface (GUI). In some of these embodiments, a user may identify certain areas and/or objects and may provide input relating to the identified areas and/or objects. For example, a user may label specific rooms, equipment, machines, and the like. Additionally or alternatively, the user may provide data relating to the identified objects and/or areas. For example, in identifying a piece of equipment, the user may provide a make/model number of the equipment. In some embodiments, the digital twin creation module 15564 may obtain information from a manufacturer of a device, a piece of equipment, or machinery. This information may include one or more properties and/or behaviors of the device, equipment, or machinery. In some embodiments, the user may, via the GUI, identify locations of sensors throughout the environment. For each sensor, the user may provide a type of sensor and related data (e.g., make, model, IP address, and the like). The digital twin creation module 15564 may record the locations (e.g., the x, y, z coordinates of the sensors) in the digital twin of the environment. In embodiments, the digital twin system 15500 may employ one or more systems that automate the population of digital twins. For example, the digital twin system 15500 may employ a machine vision-based classifier that classifies makes and models of devices, equipment, or sensors. Additionally or alternatively, the digital twin system 15500 may iteratively ping different types of known sensors to identify the presence of specific types of sensors that are in an environment. Each time a sensor responds to a ping, the digital twin system 15500 may extrapolate the make and model of the sensor.

[0761] In some embodiments, the manufacturer may provide or make available digital twins of their products (e.g., sensors, devices, machinery, equipment, raw materials, and the like). In these embodiments, the digital twin creation module 15564 may import the digital twins of one or more products that are identified in the environment and may embed those digital twins in the digital twin of the environment. In embodiments, embedding a digital twin within another digital twin may include creating a relationship between the embedded digital twin with the other digital twin. In these embodiments, the manufacturer of the digital twin may define the behaviors and/or properties of the respective products. For example, a digital twin of a machine may define the manner by which the machine operates, the inputs/outputs of the machine, and the like. In this way, the digital twin of the machine may reflect the operation of the machine given a set of inputs.

[0762] In embodiments, a user may define one or more processes that occur in an environment. In these embodiments, the user may define the steps in the process, the machines/devices that perform each step in the process, the inputs to the process, and the outputs of the process.

[0763] In embodiments, the digital twin creation module 15564 may create a graph database that defines the relationships between a set of digital twins. In these embodiments, the digital twin creation module 15564 may create nodes for the environment, systems and subsystems of the environment, devices in the environment, sensors in the environment, workers that work in the environment, processes that are performed in the environment, and the like. In embodiments, the digital twin creation module 15564 may write the graph database representing a set of digital twins to the digital twin datastore 15516.

[0764] In embodiments, the digital twin creation module 15564 may, for each node, include any data relating to the entity in the node representing the entity. For example, in defining a node representing an environment, the digital twin creation module 15564 may include the dimensions, boundaries, layout, pathways, and other relevant spatial data in the node. Furthermore, the digital twin creation module 15564 may define a coordinate space with respect to the environment. In the case that the digital twin may be rendered, the digital twin creation module 15564 may include a reference in the node to any shapes, meshes, splines, surfaces, and the like that may be used to render the environment. In representing a system, subsystem, device, or sensor, the digital twin creation module 15564 may create a node for the respective entity and may include any relevant data. For example, the digital twin creation module 15564 may create a node representing a machine in the environment. In this example, the digital twin creation module 15564 may include the dimensions, behaviors, properties, location, and/or any other suitable data relating to the machine in the node representing the machine. The digital twin creation module 15564 may connect nodes of related entities with an edge, thereby creating a relationship between the entities. In doing so, the created relationship between the entities may define the type of relationship characterized by the edge. In representing a process, the digital twin creation module 15564 may create a node for the entire process or may create a node for each step in the process. In some of these embodiments, the digital twin creation module 15564 may relate the process nodes to the nodes that represent the machinery/devices that perform the steps in the process. In embodiments, where an edge connects the process step nodes to the machinery/device that performs the process step, the edge or one of the nodes may contain information that indicates the input to the step, the output of the step, the amount of time the step takes, the nature of processing of inputs to produce outputs, a set of states or modes the process can undergo, and the like.

[0765] In embodiments, the digital twin update module 15566 updates sets of digital twins based on a current status of one or more industrial entities. In some embodiments, the digital twin update module 15566 receives sensor data from a sensor system 15530 of an industrial environment and updates the status of the digital twin of the industrial environment and/or digital twins of any affected systems, subsystems, devices, workers, processes, or the like. As discussed, the digital twin I/O system 15504 may receive the sensor data in one or more sensor packets. The digital twin I/O system 15504 may provide the sensor data to the digital twin update module 15566 and may identify the environment from which the sensor packets were received and the sensor that provided the sensor packet. In response to the sensor data, the digital twin update module 15566 may update a state of one or more digital twins based on the sensor data. In some of these embodiments, the digital twin update module 15566 may update a record (e.g., a node in a graph database) corresponding to the sensor that provided the sensor data to reflect the current sensor data. In some scenarios, the digital twin update module 15566 may identify certain areas within the environment that are monitored by the sensor and may update a record (e.g., a node in a graph database) to reflect the current sensor data. For example, the digital twin update module 15566 may receive sensor data reflecting different vibrational characteristics of a machine and/or machine components. In this example, the digital twin update module 15566 may update the records representing the vibration sensors that provided the vibration sensor data and/or the records representing the machine and/or the machine components to reflect the vibration sensor data. In another example, in some scenarios, workers in an industrial environment (e.g., manufacturing facility, industrial storage facility, a mine, a drilling operation, or the like) may be required to wear wearable devices (e.g., smart watches, smart helmets, smart shoes, or the like). In these embodiments, the wearable devices may collect sensor data relating to the worker (e.g., location, movement, heartrate, respiration rate, body temperature, or the like) and/or the environment surrounding the worker and may communicate the collected sensor data to the digital twin system 15500 (e.g., via the real-time sensor API 15514) either directly or via an aggregation device of the sensor system. In response to receiving the sensor data from the wearable device of a worker, the digital twin update module 15566 may update a digital twin of a worker to reflect, for example, a location of the worker, a trajectory of the worker, a health status of the worker, or the like. In some of these embodiments, the digital twin update module 15566 may update a node representing a worker and/or an edge that connects the node representing the environment with the collected sensor data to reflect the current status of the worker.

[0766] In some embodiments, the digital twin update module 15566 may provide the sensor data from one or more sensors to the digital twin dynamic model system 15508, which may model a behavior of the environment and/or one or more industrial entities to extrapolate additional state data.

[0767] In embodiments, the digital twin visualization module 15568 receives requests to view a visual digital twin or a portion thereof. In embodiments, the request may indicate the digital twin to be viewed (e.g., an environment identifier). In response, the digital twin visualization module 15568 may determine the requested digital twin and any other digital twins implicated by the request. For example, in requesting to view a digital twin of an environment, the digital twin visualization module 15568 may further identify the digital twins of any industrial entities within the environment. In embodiments, the digital twin visualization module 15568 may identify the spatial relationships between the industrial entities and the environment based on, for example, the relationships defined in a graph database. In these embodiments, the digital twin visualization module 15568 can determine the relative location of embedded digital twins within the containing digital twin, relative locations of adjoining digital twins, and/or the transience of the relationship (e.g., is an object fixed to a point or does the object move). The digital twin visualization module 15568 may render the requested digital twins and any other implicated digital twin based on the identified relationships. In some embodiments, the digital twin visualization module 15568 may, for each digital twin, determine the surfaces of the digital twin. In some embodiments, the surfaces of a digital may be defined or referenced in a record corresponding to the digital twin, which may be provided by a user, determined from imported images, or defined by a manufacturer of an industrial entity. In the scenario that an object can take different poses or shapes (e.g., an industrial robot), the digital twin visualization module 15568 may determine a pose or shape of the object for the digital twin. The digital twin visualization module 15568 may embed the digital twins into the requested digital twin and may output the requested digital twin to a client application.

[0768] In some of these embodiments, the request to view a digital twin may further indicate the type of view. As discussed, in some embodiments, digital twins may be depicted in a number of different view types. For example, an environment or device may be viewed in a “real-world” view that depicts the environment or device as they typically appear, in a “heat” view that depicts the environment or device in a manner that is indicative of a temperature of the environment or device, in a “vibration” view that depicts the machines and/or machine components in an industrial environment in a manner that is indicative of vibrational characteristics of the machines and/or machine components, in a “filtered” view that only displays certain types of objects within an environment or components of a device (such as objects that require attention resulting from, for example, recognition of a fault condition, an alert, an updated report, or other factors), an augmented view that overlays data on the digital twin, and/or any other suitable view types. In embodiments, digital twins may be depicted in a number of different role-based view types. For example, a manufacturing facility device may be viewed in an “operator” view that depicts the facility in a manner that is suitable for a facility operator, a “C-Suite” view that depicts the facility in a manner that is suitable for executive-level managers, a “marketing” view that depicts the facility in a manner that is suitable for workers in sales and/or marketing roles, a “board” view that depicts the facility in a manner that is suitable for members of a corporate board, a “regulatory” view that depicts the facility in a manner that is suitable for regulatory managers, and a “human resources” view that depicts the facility in a manner that is suitable for human resources personnel. In response to a request that indicates a view type, the digital twin visualization module 15568 may retrieve the data for each digital twin that corresponds to the view type. For example, if a user has requested a vibration view of a factory floor, the digital twin visualization module 15568 may retrieve vibration data for the factory floor (which may include vibration measurements taken from different machines and/or machine components and/or vibration measurements that were extrapolated by the digital twin dynamic model system 15508 and/or simulated vibration data from digital twin simulation system 15506) as well as available vibration data for any industrial entities appearing on the factory floor. In this example, the digital twin visualization module 15568 may determine colors corresponding to each machine component on a factory floor that represent a vibration fault level state (e.g., red for alarm, orange for critical, yellow for suboptimal, and green for normal operation). The digital twin visualization module 15568 may then render the digital twins of the machine components within the environment based on the determined colors. Additionally or alternatively, the digital twin visualization module 15568 may render the digital twins of the machine components within the environment with indicators having the determined colors. For instance, if the vibration fault level state of an inbound bearing of a motor is suboptimal and the outbound bearing of the motor is critical, the digital twin visualization module 15568 may render the digital twin of the inbound bearing having an indicator in a shade of yellow (e.g., suboptimal) and the outbound bearing having an indicator in a shade of orange (e.g., critical). It is noted that in some embodiments, the digital twin system 15500 may include an analytics system (not shown) that determine the manner by which the digital twin visualization system 15568 presents information to a human user. For example, the analytics system may track outcomes relating to human interactions with real-world environments or objects in response to information presented in a visual digital twin. In some embodiments, the analytics system may apply cognitive models to determine the most effective manner to display visualized information (e.g., what colors to use to denote an alarm condition, what kind of movements or animations bring attention to an alarm condition, or the like) or audio information (what sounds to use to denote an alarm condition) based on the outcome data. In some embodiments, the analytics system may apply cognitive models to determine the most suitable manner to display visualized information based on the role of the user. In embodiments, the visualization may include display of information related to the visualized digital twins, including graphical information, graphical information depicting vibration characteristics, graphical information depicting harmonic peaks, graphical information depicting peaks, vibration severity units data, vibration fault level state data, recommendations from cognitive intelligence system 15510, predictions from cognitive intelligence system 15510, probability of failure data, maintenance history data, time to failure data, cost of downtime data, probability of downtime data, cost of repair data, cost of machine replace data, probability of shutdown data, manufacturing KPIs, and the like.

[0769] In another example, a user may request a filtered view of a digital twin of a process, whereby the digital twin of the process only shows components (e.g., machine or equipment) that are involved in the process. In this example, the digital twin visualization module 15568 may retrieve a digital twin of the process, as well as any related digital twins (e.g., a digital twin of the environment and digital twins of any machinery or devices that impact the process). The digital twin visualization module 15568 may then render each of the digital twins (e.g., the environment and the relevant industrial entities) and then may perform the process on the rendered digital twins. It is noted that as a process may be performed over a period of time and may include moving items and/or parts, the digital twin visualization module 15568 may generate a series of sequential frames that demonstrate the process. In this scenario, the movements of the machines and/or devices implicated by the process may be determined according to the behaviors defined in the respective digital twins of the machines and/or devices.

[0770] As discussed, the digital twin visualization module 15568 may output the requested digital twin to a client application 15570. In some embodiments, the client application 15570 is a virtual reality application, whereby the requested digital twin is displayed on a virtual reality headset. In some embodiments, the client application 15570 is an augmented reality application, whereby the requested digital twin is depicted in an AR-enabled device. In these embodiments, the requested digital twin may be filtered such that visual elements and/or text are overlaid on the display of the AR-enabled device.

[0771] It is noted that while a graph database is discussed, the digital twin system 15500 may employ other suitable data structures to store information relating to a set of digital twins. In these embodiments, the data structures, and any related storage system, may be implemented such that the data structures provide for some degree of feedback loops and/or recursion when representing iteration of flows.

[0772] FIG. 131 illustrates an example of a digital twin I/O system 15504 that interfaces with the environment 15520, the digital twin system 15500, and/or components thereof to provide bi-directional transfer of data between coupled components according to some embodiments of the present disclosure.

[0773] In embodiments, the transferred data includes signals (e.g., request signals, command signals, response signals, etc.) between connected components, which may include software components, hardware components, physical devices, virtualized devices, simulated devices, combinations thereof, and the like. The signals may define material properties (e.g., physical quantities of temperature, pressure, humidity, density, viscosity, etc.), measured values (e.g., contemporaneous or stored values acquired by the device or system), device properties (e.g., device ID or properties of the device's design specifications, materials, measurement capabilities, dimensions, absolute position, relative position, combinations thereof, and the like), set points (e.g., targets for material properties, device properties, system properties, combinations thereof, and the like), and/or critical points (e.g., threshold values such as minimum or maximum values for material properties, device properties, system properties, etc.). The signals may be received from systems or devices that acquire (e.g., directly measure or generate) or otherwise obtain (e.g., receive, calculate, look-up, filter, etc.) the data, and may be communicated to or from the digital twin I/O system 15504 at predetermined times or in response to a request (e.g., polling) from the digital twin I/O system 15504. The communications may occur through direct or indirect connections (e.g., via intermediate modules within a circuit and/or intermediate devices between the connected components). The values may correspond to real-world elements 131302r (e.g., an input or output for a tangible vibration sensor) or virtual elements 131302v (e.g., an input or output for a digital twin 131302d and/or a simulated element 131302s that provide vibration data).

[0774] In embodiments, the real-world elements 131302r may be elements within the industrial environment 15520. The real-world elements 131302r may include, for example, non-networked objects 15522, the devices 15524 (smart or non-smart), sensors 15526, and humans 15528. The real-world elements 131302r may be process or non-process equipment within the industrial environments 15520. For example, process equipment may include motors, pumps, mills, fans, painters, welders, smelters, etc., and non-process equipment may include personal protective equipment, safety equipment, emergency stations or devices (e.g., safety showers, eyewash stations, fire extinguishers, sprinkler systems, etc.), warehouse features (e.g., walls, floor layout, etc.), obstacles (e.g., persons or other items within the environment 15520, etc.), etc.

[0775] In embodiments, the virtual elements 131302v may be digital representations of or that correspond to contemporaneously existing real-world elements 131302r. Additionally or alternatively, the virtual elements 131302v may be digital representations of or that correspond to real-world elements 131302r that may be available for later addition and implementation into the environment 15520. The virtual elements may include, for example, simulated elements 131302s and/or digital twins 131302d. In embodiments, the simulated elements 131302s may be digital representations of real-world elements 131302s that are not present within the industrial environment 15520. The simulated elements 131302s may mimic desired physical properties which may be later integrated within the environment 15520 as real-world elements 131302r (e.g., a “black box” that mimics the dimensions of a real-world elements 131302r). The simulated elements 131302s may include digital twins of existing objects (e.g., a single simulated element 131302s may include one or more digital twins 131302d for existing sensors). Information related to the simulated elements 131302s may be obtained, for example, by evaluating behavior of corresponding real-world elements 131302r using mathematical models or algorithms, from libraries that define information and behavior of the simulated elements 131302s (e.g., physics libraries, chemistry libraries, or the like).

[0776] In embodiments, the digital twin 131302d may be a digital representation of one or more real-world elements 131302r. The digital twins 131302d are configured to mimic, copy, and/or model behaviors and responses of the real-world elements 131302r in response to inputs, outputs, and/or conditions of the surrounding or ambient environment. Data related to physical properties and responses of the real-world elements 131302r may be obtained, for example, via user input, sensor input, and/or physical modeling (e.g., thermodynamic models, electrodynamic models, mechanodynamic models, etc.). Information for the digital twin 131302d may correspond to and be obtained from the one or more real-world elements 131302r corresponding to the digital twin 131302d. For example, in some embodiments, the digital twin 131302d may correspond to one real-world element 131302r that is a fixed digital vibration sensor 15536 on a machine component, and vibration data for the digital twin 131302d may be obtained by polling or fetching vibration data measured by the fixed digital vibration sensor on the machine component. In a further example, the digital twin 131302d may correspond to a plurality of real-world elements 131302r such that each of the elements can be a fixed digital vibration sensor on a machine component, and vibration data for the digital twin 131302d may be obtained by polling or fetching vibration data measured by each of the fixed digital vibration sensors on the plurality of real-world elements 131302r. Additionally or alternatively, vibration data of a first digital twin 131302d may be obtained by fetching vibration data of a second digital twin 157302d that is embedded within the first digital twin 157302d, and vibration data for the first digital twin 157302d may include or be derived from vibration data for the second digital twin 157302d. For example, the first digital twin may be a digital twin 157302d of an environment 15520 (alternatively referred to as an “environmental digital twin”) and the second digital twin 157302d may be a digital twin 157302d corresponding to a vibration sensor disposed within the environment 15520 such that the vibration data for the first digital twin 157302d is obtained from or calculated based on data including the vibration data for the second digital twin 157302d.

[0777] In embodiments, the digital twin system 15500 monitors properties of the real-world elements 157302r using the sensors 15526 within a respective environment 15520 that is or may be represented by a digital twin 157302d and/or outputs of models for one or more simulated elements 157302s. In embodiments, the digital twin system 15500 may minimize network congestion while maintaining effective monitoring of processes by extending polling intervals and/or minimizing data transfer for sensors corresponding that correspond to affected real-world elements 157302r and performing simulations (e.g., via the digital-twin simulation system 15506) during the extended interval using data that was obtained from other sources (e.g., sensors that are physically proximate to or have an effect on the affected real-world elements 157302r). Additionally or alternatively, error checking may be performed by comparing the collected sensor data with data obtained from the digital-twin simulation system 15506. For example, consistent deviations or fluctuations between sensor data obtained from the real-world element 157302r and the simulated element 157302s may indicate malfunction of the respective sensor or another fault condition.

[0778] In embodiments, the digital twin system 15500 may optimize features of the environment through use of one or more simulated elements 157302s. For example, the digital twin system 15500 may evaluate effects of the simulated elements 157302s within a digital twin of an environment to quickly and efficiently determine costs and/or benefits flowing from inclusion, exclusion, or substitution of real-world elements 157302r within the environment 15520. The costs and benefits may include, for example, increased machinery costs (e.g., capital investment and maintenance), increased efficiency (e.g., process optimization to reduce waste or increase throughput), decreased or altered footprint within the environment 15520, extension or optimization of useful lifespans, minimization of component faults, minimization of component downtime, etc.

[0779] In embodiments, the digital twin I/O system 15504 may include one or more software modules that are executed by one or more controllers of one or more devices (e.g., server devices, user devices, and/or distributed devices) to affect the described functions. The digital twin I/O system 15504 may include, for example, an input module 157304, an output module 157306, and an adapter module 157308.

[0780] In embodiments, the input module 157304 may obtain or import data from data sources in communication with the digital twin I/O system 15504, such as the sensor system 15530 and the digital twin simulation system 15506. The data may be immediately used by or stored within the digital twin system 15500. The imported data may be ingested from data streams, data batches, in response to a triggering event, combinations thereof, and the like. The input module 157304 may receive data in a format that is suitable to transfer, read, and/or write information within the digital twin system 15500.

[0781] In embodiments, the output module 157306 may output or export data to other system components (e.g., the digital twin datastore 15516, the digital twin simulation system 15506, the cognitive intelligence system 15510, etc.), devices 15524, and/or the client application 15570. The data may be output in data streams, data batches, in response to a triggering event (e.g., a request), combinations thereof, and the like. The output module 157306 may output data in a format that is suitable to be used or stored by the target element (e.g., one protocol for output to the client application and another protocol for the digital twin datastore 15516).

[0782] In embodiments, the adapter module 157308 may process and/or convert data between the input module 157304 and the output module 157306. In embodiments, the adapter module 157308 may convert and/or route data automatically (e.g., based on data type) or in response to a received request (e.g., in response to information within the data).

[0783] In embodiments, the digital twin system 15500 may represent a set of industrial workpiece elements in a digital twin, and the digital twin simulation system 15506 simulates a set of physical interactions of a worker with the workpiece elements.

[0784] In embodiments, the digital twin simulation system 15506 may determine process outcomes for the simulated physical interactions accounting for simulated human factors. For example, variations in workpiece throughput may be modeled by the digital twin system 15500 including, for example, worker response times to events, worker fatigue, discontinuity within worker actions (e.g., natural variations in human-movement speed, differing positioning times, etc.), effects of discontinuities on downstream processes, and the like. In embodiments, individualized worker interactions may be modeled using historical data that is collected, acquired, and/or stored by the digital twin system 15500. The simulation may begin based on estimated amounts (e.g., worker age, industry averages, workplace expectations, etc.). The simulation may also individualize data for each worker (e.g., comparing estimated amounts to collected worker-specific outcomes).

[0785] In embodiments, information relating to workers (e.g., fatigue rates, efficiency rates, and the like) may be determined by analyzing performance of specific workers over time and modeling said performance.

[0786] In embodiments, the digital twin system 15500 includes a plurality of proximity sensors within the sensor system 15530. The proximity sensors are or may be configured to detect elements of the environment 15520 that are within a predetermined area. For example, proximity sensors may include electromagnetic sensors, light sensors, and/or acoustic sensors.

[0787] The electromagnetic sensors are or may be configured to sense objects or interactions via one or more electromagnetic fields (e.g., emitted electromagnetic radiation or received electromagnetic radiation). In embodiments, the electromagnetic sensors include inductive sensors (e.g., radio-frequency identification sensors), capacitive sensors (e.g., contact and contactless capacitive sensors), combinations thereof, and the like.

[0788] The light sensors are or may be configured to sense objects or interactions via electromagnetic radiation in, for example, the far-infrared, near-infrared, optical, and/or ultraviolet spectra. In embodiments, the light sensors may include image sensors (e.g., charge-coupled devices and CMOS active-pixel sensors), photoelectric sensors (e.g., through-beam sensors, retroreflective sensors, and diffuse sensors), combinations thereof, and the like. Further, the light sensors may be implemented as part of a system or subsystem, such as a light detection and ranging (“LIDAR”) sensor.

[0789] The acoustic sensors are or may be configured to sense objects or interactions via sound waves that are emitted and/or received by the acoustic sensors. In embodiments, the acoustic sensors may include infrasonic, sonic, and/or ultrasonic sensors. Further, the acoustic sensors may be grouped as part of a system or subsystem, such as a sound navigation and ranging (“SONAR”) sensor.

[0790] In embodiments, the digital twin system 15500 stores and collects data from a set of proximity sensors within the environment 15520 or portions thereof. The collected data may be stored, for example, in the digital twin datastore 15516 for use by components the digital twin system 15500 and/or visualization by a user. Such use and/or visualization may occur contemporaneously with or after collection of the data (e.g., during later analysis and/or optimization of processes).

[0791] In embodiments, data collection may occur in response to a triggering condition. These triggering conditions may include, for example, expiration of a static or a dynamic predetermined interval, obtaining a value short of or in excess of a static or dynamic value, receiving an automatically generated request or instruction from the digital twin system 15500 or components thereof, interaction of an element with the respective sensor or sensors (e.g., in response to a worker or machine breaking a beam or coming within a predetermined distance from the proximity sensor), interaction of a user with a digital twin (e.g., selection of an environmental digital twin, a sensor array digital twin, or a sensor digital twin), combinations thereof, and the like.

[0792] In some embodiments, the digital twin system 15500 collects and/or stores RFID data in response to interaction of a worker with a real-world element 157302r. For example, in response to a worker interaction with a real-world environment, the digital twin will collect and/or store RFID data from RFID sensors within or associated with the corresponding environment 15520. Additionally or alternatively, worker interaction with a sensor-array digital twin will collect and/or store RFID data from RFID sensors within or associated with the corresponding sensor array. Similarly, worker interaction with a sensor digital twin will collect and/or store RFID data from the corresponding sensor. The RFID data may include suitable data attainable by RFID sensors such as proximate RFID tags, RFID tag position, authorized RFID tags, unauthorized RFID tags, unrecognized RFID tags, RFID type (e.g., active or passive), error codes, combinations thereof, and the like.

[0793] In embodiments, the digital twin system 15500 may further embed outputs from one or more devices within a corresponding digital twin. In embodiments, the digital twin system 15500 embeds output from a set of individual-associated devices into an industrial digital twin. For example, the digital twin I/O system 15504 may receive information output from one or more wearable devices 15554 or mobile devices (not shown) associated with an individual within an industrial environment. The wearable devices may include image capture devices (e.g., body cameras or augmented-reality headwear), navigation devices (e.g., GPS devices, inertial guidance systems), motion trackers, acoustic capture devices (e.g., microphones), radiation detectors, combinations thereof, and the like.

[0794] In embodiments, upon receiving the output information, the digital twin I/O system 15504 routes the information to the digital twin creation module 15564 to check and/or update the environment digital twin and/or associated digital twins within the environment (e.g., a digital twin of a worker, machine, or robot position at a given time). Further, the digital twin system 15500 may use the embedded output to determine characteristics of the environment 15520.

[0795] In embodiments, the digital twin system 15500 embeds output from a LIDAR point cloud system into an industrial digital twin. For example, the digital twin I/O system 15504 may receive information output from one or more Lidar devices 15538 within an industrial environment. The Lidar devices 15538 are configured to provide a plurality of points having associated position data (e.g., coordinates in absolute or relative x, y, and z values). Each of the plurality of points may include further LIDAR attributes, such as intensity, return number, total returns, laser color data, return color data, scan angle, scan direction, etc. The Lidar devices 15538 may provide a point cloud that includes the plurality of points to the digital twin system 15500 via, for example, the digital twin I/O system 15504. Additionally or alternatively, the digital twin system 15500 may receive a stream of points and assemble the stream into a point cloud, or may receive a point cloud and assemble the received point cloud with existing point cloud data, map data, or three dimensional (3D)-model data.

[0796] In embodiments, upon receiving the output information, the digital twin I/O system 15504 routes the point cloud information to the digital twin creation module 15564 to check and/or update the environment digital twin and/or associated digital twins within the environment (e.g., a digital twin of a worker, machine, or robot position at a given time). In some embodiments, the digital twin system 15500 is further configured to determine closed-shape objects within the received LIDAR data. For example, the digital twin system 15500 may group a plurality of points within the point cloud as an object and, if necessary, estimate obstructed faces of objects (e.g., a face of the object contacting or adjacent a floor or a face of the object contacting or adjacent another object such as another piece of equipment). The system may use such closed-shape objects to narrow search space for digital twins and thereby increase efficiency of matching algorithms (e.g., a shape-matching algorithm).

[0797] In embodiments, the digital twin system 15500 embeds output from a simultaneous location and mapping (“SLAM”) system in an environmental digital twin. For example, the digital twin I/O system 15504 may receive information output from the SLAM system, such as Slam sensor 15562, and embed the received information within an environment digital twin corresponding to the location determined by the SLAM system. In embodiments, upon receiving the output information from the SLAM system, the digital twin I/O system 15504 routes the information to the digital twin creation module 15564 to check and/or update the environment digital twin and/or associated digital twins within the environment (e.g., a digital twin of a workpiece, furniture, movable object, or autonomous object). Such updating provides digital twins of non-connected elements (e.g., furnishings or persons) automatically and without need of user interaction with the digital twin system 15500.

[0798] In embodiments, the digital twin system 15500 can leverage known digital twins to reduce computational requirements for the Slam sensor 15562 by using suboptimal map-building algorithms. For example, the suboptimal map-building algorithms may allow for a higher uncertainty tolerance using simple bounded-region representations and identifying possible digital twins. Additionally or alternatively, the digital twin system 15500 may use a bounded-region representation to limit the number of digital twins, analyze the group of potential twins for distinguishing features, then perform higher precision analysis for the distinguishing features to identify and/or eliminate categories of, groups of, or individual digital twins and, in the event that no matching digital twin is found, perform a precision scan of only the remaining areas to be scanned.

[0799] In embodiments, the digital twin system 15500 may further reduce compute required to build a location map by leveraging data captured from other sensors within the environment (e.g., captured images or video, radio images, etc.) to perform an initial map-building process (e.g., a simple bounded-region map or other suitable photogrammetry methods), associate digital twins of known environmental objects with features of the simple bounded-region map to refine the simple bounded-region map, and perform more precise scans of the remaining simple bounded regions to further refine the map. In some embodiments, the digital twin system 15500 may detect objects within received mapping information and, for each detected object, determine whether the detected object corresponds to an existing digital twin of a real-world-element. In response to determining that the detected object does not correspond to an existing real-world-element digital twin, the digital twin system 15500 may use, for example, the digital twin creation module 15564 to generate a new digital twin corresponding to the detected object (e.g., a detected-object digital twin) and add the detected-object digital twin to the real-world-element digital twins within the digital twin datastore. Additionally or alternatively, in response to determining that the detected object corresponds to an existing real-world-element digital twin, the digital twin system 15500 may update the real-world-element digital twin to include new information detected by the simultaneous location and mapping sensor, if any.

[0800] In embodiments, the digital twin system 15500 represents locations of autonomously or remotely moveable elements and attributes thereof within an industrial digital twin. Such movable elements may include, for example, workers, persons, vehicles, autonomous vehicles, robots, etc. The locations of the moveable elements may be updated in response to a triggering condition. Such triggering conditions may include, for example, expiration of a static or a dynamic predetermined interval, receiving an automatically generated request or instruction from the digital twin system 15500 or components thereof, interaction of an element with a respective sensor or sensors (e.g., in response to a worker or machine breaking a beam or coming within a predetermined distance from a proximity sensor), interaction of a user with a digital twin (e.g., selection of an environmental digital twin, a sensor array digital twin, or a sensor digital twin), combinations thereof, and the like.

[0801] In embodiments, the time intervals may be based on probability of the respective movable element having moved within a time period. For example, the time interval for updating a worker location may be relatively shorter for workers expected to move frequently (e.g., a worker tasked with lifting and carrying objects within and through the environment 15520) and relatively longer for workers expected to move infrequently (e.g., a worker tasked with monitoring a process stream). Additionally or alternatively, the time interval may be dynamically adjusted based on applicable conditions, such as increasing the time interval when no movable elements are detected, decreasing the time interval as or when the number of moveable elements within an environment increases (e.g., increasing number of workers and worker interactions), increasing the time interval during periods of reduced environmental activity (e.g., breaks such as lunch), decreasing the time interval during periods of abnormal environmental activity (e.g., tours, inspections, or maintenance), decreasing the time interval when unexpected or uncharacteristic movement is detected (e.g., frequent movement by a typically sedentary element or coordinated movement, for example, of workers approaching an exit or moving cooperatively to carry a large object), combinations thereof, and the like. Further, the time interval may also include additional, semi-random acquisitions. For example, occasional mid-interval locations may be acquired by the digital twin system 15500 to reinforce or evaluate the efficacy of the particular time interval.

[0802] In embodiments, the digital twin system 15500 may analyze data received from the digital twin I/O system 15504 to refine, remove, or add conditions. For example, the digital twin system 15500 may optimize data collection times for movable elements that are updated more frequently than needed (e.g., multiple consecutive received positions being identical or within a predetermined margin of error).

[0803] In embodiments, the digital twin system 15500 may receive, identify, and/or store a set of states 15540a-n related to the environment 15520. The states 15540a-n may be, for example, data structures that include a plurality of attributes 158404a-n and a set of identifying criteria 158406a-n to uniquely identify each respective state 15540a-n. In embodiments, the states 15540a-n may correspond to states where it is desirable for the digital twin system 15500 to set or alter conditions of real-world elements 157302r and/or the environment 15520 (e.g., increase/decrease monitoring intervals, alter operating conditions, etc.).

[0804] In embodiments, the set of states 15540a-n may further include, for example, minimum monitored attributes for each state 15540a-n, the set of identifying criteria 158406a-n for each state 15540a-n, and/or actions available to be taken or recommended to be taken in response to each state 15540a-n. Such information may be stored by, for example, the digital twin datastore 15516 or another datastore. The states 15540a-n or portions thereof may be provided to, determined by, or altered by the digital twin system 15500. Further, the set of states 15540a-n may include data from disparate sources. For example, details to identify and/or respond to occurrence of a first state may be provided to the digital twin system 15500 via user input, details to identify and/or respond to occurrence of a second state may be provided to the digital twin system 15500 via an external system, details to identify and/or respond to occurrence of a third state may be determined by the digital twin system 15500 (e.g., via simulations or analysis of process data), and details to identify and/or respond to occurrence of a fourth state may be stored by the digital twin system 15500 and altered as desired (e.g., in response to simulated occurrence of the state or analysis of data collected during an occurrence of and response to the state).

[0805] In embodiments, the plurality of attributes 158404a-n includes at least the attributes 158404a-n needed to identify the respective state 15540a-n. The plurality of attributes 158404a-n may further include additional attributes that are or may be monitored in determining the respective state 15540a-n, but are not needed to identify the respective state 15540a-n. For example, the plurality of attributes 158404a-n for a first state may include relevant information such as rotational speed, fuel level, energy input, linear speed, acceleration, temperature, strain, torque, volume, weight, etc.

[0806] The set of identifying criteria 158406a-n may include information for each of the set of attributes 158404a-n to uniquely identify the respective state. The identifying criteria 158406a-n may include, for example, rules, thresholds, limits, ranges, logical values, conditions, comparisons, combinations thereof, and the like.

[0807] The change in operating conditions or monitoring may be any suitable change. For example, after identifying occurrence of a respective state 158406a-n, the digital twin system 15500 may increase or decrease monitoring intervals for a device (e.g., decreasing monitoring intervals in response to a measured parameter differing from nominal operation) without altering operation of the device. Additionally or alternatively, the digital twin system 15500 may alter operation of the device (e.g., reduce speed or power input) without altering monitoring of the device. In further embodiments, the digital twin system 15500 may alter operation of the device (e.g., reduce speed or power input) and alter monitoring intervals for the device (e.g., decreasing monitoring intervals).

[0808] FIG. 151 illustrates an example set of identified states 15540a-n related to industrial environments that the digital twin system 15500 may identify and/or store for access by intelligent systems (e.g., the cognitive intelligence system 15510) or users of the digital twin system 15500, according to some embodiments of the present disclosure. The states 15540a-n may include operational states (e.g., suboptimal, normal, optimal, critical, or alarm operation of one or more components), excess or shortage states (e.g., supply-side or output-side quantities), combinations thereof, and the like.

[0809] In embodiments, the digital twin system 15500 may monitor attributes 151404a-n of real-world elements 157302r and/or digital twins 157302d to determine the respective state 15540a-n. The attributes 151404a-n may be, for example, operating conditions, set points, critical points, status indicators, other sensed information, combinations thereof, and the like. For example, the attributes 151404a-n may include power input 151404a, operational speed 151404b, critical speed 151404c, and operational temperature 151404d of the monitored elements. While the illustrated example illustrates uniform monitored attributes, the monitored attributes may differ by target device (e.g., the digital twin system 15500 would not monitor rotational speed for an object with no rotatable components).

[0810] Each of the states 15540a-n includes a set of identifying criteria 151406a-n meeting particular criteria that are unique among the group of monitored states 15540a-n. The digital twin system 15500 may identify the overspeed state 15540a, for example, in response to the monitored attributes 151404a-n meeting a first set of identifying criteria 151406a (e.g., operational speed 151404b being higher than the critical speed 151404c, while the operational temperature 151404d is nominal).

[0811] In response to determining that one or more states 15540a-n exists or has occurred, the digital twin system 15500 may update triggering conditions for one or more monitoring protocols, issue an alert or notification, or trigger actions of subcomponents of the digital twin system 15500. For example, subcomponents of the digital twin system 15500 may take actions to mitigate and/or evaluate impacts of the detected states 15540a-n. When attempting to take actions to mitigate impacts of the detected states 15540a-n on real-world elements 157302r, the digital twin system 15500 may determine whether instructions exist (e.g., are stored in the digital twin datastore 15516) or should be developed (e.g., developed via simulation and cognitive intelligence or via user or worker input). Further, the digital twin system 15500 may evaluate impacts of the detected states 15540a-n, for example, concurrently with the mitigation actions or in response to determining that the digital twin system 15500 has no stored mitigation instructions for the detected states 15540a-n.

[0812] In embodiments, the digital twin system 15500 employs the digital twin simulation system 15506 to simulate one or more impacts, such as immediate, upstream, downstream, and/or continuing effects, of recognized states. The digital twin simulation system 15506 may collect and/or be provided with values relevant to the evaluated states 15540a-n. In simulating the impact of the one or more states 15540a-n, the digital twin simulation system 15506 may recursively evaluate performance characteristics of affected digital twins 157302d until convergence is achieved. The digital twin simulation system 15506 may work, for example, in tandem with the cognitive intelligence system 15510 to determine response actions to alleviate, mitigate, inhibit, and/or prevent occurrence of the one or more states 15540a-n. For example, the digital twin simulation system 15506 may recursively simulate impacts of the one or more states 15540a-n until achieving a desired fit (e.g., convergence is achieved), provide the simulated values to the cognitive intelligence system 15510 for evaluation and determination of potential actions, receive the potential actions, evaluate impacts of each of the potential actions for a respective desired fit (e.g., cost functions for minimizing production disturbance, preserving critical components, minimizing maintenance and/or downtime, optimizing system, worker, user, or personal safety, etc.).

[0813] In embodiments, the digital twin simulation system 15506 and the cognitive intelligence system 15510 may repeatedly share and update the simulated values and response actions for each desired outcome until desired conditions are met (e.g., convergence for each evaluated cost function for each evaluated action). The digital twin system 15500 may store the results in the digital twin datastore 15516 for use in response to determining that one or more states 15540a-n has occurred. Additionally, simulations and evaluations by the digital twin simulation system 15506 and/or the cognitive intelligence system 15510 may occur in response to occurrence or detection of the event.

[0814] In embodiments, simulations and evaluations are triggered only when associated actions are not present within the digital twin system 15500. In further embodiments, simulations and evaluations are performed concurrently with use of stored actions to evaluate the efficacy or effectiveness of the actions in real time and/or evaluate whether further actions should be employed or whether unrecognized states may have occurred. In embodiments, the cognitive intelligence system 15510 may also be provided with notifications of instances of undesired actions with or without data on the undesired aspects or results of such actions to optimize later evaluations.

[0815] In embodiments, the digital twin system 15500 evaluates and/or represents the impact of machine downtime within a digital twin of a manufacturing facility. For example, the digital twin system 15500 may employ the digital twin simulation system 15506 to simulate the immediate, upstream, downstream, and/or continuing effects of a machine downtime state 15540b. The digital twin simulation system 15506 may collect or be provided with performance-related values such as optimal, suboptimal, and minimum performance requirements for elements (e.g., real-world elements 157302r and/or nested digital twins 157302d) within the affected digital twins 157302d, and/or characteristics thereof that are available to the affected digital twins 157302d, nested digital twins 157302d, redundant systems within the affected digital twins 157302d, combinations thereof, and the like.

[0816] In embodiments, the digital twin system 15500 is configured to: simulate one or more operating parameters for the real-world elements in response to the industrial environment being supplied with given characteristics using the real-world-element digital twins; calculate a mitigating action to be taken by one or more of the real-world elements in response to being supplied with the contemporaneous characteristics; and actuate, in response to detecting the contemporaneous characteristics, the mitigating action. The calculation may be performed in response to detecting contemporaneous characteristics or operating parameters falling outside of respective design parameters or may be determined via a simulation prior to detection of such characteristics.

[0817] Additionally or alternatively, the digital twin system 15500 may provide alerts to one or more users or system elements in response to detecting states.

[0818] In embodiments, the digital twin I/O system 15504 includes a pathing module 157310. The pathing module 157310 may ingest navigational data from the elements 157302, provide and/or request navigational data to components of the digital twin system 15500 (e.g., the digital twin simulation system 15506, the digital twin behavior system, and/or the cognitive intelligence system 15510), and/or output navigational data to elements 157302 (e.g., to the wearable devices 15554). The navigational data may be collected or estimated using, for example, historical data, guidance data provided to the elements 157302, combinations thereof, and the like.

[0819] For example, the navigational data may be collected or estimated using historical data stored by the digital twin system 15500. The historical data may include or be processed to provide information such as acquisition time, associated elements 157302, polling intervals, task performed, laden or unladen conditions, whether prior guidance data was provided and/or followed, conditions of the environment 15520, other elements 157302 within the environment 15520, combinations thereof, and the like. The estimated data may be determined using one or more suitable pathing algorithms. For example, the estimated data may be calculated using suitable order-picking algorithms, suitable path-search algorithms, combinations thereof, and the like. The order-picking algorithm may be, for example, a largest gap algorithm, an s-shape algorithm, an aisle-by-aisle algorithm, a combined algorithm, combinations thereof, and the like. The path-search algorithms may be, for example, Dijkstra's algorithm, the A* algorithm, hierarchical path-finding algorithms, incremental path-finding algorithms, any angle path-finding algorithms, flow field algorithms, combinations thereof, and the like.

[0820] Additionally or alternatively, the navigational data may be collected or estimated using guidance data of the worker. The guidance data may include, for example, a calculated route provided to a device of the worker (e.g., a mobile device or the wearable device 15554). In another example, the guidance data may include a calculated route provided to a device of the worker that instructs the worker to collect vibration measurements from one or more locations on one or more machines along the route. The collected and/or estimated navigational data may be provided to a user of the digital twin system 15500 for visualization, used by other components of the digital twin system 15500 for analysis, optimization, and/or alteration, provided to one or more elements 157302, combinations thereof, and the like.

[0821] In embodiments, the digital twin system 15500 ingests navigational data for a set of workers for representation in a digital twin. Additionally or alternatively, the digital twin system 15500 ingests navigational data for a set of mobile equipment assets of an industrial environment into a digital twin.

[0822] In embodiments, the digital twin system 15500 ingests a system for modeling traffic of mobile elements in an industrial digital twin. For example, the digital twin system 15500 may model traffic patterns for workers or persons within the environment 15520, mobile equipment assets, combinations thereof, and the like. The traffic patterns may be estimated based on modeling traffic patterns from and historical data and contemporaneous ingested data. Further, the traffic patterns may be continuously or intermittently updated depending on conditions within the environment 15520 (e.g., a plurality of autonomous mobile equipment assets may provide information to the digital twin system 15500 at a slower update interval than the environment 15520 including both workers and mobile equipment assets).

[0823] The digital twin system 15500 may alter traffic patterns (e.g., by providing updated navigational data to one or more of the mobile elements) to achieve one or more predetermined criteria. The predetermined criteria may include, for example, increasing process efficiency, decreasing interactions between laden workers and mobile equipment assets, minimizing worker path length, routing mobile equipment around paths or potential paths of persons, combinations thereof, and the like.

[0824] In embodiments, the digital twin system 15500 may provide traffic data and/or navigational information to mobile elements in an industrial digital twin. The navigational information may be provided as instructions or rule sets, displayed path data, or selective actuation of devices. For example, the digital twin system 15500 may provide a set of instructions to a robot to direct the robot to and/or along a desired route for collecting vibration data from one or more specified locations on one or more specified machines along the route using a vibration sensor. The robot may communicate updates to the system including obstructions, reroutes, unexpected interactions with other assets within the environment 15520, etc.

[0825] In some embodiments, an ant-based system 15574 enables industrial entities, including robots, to lay a trail with one or more messages for other industrial entities, including themselves, to follow in later journeys. In embodiments, the messages include information related to vibration measurement collection. In embodiments, the messages include information related to vibration sensor measurement locations. In some embodiments, the trails may be configured to fade over time. In some embodiments, the ant-based trails may be experienced via an augmented reality system. In some embodiments, the ant-based trails may be experienced via a virtual reality system. In some embodiments, the ant-based trails may be experienced via a mixed reality system. In some embodiments, ant-based tagging of areas can trigger a pain-response and/or accumulate into a warning signal. In embodiments, the ant-based trails may be configured to generate an information filtering response. In some embodiments, the ant-based trails may be configured to generate an information filtering response wherein the information filtering response is a heightened sense of visual awareness. In some embodiments, the ant-based trails may be configured to generate an information filtering response wherein the information filtering response is a heightened sense of acoustic awareness. In some embodiments, the messages include vectorized data.

[0826] In embodiments, the digital twin system 15500 includes design specification information for representing a real-world element 157302r using a digital twin 157302d. The digital may correspond to an existing real-world element 157302r or a potential real-world element 157302r. The design specification information may be received from one or more sources. For example, the design specification information may include design parameters set by user input, determined by the digital twin system 15500 (e.g., the via digital twin simulation system 15506), optimized by users or the digital twin simulation system 15506, combinations thereof, and the like. The digital twin simulation system 15506 may represent the design specification information for the component to users, for example, via a display device or a wearable device. The design specification information may be displayed schematically (e.g., as part of a process diagram or table of information) or as part of an augmented reality or virtual reality display. The design specification information may be displayed, for example, in response to a user interaction with the digital twin system 15500 (e.g., via user selection of the element or user selection to generally include design specification information within displays). Additionally or alternatively, the design specification information may be displayed automatically, for example, upon the element coming within view of an augmented reality or virtual reality device. In embodiments, the displayed design specification information may further include indicia of information source (e.g., different displayed colors indicate user input versus digital twin system 15500 determination), indicia of mismatches (e.g., between design specification information and operational information), combinations thereof, and the like.

[0827] In embodiments, the digital twin system 15500 embeds a set of control instructions for a wearable device within an industrial digital twin, such that the control instructions are provided to the wearable device to induce an experience for a wearer of the wearable device upon interaction with an element of the industrial digital twin. The induced experience may be, for example, an augmented reality experience or a virtual reality experience. The wearable device, such as a headset, may be configured to output video, audio, and/or haptic feedback to the wearer to induce the experience. For example, the wearable device may include a display device and the experience may include display of information related to the respective digital twin. The information displayed may include maintenance data associated with the digital twin, vibration data associated with the digital twin, vibration measurement location data associated with the digital twin, financial data associated with the digital twin, such as a profit or loss associated with operation of the digital twin, manufacturing KPIs associated with the digital twin, information related to an occluded element (e.g., a sub-assembly) that is at least partially occluded by a foreground element (e.g., a housing), a virtual model of the occluded element overlaid on the occluded element and visible with the foreground element, operating parameters for the occluded element, a comparison to a design parameter corresponding to the operating parameter displayed, combinations thereof, and the like. Comparisons may include, for example, altering display of the operating parameter to change a color, size, and/or display period for the operating parameter.

[0828] In some embodiments, the displayed information may include indicia for removable elements that are or may be configured to provide access to the occluded element with each indicium being displayed proximate to or overlying the respective removable element. Further, the indicia may be sequentially displayed such that a first indicium corresponding to a first removable element (e.g., a housing) is displayed, and a second indicium corresponding to a second removable element (e.g., an access panel within the housing) is displayed in response to the worker removing the first removable element. In some embodiments, the induced experience allows the wearer to see one or more locations on a machine for optimal vibration measurement collection. In an example, the digital twin system 15500 may provide an augmented reality view that includes highlighted vibration measurement collection locations on a machine and/or instructions related to collecting vibration measurements. Furthering the example, the digital twin system 15500 may provide an augmented reality view that includes instructions related to timing of vibration measurement collection. Information utilized in displaying the highlighted placement locations may be obtained using information stored by the digital twin system 15500. In some embodiments, mobile elements may be tracked by the digital twin system 15500 (e.g., via observational elements within the environment 15520 and/or via pathing information communicated to the digital twin system 15500) and continually displayed by the wearable device within the occluded view of the worker. This optimizes movement of elements within the environment 15520, increases worker safety, and minimizes down time of elements resulting from damage.

[0829] In some embodiments, the digital twin system 15500 may provide an augmented reality view that displays mismatches between design parameters or expected parameters of real-world elements 157302r to the wearer. The displayed information may correspond to real-world elements 157302r that are not within the view of the wearer (e.g., elements within another room or obscured by machinery). This allows the worker to quickly and accurately troubleshoot mismatches to determine one or more sources for the mismatch. The cause of the mismatch may then be determined, for example, by the digital twin system 15500 and corrective actions ordered. In example embodiments, a wearer may be able to view malfunctioning subcomponents of machines without removing occluding elements (e.g., housings or shields). Additionally or alternatively, the wearer may be provided with instructions to repair the device, for example, including display of the removal process (e.g., location of fasteners to be removed), assemblies or subassemblies that should be transported to other areas for repair (e.g., dust-sensitive components), assemblies or subassemblies that need lubrication, and locations of objects for reassembly (e.g., storing location that the wearer has placed removed objects and directing the wearer or another wearer to the stored locations to expedite reassembly and minimize further disassembly or missing parts in the reassembled element). This can expedite repair work, minimize process impact, allow workers to disassemble and reassemble equipment (e.g., by coordinating disassembly without direct communication between the workers), increase equipment longevity and reliability (e.g., by assuring that all components are properly replaced prior to placing back in service), combinations thereof, and the like.

[0830] In some embodiments, the induced experience includes a virtual reality view or an augmented reality view that allows the wearer to see information related to existing or planned elements. The information may be unrelated to physical performance of the element (e.g., financial performance such as asset value, energy cost, input material cost, output material value, legal compliance, and corporate operations). One or more wearers may perform a virtual walkthrough or an augmented walkthrough of the industrial environment 15520.

[0831] In examples, the wearable device displays compliance information that expedites inspections or performance of work.

[0832] In further examples, the wearable device displays financial information that is used to identify targets for alteration or optimization. For example, a manager or officer may inspect the environment 15520 for compliance with updated regulations, including information regarding compliance with former regulations, “grandfathered,” and/or excepted elements. This can be used to reduce unnecessary downtime (e.g., scheduling upgrades for the least impactful times, such as during planned maintenance cycles), prevent unnecessary upgrades (e.g., replacing grandfathered or excepted equipment), and reduce capital investment.

[0833] Referring back to FIG. 155, in embodiments, the digital twin system 15500 may include, integrate, integrate with, manage, handle, link to, take input from, provide output to, control, coordinate with, or otherwise interact with a digital twin dynamic model system 15508. The digital twin dynamic model system 15508 can update the properties of a set of digital twins of a set of industrial entities and/or environments, including properties of physical industrial assets, workers, processes, manufacturing facilities, warehouses, and the like (or any of the other types of entities or environments described in this disclosure or in the documents incorporated by reference herein) in such a manner that the digital twins may represent those industrial entities and environments, and properties or attributes thereof, in real-time or very near real-time. In some embodiments, the digital twin dynamic model system 15508 may obtain sensor data received from a sensor system 15530 and may determine one or more properties of an industrial environment or an industrial entity within an environment based on the sensor data and based on one or more dynamic models.

[0834] In embodiments, the digital twin dynamic model system 15508 may update/assign values of various properties in a digital twin and/or one or more embedded digital twins, including, but not limited to, vibration values, vibration fault level states, probability of failure values, probability of downtime values, cost of downtime values, probability of shutdown values, financial values, KPI values, temperature values, humidity values, heat flow values, fluid flow values, radiation values, substance concentration values, velocity values, acceleration values, location values, pressure values, stress values, strain values, light intensity values, sound level values, volume values, shape characteristics, material characteristics, and dimensions.

[0835] In embodiments, a digital twin may be comprised of (e.g., via reference) of other embedded digital twins. For example, a digital twin of a manufacturing facility may include an embedded digital twin of a machine and one or more embedded digital twins of one or more respective motors enclosed within the machine. A digital twin may be embedded, for example, in the memory of an industrial machine that has an onboard IT system (e.g., the memory of an Onboard Diagnostic System, control system (e.g., SCADA system) or the like). Other non-limiting examples of where a digital twin may be embedded include the following: on a wearable device of a worker; in memory on a local network asset, such as a switch, router, access point, or the like; in a cloud computing resource that is provisioned for an environment or entity; and on an asset tag or other memory structure that is dedicated to an entity.

[0836] In one example, the digital twin dynamic model system 15508 can update vibration characteristics throughout an industrial environment digital twin based on captured vibration sensor data measured at one or more locations in the industrial environment and one or more dynamic models that model vibration within the industrial environment digital twin. The industrial digital twin may, before updating, already contain information about properties of the industrial entities and/or environment that can be used to feed a dynamic model, such as information about materials, shapes/volumes (e.g., of conduits), positions, connections/interfaces, and the like, such that vibration characteristics can be represented for the entities and/or environment in the digital twin. Alternatively, the dynamic models may be configured using such information.

[0837] In embodiments, the digital twin dynamic model system 15508 can update the properties of a digital twin and/or one or more embedded digital twins on behalf of a client application 15570. In embodiments, a client application 15570 may be an application relating to an industrial component or environment (e.g., monitoring an industrial facility or a component within, simulating an industrial environment, or the like). In embodiments, the client application 15570 may be used in connection with both fixed and mobile data collection systems. In embodiments, the client application 15570 may be used in connection with Industrial Internet of Things sensor system 15530.

[0838] In embodiments, the digital twin dynamic model system 15508 leverages digital twin dynamic models 155100 to model the behavior of an industrial entity and/or environment. Dynamic models 155100 may enable digital twins to represent physical reality, including the interactions of industrial entities, by using a limited number of measurements to enrich the digital representation of an industrial entity and/or environment, such as based on scientific principles. In embodiments, the dynamic models 155100 are formulaic or mathematical models. In embodiments, the dynamic models 155100 adhere to scientific laws, laws of nature, and formulas (e.g., Newton's laws of motion, second law of thermodynamics, Bernoulli's principle, ideal gas law, Dalton's law of partial pressures, Hooke's law of elasticity, Fourier's law of heat conduction, Archimedes' principle of buoyancy, and the like). In embodiments, the dynamic models are machine-learned models.

[0839] In embodiments, the digital twin system 15500 may have a digital twin dynamic model datastore 155102 for storing dynamic models 155100 that may be represented in digital twins. In embodiments, digital twin dynamic model datastore can be searchable and/or discoverable. In embodiments, digital twin dynamic model datastore can contain metadata that allows a user to understand what characteristics a given dynamic model can handle, what inputs are required, what outputs are provided, and the like. In some embodiments, digital twin dynamic model datastore 155102 can be hierarchical (such as where a model can be deepened or made more simple based on the extent of available data and/or inputs, the granularity of the inputs, and/or situational factors (such as where something becomes of high interest and a higher fidelity model is accessed for a period of time).

[0840] In embodiments, a digital twin or digital representation of an industrial entity or facility may include a set of data structures that collectively define a set of properties of a represented physical industrial asset, device, worker, process, facility, and/or environment, and/or possible behaviors thereof. In embodiments, the digital twin dynamic model system 15508 may leverage the dynamic models 155100 to inform the set of data structures that collectively define a digital twin with real-time data values. The digital twin dynamic models 155100 may receive one or more sensor measurements, Industrial Internet of Things device data, and/or other suitable data as inputs and calculate one or more outputs based on the received data and one or more dynamic models 155100. The digital twin dynamic model system 15508 then uses the one or more outputs to update the digital twin data structures.

[0841] In one example, the set of properties of a digital twin of an industrial asset that may be updated by the digital twin dynamic model system 15508 using dynamic models 155100 may include the vibration characteristics of the asset, temperature(s) of the asset, the state of the asset (e.g., a solid, liquid, or gas), the location of the asset, the displacement of the asset, the velocity of the asset, the acceleration of the asset, probability of downtime values associated with the asset, cost of downtime values associated with the asset, probability of shutdown values associated with the asset, manufacturing KPIs associated with the asset, financial information associated with the asset, heat flow characteristics associated with the asset, fluid flow rates associated with the asset (e.g., fluid flow rates of a fluid flowing through a pipe), identifiers of other digital twins embedded within the digital twin of the asset and/or identifiers of digital twins embedding the digital twin of the asset, and/or other suitable properties. Dynamic models 155100 associated with a digital twin of an asset can be configured to calculate, interpolate, extrapolate, and/or output values for such asset digital twin properties based on input data collected from sensors and/or devices disposed in the industrial setting and/or other suitable data and subsequently populate the asset digital twin with the calculated values.

[0842] In some embodiments, the set of properties of a digital twin of an industrial device that may be updated by the digital twin dynamic model system 15508 using dynamic models 155100 may include the status of the device, a location of the device, the temperature(s) of a device, a trajectory of the device, identifiers of other digital twins that the digital twin of the device is embedded within, embeds, is linked to, includes, integrates with, takes input from, provides output to, and/or interacts with and the like. Dynamic models 155100 associated with a digital twin of a device can be configured to calculate or output values for these device digital twin properties based on input data and subsequently update the device digital twin with the calculated values.

[0843] In some embodiments, the set of properties of a digital twin of an industrial worker that may be updated by the digital twin dynamic model system 15508 using dynamic models 155100 may include the status of the worker, the location of the worker, a stress measure for the worker, a task being performed by the worker, a performance measure for the worker, and the like. Dynamic models associated with a digital twin of an industrial worker can be configured to calculate or output values for such properties based on input data, which then may be used to populate industrial worker digital twin. In embodiments, industrial worker dynamic models (e.g., psychometric models) can be configured to predict reactions to stimuli, such as cues that are given to workers to direct them to undertake tasks and/or alerts or warnings that are intended to induce safe behavior. In embodiments, industrial worker dynamic models may be workflow models (Gantt charts and the like), failure mode effects analysis models (FMEA), biophysical models (such as to model worker fatigue, energy utilization, hunger), and the like.

[0844] Example properties of a digital twin of an industrial environment that may be updated by the digital twin dynamic model system 15508 using dynamic models 155100 may include the dimensions of the industrial environment, the temperature(s) of the industrial environment, the humidity value(s) of the industrial environment, the fluid flow characteristics in the industrial environment, the heat flow characteristics of the industrial environment, the lighting characteristics of the industrial environment, the acoustic characteristics of the industrial environment the physical objects in the environment, processes occurring in the industrial environment, currents of the industrial environment (if a body of water), and the like. Dynamic models associated with a digital twin of an industrial environment can be configured to calculate or output these properties based on input data collected from sensors and/or devices disposed in the industrial environment and/or other suitable data and subsequently populate the industrial environment digital twin with the calculated values.

[0845] In embodiments, dynamic models 155100 may adhere to physical limitations that define boundary conditions, constants or variables for digital twin modeling. For example, the physical characterization of a digital twin of an industrial entity or industrial environment may include a gravity constant (e.g., 9.8 m/s2), friction coefficients of surfaces, thermal coefficients of materials, maximum temperatures of assets, maximum flow capacities, and the like. Additionally or alternatively, the dynamic models may adhere to the laws of nature. For example, dynamic models may adhere to the laws of thermodynamics, laws of motion, laws of fluid dynamics, laws of buoyancy, laws of heat transfer, laws of radiation, laws of quantum dynamics, and the like. In some embodiments, dynamic models may adhere to biological aging theories or mechanical aging principles. Thus, when the digital twin dynamic model system 15508 facilitates a real-time digital representation, the digital representation may conform to dynamic models, such that the digital representations mimic real world conditions. In some embodiments, the output(s) from a dynamic model can be presented to a human user and/or compared against real-world data to ensure convergence of the dynamic models with the real world. Furthermore, as dynamic models are based partly on assumptions, the properties of a digital twin may be improved and/or corrected when a real-world behavior differs from that of the digital twin. In embodiments, additional data collection and/or instrumentation can be recommended based on the recognition that an input is missing from a desired dynamic model, that a model in operation isn't working as expected (perhaps due to missing and/or faulty sensor information), that a different result is needed (such as due to situational factors that make something of high interest), and the like.

[0846] Dynamic models may be obtained from a number of different sources. In some embodiments, a user can upload a model created by the user or a third party. Additionally or alternatively, the models may be created on the digital twin system using a graphical user interface. The dynamic models may include bespoke models that are configured for a particular environment and/or set of industrial entities and/or agnostic models that are applicable to similar types of digital twins. The dynamic models may be machine-learned models.

[0847] FIG. 159 illustrates example embodiments of a method for updating a set of properties of a digital twin and/or one or more embedded digital twins on behalf of client applications 15570. In embodiments, digital twin dynamic model system 15508 leverages one or more dynamic models 155100 to update a set of properties of a digital twin and/or one or more embedded digital twins on behalf of client application 15570 based on the impact of collected sensor data from sensor system 15530, data collected from Internet of Things connected devices 15524, and/or other suitable data in the set of dynamic models 155100 that are used to enable the industrial digital twins. In embodiments, the digital twin dynamic model system 15508 may be instructed to run specific dynamic models using one or more digital twins that represent physical industrial assets, devices, workers, processes, and/or industrial environments that are managed, maintained, and/or monitored by the client applications 15570.

[0848] In embodiments, the digital twin dynamic model system 15508 may obtain data from other types of external data sources that are not necessarily industrial-related data sources, but may provide data that can be used as input data for the dynamic models. For example, weather data, news events, social media data, and the like may be collected, crawled, subscribed to, and the like to supplement sensor data, Industrial Internet of Things device data, and/or other data that is used by the dynamic models. In embodiments, the digital twin dynamic model system 15508 may obtain data from a machine vision system. The machine vision system may use video and/or still images to provide measurements (e.g., locations, statuses, and the like) that may be used as inputs by the dynamic models.

[0849] In embodiments, the digital twin dynamic model system 15508 may feed this data into one or more of the dynamic models discussed above to obtain one or more outputs. These outputs may include calculated vibration fault level states, vibration severity unit values, vibration characteristics, probability of failure values, probability of downtime values, probability of shutdown values, cost of downtime values, cost of shutdown values, time to failure values, temperature values, pressure values, humidity values, precipitation values, visibility values, air quality values, strain values, stress values, displacement values, velocity values, acceleration values, location values, performance values, financial values, manufacturing KPI values, electrodynamic values, thermodynamic values, fluid flow rate values, and the like. The client application 15570 may then initiate a digital twin visualization event using the results obtained by the digital twin dynamic model system 15508. In embodiments, the visualization may be a heat map visualization.

[0850] In embodiments, the digital twin dynamic model system 15508 may receive requests to update one or more properties of digital twins of industrial entities and/or environments such that the digital twins represent the industrial entities and/or environments in real-time. At 159100, the digital twin dynamic model system 15508 receives a request to update one or more properties of one or more of the digital twins of industrial entities and/or environments. For example, the digital twin dynamic model system 15508 may receive the request from a client application 15570 or from another process executed by the digital twin system 15500 (e.g., a predictive maintenance process). The request may indicate the one or more properties and the digital twin or digital twins implicated by the request. In step 159102, the digital twin dynamic model system 15508 determines the one or more digital twins required to fulfill the request and retrieves the one or more required digital twins, including any embedded digital twins, from digital twin datastore 15516. At 159104, digital twin dynamic model system 15508 determines one or more dynamic models required to fulfill the request and retrieves the one or more required dynamic models from digital twin dynamic model store 155102. At 159106, the digital twin dynamic model system 15508 selects one or more sensors from sensor system 15530, data collected from Internet of Things connected devices 15524, and/or other data sources from digital twin I/O system 15504 based on available data sources and the one or more required inputs of the dynamic model(s). In embodiments, the data sources may be defined in the inputs required by the one or more dynamic models or may be selected using a lookup table. At 159108, the digital twin dynamic model system 15508 retrieves the selected data from digital twin I/O system 15504. At 159110, digital twin dynamic model system 15508 runs the dynamic model(s) using the retrieved input data (e.g., vibration sensor data, Industrial Internet of Things device data, and the like) as inputs and determines one or more output values based on the dynamic model(s) and the input data. At 159112, the digital twin dynamic model system 15508 updates the values of one or more properties of the one or more digital twins based on the one or more outputs of the dynamic model(s).

[0851] In example embodiments, client application 15570 may be configured to provide a digital representation and/or visualization of the digital twin of an industrial entity. In embodiments, the client application 15570 may include one or more software modules that are executed by one or more server devices. These software modules may be configured to quantify properties of the digital twin, model properties of a digital twin, and/or to visualize digital twin behaviors. In embodiments, these software modules may enable a user to select a particular digital twin behavior visualization for viewing. In embodiments, these software modules may enable a user to select to view a digital twin behavior visualization playback. In some embodiments, the client application 15570 may provide a selected behavior visualization to digital twin dynamic model system 15508.

[0852] In embodiments, the digital twin dynamic model system 15508 may receive requests from client application 15570 to update properties of a digital twin in order to enable a digital representation of an industrial entity and/or environment wherein the real-time digital representation is a visualization of the digital twin. In embodiments, a digital twin may be rendered by a computing device, such that a human user can view the digital representations of real-world industrial assets, devices, workers, processes and/or environments. For example, the digital twin may be rendered and outcome to a display device. In embodiments, dynamic model outputs and/or related data may be overlaid on the rendering of the digital twin. In embodiments, dynamic model outputs and/or related information may appear with the rendering of the digital twin in a display interface. In embodiments, the related information may include real-time video footage associated with the real-world entity represented by the digital twin. In embodiments, the related information may include a sum of each of the vibration fault level states in the machine. In embodiments, the related information may be graphical information. In embodiments, the graphical information may depict motion and/or motion as a function of frequency for individual machine components. In embodiments, graphical information may depict motion and/or motion as a function of frequency for individual machine components, wherein a user is enabled to select a view of the graphical information in the x, y, and z dimensions. In embodiments, graphical information may depict motion and/or motion as a function of frequency for individual machine components, wherein the graphical information includes harmonic peaks and peaks. In embodiments, the related information may be cost data, including the cost of downtime per day data, cost of repair data, cost of new part data, cost of new machine data, and the like. In embodiments, related information may be a probability of downtime data, probability of failure data, and the like. In embodiments, related information may be time to failure data.

[0853] In embodiments, the related information may be recommendations and/or insights. For example, recommendations or insights received from the cognitive intelligence system related to a machine may appear with the rendering of the digital twin of a machine in a display interface.

[0854] In embodiments, clicking, touching, or otherwise interacting with the digital twin rendered in the display interface can allow a user to “drill down” and see underlying subsystems or processes and/or embedded digital twins. For example, in response to a user clicking on a machine bearing rendered in the digital twin of a machine, the display interface can allow a user to drill down and see information related to the bearing, view a 3D visualization of the bearing's vibration, and/or view a digital twin of the bearing.

[0855] In embodiments, clicking, touching, or otherwise interacting with information related to the digital twin rendered in the display interface can allow a user to “drill down” and see underlying information.

[0856] FIG. 160 illustrates example embodiments of a display interface that renders the digital twin of a dryer centrifuge and other information related to the dryer centrifuge.

[0857] In some embodiments, the digital twin may be rendered and output in a virtual reality display. For example, a user may view a 3D rendering of an environment (e.g., using a monitor or a virtual reality headset). The user may also inspect and/or interact with digital twins of industrial entities. In embodiments, a user may view processes being performed with respect to one or more digital twins (e.g., collecting measurements, movements, interactions, inventorying, loading, packing, shipping, and the like). In embodiments, a user may provide input that controls one or more properties of a digital twin via a graphical user interface.

[0858] In some embodiments, the digital twin dynamic model system 15508 may receive requests from client application 15570 to update properties of a digital twin in order to enable a digital representation of industrial entities and/or environments wherein the digital representation is a heat map visualization of the digital twin. In embodiments, a platform is provided having heat maps displaying collected data from the sensor system 15530, Internet of Things connected devices 15524, and data outputs from dynamic models 155100 for providing input to a display interface. In embodiments, the heat map interface is provided as an output for digital twin data, such as for handling and providing information for visualization of various sensor data, dynamic model output data, and other data (such as map data, analog sensor data, and other data), such as to another system, such as a mobile device, tablet, dashboard, computer, AR/VR device, or the like. A digital twin representation may be provided in a form factor (e.g., user device, VR-enabled device, AR-enabled device, or the like) suitable for delivering visual input to a user, such as the presentation of a map that includes indicators of levels of analog sensor data, digital sensor data, and output values from the dynamic models (such as data indicating vibration fault level states, vibration severity unit values, probability of downtime values, cost of downtime values, probability of shutdown values, time to failure values, probability of failure values, manufacturing KPIs, temperatures, levels of rotation, vibration characteristics, fluid flow, heating or cooling, pressure, substance concentrations, and many other output values). In embodiments, signals from various sensors or input sources (or selective combinations, permutations, mixes, and the like) as well as data determined by the digital twin dynamic model system 15508 may provide input data to a heat map. Coordinates may include real world location coordinates (such as geo-location or location on a map of an environment), as well as other coordinates, such as time-based coordinates, frequency-based coordinates, or other coordinates that allow for representation of analog sensor signals, digital signals, dynamic model outputs, input source information, and various combinations, in a map-based visualization, such that colors may represent varying levels of input along the relevant dimensions. For example, among many other possibilities, if an industrial machine component is at a critical vibration fault level state, the heat map interface may alert a user by showing the machine component in orange. In the example of a heat map, clicking, touching, or otherwise interacting with the heat map can allow a user to drill down and see underlying sensor, dynamic model outputs, or other input data that is used as an input to the heat map display. In other examples, such as ones where a digital twin is displayed in a VR or AR environment, if an industrial machine component is vibrating outside of normal operation (e.g., at a suboptimal, critical, or alarm vibration fault level), a haptic interface may induce vibration when a user touches a representation of the machine component, or if a machine component is operating in an unsafe manner, a directional sound signal may direct a user's attention toward the machine in digital twin, such as by playing in a particular speaker of a headset or other sound system.

[0859] In embodiments, the digital twin dynamic model system 15508 may take a set of ambient environmental data and/or other data and automatically update a set of properties of a digital twin of an industrial entity or facility based on the impact of the environmental data and/or other data in the set of dynamic models 155100 that are used to enable the digital twin. Ambient environmental data may include temperature data, pressure data, humidity data, wind data, rainfall data, tide data, storm surge data, cloud cover data, snowfall data, visibility data, water level data, and the like. Additionally or alternatively, the digital twin dynamic model system 15508 may use a set of environmental data measurements collected by a set of Internet of Things connected devices 15524 disposed in an industrial setting as inputs for the set of dynamic models 155100 that are used to enable the digital twin. For example, digital twin dynamic model system 15508 may feed the dynamic models 155100 data collected, handled or exchanged by Internet of Things connected devices 15524, such as cameras, monitors, embedded sensors, mobile devices, diagnostic devices and systems, instrumentation systems, telematics systems, and the like, such as for monitoring various parameters and features of machines, devices, components, parts, operations, functions, conditions, states, events, workflows and other elements (collectively encompassed by the term “states”) of industrial environments. Other examples of Internet of Things connected devices include smart fire alarms, smart security systems, smart air quality monitors, smart/learning thermostats, and smart lighting systems.

[0860] FIG. 161 illustrates example embodiments of a method for updating a set of vibration fault level states for a set of bearings in a digital twin of a machine. In this example, a client application 15570, which interfaces with digital twin dynamic model system 15508, may be configured to provide a visualization of the fault level states of the bearings in the digital twin of the machine.

[0861] In this example, the digital twin dynamic model system 15508 may receive requests from client application 15570 to update the vibration fault level states of the machine digital twin. At 161200, digital twin dynamic model system 15508 receives a request from client application 15570 to update one or more vibration fault level states of the machine digital twin. Next, in step 161202, digital twin dynamic model system 15508 determines the one or more digital twins required to fulfill the request and retrieves the one or more required digital twins from digital twin datastore 15516. In this example, the digital twin dynamic model system 15508 may retrieve the digital twin of the machine and any embedded digital twins, such as any embedded motor digital twins and bearing digital twins, and any digital twins that embed the machine digital twin, such as the manufacturing facility digital twin. At 161204, digital twin dynamic model system 15508 determines one or more dynamic models required to fulfill the request and retrieves the one or more required dynamic models from the digital twin dynamic model datastore 155102. At 161206, the digital twin dynamic model system 15508 selects dynamic model input data sources (e.g., one or more sensors from sensor system 15530, data from Internet of Things connected devices 15524, and any other suitable data) via digital twin I/O system 15504 based on available data sources (e.g., available sensors from a set of sensors in sensor system 15530) and the and the one or more required inputs of the dynamic model(s). In the present example, the retrieved dynamic model(s) 155100 may take one or more vibration sensor measurements from vibration sensors 15536 as inputs to the dynamic models. In embodiments, vibration sensors 15536 may be optical vibration sensors, single axis vibration sensors, tri-axial vibration sensors, and the like. At 161208, digital twin dynamic model system 15508 retrieves one or more measurements from each of the selected data sources from the digital twin I/O system 15504. Next, At 161210, digital twin dynamic model system 15508 runs the dynamic model(s), using the retrieved vibration sensor measurements as inputs, and calculates one or more outputs that represent bearing vibration fault level states. Next, At 161212, the digital twin dynamic model system 15508 updates one or more bearing fault level states of the manufacturing facility digital twin, machine digital twin, motor digital twin, and/or bearing digital twins based on the one or more outputs of the dynamic model(s). The client application 15570 may obtain vibration fault level states of the bearings and may display the obtained vibration fault level state associated with each bearing and/or display colors associated with fault level severity (e.g., red for alarm, orange for critical, yellow for suboptimal, green for normal operation) in the rendering of one or more of the digital twins on a display interface.

[0862] In another example, a client application 15570 may be an augmented reality application. In some embodiments of this example, the client application 15570 may obtain vibration fault level states of bearings in a field of view of an AR-enabled device (e.g., smart glasses) hosting the client application from the digital twin of the industrial environment (e.g., via an API of the digital twin system 15500) and may display the obtained vibration fault level states on the display of the AR-enabled device, such that the vibration fault level state displayed corresponds to the location in the field of view of the AR-enabled device. In this way, a vibration fault level state may be displayed even if there are no vibration sensors located within the field of view of the AR-enabled device.

[0863] FIG. 155 illustrates example embodiments of a method for updating a set of vibration severity unit values of bearings in a digital twin of a machine. Vibration severity units may be measured as displacement, velocity, and acceleration.

[0864] In this example, client application 15570 that interfaces with the digital twin dynamic model system 15508 may be configured to provide a visualization of the three-dimensional vibration characteristics of bearings in a digital twin of a machine.

[0865] In this example, the digital twin dynamic model system 15508 may receive requests from client application 15570 to update the vibration severity unit values for bearings in the digital twin of a machine. At 155300, digital twin dynamic model system 15508 receives a request from client application 15570 to update one or more vibration severity unit value(s) of the manufacturing facility digital twin. Next, in step 155302, digital twin dynamic model system 15508 determines the one or more digital twins required to fulfill the request and retrieves the one or more required digital twins from digital twin datastore 15516. In this example, the digital twin dynamic model system 15508 may retrieve the digital twin of the machine and any embedded digital twins (e.g., digital twins of bearings and other components). At 155304, digital twin dynamic model system 15508 determines one or more dynamic models required to fulfill the request and retrieves the one or more required dynamic models from dynamic model datastore 155102. At 155306, the digital twin dynamic model system 15508 selects dynamic model input data sources (e.g., one or more sensors from sensor system 15530, data from Internet of Things connected devices 15524, and any other suitable data) via digital twin I/O system 15504 based on available data sources (e.g., available sensors from a set of sensors in sensor system 15530) and the one or more required inputs of the dynamic model(s). In the present example, the retrieved dynamic models may be configured to take one or more vibration sensor measurements as inputs and provide severity unit values for bearings in the machine. At 155308, digital twin dynamic model system 15508 retrieves one or more measurements from each of the selected sensors. In the present example, the digital twin dynamic model system 15508 retrieves measurements from vibration sensors 15536 via digital twin I/O system 15504. At 155310, digital twin dynamic model system 15508 runs the dynamic model(s) using the retrieved vibration measurements as inputs and calculates one or more output values that represent vibration severity unit values for bearings in the machine. Next, At 155312, the digital twin dynamic model system 15508 updates one or more vibration severity unit values of the bearings in the machine digital twin and all other embedded digital twins or digital twins that embed the machine digital twin based on the one or more values output by the dynamic model(s).

[0866] FIG. 163 illustrates example embodiments of a method for updating a set of probability of failure values for machine components in the digital twin of a machine.

[0867] In this example, the digital twin dynamic model system 15508 may receive requests from client application 15570 to update the probability of failure values for components in a machine digital twin. At 163400, digital twin dynamic model system 15508 receives a request from client application 15570 to update one or more probability of failure value(s) of the machine digital twin, any embedded component digital twins, and any digital twins that embed the machine digital twin such as a manufacturing facility digital twin. Next, in step 163402, digital twin dynamic model system 15508 determines the one or more digital twins required to fulfill the request and retrieves the one or more required digital twins. In this example, the digital twin dynamic model system 15508 may retrieve the digital twin of the manufacturing facility, the digital twin of the machine, and the digital twins of machine components from digital twin datastore 15516. At 163404, digital twin dynamic model system 15508 determines one or more dynamic models required to fulfill the request and retrieves the one or more required dynamic models from dynamic model datastore 155102. At 163406, the digital twin dynamic model system 15508 selects, via digital twin I/O system 15504, dynamic model input data sources (e.g., one or more sensors from sensor system 15530, data from Internet of Things connected devices 15524, and any other suitable data) based on available data sources (e.g., available sensors from a set of sensors in sensor system 15530) and the and the one or more required inputs of the dynamic model(s). In the present example, the retrieved dynamic models may take one or more vibration measurements from vibration sensors 15536 and historical failure data as dynamic model inputs and output probability of failure values for the machine components in the digital twin of the machine. At 163408, digital twin dynamic model system 15508 retrieves data from each of the selected sensors and/or Internet of Things connected devices via digital twin I/O system 15504. At 163410, digital twin dynamic model system 15508 runs the dynamic model(s) using the retrieved vibration data and historical failure data as inputs and calculates one or more outputs that represent probability of failure values for bearings in the machine digital twin. Next, At 163412, the digital twin dynamic model system 15508 updates one or more probability of failure values of the bearings in the machine digital twin, all embedded digital twins, and all digital twins that embed the machine digital twin based on the output of the dynamic model(s).

[0868] FIG. 164 illustrates example embodiments of a method for updating a set of probability of downtime for machines in the digital twin of a manufacturing facility.

[0869] In this example, client application 15570, which interfaces with the digital twin dynamic model system 15508, may be configured to provide a visualization of the probability of downtime values of a manufacturing facility in the digital twin of the manufacturing facility.

[0870] In this example, the digital twin dynamic model system 15508 may receive requests from client application 15570 to assign probability of downtime values to machines in a manufacturing facility digital twin. At 164500, digital twin dynamic model system 15508 receives a request from client application 15570 to update one or more probability of downtime values of machines in the manufacturing facility digital twin and any embedded digital twins such as the individual machine digital twins. Next, in step 164502, digital twin dynamic model system 15508 determines the one or more digital twins required to fulfill the request and retrieves the one or more required digital twins from digital twin datastore 15516. In this example, the digital twin dynamic model system 15508 may retrieve the digital twin of the manufacturing facility and any embedded digital twins from digital twin datastore 15516. At 164504, digital twin dynamic model system 15508 determines one or more dynamic models required to fulfill the request and retrieves the one or more required dynamic models from dynamic model datastore 155102. At 164506, the digital twin dynamic model system 15508 selects dynamic model input data sources (e.g., one or more sensors from sensor system 15530, data from Internet of Things connected devices 15524, and any other suitable data) based on available data sources (e.g., available sensors from a set of sensors in sensor system 15530) and the and the one or more required inputs of the dynamic model(s) via digital twin I/O system 15504. In the present example, the dynamic model(s) may be configured to take vibration measurements from vibration sensors and historical downtime data as inputs and output probability of downtime values for different machines throughout the manufacturing facility. At 164508, digital twin dynamic model system 15508 retrieves one or more measurements from each of the selected sensors via digital twin I/O system 15504. At 164510, digital twin dynamic model system 15508 runs the dynamic model(s) using the retrieved vibration measurements and historical downtime data as inputs and calculates one or more outputs that represent probability of downtime values for machines in the manufacturing facility. Next, At 164512, the digital twin dynamic model system 15508 updates one or more probability of downtime values for machines in the manufacturing facility digital twins and all embedded digital twins based on the one or more outputs of the dynamic models.

[0871] FIG. 165 illustrates example embodiments of a method for updating one or more probability of shutdown values in the digital twin of an enterprise having a set of manufacturing facilities.

[0872] In the present example, the digital twin dynamic model system 15508 may receive requests from client application 15570 to update the probability of shutdown values for the set of manufacturing facilities within an enterprise digital twin. At 165600, digital twin dynamic model system 15508 receives a request from client application 15570 to update one or more probability of shutdown values of the enterprise digital twin and any embedded digital twins. Next, in step 165602, digital twin dynamic model system 15508 determines the one or more digital twins required to fulfill the request and retrieves the one or more required digital twins from digital twin datastore 15516. In this example, the digital twin dynamic model system 15508 may retrieve the digital twin of the enterprise and any embedded digital twins. At 165604, digital twin dynamic model system 15508 determines one or more dynamic models required to fulfill the request and retrieves the one or more required dynamic models from dynamic model datastore 155102. At 165606, the digital twin dynamic model system 15508 selects dynamic model input data sources (e.g., one or more sensors from sensor system 15530, data from Internet of Things connected devices 15524, and any other suitable data) based on available data sources (e.g., available sensors from a set of sensors in sensor system 15530) and the and the one or more required inputs of the dynamic model(s) via digital twin I/O system 15504. In the present example, the retrieved dynamic models may be configured to take one or more vibration measurements from vibration sensors 15536 and/or other suitable data as inputs and output probability of shutdown values for each manufacturing entity in the enterprise digital twin. At 165608, digital twin dynamic model system 15508 retrieves one or more vibration measurements from each of the selected vibration sensors 15536 from digital twin I/O system 15504. At 165610, digital twin dynamic model system 15508 runs the dynamic model(s) using the retrieved vibration measurements and historical shut down data as inputs and calculates one or more outputs that represent probability of shutdown values for manufacturing facilities within the enterprise digital twin. Next, At 165612, the digital twin dynamic model system 15508 updates one or more probability of shutdown values of the enterprise digital twin and all embedded digital twins based on the one or more outputs of the dynamic model(s).

[0873] FIG. 159 illustrates example embodiments of a method for updating a set of cost of downtime values in machines in the digital twin of a manufacturing facility. In embodiments, the manufacturing

[0874] In the present example, the digital twin dynamic model system 15508 may receive requests from a client application 15570 to populate real-time cost of downtime values associated with machines in a manufacturing facility digital twin. At 159700, digital twin dynamic model system 15508 receives a request from the client application 15570 to update one or more cost of downtime values of the manufacturing facility digital twin and any embedded digital twins (e.g., machines, machine parts, and the like) from the client application 15570. Next, in step 159702, the digital twin dynamic model system 15508 determines the one or more digital twins required to fulfill the request and retrieves the one or more required digital twins. In this example, the digital twin dynamic model system 15508 may retrieve the digital twins of the manufacturing facility, the machines, the machine parts, and any other embedded digital twins from digital twin datastore 15516. At 159704, digital twin dynamic model system 15508 determines one or more dynamic models required to fulfill the request and retrieves the one or more required dynamic models from dynamic model datastore 155102. At 159706, the digital twin dynamic model system 15508 selects dynamic model input data sources (e.g., one or more sensors from sensor system 15530, data from Internet of Things connected devices 15524, and any other suitable data) based on available data sources (e.g., available sensors from a set of sensors in sensor system 15530) and the and the one or more required inputs of the dynamic model(s) via digital twin I/O system 15504. In the present example, the retrieved dynamic model(s) may be configured to take historical downtime data and operational data as inputs and output data representing cost of downtime per day for machines in the manufacturing facility. At 159708, digital twin dynamic model system 15508 retrieves historical downtime data and operational data from digital twin I/O system 15504. At 159710, digital twin dynamic model system 15508 runs the dynamic model(s) using the retrieved data as input and calculates one or more outputs that represent cost of downtime per day for machines in the manufacturing facility. Next, At 159712, the digital twin dynamic model system 15508 updates one or more cost of downtime values of the manufacturing facility digital twins and machine digital twins based on the one or more outputs of the dynamic model(s).

[0875] FIG. 160 illustrates example embodiments of a method for updating a set of manufacturing KPI values in the digital twin of a manufacturing facility. In embodiments, the manufacturing KPI is selected from the set of uptime, capacity utilization, on standard operating efficiency, overall operating efficiency, overall equipment effectiveness, machine downtime, unscheduled downtime, machine set up time, inventory turns, inventory accuracy, quality (e.g., percent defective), first pass yield, rework, scrap, failed audits, on-time delivery, customer returns, training hours, employee turnover, reportable health & safety incidents, revenue per employee, and profit per employee, schedule attainment, total cycle time, throughput, changeover time, yield, planned maintenance percentage, availability, and customer return rate.

[0876] In the present example, the digital twin dynamic model system 15508 may receive requests from a client application 15570 to populate real-time manufacturing KPI values in a manufacturing facility digital twin. At 159700, digital twin dynamic model system 15508 receives a request from the client application 15570 to update one or more KPI values of the manufacturing facility digital twin and any embedded digital twins (e.g., machines, machine parts, and the like) from the client application 15570. Next, in step 159702, the digital twin dynamic model system 15508 determines the one or more digital twins required to fulfill the request and retrieves the one or more required digital twins. In this example, the digital twin dynamic model system 15508 may retrieve the digital twins of the manufacturing facility, the machines, the machine parts, and any other embedded digital twins from digital twin datastore 15516. At 159704, digital twin dynamic model system 15508 determines one or more dynamic models required to fulfill the request and retrieves the one or more required dynamic models from dynamic model datastore 155102. At 159706, the digital twin dynamic model system 15508 selects dynamic model input data sources (e.g., one or more sensors from sensor system 15530, data from Internet of Things connected devices 15524, and any other suitable data) based on available data sources (e.g., available sensors from a set of sensors in sensor system 15530) and the and the one or more required inputs of the dynamic model(s) via digital twin I/O system 15504. In the present example, the retrieved dynamic model(s) may be configured to take one or more vibration measurements obtained from vibration sensors 15536 and other operational data as inputs and output one or more manufacturing KPIs for the facility. At 167708, digital twin dynamic model system 15508 retrieves one or more vibration measurements from each of the selected vibration sensors 15536 and operational data from digital twin I/O system 15504. At 159710, digital twin dynamic model system 15508 runs the dynamic model(s) using the retrieved vibration measurements and operational data as inputs and calculates one or more outputs that represent manufacturing KPIs for the manufacturing facility. Next, At 159712, the digital twin dynamic model system 15508 updates one or more KPI values of the manufacturing facility digital twins, machine digital twins, machine part digital twins, and all other embedded digital twins based on the one or more outputs of the dynamic model(s).

[0877] With the proliferation of vibration sensors and other Industrial Internet of Things (IIoT) sensors, there are vast amounts of data available relating to industrial environments. This data is useful in predicting the need for maintenance and for classifying potential issues in the industrial environments. There are, however, many unexplored uses for vibration sensor data and other IIoT sensor data that can improve the operation and uptime of the industrial environments and provide industrial entities with agility in responding to problems before the problems become catastrophic.

[0878] Industrial enterprises that rely on industrial experts struggle to capture the knowledge of these experts when they move on to another enterprise or leave the workforce. There exists a need in the art to capture industrial expertise and to use the captured industrial expertise in guiding newer workers or mobile electronic industrial entities to perform industrial-related tasks.

[0879] A knowledge distribution process and related technologies now will be described more fully hereinafter with reference to the accompanying drawings, in which illustrative embodiments are shown. The knowledge distribution process and technologies may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure and inventions to those skilled in the art. The knowledge distribution process may use a knowledge distribution platform or system that utilizes blockchain technology for storing digital knowledge and providing convenient and secure control of the digital knowledge.

[0880] Where digital knowledge may be cryptographically secured, there can be a number of practical obstacles to the sharing of knowledge, such as the absence of trust between parties that could potentially benefit from sharing of the knowledge. For example, a manufacturer might benefit from having a supplier access trade secrets of the manufacturer in order to make components or materials on behalf of the manufacturer, but sharing the trade secrets creates a risk that the supplier may use the trade secrets on its own behalf or on behalf of competitors. Similarly, an engineer may be willing to share valuable code or instruction sets with others but be fearful of the misuse of that code. A need exists for a digital knowledge distribution system that facilitates orchestration of the sharing of knowledge by providing a high degree of control over the extent to which counterparties can access shared knowledge.

[0881] Even where knowledge is secure and well-controlled, some types of knowledge are so sensitive that an owner may be unwilling to share the entire set of knowledge with a single counterparty. For example, a proprietary process may be divided among different suppliers in order to keep any one supplier from deducing or reverse engineering the entire process. However, dividing knowledge presents operational challenges, as the owner may orchestrate a series of secure interactions with all involved parties in order to assure that the full set of knowledge may be maintained and accurately implemented. A need exists for a digital knowledge distribution system that facilitates handling and control of subsets of knowledge, including automated handling of aggregation of knowledge, or related outputs, that result from division of knowledge subsets.

[0882] Referring to FIG. 168, a knowledge distribution system 16802 is configured to facilitate management of digital knowledge 16804 by one or more users via a distributed ledger 16808. The digital knowledge 16804 may include any suitable knowledge that is conveyable from one party to another, such as in a digital format. Users and/or parties may include one or more knowledge providers 16806 and/or one or more knowledge recipients 16818. The knowledge providers 16806 are parties that provide knowledge to be managed via the knowledge distribution system 16802, such as by uploading one or more instances of the digital knowledge 16804 to the knowledge distribution system 16802 and/or the distributed ledger 16808. Uploading one or more instances of the digital knowledge 16804 and/or hosting one or more instances of the digital knowledge 16804 on the distributed ledger 16808 may include uploading an instance of the digital knowledge 16804 itself to the distributed ledger 16808 (e.g., which may be tokenized, contained in the smart contract, and/or stored in an associated database) and/or providing a reference to an accessible location of the instance of the digital knowledge 16804 and any other information required to retrieve the digital knowledge from the accessible location. When reference is made to receiving digital knowledge 16804, the digital knowledge 16804 itself or a reference thereto may be received. The term knowledge recipients 16818 may refer to parties that receive knowledge from the knowledge providers 16806 via the knowledge distribution system 16802 (including via reference or link to digital knowledge 16804) and/or via a distributed ledger 16808 that stores digital knowledge 16804. In some embodiments, the knowledge distribution system 16802 may facilitate management of digital knowledge 16804 by facilitating establishment of a chain of work, possession, and/or title of one or more instances of digital knowledge, such as by serving as a log of ownership of an instance of knowledge. The log of ownership may include a chain of log entries including an indication of a set of owners and/or contributors. For example, in some embodiments the knowledge distribution system 16802 may facilitate establishment of a chain of work, a chain of possession, and/or a chain of title corresponding to a 3D-printing instruction set for 3D printing an object (e.g., a custom-designed part, a replacement part, a toy, a medical device, a tool, or the like). In some embodiments, the knowledge distribution system 16802 may facilitate establishment of a seller database where the schematic may be stored prior to one or more of sale, transfer of the schematic to a buyer database, entry of a serial number of the custom part into a clause of a smart contract 16840, and printing of the custom part by a 3D printer owned by a buyer.

[0883] In some embodiments the knowledge distribution system 16802 may facilitate management of digital knowledge 16804 by managing aggregation of instances of digital knowledge 16804, such as where component instances of digital knowledge 16804 are aggregated to form larger instances of digital knowledge (e.g., where chapter instances are concatenated to form book instances, where component instances are linked schematically to form a system, where element instances are linked diagrammatically to generate a workflow, where partial instances are coupled to form a whole instance (e.g., the necessary parts of a formula), where related instances are topically linked to form a cluster, and via many other forms of aggregation).

[0884] In some embodiments, the knowledge distribution system 16802 may facilitate management of digital knowledge 16804 by facilitating verification of one or more sources of the digital knowledge and/or providing a chain of origination for a digital or physical item by virtue of related knowledge. For example, in embodiments, the knowledge distribution system 16802 may log a digital signature of a steel manufacturer in a distributed ledger that certifies a quality grade of steel provided by the steel manufacturer to a factory owner and may link the digital signature to serial numbers of each part produced by a factory owned by the factory owner that used the steel provided by the steel manufacturer.

[0885] In some embodiments, the knowledge distribution system 16802 may facilitate control of digital knowledge 16804 by facilitating collaboration of a plurality of knowledge providers 16806 such that information related to one or more instances of digital knowledge from one or more of disparate parties, disparate knowledge providers 16806, and disparate distributed ledgers 16808 may be tracked and/or combined into one or more consolidated distributed ledgers.

[0886] In some embodiments, instances of the digital knowledge 16804 may include, for example, instruction sets such as process steps and other methodologies in food production, transportation, executable algorithmic logic such as computer programs, a firmware program, an instructions set for a field-programmable gate array (FPGA), serverless code logic, a crystal fabrication system/process, a polymer production process, a chemical synthesis process, a biological production process, part schematics, and/or production records (e.g., production records of aircraft parts, spaceship parts, nuclear engine parts, etc.), a process and/or instruction set for semiconductor fabrication such as silicon etching and/or doping, an instruction set for a 3D printer such as for printing a medical device, an automobile part, an airplane part, a piece of furniture or component thereof, a replacement part for an industrial robot or machine, algorithmic logic such as an instruction set for use in an application, AI logic and/or definitions, machine learning logic and/or definitions, cryptography logic, serverless code logic, trade secrets and/or other intellectual property such as know-how, patented material, and works of authorship, food preparation instructions (e.g., for industrial food preparation), coating process instructions, biological production process instructions, chemical synthesis instructions, polymer production instructions, smart contract instructions, data sets and/or sensor information defining and/or populating a set of digital twins (such as digital twins that embody digital knowledge about one or more physical entities, including knowledge about configurations, operating modes, instruction sets, capabilities, defects, performance parameters, and many others), and/or any other suitable type of digitally transmittable knowledge. In these embodiments, the instruction sets may be consumed/leveraged by a computing device, a special purpose device, or a combination of devices (e.g., factory equipment). In some embodiments, instances of the digital knowledge 16804 may include personal and/or professional knowledge relating to one or more organizations and/or individuals, such as a professional resume and/or professional history tracking information. In some embodiments, the personal and/or professional knowledge may include one or more records of professional credentials such as academic degrees and/or certificates. In some embodiments, the personal and/or professional knowledge may include one or more verifications of professional positions held by the one or more individuals. In some embodiments, the personal and/or professional knowledge may include professional feedback for and/or verification of work performed for and/or by one or more third parties. The personal and/or professional knowledge may include personal and/or business financial history, personal life achievements as verified by one or more third parties. The knowledge provider 16806 may be any party that at least partially provides one or more instances of the digital knowledge 16804, such as a manufacturer, a seller, a customer, a wholesaler, a user, a manager, a notary, a factory owner, a maintenance worker, or any other suitable provider of the digital knowledge 16804.

[0887] In embodiments, the distributed ledger 16808 may be any suitable type of electronic ledger 16808, such as a blockchain (e.g., Hyperledger, Solidity, Ethereum, and the like). The distributed ledger 16808 may be centralized, decentralized, or a hybrid configuration where the knowledge distribution system 16802 stores a copy of a distributed ledger 16808 in addition to any number of participant nodes 16916 that store copies of the distributed ledger 16808. When referring to the distributed ledger 16808, the term “distributed ledger” (and/or any logs, records, smart contracts, blocks, tokens, and/or data stored thereon) may refer to a specific instance of a copy of the distributed ledger 16808 (and/or any logs, records, smart contracts, blocks, tokens, and/or data stored thereon) and/or the collection of local copies of the distributed ledger 16808-L stored across any number of nodes (which may include the knowledge distribution system 16802), unless specifically indicated otherwise.

[0888] In some embodiments, a private network of authorized participants, such as one or more of the knowledge providers and/or nodes, may establish cryptography-based consensus on one or more items, such that the knowledge distribution system 16802 may provide security, transparency, auditability, immutability, and non-repudiation to transactions for digital knowledge. In some embodiments, a trusted authority (e.g., the knowledge distribution system 16802 or another suitable authority) may issue private key and public key pairs to each registered user of the knowledge distribution system 16802. The private key and public key pairs may be used to encrypt and decrypt data (e.g., messages, files, documents, etc.) and/or to perform operations with respect to the distributed ledger 16808. In some embodiments, the knowledge distribution system 16802 (or another trusted authority) may provide two or more levels of access to users. In some embodiments, the knowledge distribution system 16802 may define one or more classes of users, where each of the classes of users is granted a respective level of access. In some of these embodiments, the knowledge distribution system 16802 may issue one or more access keys to one or more classes of users, where the one or more access keys each correspond to a respective level of access, thereby providing users of different levels of access via their respective issued access keys. In embodiments, possession of certain access keys may be used to determine a level of access to the distributed ledger 16808. For example, in some embodiments, a first class of users may be granted full viewing access of a block, while a second class of users may be granted both viewing access of blocks and an ability to verify and/or certify one or more instances of digital knowledge contained within a block, and while a third class of users may be granted viewing access of blocks, an ability to verify and/or certify one or more instances of digital knowledge contained within a block, and an ability to modify the one or more instances of digital knowledge contained within the block. In some embodiments, a class of users may be verified as being a legitimate user of the distributed ledger 16808 in one or more roles and allowed related permissions with respect to the distributed ledger and content stored therein. A user may be verified, for example, as a bona fide knowledge provider 16806 that uses a knowledge provider device 16890, knowledge recipient 16818 that uses a knowledge recipient device 16894, and/or crowdsourcer 16836 that uses a crowdsourcer device 16892. There may be any number of each device 16890, 16892, 16894. As shown in FIG. 168, there is one knowledge provider device 16890, two crowdsourcer devices 16892, and one knowledge recipient device 16894. In other examples, as it is understood, there may be one, two, three, or more of any device type 16890, 16892, 16894, in any combination. In other examples, there may be one of each device type (e.g., one knowledge provider device 16890, one crowdsourcer device 16892, and one knowledge recipient device 16894). In other embodiments, these devices 16890, 16892, 16894 may be implemented as one or more computing devices and/or server devices (e.g., as part of a server farm).

[0889] In some embodiments, the knowledge distribution system 16802 may include a ledger management system 16910. In some embodiments, the ledger management system 16910 manages one or more distributed ledgers (also referred to as “ledgers”). In some embodiments, the ledger management system 16910 may instantiate a distributed ledger for a particular knowledge provider 16806 or group of knowledge providers 16806, such as by instantiating a distributed ledger 16808 that stores instances of digital knowledge 16804 provided by the knowledge provider 16806 or group of knowledge providers 16806. The knowledge distribution system 16802 may allow only the particular knowledge provider 16806 or particular group of knowledge providers 16806 to host instances of digital knowledge 16804 (e.g., by using knowledge provider device 16890) on the related distributed ledger 16808 and/or for each instance of digital knowledge 16804, such that each distributed ledger 16808 is specific to a respective knowledge provider 16806 and/or an instance of digital knowledge 16804. In some embodiments, the ledger management system 16910 may instantiate a plurality of distributed ledgers 16808, one or more of the distributed ledgers 16808 being configured to facilitate hosting, sharing, buying, selling, licensing, or otherwise managing a category of digital knowledge 16804. Categories of digital knowledge may be related to, for example, one or more industries such as automotive and/or financial, or one or more types of digital knowledge, such as 3D printing schematics. In some embodiments, the ledger management system 16910 may maintain a distributed ledger that facilitates management of some or all of the instances of digital knowledge 16808 and/or the knowledge providers 16806 for which related data is stored by the knowledge distribution system 16802.

[0890] In some embodiments, a distributed ledger 16808 is any suitable type of blockchain. Any other suitable types of distributed ledgers may be used, however, without departing from the scope of the disclosure. The distributed ledger may be public or private. In embodiments, where the distributed ledger is private, reading from the ledger and/or validation privileges by a user such as the knowledge provider 16806 (e.g., using knowledge provider device 16890) may be restricted to invitees, users with one or more accounts/passwords, or by any other suitable method of restricting access to the distributed ledger 16808. In some embodiments, the distributed ledger 16808 may be at least partially centralized, such that a plurality of nodes of the distributed ledger is stored by the knowledge distribution system 16802. In some embodiments, the distributed ledgers are federated distributed ledgers, as the distributed ledgers may be stored on pre-selected or pre-approved nodes that are associated with the parties to a management of digital knowledge 16804 via the knowledge distribution system 16802. The techniques described herein may be applied, however, to publicly distributed ledgers as well. In a publicly distributed ledger, any suitably configured computing device (personal computers, user devices, servers) or set of devices (e.g., a server farm) may act as a node 16916 and may store a local copy of a distributed ledger 16808-L, whether the owner of the node otherwise participates in the transactions facilitated by the knowledge distribution system 16802. In these embodiments, such nodes 16916 may add validate/deny new blocks, save new blocks to the distributed ledger 16808 (if validated) to maintain a full copy (or nearly full copy) of the transaction history relating to the distributed ledger 16808, and broadcast the transaction history to other participating nodes 16916.

[0891] In some embodiments, the ledger management system 16910 (and/or the collection of participant nodes 16916) may be configured to leverage a distributed ledger 16808 to create an immutable log establishing of a chain of work, possession, and/or title of one or more instances of digital knowledge 16804, establishing verification of 16810 may utilize a distributed ledger to manage a set of permission keys that provide access to one or more instances of the digital knowledge 16804 and/or services associated with the knowledge distribution system 16802. In some embodiments, the distributed ledger 16808 provides provable access to the digital knowledge 16804, such as by one or more cryptographic proofs and/or techniques. In some embodiments, the distributed ledger 16808 may provide provable access to the digital knowledge 16804 by one or more zero-knowledge proof techniques. In some embodiments, the ledger management system 16910 may manage the distributed ledger to facilitate cooperation and/or collaboration between two or more knowledge providers 16806 with regard to one or more instances of digital knowledge 16804.

[0892] FIG. 169 illustrates an exemplary embodiment of the distributed ledger 16808, the distributed ledger 16808 being distributed over a ledger network 16970. The ledger network 16970 may include the distributed ledger 16808 and a set of node computing devices 16916-1, 1691602, 1691603, 16916-N that communicate via one or more communication networks 16814. In some embodiments, the communication network 16814 may include the Internet, private networks, cellular networks, and/or the like. In embodiments, the nodes 16916 may all host a copy of the distributed ledger 16808 (or a portion thereof). For example, the ledger network 16970 may include a first node 16916-1, a second node 16916-2, a third node 16916-3 . . . and an Nth node 16916-N that communicate with the knowledge distribution system 16802 and with other nodes 16916 in the ledger network 16970. In some embodiments, the knowledge distribution system 16802 is configured to execute the ledger management system 16910 and may store and manage a local copy of a distributed ledger 16808 that is used in connection with facilitating management of one or more instances of the digital knowledge 16804 via the knowledge distribution system 16802. In some embodiments, the knowledge distribution system 16802 (or the ledger management system 16910 executed thereon) may also be thought of and referred to as a node of the ledger network 16970. In some embodiments, the ledger management system 16910 may also generate and assign private key and public key pairs to users such as one or more of the knowledge providers 16806 and/or one or more knowledge recipients 16818 of the digital knowledge 16804 (also referred to as “knowledge recipients”) and/or to each node 16916 in the ledger network 16970, such that the private key and public key pairs are used to encrypt data transmitted between nodes 16916 in the ledger network 16970.

[0893] In some embodiments, each of the nodes 16916 of the ledger network 16970 (other than the knowledge distribution system 16802) may be a computing device or a set of connected computing devices that are associated with the knowledge providers 16806 and/or knowledge recipients 16818. In some embodiments, the nodes 16916 may include computing devices of parties that are not involved in the providing or receipt of knowledge (e.g., parties that are associated with neither the knowledge providers 16806 nor any of the knowledge recipients 16818). In some embodiments, each of the nodes 16916 may store a respective local copy 16808-L of the distributed ledger 16808. In some embodiments, one or more nodes may store a partial copy of the distributed ledger 16808. In some embodiments, each of the nodes 16916, 16916-1, 16916-2, 16916-3, 16916-N may execute a respective agent 16920, 16920-1, 16920-2, 16920-3, 16920-N. An agent 16920 may be configured to perform one or more of managing the local copy 16808-L of the distributed ledger 16808 associated with the node 16916 that executed the agent 16920, helping verify blocks that were previously stored on the ledger 16808, helping verify requests from other nodes 16916 to store new blocks on the ledger 16808, requesting permission to perform operations relating to the digital knowledge or management thereof on behalf of a user associated with the node 16916 on which the agent resides, and/or facilitating collaboration between one or more of the knowledge providers 16806 and/or one or more of the knowledge recipients 16818 (e.g., using knowledge provider device(s) 16890 and/or knowledge recipient device(s) 16894, respectively), such as by assisting with validation and/or transfer of one or more instances of the digital knowledge 16804 and/or executing one or more clauses of one or more smart contracts 16840. It is understood that nodes may perform additional or alternative tasks without departing from the scope of the disclosure.

[0894] In some embodiments, a knowledge recipient 16818 may receive one or more in 16894 may be any device that is configured to receive and/or use the digital knowledge 16804 from the distributed ledger 16808, such as a computing device, and/or may be devices for using the digital knowledge 16804, such as a 3D printer, a manufacturing device or system, and the like. In some scenarios, knowledge recipient 16818 may employ a plurality of knowledge recipient devices 16894, such as a server or computing device configured to download one or more instances of digital knowledge 16804 from the distributed ledger 16808 and transmit the one or more instances of digital knowledge to a 3D printer, a factory machine, a manufacturing system, or some other suitable device for using the one or more instances of the digital knowledge 16804. For example, a knowledge provider 16806 may upload a link (e.g., using a knowledge provider device 16890) of a computer-aided design (CAD) file of a 3D printable airplane part to the distributed ledger 16808. In embodiments, the knowledge provider 16806 may use e.g., the knowledge provider device 16890 to define or otherwise provide a smart contract that governs the use of the digital knowledge (e.g., the design file for the airplane part), including a cost of a use of the CAD file of the airplane part. A knowledge recipient 16818 may transfer funds (e.g., using knowledge recipient device 16894) to the knowledge provider 16806 (e.g., knowledge provider device 16890) (e.g., via the smart contract) in exchange for access to the CAD file via the distributed ledger 16808. A knowledge recipient device 16894 may then download the CAD file, which may then be used to 3D print the part. For example, the knowledge recipient device 16894 may be a business computer in communication with a 3D printer or a smart 3D printer itself. In the former scenario, the business computer may transfer the CAD file to the 3D printer. Upon receiving the CAD file, the 3D printer may 3D print the airplane part. In some embodiments, the digital knowledge itself (e.g., the CAD file) may be contained in the smart contract, such that the smart contract provides the digital knowledge to the knowledge recipient device 16894 upon verifying that the knowledge recipient 16818 has satisfied the conditions of release of the digital knowledge 16804 (e.g., deposited a requisite amount of currency). In some embodiments, each time that an instance of knowledge is used by a knowledge recipient 16818, a smart contract, the knowledge distribution system 16802, an agent 16920, and/or the knowledge recipient device 16894 may update the distributed ledger 16808 with a block indicating that the knowledge recipient used the instance of digital knowledge 16804.

[0895] In some embodiments, the knowledge distribution system 16802 may be configured to facilitate participation in management of digital knowledge 16804 by one or more crowdsourcers 16836, such as by allowing a crowdsourcer 16836 to verify one or more aspects of an instance of digital knowledge 16804 (e.g., using crowdsourcer device 16892). In embodiments, a crowdsourcer 16836 may be granted crowdsourcing permissions, thereby allowing the crowdsourcer 16836 to view/inspect the digital knowledge and to provide a verification vote 16926 and/or opinion. In embodiments, non-limiting examples of crowdsourcing permissions may include one or more of reviewing an instance of digital knowledge 16804, signing an instance of digital knowledge 16804, verifying an instance of digital knowledge 16804, and the like. Examples of crowdsourcers 16836 include certifying entities, domain experts, customers, manufacturers, wholesalers, and any other suitable party capable of verifying an instance of digital knowledge. In embodiments, certifying entities or domain experts may certify an instance of digital knowledge 16804 as being authentic, accurate, and/or reliable, and/or as coming from an authentic, accurate, and/or reliable source. In embodiments, customers may review an instance of digital knowledge 16804, such as to indicate that the digital knowledge 16804 is in working order and/or of expected quality. In embodiments, manufacturers and/or wholesalers may sign an instance of digital knowledge 16804, such as by applying a serial number to a piece of digital knowledge 16804 before the piece of digital knowledge is transmittable to a knowledge recipient 16818 (e.g., via knowledge recipient device 16894). Certifications, reviews, signatures, and/or any other validation indicia made by crowdsourcers 16836 may be recorded in the distributed ledger 16808, such as by adding one or more new blocks 16922 to the distributed ledger 16808 that indicate the certification, review, signature, or other validation indicia. In some embodiments, the new blocks 16922 may include data related to the certifications, reviews, signatures, and/or other validation indicia made by the one or more crowdsourcers 16836 (e.g., an identifier of the crowdsources, a timestamp, a location, and/or the like), e.g., using crowdsourcer devices 16892. In some examples, the knowledge distribution system 16802 may be paired with a crowdsourcing system (e.g., crowdsourcer devices 16892). Specifically, in examples, the crowdsourcing system (e.g., crowdsourcer devices 16892) may communicate with and engage with the smart contract 16840 such that upon crowdsourcing an element of the digital knowledge 16804 via the smart contract 16840, the digital knowledge 16804 may be embodied (e.g., recorded) in the distributed ledger 16808. The knowledge distribution system 16802 may use the smart contract 16840 to facilitate management of the digital knowledge 16804, such as by allowing the smart contract 16840 and crowdsourcers 16836 to verify (and/or contribute to) one or more aspects of an instance of digital knowledge 16804. For example, a software developer may provide a crowdsource request for a module or function in the smart contract 16840. This crowdsource request may be embedded in open source code as a request for a code element (e.g., where a first supplier of working code may get a share of proceeds (or a credit, or a token, etc.)) of a product. For this example, crowdsourcers 16836 may use the crowdsourcing system (e.g., crowdsource devices 16892) to respond to the crowdsource request by viewing/inspecting the digital knowledge (e.g., open source code) and may provide collaboration in the form of verifications, opinions, corrections, and/or contributions to the open source code which may relate to improvements to the open source code (e.g., improve accuracy and/or reliability of software). These verifications, opinions, corrections, and/or contributions indicia provided by the crowdsourcers 16836 may be recorded in the distributed ledger 16808 by adding one or more new blocks 16922 to the distributed ledger 16808 that indicate the indicia. The crowdsourcers 16836 may be compensated (e.g., via the smart contract 16840) based on their percentage of contribution to the open source code such that the original software developer may share the proceeds (or credits, or tokens, etc.) of the software product with the crowdsources. The percentage contribution may be based on the amount of code written and/or the impact of each crowdsourcer's contribution on the resulting open source code's functionality.

[0896] In some embodiments, the digital knowledge 16804 may be tokenized (e.g., at least partially converted to/wrapped in a knowledge token 17038). In embodiments, tokenizing the digital knowledge 16804 may include wrapping the digital knowledge into a knowledge token 17038 and/or wrapping access, licensing, ownership, and/or other suitable rights related to the digital knowledge 16804 such that the access, licensing, ownership and/or other suitable rights managed by one or more of the knowledge tokens 17038. By tokenizing digital knowledge 16804, the digital knowledge 16804 may reside in and be distributed via a distributed ledger 16808 and smart contracts 16840. In some embodiments, the knowledge distribution system 16802 may define permissions and/or operations associated with the knowledge tokens 17038. For example, the knowledge token 17038 may allow the tokenized digital knowledge 16804 to be viewed, edited, copied, bought, sold, and/or licensed based on permissions set at a time of tokenization by the knowledge distribution system 16802. In embodiments, the knowledge distribution system 16802 may provide for orchestration of a marketplace or exchange for digital knowledge 16804, such as where bodies or instances of digital knowledge 16804 may be exchanged, such as, without limitation, through sets of knowledge tokens 17038 that are optionally governed by smart contracts that may be configured by a host of a knowledge exchange or marketplace and/or by knowledge providers 16806 (e.g., using knowledge provider devices 16890) or knowledge recipients 16818 (e.g., using knowledge recipient devices 16894). For example, an exchange or marketplace may host exchanges for specific categories of know-how, expertise, instruction sets, trade secrets, insight, or other elements of knowledge described or referenced herein, where knowledge is categorized by subject matter of interest, where transaction terms are pre-defined and/or configurable (such as with configurable smart contracts that enable various transaction models, including bid/ask models, auction models, donation models, reverse auction models, fixed price models, variable price models, contingent pricing models and others), where metadata is collected and/or represented about categories of knowledge exchange, and where relevant content is presented, including market pricing data, substantive content about knowledge areas, content about providers, and the like. Such an exchange may facilitate monetization of tokenized knowledge represented in knowledge tokens 17038. In embodiments, a knowledge exchange, as described herein, may be integrated with or within another exchange, such as a domain-specific exchange, a geography-specific exchange, or the like, where the knowledge exchange may facilitate exchange of valuable or sensitive knowledge related to the subject matter of the other exchange. The other exchange may be a stock exchange, a commodities exchange, a derivatives exchange, a futures exchange, an advertising exchange, an energy exchange, a renewable energy credits exchange, a cryptocurrency exchange, a bonds exchange, a currency exchange, a precious metals exchange, a petroleum exchange, an exchange for goods, an exchange for services, or any of a wide variety of others. This may include integration by APIs, connectors, ports, brokers, and other interfaces, as well as integration by extraction, transformation and loading (ETL) technologies, smart contracts, wrappers, containers, or other capabilities.

[0897] In some embodiments, the knowledge distribution system 16802 may be configured to create and issue one or more currency tokens associated with the distributed ledger 16808. The currency tokens may be digital objects such as cryptographic tokens, cryptographic currency, and the like, that may be purchased, mined, assigned, and/or distributed to users of the distributed ledger 16808. In some embodiments, the currency tokens may represent fiat currency (e.g., US Dollars, British Pounds, Euros, or the like), such that the value of the token is pegged to the fiat currency. In embodiments, the currency tokens may be used to transact digital knowledge. For example, in embodiments, smart contracts may be used to receive and verify that a knowledge recipient 16818 has paid the requisite amount of funds before releasing the digital knowledge 16804 to a knowledge recipient device 16894. Additionally or alternatively, knowledge recipients 16818 may use traditional payment methods (e.g., credit card payments) to transact for instances of knowledge. In some embodiments, the currency tokens may function as digital currency. For example, the currency tokens may be paid by knowledge recipients to knowledge providers in exchange for digital knowledge 16804 and/or paid to crowdsources (e.g., certifiers or experts) for verifying one or more aspects of digital knowledge 16804. In some embodiments, one or more users may be awarded currency tokens as a reward for discovering, or “mining”, one or more new blocks 16922 of the distributed ledger 16808. In some embodiments, currency tokens may be asset-backed tokens, such as tokens backed by one or more other currencies (e.g., fiat currencies), securities, ownership rights of property, ownership rights of intellectual property, licensing rights of property and/or intellectual property, and the like. In some embodiments, the knowledge distribution system 16802 may be configured to track access rights and/or ownership rights of one or more of the currency tokens, such as by logging contents and/or balances of digital wallets of users. In some embodiments, the knowledge distribution system 16802 may be configured to issue a wallet passcode to a user, the wallet passcode being necessary to access, view, transfer, and otherwise manage the currency tokens owned (or at least partially owned) by the user to which the wallet passcode has been issued.

[0898] In some embodiments, the knowledge distribution system 16802 may include a smart contract system 16868 configured to generate smart contracts 16840 and deploy the smart contracts 16840 to the distributed ledger 16808. In embodiments, a smart contract 16840 may refer to a piece of software stored on the distributed ledger 16808 and configured to manage one or more rights associated with one or more instances of the digital knowledge 16804 and/or one or more knowledge tokens 17038. In embodiments, the smart contract may be a computer protocol that assists with negotiation and/or performance of terms in an agreement (e.g., distributed on blockchain such as Ethereum blockchain). The smart contract may be used in banking, government, management, supply chain, automobiles, real estate, health care, insurance, etc. In some embodiments, the smart contract 16840 may be contained and/or executed in a virtual machine or a container (e.g., a Docker container). In some embodiments, one or more of the nodes 16916 of the ledger network 16970 may provide an execution environment for the smart contract 16840. In embodiments, a smart contract 16840 may include information, data, and/or logic related to an instance of digital knowledge 16804, one or more triggering events, one or more smart contract actions to be executed in response to detection of one or more of the triggering events, and the like. In embodiments, the triggering events may define conditions that may be satisfied by events performable by one or more users, such as the knowledge provider 16806, the knowledge recipient 16818, and/or the crowdsourcer 16836, or by one or more third parties. Examples of the triggering events include payment of one party by another party, adherence or lack of adherence to one or more terms of a sales, licensing, insurance, or other agreement made by one or more parties, meeting of one or more thresholds or ranges of properties of one or more pieces of the digital knowledge 16804, such as value, user rating, production amount, or any other suitable property, passage of time, or any other suitable triggering event. Additionally or alternatively, the triggering events defined in a smart contract 16840 may include conditions that may be satisfied independently of action or inaction of a human. For example, a triggering event may be when a certain date is reached, when a stock price reaches a certain threshold, when patent rights expire, when a copyright expires, when a natural event occurs (e.g., a hurricane, a tornado, a drought, or the like), etc. Triggering events may be defined as different types of triggers. For example, triggers or triggering events may refer to changing states (e.g., state change event) such as where the smart contract is active upon a set of data states (e.g., state change events). In other examples, triggers or triggering events may refer to events that occur such that users may need to passively wait for the events to occur and the knowledge distribution system 16802 may need to monitor for these events.

[0899] Referring to FIG. 170, the knowledge distribution system 16802 includes details of the smart contract 16840 and the smart contract system 17068. In embodiments, smart contract actions 17086 may include, for example, monitoring events from a defined data source, verifying fulfillment of obligations of one or more users and/or third parties according to one or more conditions 17084 defined in the smart contract 16840, verifying payment and/or transfer of tokens, property, other goods, or services, between one or more users and/or third parties, transferring the digital knowledge 16804 between parties or to one or more users, logging one or more transactions in the distributed ledger 16808, performing one or more operations with respect to the distributed ledger 16808, creating one or more new blocks 16922 in the distributed ledger 16808, and the like. In some embodiments, a smart contract 16840 may include an event listener 17080 that is configured to monitor one or more data sources (e.g., databases, data feeds, data lakes, public data sources, or the like) for detecting events to determine whether one or more conditions 17084 are met. For example, an event listener 17080 may listen to an application programming interface (API) that provides a connection between the knowledge distribution system 16802 and a printer, such that a smart contract may trigger an obligation of a user to make a payment when a printing instruction set governed by the knowledge distribution set (such as a tokenized instruction set in a knowledge token 17038) is used to print an item using the instruction set. Thus, when a predefined set of conditions 17084 is met, then a smart contract action 17086 may be triggered. This may include triggering a payment process (such as initiating an authorization of a payment on a credit card), closing out a contract (such as when a prepaid number of uses of a knowledge set has been reached), determining a price (such as by initiating a reference to current pricing data in a marketplace or exchange), reporting on an outcome (such as reporting a workflow or event), or the like. In response to being triggered, the smart contract may automatically execute the smart contract action 17086. In some embodiments, the smart contracts are Ethereum smart contracts and may be defined in accordance with the Ethereum specification, which may be accessed at https://github.com/ethereum, the contents of which are incorporated by reference. In other embodiments, the smart contract system 17068 may include the event listener 17080.

[0900] In some embodiments, the smart contract 16840 may be configured to “wrap” one or more instances of the digital knowledge 16804 in a smart contract wrapper (e.g., a “smart wrapper”). Once wrapped, an instance of digital knowledge may be handled and/or accessed differently than when unwrapped, such as by only being readable, editable, and/or transferrable according to terms, conditions, and/or operations of the smart contract 16840. The smart contract 16840 may wrap the digital knowledge 16804 such that in order to be accessed by the knowledge recipient 16818, the digital knowledge 16804 must first be “unwrapped,” (e.g., reverted to a pre-wrapped form). In some embodiments, the pre-wrapped form may be the tokenized form. The smart contract 16840, the distributed ledger 16808, and/or the knowledge distribution system 16802 may unwrap one or more tokens and/or instances of the digital knowledge 16804 in response to one or more triggering events. In some embodiments, the knowledge distribution system 16802, or another suitable system, may store a plurality of smart contract templates from which the smart contract 16840 may be generated. In some embodiments, the smart contract system 17068 may include a smart contract (SC) generator 17082 that may parameterize at least one smart contract template (from the plurality of smart contract templates) based on the information provided by a user and any conditions 17084 and/or actions 17086 defined by the user. For example, the smart contract template may correspond to a type of digital knowledge that is to be tokenized. The contract template may include parameters based on the type of the digital knowledge. These parameters may include: financial parameters for use of the tokenized digital knowledge (e.g., financial parameters), royalty rate parameters for intellectual property (e.g., royalty parameters), number of times an instruction set can be used parameters (e.g., usage parameters), output amount parameters that may be produced using an instruction set (e.g., output produced parameters), allocation of consideration among parties parameters to the smart contract and designated beneficiaries of the smart contract (e.g., allocation of consideration parameters), identity parameters that may have permission to access the distributed ledger 16808 and/or the digital knowledge (e.g., identity parameters), and/or access condition parameters for the distributed ledger 16808 and/or the digital knowledge (e.g., access condition parameters). In some embodiments, the smart contract 16840 may be configured to manage a wrapped token based on an aggregated set of instructions defined in the smart contract 16840.

[0901] In some embodiments, the distributed ledger 16808 may store smart contracts 16840 configured to facilitate licensing of one or more intellectual property rights corresponding to an instance of digital knowledge, such as know-how, patented material, trademarks, works of authorship (e.g., copyrights), and/or trade secrets. In embodiments, the knowledge distribution system 16802 may be configured to allow one or more of the knowledge providers 16806 to engage in a licensing agreement with one or more of the knowledge recipients 16818 via a smart contract 16840 (e.g., using one or more knowledge provider devices 16890 and/or one or more knowledge recipient devices 16894). In embodiments, a smart contract 16840 may be configured to embed licensing terms for the intellectual property in one or more of the blocks 16922 of the distributed ledger 16808, including scopes of use, waivers, indemnifications, limitations of use, geographical limitations, and/or the like. In embodiments, one or more copies of and/or references to the one or more pieces of intellectual property may be stored on the distributed ledger 16808, and access to the one or more pieces of intellectual property may be governed by terms of the smart contract 16840. Upon execution of the smart contract 16840, the knowledge distribution system 16802 may automatically transfer access and licensing rights to the intellectual property to the knowledge recipient 16818 (e.g., knowledge recipient device 16894 of knowledge recipient 16818) according to terms and/or operations set forth in the smart contract 16840. In some embodiments, the knowledge distribution system may be configured to verify assignee rights with resources such as public patent assignee logs prior to transferring access and/or licensing rights. In embodiments, the smart contract 16840 may contain one or more operations to be performed with respect to the distributed ledger 16808 to facilitate an execution defined by the smart contract 16840. In some embodiments, the smart contract 16840 may be configured to automatically allocate royalties in transfers between one or more knowledge providers 16806 and knowledge recipients 16818 (e.g., using knowledge provider devices 16890 and knowledge recipient devices 16894) involving transfer of access to, ownership of, and/or licensing rights to intellectual property. For example, if the owner of the digital knowledge pays licensing fees to a third-party patent owner of one or more aspects of the digital knowledge (e.g., the inventor of a particular product design), the smart contract may allocate a set percentage or amount of the transaction price of the digital knowledge 16804 to the licensor, such that the license to make, sell, use, and/or otherwise transact for is transferred to the recipient of the digital knowledge 16804. In embodiments, the operations for allocating royalties may be performed according to one or more terms of one or more of the smart contracts 16840 and may have related smart contract actions 17086.

[0902] In some embodiments, the knowledge distribution system 16802 may be configured to aggregate intellectual property licensing terms. The distributed ledger 16808 may be configured to store an aggregate stack of instances of the digital knowledge 16804, where one or more aspects of the digital knowledge 16804 are restricted in accordance with an intellectual property right of a party (e.g., a patent, copyright, trademark, or trade secret of the knowledge provider or any other party). In embodiments, the ledger management system 16910 may facilitate adding one or more instances of the intellectual property to the aggregate stack, thereby associating the added instance of intellectual property to the stack of intellectual property to which the instance of intellectual property is added. Operations such as transfer of control, edit, viewing, ownership, and/or licensing rights may be performed on an entire stack of intellectual property by the knowledge distribution system 16802, such as according to terms of one or more smart contracts 16840. Access to, ownership of, and/or sublicensing rights to the aggregate stack of intellectual property may be transferred from one or more of the knowledge providers 16806 to one or more of the knowledge recipients 16818 via the knowledge distribution system 16802 (e.g., using knowledge provider devices 16890 and knowledge recipient devices 16894). In some embodiments, a smart contract may be configured to transfer rights to the aggregate stack of intellectual property associated with an instance of digital knowledge (e.g., the right to use, sell, offer for sale, export, import, a product or process associated with the intellectual property stack) or to transfer the intellectual property stack in its entirety to the digital knowledge recipient. In the latter scenario, the smart contract may be configured to facilitate the assignment of the intellectual property stack to the digital knowledge recipient (e.g., populating assignment forms that are submitted to patent, trademark, or copyright offices of one or more jurisdictions and to electronically file the assignment documents). In some embodiments, the assignment of intellectual property rights may be recorded in the distributed ledger 16808 as well.

[0903] In some embodiments, the ledger management system 16910 may define one or more operations that may handle or process commitments of one or more parties to the smart contract 16840 and/or terms thereof. When a set of parties (e.g., knowledge providers 16806, knowledge recipients 16818, crowdsourcers 16836 and/or third parties) commit to the terms of a smart contract 16840 to a term of a smart contract governing the transfer of digital knowledge 16804, the knowledge distribution system 16802 (and/or the smart contract 16840 itself) may handle or process commitments of the parties and/or identifiers of the parties to one or more portions (e.g., terms) of the smart contracts 16840. In embodiments, upon a set of parties committing to a smart contract 16840, the smart contract 16840 and/or the knowledge distribution system 16802 may link one or more of the parties to one or more of the triggering events defined in the smart contract 16840, begin monitoring one or more data sources to determine whether any conditions 17084 defined trigger events are met, and/or automatically perform operations/actions defined in the smart contract (e.g., in response to the occurrence of a triggering event). For example, a knowledge provider 16806 may upload a smart contract 16840 (e.g., using knowledge provider device 16890) to the distributed ledger 16808 and/or customize a smart contract 16840 using a smart contract template in connection with uploading an instance of the digital knowledge 16804. In embodiments, the knowledge provider 16806, a knowledge recipient 16818, or some other party may indicate (e.g., via the knowledge distribution system 16802, the distributed ledger 16808, and/or the smart contract 16840) terms of an agreement between the knowledge provider 16806 and the knowledge recipient 16818 upon an agreement being formed between the knowledge provider 16806 and the knowledge recipient 16818. In some embodiments, the smart contract 16840 may include one or more rights, terms, and/or obligations provided by the knowledge provider 16806 and/or a third party prior to identification of and/or dealing with the knowledge recipient 16818. The knowledge recipient 16818 may agree to be bound by rights, terms, and/or obligations defined via the smart contract 16840 upon agreeing to receive the digital knowledge 16804 (e.g., using knowledge recipient device 16894). The knowledge recipient 16818 may be a user who is willing to transact (e.g., buy, license, or otherwise make a deal with the knowledge provider 16806) for the digital knowledge 16804. The smart contract 16840 may commit or otherwise bind (or process commitments) the knowledge provider 16806, the knowledge recipient 16818, and/or other parties to the agreement to terms and/or conditions 17084 of the smart contract 16840 in response to receiving indication via the knowledge distribution system 16802 and/or the distributed ledger 16808.

[0904] In some embodiments, the knowledge distribution system 16802 may include an account management system. In embodiments, the account management system 16846 may facilitate creation and/or storage of user accounts related to users of the knowledge distribution system 16802, the knowledge distribution system 16802, and/or the distributed ledger 16808. For example, the account management system 16846 may be configured to facilitate registration of one or more of the knowledge providers 16806, the knowledge recipients 16818, the crowdsourcers 16836, and/or other third parties that may be associated with the knowledge distribution system 16802, the knowledge distribution system 16802, and/or the distributed ledger 16808. In some embodiments, the account management system 16846 may be configured to, together with the ledger management system 16910, facilitate intake of data from registered users of the distributed ledger 16808, such as name, address, company affiliation, financial account information (e.g., bank account numbers and/or routing numbers), digital identifiers (e.g., IP addresses, MAC addresses, and the like), and any other suitable information related to the registered users.

[0905] The account management system 16846 may update the user account of the registered user with data taken in and related to the registered user. In some embodiments, the account management system may facilitate generation and/or distribution of one or more of the permission keys 16932 to one or more of the registered users. The permission keys 16932, 16932-1, 16932-2, 16932-3, 16932-N may provide the registered user with access to one or more instances of the digital knowledge 16804 and/or services associated with the knowledge distribution system 16802.

[0906] In some embodiments, the knowledge distribution system 16802 may include a user interface system 16850 configured to present a user interface. The user interface may be configured to facilitate uploading of digital knowledge 16804, generation and/or uploading of a smart contract 16840, and viewing of the digital knowledge 16804 and/or the smart contract 16840 (and statuses thereof). The user interface may be a graphical user interface. Information presented to users of the knowledge distribution system 16802 via the user interface may include descriptions of one or more instances of the digital knowledge 16804, ownership and/or licensing information related to the one or more instances of the digital knowledge 16804, information related to the user viewing the user interface and/or other users of the knowledge distribution system 16802, price information related to one or more instances of the digital knowledge 16804, statistics and/or metrics related to the distributed ledger 16808 and/or contents thereof, such as node count, payouts for generation of additional nodes, and any other suitable information. In some embodiments, users may view contents of their digital wallets via the user interface, such as a balance of one or more types of currency tokens.

[0907] In some embodiments, the user interface may be configured to allow one or more users to perform one or more of the operations related to the digital knowledge 16804 and/or the distributed ledger 16808, such as buying, selling, verifying, and/or reviewing the digital knowledge 16804 and/or performing other operations related to the distributed ledger 16808 discussed herein. For example, the knowledge provider 16806 may select a computer file (such as a 3D printer schematic file) to upload to the distributed ledger 16808 via the user interface (e.g., using knowledge provider device 16890). The user interface may present the knowledge provider 16806 with one or more options related to uploading the digital knowledge 16804, such as an ability to configure a smart contract 16840 and related terms for wrapping and/or tokenizing the digital knowledge 16804. Other options may include privacy options, such as options pertaining to one or more users or classes of users who may and/or may not view, buy, sell, license, rate, verify, review, or otherwise manage or interact with the digital knowledge 16804.

[0908] In some embodiments, the user interface system 16850 may include a marketplace system 16854 configured to establish and maintain a digital marketplace 16856. In embodiments, the digital marketplace 16856 provides an environment that allows knowledge providers and potential recipients to engage in commerce relating to the transfer of digital knowledge 16804. For example, the digital marketplace may be configured to allow one or more users and/or third parties to search for one or more pieces of digital knowledge 16804 similar to a digital storefront, transact for one or more pieces of the digital knowledge 16804 (e.g., buy, sell, license, lease, bid on, and/or give away the digital knowledge), receive recommendations for digital knowledge 16804, review one or more pieces of the digital knowledge 16804, verify source information and/or other information related to one or more pieces of the digital knowledge 16804, transact for one or more pieces of the digital knowledge 16804 (e.g., buy, license, bid on one or more pieces of the digital knowledge, or the like), and/or perform any other suitable marketplace interaction with the digital knowledge 16804, one or more of the knowledge providers 16806, the distributed ledger 16808, one or more of the knowledge recipients 16818, one or more crowdsourcers 16836, or any other user or third party. In some embodiments, the digital marketplace 16856 may be configured to allow users to edit user accounts associated with themselves and view user accounts associated with other users. In some embodiments, the digital marketplace 16856 user interface may allow users to make reviews and/or ratings of other users.

[0909] In embodiments, the knowledge distribution system 16802 may include one or more datastores 16858. FIG. 171 illustrates an example set of datastores 16858 of the knowledge distribution system 16802. In some embodiments, the knowledge distribution system 16802 may include one or more datastores 16858 configured to store data related to the digital knowledge 16804, the distributed ledger 16808, the knowledge providers 16806, the knowledge recipients 16818, the crowdsourcers 16836, the knowledge tokens 17038, the smart contracts 16840, the account management system 16846, the marketplace system 16854, or any other suitable type of data. A datastore may store folders, files, documents, databases, data lakes, structured data, unstructured data, or any other suitable data.

[0910] In some embodiments, the datastores 16858 may include a knowledge datastore 17160 configured to store data. The knowledge datastore 17160 may be in communication with the user interface system 16850. The user interface system 16850 may be configured to populate the user interface with data stored in the knowledge datastore 17160. In some embodiments, data stored in the knowledge datastore 17160 may include knowledge related to the digital knowledge 16804 such as source, reviews, price, ownership, licensing, related knowledge providers 16806, related knowledge recipients 16818, serial numbers, related crowdsourcers 16836, or any other suitable information. For example, the knowledge datastore 17160 may contain information related to a 3D printer schematic such as origin, date of creation, names of one or more contributing individuals, groups, and/or companies, pricing, market trends for related schematics, serial numbers and/or part identifiers, and any other suitable type of data related to the 3D printer schematic.

[0911] In some embodiments, the datastores 16858 may include a client datastore 17162 (e.g., may include user datastore), the client datastore 17162 being configured to store data relating to users of the knowledge distribution system 16802. The client datastore 17162 may be in communication with the account management system 16846 and may be populated with user accounts related to one or more of the user accounts, data contained in one or more of the user accounts, data related to the one or more user accounts, and/or a combination thereof.

[0912] In some embodiments, as shown in FIGS. 170 and 171, the datastores 16858 may include a smart contract datastore 17164. In embodiments, the smart contract datastore 17064 is configured to store data related to one or more of the smart contracts 16840 and/or smart contract templates (from which smart contracts 16840 may be parameterized and instantiated). In embodiments, the smart contract datastore 17064 may be in communication with the ledger management system 16910. Data stored in the smart contract datastore may include, for example, smart contract templates, one or more smart contracts 16840, data related to instances of the digital knowledge 16804 related to one or more of the smart contracts 16840, data related to parties to one or more of the smart contracts 16840, and any other suitable data. The smart contract datastore 17064 may be configured to store completed smart contracts that have already been executed. The smart contract datastore 17064 may be configured to store smart contracts that have not yet been uploaded to the distributed ledger 16808.

[0913] Referring to FIG. 168, in some embodiments, the knowledge distribution system 16802 may include an analytics system 16866 configured to analyze one or more tokenized instances of the digital knowledge 16804, such as the knowledge token 17038, and report an analytic result. The analytics system may analyze the tokenized instance of the digital knowledge 16804 in order to determine one or more properties and/or metrics of the tokenized instance of the digital knowledge 16804. Properties of tokenized digital knowledge 16804 may include, for example, source, reviews, price, ownership, licensing, related knowledge providers 16806, related knowledge recipients 16818, serial numbers, related crowdsourcers 16836, or any other suitable information. The analytics system 16866 may be configured to determine one or more trends, metrics, and/or predictions related to the properties. In some embodiments, the analytics system 16866 may include a machine learning module configured to perform predictions and/or analyses of the properties related to the digital knowledge 16804 via one or more machine learning techniques.

[0914] In some embodiments, properties of tokenized intellectual property may be analyzed by the analytics system 16866. For example, the analytics system 16866 may be configured to analyze tokenized digital knowledge 16804 including intellectual property. Analyzed properties of tokenized intellectual property may include, for example, transaction history including changes and/or assignments in ownership and/or licensing rights of the intellectual property, litigation history including lawsuits involving the intellectual property and data related to the lawsuits, information pulled from one or more databases of intellectual property related to the intellectual property, and any other suitable property of the tokenized intellectual property or any other token or suitable instance of the digital knowledge 16804. Metrics related to tokenized intellectual property may include, for example, value, age, strength, efficacy, or any other suitable metric related to the tokenized intellectual property or any other knowledge token 17038 or suitable instance of the digital knowledge 16804.

[0915] In some embodiments, the knowledge distribution system 16802 may be configured to perform an aggregation operation that aggregates a set of operations and/or instructions included in one or more instances of the digital knowledge 16804. Aggregation may be employed where component instances of digital knowledge 16804 are aggregated to form larger instances of digital knowledge. In embodiments, aggregation occurs where component instances are concatenated to form larger instances, such as by adding component instances as additional (optionally tokenized) blocks to a chain, or by adding references or links to component knowledge blocks. Examples of concatenation aggregation include where chapter instances are concatenated to form book instances, where sentence instances are concatenated to form paragraphs, where word instances are concatenated to form sentence instances, and the like. In embodiments, aggregation occurs where component instances are linked schematically to form a system, such as where knowledge representing physical component parts of a machine are linked to form the machine, where component steps in a process are linked to form the complete process, or the like. In embodiments, aggregation of knowledge involves linking elements in a flow, such as where instances are linked diagrammatically to generate a workflow, such as where ingredients and process steps are linked to generate a recipe or formulation process, where workflow steps and materials are linked to describe a work process (such as one involving expertise or know how) or the like. In embodiments, aggregation of knowledge involves coupling of partial instances to form a whole instance, such as where two or more sub-parts of a formula are joined to form a complete formula (e.g., a chemical, pharmaceutical, biological, materials science, physical, or other formula), where two or more sub-parts of an instruction set (e.g., computer code) are joined to form the entire instruction set, or the like. In embodiments, aggregation may involve linking related instances of knowledge in a cluster, such as where instances of knowledge are topically linked to form a cluster, such as a cluster of related subjects in a knowledge domain (such as a scientific domain, a domain of the humanities, a social science domain, a commercial domain, a business domain, or many others). In embodiments, aggregation may involve hierarchical aggregation of knowledge, such as by representing knowledge according to one or more defined hierarchies, such as an organizational hierarchy (such as an organizational chart or reporting structure), an industry hierarchy, a topical hierarchy, a physical hierarchy, or the like. Many other examples of aggregation may be envisioned. The ledger management system 16910 may be configured to perform the aggregation operation. The aggregation operation adds at least one instruction to a preexisting set of instructions, thereby yielding a modified set of instructions. The modified set of instructions may then be stored in the distributed ledger 16808 and may be tokenized, manipulated, and/or managed similarly to any instance of the digital knowledge 16804. In some embodiments, the aggregation operation may be performed by the smart contract 16840, according to one or more terms of the smart contract 16840, and/or in reaction to triggering of one or more triggering events of the smart contract 16840. In some embodiments, the aggregation operation may be performed at request of a user of the knowledge distribution system 16802.

[0916] In some embodiments, the ledger network 16970 is a federated network, such that the ledger management system 16910 of the knowledge distribution system 16802 may act as an arbiter to simplify the consensus mechanism. Some or all of the nodes 16916 may be preselected or preapproved to act as nodes 16916 with respect to the management of blocks of the distributed ledger 16808 and/or data contained therein, such as one or more instances of the digital knowledge 16804. The ledger management system 16910 may ease computational burdens on the other nodes 16916 in the ledger network 16970. In some embodiments, the distributed ledger 16808 is distributed, such that the participating nodes 16916 may each store a respective local copy 16808-L of the distributed ledger 16808, where each local copy 16808-L may include the entire distributed ledger 16808 or a portion thereof.

[0917] In the illustrated example, the knowledge distribution system 16802 stores a copy of the distributed ledger 16808, the copy of the distributed ledger 16808 being local to the knowledge distribution system 16802, and each node 16916 stores a distributed local copy 16808-L of the distributed ledger 16808. In some embodiments, however, the knowledge distribution system 16802 does not store a local copy of the distributed ledger 16808 such that the distributed ledger 16808 is maintained wholly by participant nodes 16916. A distributed copy (e.g., copy 16808-L) of the distributed ledger 16808 may contain the entire distributed ledger 16808 or only a portion of the distributed ledger 16808. In general, each copy of the distributed ledger 16808 stores a set of blocks 16922. In some embodiments, each respective block may store information relating to a respective state change event as a hash value and may further store a block identifier of a “parent” block that was added to the distributed ledger 16808 prior to the respective block. In some embodiments, the ledger management system 16910 may select the block that was most recently added to the ledger to act as the parent block, whereby the ledger management system 16910 includes the block identifier of the most recently added block to the state change event record.

[0918] A state change event may refer to any change of state relating to the digital knowledge 16804 and/or management of one or more instances of the digital knowledge 16804. Non-exhaustive examples of state change events may include creating a new instance of the digital knowledge 16804, registering a new user of the knowledge distribution system 16802, such as a new knowledge provider 16806 (and/or registering a new knowledge provider device 16890) or a new knowledge recipient 16818 (and/or registering a new knowledge recipient device 16894), granting the new user permission to perform a specific operation, modifying certification and/or validation of one or more instances of the digital knowledge 16804 at the request of a user, transmitting one or more instances of the digital knowledge 16804 to one or more knowledge recipients 16816 (e.g., knowledge recipient devices 16894), recordation of a use of an instance of digital knowledge 16804 by a knowledge recipient, and the like. In some embodiments, the ledger management system 16910 may create a state change event record that indicates the state change event, e.g., the operation that was performed, for each state change event that occurs. A state change event record may further be information/metadata relating to the event, such as one or more user identifiers of one or more respective users associated with the state change event, a timestamp corresponding to the state change event, a device identifier of the device that requested or performed an operation, an IP address corresponding to the device that requested or performed the operation, and/or any other relevant data. In some embodiments, the ledger management system 16910 may include a block identifier of a previous block that was previously stored on the ledger 16808 in the state change event record, such that the previous block may be a “parent” to a new block that will be generated based on the state change event record, as the state change event record references the previously stored block, but the previously stored block will not reference the new block. In some embodiments, the block identifier may be the hash value of a previously generated block.

[0919] In some embodiments, the ledger management system 16910 and/or one or more of the nodes 16916 may be configured to generate a state change event record for each event occurring with respect to management of digital knowledge 16804 via the knowledge distribution system 16802. In embodiments, the ledger management system 16910 and/or one or more of the nodes 16916 may generate a new block 16922 corresponding to the state change event record by generating a cryptographic hash (or “hash value”) of the state change event record by inputting the state change event record into a hashing function to obtain the cryptographic hash. The resultant hash value is a unique value (or substantially unique value with a very low likelihood of collisions) that represents the contents of the state change event record, such that the resultant hash value is a unique identifier that identifies the new block and that also encodes the contents thereof, including a block identifier of the parent block. Thus, when the new block is “solved” (solving a block in this context may refer to the process of determining the original contents of the state change event record encoded in the hash value), the solution of the new block indicates the contents of the state change event record, including the block identifier of the parent block. As such, the hash value of the preceding state change event record may be used to verify the authenticity of the current state change event record by way of verification. While the above description describes blocks that store only one state change event record, in some embodiments, the ledger management system 16910 and/or one or more of the nodes 16916 may encode two or more state change event records in a single block. The ledger management system 16910 and/or one or more of the nodes 16916 may include the two or more state change event records in the body of a new block data structure and may include the block identifier of the previous block in a block header of the new block data structure. The ledger management system 16910 and/or one or more of the nodes 16916 may then input the new block data structure into the hashing function, which outputs the new block 16922. In these embodiments, the new block 16922 may be a cryptographic hash that represents the two or more state change event records and the block identifier of the previous block (i.e., the parent block to the new block). In this way, when the new block is solved, the solution to the block is the two or more state change event records and the block identifier of the parent block, where the block identifier of the parent block can be used to validate the authenticity and accuracy of the new block.

[0920] In embodiments, the ledger management system 16910 and/or one or more of the nodes 16916 may request verification of a block 16922. In some embodiments, verification of a block 16922 may include broadcasting a request 16924 to verify a block 16922 (referred to as “the block 16922 to be verified”) to the other nodes 16916 in the ledger network 16970 (which may include the ledger management system 16910 if the ledger management system 16910 is not issuing the request 16924). In some embodiments, the request 16924 may include or be broadcasted with the block 16922 to be verified. Verification may further include one of the other nodes 16916 that received the request 16924 (or potentially the ledger management system 16910) solving the block 16922 to be verified. A node 16916 may determine it has solved the block 16922, when the solution to the block contains a valid block identifier—that is, a block identifier that references one of the other blocks 16922 stored on the distributed ledger 16808. Once the solver has determined the solution to the block 16922, the solver broadcasts a “proof of work” 16928 to the other nodes 16916. In some embodiments, the proof of work 16928 may be the block identifier of the previous block 16922. In some embodiments, each of the non-solving nodes 16916 (potentially including the ledger management system 16910), may receive the proof of work and may validate the proof of work based on the copy of the distributed ledger 16808 that is stored at the node 16916. In these embodiments, each node 16916 may determine whether the block identifier contained in the proof of work corresponds to (e.g., matches) a block identifier of a block stored on the local copy of the distributed ledger 16808.

[0921] In some embodiments, the ledger management system 16910, in conjunction with the other nodes 16916 in the ledger network 16970, maintains an immutable record of any operations performed with respect to a management of digital knowledge 16804 via the knowledge distribution system 16802 using the knowledge distribution system 16802. In these embodiments, any time a user performs an operation with respect to management of digital knowledge 16804 via the knowledge distribution system 16802 hosted on the knowledge distribution system 16802, the ledger management system 16910 may: generate a new event state record corresponding to the operation; encode the new event state record into a new block data structure and a block identifier of a previous block (e.g., the most recently added block) into a block header of the new block data structure; and hash the new block data structure using a hashing function to obtain the new block. Furthermore, in some embodiments, the ledger management system 16910 may transmit a request 169240 to verify the new block 16922 to the other nodes 16922 in the network 16814. In some embodiments, one of the nodes 16916 may attempt to determine a solution to the new block 16922. If a valid solution is determined, the solver node 16916 may transmit a proof of work 16928 to the other nodes 16916 in the ledger network 16970, and the other nodes 16916 may attempt to validate the proof of work 16928.

[0922] In some embodiments, the ledger management system 16910 utilizes a distributed ledger 16808 to manage permissions of different users of the knowledge distribution system 16802, such as one or more of the knowledge providers 16806 (and/or one or more knowledge provider devices 16890) and/or one or more of the knowledge recipients 16818 (and/or one or more knowledge recipient devices 16894). In some embodiments, permissions may be granted with respect to an instance of the digital knowledge 16804 or set of instances of the digital knowledge 16804. For example, permissions may include permission for a user to upload an instance of the digital knowledge 16804 or set of instances of the digital knowledge 16804, permission for a user to view an instance of the digital knowledge 16804 or set of instances of the digital knowledge 16804, permission for a user to edit an instance of the digital knowledge 16804 or set of instances of the digital knowledge 16804, permission for a user to delete an instance of the digital knowledge 16804 or set of instances of the digital knowledge 16804, permission for a user to download an instance of the digital knowledge 16804 or set of instances of the digital knowledge 16804, permission for a user to print (e.g., print-to-paper or 3D print) an instance of the digital knowledge 16804 or set of instances of the digital knowledge 16804, and the like. Permissions may additionally or alternatively relate to services 16930 that are offered by the knowledge distribution system 16802. For example, permissions may include permission for a user to access a full-text search functionality on the knowledge distribution system 16802, permission for the user to use a virus scanner offered by the knowledge distribution system 16802, permission for the user to have the knowledge distribution system 16802 generate a machine-generated instance of the digital knowledge 16804 or set of instances of the digital knowledge 16804, and the like. Permissions may also include the permission to perform an operation granted to one or more other users. Permissions may be applied to one or more users by default, applied to one or more classes of users, such as users holding one or more of the permission keys 16932, automatically be applied to one or more categories of users such as knowledge provider 16806, knowledge recipient 16818, and/or crowdsourcer 16836, and/or may be manually given to one or more users by administrators and/or managers of the knowledge distribution system.

[0923] In some embodiments, the ledger management system 16910 may manage individual participant's access to respective services 16930 by generating one or more unique service-specific permission keys 16932 for a respective service 16930 and issuing each respective unique service-specific permission key 16932 to a respective participant that has been granted access to the respective service 16930. In some of these embodiments, the ledger management system 16910 may utilize the distributed ledger 16808 to store proof of the service-specific permission keys 16932 and to manage permissions to the services 16930. In these embodiments, the ledger management system 16910 may: receive an instruction to grant a user permission to access a particular service; generate a service-specific permission key 16932 corresponding to the particular service and assign the key 16932 to the user; encode a user ID of the user and the service-specific permission key 16932 in a state change event record; generate a new block based on the state change event record and a block identifier of a previously stored block; store the new block on its local copy of the distributed ledger 16808, and broadcast the new block to other nodes 16916 in the network for storage on the respective copies of the distributed ledger 16808 stored at the nodes. In some embodiments, the ledger management system 16910 may validate the new block prior to storing and transmitting the block for storage at the other nodes 16916. The ledger management system 16910 may further transmit the new block to a computing device associated with the user (which may or may not be a participating node), whereby an agent 16920 on the computing device may store the new block. In this way, the agent 16920 may use the new block to obtain access to the particular service, when the user attempts to access the particular service 16930 from the computing device. When the user attempts to access the particular service 16930, the agent may communicate the block containing the permission key 16932 corresponding to the particular service 16930 to the ledger management system 16910. The ledger management system 16910 may solve the received block and/or validate the received block, in the manner described above. If the ledger management system 16910 is able to validate the received block, the ledger management system 16910 grants the computing device of the user access to the service 16930, whereby the user may begin using the service 16930. In some embodiments, permissions and access to an instance of the digital knowledge 16804 or set of instances of the digital knowledge 16804 that are stored in an organizational structure may be managed in a similar way, where users are granted permission keys 16932, where these permission keys 16932 correspond to specific operations that a user may perform on the instance of the digital knowledge 16804 or set of instances of the digital knowledge 16804 with which the permission keys 16932 are associated.

[0924] In some embodiments, the ledger management system 16910 and/or one or more computing node computing devices 16916 having requisite processing resources may generate an immutable log of a transaction based on the distributed ledger 16808. In these embodiments, the ledger management system 16910 and/or the nodes 16916 (referred collectively as the solving nodes 16916) may begin solving the most recent blocks 16922 in the distributed ledger 16808. Each time a block is solved, the solving node 16916 may transmit the proof of work 16928 to other nodes 16916, which may then verify the accuracy of the solution. The solving nodes 16916 may iteratively solve each of the blocks 16922 in the distributed ledger 16808 in this manner until the entire distributed ledger 16808 is solved, thereby resulting in an operation log of the management of digital knowledge 16804 via the knowledge distribution system 16802. The operational log may define the actions or operations that were performed using the knowledge distribution system 16802. By creating, validating, and solving the blocks 16922 of the distributed ledger 16808 in the manners described above, the distributed ledger 16808 is generated in a transparent and secure manner. The resultant operational log is stored in an encrypted manner until it is solved, and once solved, the operational log is auditable and immutable. The operational log may indicate each time a user was allowed to access the distributed ledger 16808 and/or management of digital knowledge 16804 via the knowledge distribution system 16802, the permissions that each user was granted, the requests to perform operations or use services 16930 that each user initiated, the operations that were performed, the user that performed the operation, and the like.

[0925] In some embodiments, the solving nodes 16916 may optimize the solving of the ledger 16808 by solving different blocks 16922 in a distributed manner. For example, if the distributed ledger 16808 includes one or more forks (e.g., when more than one child block points 16922 to the same parent block 16922), the distributed ledger 16808 may be said to fork at the parent block 16922. In this example, each chain originating at the fork may have a final block 16922 (or leaf block 16922). In this scenario, different solving nodes 16916 may begin solving the ledger 16808 at different leaf blocks 16922 in a breadth-first or depth-first manner, thereby increasing the speed at which the ledger 16808 is solved.

[0926] In some embodiments, the ledger management system 16910 may be configured to facilitate collaboration between one or more of the knowledge providers 16806, one or more of the knowledge recipients 16818, or a combination thereof, by assisting in the execution of management of digital knowledge 16804 via the knowledge distribution system 16802 using, for example, smart contracts. In these embodiments, the ledger management system 16910 may provide management of digital knowledge 16804 via the knowledge distribution system 16802 that is defined to facilitate a respective type of management of digital knowledge 16804. For example, for a transfer of one or more instances of digital knowledge to a knowledge recipient 16818 (e.g., using knowledge recipient device 16894) in exchange for funds transmitted to a knowledge provider 16806 (e.g., knowledge provider device 16890) in accordance with a sale, license, or rental agreement and/or a smart contract, the ledger management system 16910 define various tasks that must be completed before a next step can be performed in sale, license, or rental of the digital knowledge 16804. In this example, the knowledge distribution system 16802 may require that an instance of the digital knowledge 16804 or a link and/or reference thereto must be uploaded to the distributed ledger 16808 prior to a transfer of funds from the knowledge recipient 16818 to the knowledge provider 16806. Another condition may be that one or more parties having adequate permission to sign a document must electronically execute a document before engaging in a transfer of one or more instances of the digital knowledge 16804. The knowledge distribution system 16802, the ledger management system 16910, and/or the distributed ledger 16808 may be preconfigured based on the type of management of digital knowledge 16804 to be executed via the knowledge distribution system 16802 and/or may be customized by one or more parties associated with the management of digital knowledge 16804 via the knowledge distribution system 16802. In some embodiments, each operation and/or management of digital knowledge 16804 via the knowledge distribution system 16802 may be encoded in a smart contract, whereby the smart contract may manage the phases of the workflow when the smart contract determines that one or more required conditions are met. In some embodiments, copies of a smart contract are stored and executed by the agents 16920 of one or more respective nodes 16916. The agent 16920 may facilitate the performance of operations that are defined in the smart contract (including validating permissions to perform the operations using the distributed ledger 16808), the reporting and recording of the performance of the operations (e.g., by generating blocks or requesting generation of blocks from the ledger management system 16910), and/or verifying that one or more conditions defined in the smart contract are met. Once a consensus is achieved with respect to one or more required conditions, the management of digital knowledge 16804 via the knowledge distribution system 16802 may progress to a next phase in the workflow. In this way, the ledger network 16970 (e.g., the ledger management system 16910 and the participating nodes 16916) may facilitate collaboration between parties in the management of digital knowledge 16804 via the knowledge distribution system 16802 by assisting in the execution of the workflow associated with the management of digital knowledge 16804 via the knowledge distribution system 16802 by validating pre-closing and closing work and/or providing a framework for the management of digital knowledge 16804 via the knowledge distribution system 16802 by way of smart contracts.

[0927] FIG. 172 illustrates a method 17200 of deploying a knowledge token 17038 and related smart contract 16840 via the knowledge distribution system 16802.

[0928] At 17210, the knowledge distribution system 16802 receives an instance of the digital knowledge 16804, such as from a user. In embodiments, the user may be affiliated with an organization (e.g., an organization that owns the digital knowledge) or an unaffiliated individual (e.g., a person who created the digital knowledge on their own or in collaboration with other unaffiliated individuals). The user may provide the instance of the digital knowledge 16804 via a graphical user interface. For example, the user may upload the digital knowledge via the graphical user interface. In embodiments, the digital knowledge may be an instruction set that may be performed by a device or set of devices. The user may upload the digital knowledge by providing the knowledge itself or a reference to the digital knowledge (e.g., an address from which the digital knowledge may be accessed/retrieved electronically).

[0929] In embodiments, the user may provide additional information, such as a type of the digital knowledge, a description of the digital knowledge, a price to be charged to access the digital knowledge, and the like. In some embodiments, the user may provide licensing data, such as any patent, trademark, copyright rights that are licensed or otherwise conveyed to a knowledge recipient, a length of the license(s) (e.g., when each license expires), a scope of the license(s) (e.g., limitations on use/sale/transferability or geographical limitations), and the like. In embodiments, the user may define validation information, such as certifications/validations of the digital knowledge. In embodiments, the user may also define limitations on the distribution of the digital knowledge (e.g., a total number of knowledge tokens that may be generated).

[0930] In embodiments, the user may define a set of conditions and/or actions that are used to generate a smart contract governing transactions for the digital knowledge. Examples of conditions may include a time period when the smart contract is valid, requirements for a recipient device (e.g., certain specifications on a device, such as a type of 3D printer, a minimum amount of processing power, required machinery to perform certain processes, or the like) that must be verified before release of the digital knowledge, requirements for a knowledge recipient (e.g., definitions of certain types of data that must be provided to ensure the knowledge recipient is eligible to receive the digital knowledge), or any other suitable conditions. In some embodiments, the user may define a set of actions that may be performed in response to certain conditions being triggered. Some of the actions that are performed by a smart contract may be default conditions, such as writing a record of the transaction to the distributed ledger or releasing the digital knowledge. In some embodiments, a user may define custom actions, such as defining allocations of funds to third-party rights holders, generating a serial number for a product that is produced by the digital knowledge, digitally signing a product that is produced by the digital knowledge, exposing an API to a knowledge recipient, or the like.

[0931] At 17212, the knowledge distribution system tokenizes the digital knowledge 16804, thereby creating a knowledge token 17038. In embodiments, the ledger management system may tokenize the digital knowledge by wrapping a smart contract around the digital knowledge to obtain the knowledge token. In some embodiments, the ledger management system may retrieve a smart contract template from the smart contract datastore, such that the smart contract template corresponds to a type of the digital knowledge that is to be tokenized. In some of these embodiments, the ledger management system may parameterize the smart contract template based on the information provided by the user and any conditions and/or actions defined by the user. For example, the smart contract may be parameterized for the instance of digital knowledge (or a reference thereto), any licenses that are granted, the price to be paid, any conditions that are to be met, and any actions to be performed. In some embodiments, the ledger management system may include any libraries in the smart contract that are needed to support any of the functions defined in the smart contract. In some embodiments, the ledger management system may configure one or more event listeners that allow the smart contract to monitor one or more data sources. In these embodiments, the ledger management system may define the data source(s) to be monitored, whereby the event listener obtains and/or processes the data from the data source(s) which is then used to determine whether a certain condition or set of conditions is met. Additional examples of tokenization may be found in the Ethereum specification, which may be accessed at https://github.com/ethereum. In embodiments, the knowledge distribution system may generate a set number of knowledge tokens, whereby each knowledge token may be used to facilitate a different transaction for the instance of digital knowledge.

[0932] At 17214, the knowledge distribution system stores the knowledge token(s) 17038. In embodiments, the ledger management system may store the knowledge token(s) by deploying the knowledge token(s) to a distributed ledger 16808. In embodiments, the ledger management system may initially assign the ownership of the knowledge token(s) to the knowledge provider. In embodiments, the knowledge distribution system may also store information relating to the instance of digital knowledge in the knowledge datastore, which may be used to populate a marketplace site where potential knowledge recipients can view information relating to the digital knowledge.

[0933] FIG. 173 illustrates a method 17300 of performing high level process flow of a smart contract that distributes digital knowledge. In embodiments, the smart contract may be a knowledge token that is stored on the distributed ledger and that is executed by one or more nodes that host the distributed ledger. In some of these embodiments, the smart contract may be executed on a virtual machine or in a container.

[0934] At 17310, the smart contract monitors one or more of the conditions defined in the smart contract. In some embodiments, an event listener obtains data (either passively or actively) from one or more data sources defined in the smart contract 16840. As the event listener obtains data from the one or more data sources, the smart contract may determine whether certain conditions are met, and if so, may perform an action that is triggered by the met conditions.

[0935] At 17312, the smart contract verifies conditions for transaction of digital knowledge and at 17314, the smart contract initiates transfer of the digital knowledge 16804. In embodiments, the smart contract may include an event listener that determines whether a requisite amount of funds have been deposited to the smart contract. Once a party has deposited the requisite amount of funds (e.g., a predefined amount of cryptocurrency or fiat currency), the smart contract may initiate the transfer of the digital knowledge to the knowledge recipient (e.g., the party that deposited the requisite amount of funds). In embodiments, this may include updating the distributed ledger with a block that indicates the change in ownership of the token to the knowledge recipient and providing any required keys to the knowledge recipient. Once the ownership of the knowledge token has been changed, the knowledge recipient may access the digital knowledge contained therein (and in accordance with any restrictions defined in the smart contract, such as using a particular type of device).

[0936] As discussed, the techniques described herein may be applied to facilitate transactions for different types of instruction sets. In some embodiments, the knowledge distribution system may be used to distribute instruction sets for 3D-printing specific products (e.g., replacement parts, medical devices, custom products, manufacturing parts, and the like). In operation, the knowledge distribution system 16802 may present a graphical user interface to a user, whereby the user may provide an instance of digital knowledge, as well as a user provider (e.g., a knowledge provider) may upload an instruction set for printing a 3D item to the knowledge distribution system 16802. In embodiments, the 3D printing instruction set may include a file (e.g., a CAD file and/or an STL file) and any accompanying instructions for printing the product defined in the file. In some embodiments, the user may also define a transaction price that defines an amount of currency (fiat currency and/or cryptocurrency) that must be paid to purchase a knowledge token containing the 3D printing instruction set. Additionally, the user may provide a description of the product and any requirements for printing (e.g., required materials and/or device types or minimum specifications needed to 3D print the product). The user may also provide additional information, such as photographs of a printed product, certifications made with respect to the product, and the like.

[0937] In embodiments, the user may define any intellectual property rights that are being licensed or otherwise conveyed to a knowledge recipient with the digital knowledge (also referred to as an intellectual property stack) with the transaction for the 3D printing instruction set. In some embodiments, the user may define an allocation schedule that defines how royalties are divided amongst one or more licensors. For example, if the product that is printed from the instance of digital knowledge is licensed under one or more patents, design patents, copyrights, and/or trademarks, a portion of the transaction price for each printed product may be allocated to the licensors as royalty payments. In this example, the user may identify the licensor(s) that collect the royalties and may assign a percentage or amount of the royalties that go to each respective licensor. In embodiments, the user may define any geographical limitations on the digital knowledge. For example, the user may define countries, regions, jurisdictions, or other geographical areas to which the digital knowledge may or may not be distributed. In embodiments, the user may further define other types of permissions or restrictions, including 3D printer requirements (e.g., a set of 3D printer types, makes and models that can print the product, serial numbers of 3D printers that can print the product, material types that must be used to print the 3D product, and the like), a time period during which the item can be 3D printed, whether the digital token may be transferred to a downstream recipient, or the like. In embodiments, the user may define actions that are performed in connection with 3D printing an object, such as assigning a serial number to the product (which may or may not be printed to the object), and/or the like. In embodiments, the user may further define any warranties, disclaimers, indemnifications, and/or the like associated with the 3D-printed product.

[0938] In embodiments, the smart contract system 17068 may generate knowledge tokens 17038 that contain the digital knowledge (or a reference thereto). In some embodiments, the smart contract system 17068 may tokenize the digital knowledge by wrapping the digital knowledge (e.g., the 3D printing instruction set or a reference to the instruction set) with a smart contract wrapper. In some embodiments, the smart contract system 17068 may obtain a smart contract template and may parameterize the smart contract using some of the information entered in by the user, such as price, license fee allocations, geographic restrictions, other restrictions, custom actions (e.g., assigning serial numbers), if/when the token expires, 3D printer requirements, and the like. In some embodiments, each knowledge token that is generated for the 3D printer instruction set may be assigned a different serial number, such that each 3D-printed product may be identified by its serial number and associated with the token from which it was printed. In this way, the product may be verified and tied to a particular record in the distributed ledger. In embodiments, the smart contract system 17068 may output the generated knowledge tokens to the ledger management system 16910.

[0939] In embodiments, the ledger management system 16910 may upload the knowledge tokens on the distributed ledger. In some embodiments, the ledger management system 16910 may generate a block containing the knowledge tokens and may broadcast the block to the distributed ledger 16808, whereby a knowledge recipient may then transact for one or more of the knowledge tokens (e.g., to print one or more respective products using the 3D printing instruction set). In some embodiments, one or more of the recipient nodes may execute the smart contracts that wrap the digital tokens, whereby the smart contract listens for one or more triggering conditions (e.g., receiving an amount of currency equal to the transaction price of the knowledge token). Additionally or alternatively, the ledger management system 16910 may execute the smart contracts (e.g., in containers) and may record the transaction for the knowledge token to the distributed ledger.

[0940] In embodiments, the knowledge distribution system 16802 may provide or connect to a digital knowledge marketplace, whereby potential recipients may purchase knowledge tokens corresponding to respective 3D-printing instruction sets. For example, the marketplace may display items that may be 3D printed, such as airplane parts, car parts, machinery parts, other types of replacement parts, toys, medical devices, and/or the like. A potential recipient may enter into a transaction for a particular 3D printing instruction set. In embodiments, the potential recipient may select one of the items. In response, the knowledge distribution system may present the price of each token, the restrictions associated with the knowledge token (e.g., any device requirements, geographical restrictions, use limitations, and/or the like), warranties, disclaimers, indemnifications, certifications, and/or the like to the potential recipient. The potential recipient may then choose to accept the terms of the transaction (e.g., agree to buy the token). The potential recipient may then commit a defined amount of currency to the transaction. In response, the smart contract may listen for additional conditions (if so defined) before completing the transaction and/or releasing the digital knowledge. For example, the smart contract may request the potential recipient to verify that the printer requirements are met or may connect to the 3D printer to verify the requirements. If all the conditions required to complete the transaction are met, the smart contract may provide the currency to the knowledge provider (and any other licensors) and may perform any other actions, such as releasing the digital knowledge to the 3D printer (or another device), broadcasting a block to the distributed ledger verifying the transaction and/or recording the serial number in the distributed ledger. The 3D printer may receive the 3D printing instructions and may print the product in accordance with the 3D printing instruction set.

[0941] In embodiments, the knowledge distribution system 16802 may be deployed on or integrated with or within a set of infrastructure capabilities, such as cloud computing infrastructure, platform-as-a-service infrastructure, Internet of Things platform capabilities, distributed database capabilities, data management platform infrastructure, enterprise database resources (including cloud and on premises resources), and the like. In embodiments, the knowledge distribution system 16802 may use or integrate with or within various services, such as identity management services, information management services, digital rights management services, information rights management services, cryptographic services, key management services, distributed database services, and many others.

[0942] Referring to FIG. 174, in embodiments, the knowledge distribution system 16802 may provide one or more collaboration APIs 17474 for facilitating collaboration between users. The collaboration APIs may be configured to allow users to provide and share information to establish a shared set of data resources for collaboration, such as to provide a shared “ground truth” as to underlying facts, to establish a set of alternative views regarding the underlying facts (e.g., to identify where there may be disagreement as to the ground truth or the absence of information that is needed to establish shared understanding), to facilitate management of a set of scenarios with respect to which collaboration is desired, to facilitate a set of simulations relating to topics of interest for collaborators, to facilitate controlled access to shared and non-shared knowledge elements, and/or to allow users to provide, verify, and/or share information outside of enterprise firewalls. The collaboration API 17474 may be configured to allow users and/or parties to provide, receive, share, and/or verify information, such as the digital knowledge 16804, information related to the digital knowledge 16804, information related to transactions performed via the distributed ledger 16808, via one or more smart contracts 16840, via the marketplace system 17454, and the like. The APIs may be configured to allow for sharing of information privately, publicly, or a combination thereof. Information shared via the APIs, or events or transactions relating thereto, may be stored on the distributed ledger 16808 and thereby be distributed across the nodes 16916 of the distributed ledger. The users may include the knowledge providers 16806, the knowledge recipients 16818, the crowdsources 16836, the users and/or parties to the distributed ledger 16808 and/or the digital marketplace 17456, and the like.

[0943] In some embodiments, the collaboration API 17474 may include operational and/or situational knowledge that may be captured by the knowledge distribution system 16802. The collaboration API 17474 may be configured to process the situational knowledge and transmit the situational knowledge and/or interpretations of the situational knowledge to the ledger management system 16910. The ledger management system 16910 may be configured to store the situational knowledge and/or interpretations of the situational knowledge on the distributed ledger 16808. An example of situational knowledge is data regarding current condition, state, and/or location of a piece of collateral related to an instance of the digital knowledge 16804 and/or related to a smart contract 16840. Another example of situational knowledge is a state of completion of a work-in-progress that is subject to a transaction, a term of payment and/or lending triggered by completion of an item (e.g., an instance of the digital knowledge 16804) to a certain stage of completion.

[0944] In embodiments, the smart contract system 16868 may include one or more transaction frameworks 17476 configured to facilitate managing transactions via the smart contracts 16840. The transaction frameworks 17476 may include one or more data structures, routines, subroutines, and the like configured to assist in management of transactions, such as by automatically importing, exporting, sorting, configuring, handling, or otherwise processing data related to transactions handled via the knowledge distribution system 16802. The smart contract system 17068 may be configured to include one or more transaction frameworks 17476 related to billing, payments, reporting, auditing, reconciliation, and/or the like.

[0945] In embodiments, each of the transaction frameworks 17476 may be configured to facilitate management of one or more particular types of transactions. Examples of types of transactions and related data of which one or more of the transaction frameworks 17476 may be configured to facilitate management include purchase/sale, lending/leasing, rental, licensing, resource/time sharing, service contracts, maintenance/repair, warranty, guaranty, insurance, profit/revenue sharing, manufacturing (optionally tiered), resale/distribution (optionally tiered), demand aggregation, forward market/futures transactions, and conditional/contingent contracts, among others, including any of the many types describe in this disclosure and the documents incorporated herein by reference. For example, in a tiered distribution contract framework, the transaction framework 17476 may be configured to use the distributed ledger 16808 and the smart contract 16840 to allocate one or more of payments, commissions, and costs in a granular manner. In another example, in a contingent contract framework, the transaction framework 17476 may be configured to use the distributed ledger 16808 and the smart contract 16840 to manage one or more of options, futures, emergent events, and the like. Other examples of smart contract frameworks 17476 include those configured to manage commissions, incentive payments, payments for milestones (e.g., partial work, delivery partway through a supply chain, etc.), and escrows.

[0946] In embodiments, one or more of the transaction frameworks 17476 may be configured to facilitate management of the smart contracts 16840 in situations in which there are issues with performance by one or more parties to an agreement. Issues with performance may include, for example, breach of contract, failure to pay, late payment, poor performance, poor quality goods, failure to perform services, and the like. Remedies for issues that may be encoded in the transactional frameworks 17476 may include pulling functionality, loss of license, ramping down of performance, financial penalties (e.g., loss of tokens or currency) and the like.

[0947] In embodiments, the transaction framework 17476 may facilitate using the distributed ledger 16808 and the smart contract 16840 to allocate risk and liability in a granular manner. The knowledge distribution system 16802 may be configured to import sensor data from one or more sensors, such as IoT sensors. The sensor data may include single sensor data, multiple sensor data, fused sensor data (e.g., where results from two or more sensors are joined, such as by multiplexing, by computation, or the like), raw sensor data, normalized sensor data (such as to allow comparison to a scale, such as a quality scale, a condition scale, or the like), calibrated sensor data (such as to allow comparison to other sensors on an accurate basis), and others. In embodiments, the sensor data may indicate the state or condition of a physical item or its environment at a point in time or over a period of time, such as its temperature, the ambient temperature of the environment in which it is located, environmental humidity, movements of the item (such as resulting from impacts, vibration, transport, or the like), exposure to heat, exposure to radiation, exposure to chemicals (including particulates, toxins, and the like), bearing of loads, bearing of weight, exposure to stress, exposure to strain, exposure to impacts, damage (such as dents, deformations, deflections, disconnects, breaks, cracks, shatters, tears and many others), exposure to biological factors (including pathogens), extent of progressive damage (such as rust), and other factors. In embodiments, the sensor data may indicate the presence or absence of activities or workflows related to an item, such as where sensor data indicates fluid levels (e.g., oil or other lubrication, fuels, antifreeze, and other fluids, which indicate whether required maintenance, such as an oil change, has been timely performed), levels of particulates or other matter (such as dirt, grime, sand particles, and many others, which may indicate whether required cleaning has occurred), levels of rust, and many others. In various embodiments, the imported sensor data may allow the smart contract system 17068 to allocate related to performance, lack of performance, utilization, deterioration, wear-and-tear, damage, maintenance activity, or other relevant factors that may be attributed to individual parts of a tiered manufacturing system (including individual machines, equipment items, devices, component parts, or the like) to particular related parties via the transaction framework 17476. As one example among many, a series of parties in possession of an item may be allocated responsibility for depreciation, deterioration, or other reduction in its value based on their measured activities with respect to its caretaking, such as the environmental conditions in which it was stored and the presence or absence of required maintenance activities, such as fluid changes, cleaning, and the like. For example, a party that stored the item in pristine conditions at specified temperatures and replaced fluids according to a defined schedule might be assigned a moderate number of points (or other metrics), while a party that stored the item outdoors in poor conditions might be assigned a much higher number of points, in automatically allocating responsibility for the replacement of the item by a smart contract. Similarly, a party whose actions or lack of actions can be directly measured as causing damage (e.g., the item was dropped and dented while in the party's possession), may be automatically allocated responsibility for the damage. Thus, a sensor-enabled smart contract may track and allocate responsibility for conditions and activities involving a physical item across its lifetime, including among parties that share or transfer possession of the item, share use of the item, or the like. Shared use or possession over the lifetime may include situations of tiered manufacturing, such as where component parts are progressively configured into an overall system by a set of parties. In such a situation, a smart contract may use sensor data collected throughout manufacturing to determine responsibility for a failure of an item (e.g., a manufacturing defect) based on what part of the item failed and/or why an item failed (such as due to a problem in the manufacturing chain). Shared use of possession may also include “shared economy” situations, such as shared use of property (including rooms, office space, homes, apartments, real estate, vehicles, electronic devices, and many others), where a smart contract may allocate responsibility for damage, maintenance (or lack thereof), cleaning, and other factors based on sensor data collected over the lifetime of the shared item. In embodiments, the smart contract framework 17476 may also provide for inclusion of indemnity clauses and more complex causes allocating liability and/or limitation thereof (including exceptions to the same) which may include factors related to the sensor data collected over time as noted above. For example, a smart contract may limit a manufacturer's liability for defects to a period (e.g., ninety days, one year, or the like) but the smart contract may embody an exception for hidden defects (e.g., ones that were present but did not manifest during the warranty period). Sensor data may indicate whether a defect was manifested or not during the base warranty period and automatically determine whether a warranty claim asserted after the period is valid. In embodiments, such a smart contract may further allocate, and optionally execute a transfer of value, such as currency, upon determination of the ultimate responsibilities among parties, such as where one party has indemnified another for a type of liability. In embodiments, a smart contract may be configured to perform a computation and allocation of net liability among multiple parties to a contract that involves indemnification by one or more parties of another. In embodiments, such a smart contract may consume sensor data that is used to determine the extent of liability to be allocated to each party (e.g., where a party's actions or inactions may result in sensed changes of the condition of an item that may trigger greater responsibility for indemnification of others). In embodiments, such a smart contract may automatically credit or debit an account, trigger a transfer of value, or the like.

[0948] In embodiments, the transaction framework 17476 may facilitate using the distributed ledger 16808 and the smart contract 16840 to allocate payments, commissions, costs, and the like in a granular manner. The transaction framework 17476 may facilitate inclusion in the smart contract 16840 and management by the smart contract 16840 of one or more parties to a set of distribution agreements, value added reseller agreements, manufacturer agreements, sub-distributor agreements, sub-licensee agreements, payment agreements, servicing agreements, maintenance agreements, update agreements, upgrade agreements, rental agreements, resource sharing agreements, item-sharing agreements, warranty agreements, insurance agreements, lending agreements, indemnification agreements, guarantee agreements, and the like.

[0949] In embodiments, the transaction framework 17476 may facilitate management and/or execution of contingent contracts via the distributed ledger 16808 and the smart contract 16840. The contingent contracts may include clauses whereby a provision of a good, service, payment, and the like is contingent on one or more triggering events taking place. For example, admission tickets for a sporting event may be sold to a fans of a plurality of sports teams, with validity of the ticket and/or the related transaction being contingent on the team of which the fan is a fan of being eligible to participate in the sporting event. In embodiments, the transaction framework 17476 may have one or more data collection facilities, such as web crawlers, spiders, clustering systems, sensor data collection systems, services, APIs, or the like that collect data indicating the presence or absence of a triggering condition for the contingent contract, such as, in the example of an event-triggered contract, a system that searches for the existence of an event involving a particular performer, player, or team (among others) in an event, and the smart contract may automatically handle the allocation of rights that are triggered by the occurrence of the event. For example, where the right to attend the Super Bowl (or other game) is triggered by a particular team's presence in the game (or in similar examples where an attendance right is triggered by emergence or realization of a desired instance of a type of event), the smart contract transaction framework 17476 may automatically determine (such as via a search engine or other capability operating on news data sources) the triggering event (e.g., that a given team won a conference championship game resulting in becoming a participant in the league championship, or other similar example, or the a particular performer or group has announced a date and place for a concert tour or other performance). Further, the smart contract transaction framework 17476 may trigger a set of actions upon the automatic determination of the instance of the triggering event, such as transferring ticket rights to parties for whom the rights vest upon the event, informing other parties that their contracts are closed (i.e., that there remains no possibility of the event occurring under the defined conditions for those parties, such as holders of rights related to teams that did not make it to the championship games), allocating consolation prizes to losing parties, triggering other smart contracts (such as smart contracts that allocate provision of related goods and services, such as travel and transportation services (e.g., automatically securing airline tickets based on the location of the ticket holder and the location of the game, automatically securing a rental car, and the like), hospitality services (e.g., automatically securing a hotel reservation in the city of the game for a fan that does not live in the city, automatically securing reservations for meals, and the like).

[0950] In embodiments a smart contract for an event embodying automatic detection of triggers for contingencies related to the emergence or realization of an instance of an event, and embodying automatic allocation of rights (such as attendance rights, travel and hospitality rights, and the like) based on the triggers may include, take input from, use, connect with, link to, and/or integrate with a set of intelligent agents, such as using any of the artificial intelligence, machine learning, deep learning, and other techniques described herein or in the documents incorporated by reference herein, including robotic process automation trained and/or supervised by human experts. The set of intelligent agents may include ones that are trained, for example, (a) to determine and manage a set of possible events (such as what teams could be involved in what games at what locations and what points in time across a set of leagues, sports, locations and the like), including expanding or pruning the list based on game results and other factors (e.g., where teams fall out of contention for playoff spots, rendering previously possible games impossible); (b) to forecast probabilities of likelihood of instances of event based on current and historical data (e.g., the likelihood that a game will occur between two particular teams, the likelihood that a performer will hold a concert at a given location (or within a geofence) during a date range, or the like); (c) to generate and configure a smart contract that governs allocation of rights subject to contingencies, including setting parameters for the launch (e.g., by auction, by lottery, by “drop” or the like) of a marketplace or other venue by which parties may enter into the smart contract for the contingent event; (d) to forecast demand for an instance of a contract (e.g., demand for Final Four tickets in New Orleans if University of Kentucky is playing; or demand for Elton John tickets in Paris during Q3 of a given year; among many others) based on a given type of contingent event, such as based on historical demand for similar events (optionally using various clustering and similarity techniques operating on historical attendance data, secondary market ticket data and other data sets), expressed demand (including demand expressed in demand aggregation contracts, such as where some users have purchased options for the event or similar events), historical data on contingent smart contracts for similar items or services, secondary indicators of demand (such as search engine metrics, social media metrics and the like) and many others; (e) to set initial pricing for events, including based on the forecast demand and historical pricing data for underlying events (e.g., ticket prices, secondary market prices and activity levels, time required to sell out tickets and the like) and for other contingent event contracts; (f) to manage allocation of smart contracts, such as in tranches of release; (g) to collect and manage party-specific factors and user profiles, such as understanding location factors (e.g., place of residence, place of work), affinity and loyalty factors (favorite teams, favorite restaurants, favorite airlines, favorite hotel chains, favorite types of food, and others), and others; (h) to manage matching of party-specific factors and user profiles to contingent events (such as to find and present smart contract opportunities that fit a user's profile, such as ones involving possibilities of attending events with a favorite team, player or performer involved); and (i) to manage discovery and presentation of, and configuration of parameters for, smart contracts that embody other goods and services that may be paired with a contingent event smart contract (such as automatically finding and matching an appropriate airline flight, train reservation, bus ticket or the like and configuring a contingent smart contract for the same between the transportation provider and the prospective event ticket holder; automatically finding and matching an appropriate hotel reservation and configuration a smart contract hotel reservation between the prospective ticket holder and the hotel provider, or creating similar contingent smart contracts among providers and prospective ticket holders for other travel, accommodations and hospitality packages, such as restaurant reservations, rental cars, and many others); among others. Thus, the set of AI-enabled intelligent agents may provide automation of various capabilities for enabling the creation, hosting, provisioning and resolution of a marketplace for contingent event smart contracts.

[0951] In embodiments, the transaction framework 17476 may facilitate demand aggregation via the distributed ledger 16808 and the smart contract 16840. The transaction framework 17476 may aggregate demand for one or more products and/or services accumulated via analytics, commitments, options, or any other suitable source. Upon accumulation of demand, such as by a demand metric meeting a demand threshold, the smart contract 16840 may trigger to begin design, manufacturing, distribution, and/or the like of the related product and/or service. In embodiments, a set of intelligent agents, using various AI capabilities noted above, may be configured facilitate demand aggregation, including agents that may (a) forecast demand for an instance or type of product, such as based on various secondary indicators of demand, such as search engine metrics, chat activity (e.g., in relevant forums), event information (such as attendance at relevant industry events), social media information (such as numbers of posts), product sales, historical selling times (e.g., time from product launch to selling out of a product), and many others; (b) aggregate demand, such as by configuring a set of smart contracts by which parties commit to purchasing an item upon its instantiation, such as during a given time window within a given price range and determining a total aggregate demand; (c) projects the cost a demand-aggregated offering, such as based on a model (optionally itself managed and/or created by an intelligent agent) that indicates the projected cost of an item at various volumes of production, optionally based on a projection or model of the likely component parts and cost thereof, as well as other costs, such as assembly, transportation, financing, warranty and the like; (d) projects the price of the demand-aggregated item at various volumes of offering, such as based on the forecast demand and historical pricing; (e) forecasts the profit likely to be associated with offering the demand-aggregated item at various volumes of production and/or at various points in time, such as using the forecasted demand, cost and pricing information; and the others. Thus a demand aggregation marketplace may be enabled and/or supported by automation capabilities provided by the set of intelligent agents.

[0952] In embodiments, the smart contract system 16868 may be configured to import patterns of implementation and/or systems building knowledge into one or more of the transaction frameworks 17476. The patterns of implementation and/or systems building knowledge may include, for example, knowledge systems, workflow, product management, support calls, human interaction, social media, redundant systems, data storage, and implementation patterns at scale. The smart contract system 16868 may automatically configure the smart contracts 16840 to implement the imported patterns of implementation and/or systems building knowledge. The imported patterns of implementation and/or systems building knowledge may be stored in the datastore 16858.

[0953] In some embodiments, the knowledge distribution system 16802 may include an artificial intelligence (AI) system 17480 in communication with the ledger management system 16910 and/or the smart contract system 17468 and configured to perform AI-related tasks according to a machine learned model. The AI system 17480 may be configured to perform actions with respect to the knowledge distribution system 16802 to manage the digital knowledge 16804. The AI system 17480 may have permission and access rights to manage, use, and interact with systems of the knowledge distribution system 16802 similarly to a user.

[0954] In embodiments, the AI system 17480 may be trained by one or more transaction experts to develop the machine learned model by which the AI system 17480 operates to perform AI-related functions. Examples of transaction experts that may at least partially train the AI system 17480 include agents, brokers, traders, attorneys, financial advisors, auditors, accountants, bankers, marketers, advertisers, exchange operators, buyers, sellers, distributors, and manufacturers/developers. The AI system 17480 may be trained by any suitable machine learning algorithm, and by any suitable training data set. Examples of machine learning algorithms include supervised learning, unsupervised learning, semi-supervised learning, reinforcement learning, self-learning, feature learning, sparse dictionary learning, anomaly detection, robot learning, and association rules. The machine learned model may be any suitable type of model, such as an artificial neural network, a decision tree, a support vector machine, a regression analysis model, a Bayesian network, or a genetic algorithm.

[0955] In embodiments, the AI system 17480 may be trained to identify opportunities for smart contracts. Examples of opportunities include exchange opportunities and arbitrage opportunities.

[0956] In embodiments, the AI system 17480 may be trained to configure market contract terms and conditions.

[0957] In embodiments, the AI system 17480 may be trained to monitor market conditions.

[0958] In embodiments, the AI system 17480 may be trained to monitor and manage contract terms and conditions. Monitoring and managing contract terms and conditions may include monitoring goods and/or observing services.

[0959] In embodiments, the AI system 17480 may be trained to monitor and manage transaction processes. For example, the AI system 17480 may be trained to recognize release of funds from an escrow account.

[0960] In embodiments, the AI system 17480 may be trained to monitor counter-party information. Examples of counter-party information include solvency, and status of performance, and quality of performance.

[0961] In embodiments, the AI system 17480 may be trained to identify transaction opportunities. Examples of transaction opportunities include instances of exchange and arbitration opportunities.

[0962] In embodiments, the AI system 17480 may be trained to negotiate on behalf of parties to transactions involving digital knowledge.

[0963] In embodiments, the AI system 17480 may be configured to configure and execute auctions. The AI system 17480 may perform auction-related actions such as selecting a type of auction suitable for a transaction and/or settings rules and parameters for an auction to be at least partially carried out on the distributed ledger 16808. The auctions selected may be any suitable type of auction for being at least partially carried out on the distributed ledger 16808, such as a Dutch auction or a reverse auction.

[0964] In embodiments, the AI system 17480 may be configured to distribute currency tokens and/or tokenized digital knowledge 16804.

[0965] In embodiments, the AI system 17480 may be configured to configure and manage exchange of the digital knowledge 16804 across different marketplaces and exchanges. The AI system 17480 may set exchange rates between native currencies of exchanges and/or may tokenize the digital knowledge 16804 and set exchange rates between instances of the tokenized digital knowledge 16804.

[0966] In embodiments, the AI system 17480 may be configured to establish, monitor, and/or negotiate payment, leasing, and/or lending options related to management of the digital knowledge 16804. The lending options may include payment plans, trust-less scenarios, and/or non-trust-less scenarios.

[0967] In embodiments, the knowledge distribution system 16802 may include a robotic process automation (RPA) system 17482 in communication with the AI system 17480 and configured to improve one or more functions of the AI system 17480. The RPA system 17482 may use robotic process automation techniques to allow the AI system 17480 to interface with one or more of systems of the knowledge distribution system 16802, the distributed ledger 16808, and systems, marketplaces, and/or exchanges and the like external to the knowledge distribution system 16802 by performing actions in one or more graphical user interfaces of the knowledge distribution system 16802, the distributed ledger 16808, and systems, marketplaces, and/or exchanges and the like external to the knowledge distribution system 16802.

[0968] In embodiments, the knowledge distribution system 16802 may include a rights management system 17484 configured to manage rights of users apart from an exchange or marketplace.

[0969] In embodiments, the knowledge distribution system 16802 may include a market management system 17486 configured to establish a market for selling and/or reselling currency tokens and/or instances of the digital knowledge 16804. The market may be configured such that wrapped and/or tokenized instances of the digital knowledge 16804 may be resold without being unwrapped. The market may be established and configured as a spot market, a secondary market, and/or a futures/derivatives market. Futures and derivatives resold on the futures/derivatives market may include options, futures, and other derivatives. The knowledge distribution system 16802 may establish and/or monitor secondary markets, ancillary markets, forward markets, and the like in addition to resale markets for digital currency and instances of the digital knowledge 16804.

[0970] In embodiments, the market management system 17486 may be configured to monitor metrics of users, buyers, and/or sellers participating in one or more markets established by the market management system 17486. The metrics may include, for example, metrics indicating how, where, or how often an instance of the digital knowledge 16804 is used. The metrics may alternatively or additionally include metrics regarding creation of the digital knowledge 16804, duration during which a given type of digital knowledge 16804 remains relevant or valuable, and/or metrics regarding transaction patterns. Examples of transaction patterns include size of transaction, transaction pricing and trends thereof, profile information of buyers, sellers, consumers, users, and/or creators of the digital knowledge 16804, and the like. Another metric additionally or alternatively monitored by the markets system may include metrics indicative of gaming and/or misconduct by users of the market.

[0971] In embodiments, the digital knowledge 16804 may include instruction sets such as: process steps in food production or food preparation instructions (e.g., for industrial food preparation), additive manufacturing/3D printing instructions, instruction sets for surgical robots and human/robot interfaces generally, crystal fabrication system instructions, crystal fabrication process instructions, polymer production process instructions, chemical synthesis process instructions, coating process instructions, semiconductor fabrication process instructions, silicon etching instructions, doping instructions, chemical vapor deposition instructions, biological production process instructions, smart contract instructions, and/or instructions for establishing, updating, and/or verifying a chain of work, possession, title, and the like.

[0972] In embodiments, the digital knowledge 16804 may include code, software, and/or logic, such as: algorithmic logic, instruction sets for use in an application, executable algorithmic logic, computer programs, firmware programs, instruction sets for field-programmable gate arrays, instruction sets for complex programmable logic devices, serverless code logic, cryptography logic, AI logic, AI definitions, machine learning logic and/or definitions, and/or quantum algorithms.

[0973] In embodiments, the digital knowledge 16804 may include digital documents, such as digital documents relating to: part schematics, production records (e.g., for aircraft parts, spaceship parts, nuclear engine parts, and the any/or any other suitable part), automobile parts, airplane parts, pieces of furniture or components thereof, replacement parts for industrial robots or machines, trade secrets, and/or other intellectual property such as know-how, patented material, and/or works of authorship.

[0974] In embodiments, the digital knowledge 16804 may include 3D printing schematics, such as schematics for printing medical devices, automobile parts, airplane parts, furniture, furniture components, and/or replacement parts for industrial robots or machines.

[0975] In embodiments, the digital knowledge 16804 may include personal and/or professional knowledge relating to one or more organizations and/or individuals. The personal and/or professional knowledge may include: professions resumes, professional history tracking information, records of professional credentials, academic degrees, professional certificates, verifications of professional positions held by one or more individuals, professional feedback, verification of work performed by one or more individuals and/or parties, personal financial history, business financial history, and/or personal life achievements as verified by one or more third parties.

[0976] In some embodiments, the digital knowledge 16804 may include data sets and/or sensor information defining and/or population a set of digital twins. The digital twins may embody one or more instances of the digital knowledge 16804 relating to one or more physical entities. The one or more instances of the digital knowledge 16804 may include knowledge related to one or more of configurations, operating modes, instructions sets, capabilities, defects, performance parameters, and the like.

[0977] In embodiments, the knowledge distribution system 16802 may be configured to transmit instances of the digital knowledge 16804 to and/or receive instances of the digital knowledge 16804 from one or more external knowledge exchanges and/or knowledge databases. The external knowledge exchanges and/or knowledge databases include domain-specific exchanges, geography-specific exchanges, and the like. The knowledge distribution system 16802 may be configured to facilitate exchange of valuable or sensitive instances of the digital knowledge 16804 related to the subject matter of the external knowledge exchange and/or knowledge database. Additional or alternative examples of external knowledge exchanges and/or databases may include stock exchanges, commodities exchanges, derivative exchanges, futures exchanges, advertising exchanges, energy exchanges, renewable energy credits exchanges, cryptocurrency exchanges, bonds exchanges, currency exchanges, precious metals exchanges, petroleum exchanges, goods exchanges, services exchanges, or any other suitable type of exchange and/or database. The knowledge distribution system 16802 may integrate and/or communicate with interfaces of external knowledge exchanges and/or databases, such as APIs connectors, ports, brokers. The integration and/or communication may be facilitated via one or more of extraction, transformation, and loading (ETL) technologies, smart contracts, wrappers, tokens, containers, and the like.

[0978] In embodiments, the knowledge distribution system 16802 may be deployed on and/or integrated with or within a set of infrastructure capabilities. Examples of infrastructure capabilities include cloud computing infrastructure, platform-as-a-service infrastructure, Internet of Things platform capabilities, distributed database capabilities, data management platform infrastructure, enterprise database resources (including cloud and on premises resources), and the like.

[0979] In embodiments, the knowledge distribution system 16802 may use and/or integrate with or within various services. Examples of services with which or within which the knowledge distribution system 16802 may integrate include identify management services, information management services, digital rights management services, information rights management services, cryptographic services, key management services, distributed databased services, and the like.

[0980] Referring to FIG. 175, knowledge distribution system 17500 for controlling rights related to digital knowledge is depicted. The knowledge distribution system 17500 may include an input system 17802, a tokenization system 17812, a ledger management system 17818, and a smart contract system 17824. In some embodiments the knowledge distribution system 17500 may further include a smart contract generator 17858, an execution system 17510, a reporting system 17514, and a crowdsourcing module 17516.

[0981] The input system 17802 receives digital knowledge 17808 from a user 17502 and the tokenization system 17812 may tokenize the received digital knowledge 17808 resulting in a token/tokenized digital knowledge 17814 that is manipulable as a token.

[0982] The ledger management system 17818 creates and manages one or more distributed ledgers 17820, where a distributed ledger may include a plurality of cryptographically linked blocks distributed over a plurality of nodes of a network 17848 as described elsewhere herein. The ledger management system 17818 may then store a smart contract(s) 17822 and the tokenized digital knowledge 17814 in a distributed ledger 17820 (FIG. 188).

[0983] A smart contract system 17824 may implement and manage a smart contract 17822 which may include the tokenized digital knowledge 17814, a triggering event 17828, and a smart contract action 17830. Upon occurrence of a triggering event 17828, the smart contract system 17824 may perform the smart contract action 17830. The smart contract system 17824 may process commitment(s) 17832 of parties 17532 to the smart contract 17822. The smart contract system 17824 may manage rights 17540 including control rights 17840 over the tokenized digital knowledge 17814 and access rights 17842 regarding who can view, edit, access, or use the tokenized digital knowledge 17814. The smart contract 17822 further comprises a smart contract wrapper 17503. The knowledge distribution system 17500 further comprises an account management system 17505, a user interface system 17507, and a marketplace system 17509.

[0984] As depicted in FIG. 180, the tokenized digital knowledge 17814 may include executable algorithmic logic 18002, a 3D printer instruction set 18004, an instruction set for a coating process 18008, an instructions set for a semiconductor fabrication process 18010, a firmware program 18012, an instruction set for a field-programmable gate array (FPGA) 18014, serverless code logic 18018, an instructions set for a crystal fabrication system 18020, an instruction set for a food preparation process 18022, an instruction set for a polymer production process 18024, an instruction set for a biological production process 18030, a data set for a digital twin 18032, an instruction set to perform a trade secret 18034, intellectual property 18038, an instruction set 18040, or the like. In embodiments, where the tokenized digital knowledge 17814 includes intellectual property 18038, the smart contract system 17824 may embed intellectual property licensing term(s) 18802 for the intellectual property 18038 in the distributed ledger and, in response to a triggering event 17828, update the access rights 17842 to provide access to the intellectual property 18038 or process a commitment 17832 of a party 17532 to the smart contract 17822 and the corresponding intellectual property licensing term(s) 18802.

[0985] In embodiments, the smart contract 17822 may include a smart contract wrapper 17503 which may add intellectual property 18038 to a stack of intellectual property which may be on the distributed ledger 17820 and commitment 17832 by one or more parties 17532 to: an apportionment of royalties for the added intellectual property 18804. The smart contract wrapper 17503 may record, in a distributed ledger, a commitment 17832 by one or more parties 17532 to: an apportionment of royalties for the aggregate stack of intellectual property 18804, or a contract term 18810.

[0986] In embodiments the ledger management system 17818 may include a logging system 17512 to store logged data in the distributed ledger 17820. In embodiments, the digital knowledge 17808 may be an instruction set and the ledger management system 17818 may provide provable access to the instruction set and execute the instruction set on a system. Providing provable access may include logging or recording data in at least one of the plurality of cryptographically linked blocks. Provable access may include: aggregating views of a trade secret into a chain that records which knowledge recipients have viewed the trade secret 18814 on the distributed ledger; recording a party who has contributed to the digital knowledge, by logging data related to the party, logging access transactions to an instance of digital knowledge 18830; recording, a source of an instance of the digital information by storing data related to the source,

[0987] The knowledge distribution system 17500 may include a reporting system 17514 to report analytic data or an analytic response(s) 18834 based on a plurality of operations performed on the distributed ledger, or on the tokenized digital knowledge. The reporting system 17514 may also analyzed the tokenized digital knowledge 17814 and report the analytic result 18832.

[0988] In an embodiment, the smart contract system 17824 may aggregate a set of instructions into an instructions set 18040, add an instruction to pre-existing instructions set to provide a modified instruction set 18040, manage allocation of instruction subsets 18042 to the distributed ledger, manage access to the instruction to the instruction sets based on access rights 17842, or the like.

[0989] In embodiments the ledger management system 17818 may include a crowdsourcing module 17516 to obtain crowdsourced information 18602 which may then be stored in the distributed ledger. crowdsourced information 18602 may include: a review of an instance of the digital knowledge 18824, a signature related to an instance of crowdsourced information 18826, a verification of an instance of the digital knowledge 18828, and the like.

[0990] In embodiments, the knowledge distribution system 17500 may include a private network system to enable a private network and allow authorized parties to establish a cryptography-based consensus requirement for verification of new cryptographically linked blocks to be added to the plurality of cryptographically linked block. In embodiments, the ledger management may establish cryptocurrency tokens designed to be tradeable among users of the distributed ledger.

[0991] In embodiments, the knowledge distribution system 17500 may include an account management system 17505 to facilitate creation and management of a plurality of user accounts 19094 corresponding to a plurality of users 17502, 19004 of a knowledge distribution system 17500. The user account data may be stored on the distributed ledger.

[0992] In embodiments, the knowledge distribution system may include a user interface system 17507, 19074 to present a user interface 19093 to a user(s) 17502, 19004 which enables the user to view data related to an instance of the digital knowledge.

[0993] In embodiments, the knowledge distribution system may include a marketplace system 17509 to establish and maintain a digital marketplace 19090 and visually present data corresponding to an instance of the digital knowledge to a user of the knowledge distribution system.

[0994] In embodiments, the knowledge distribution system may include a datastore in communication with the distributed ledger where the datastore may include a knowledge datastore configured to store data related to the digital knowledge, client datastore is configured to store data related to a plurality of users of the knowledge distribution system, smart contract datastore is configured to store data related to the smart contract, and the like.